So here is what I currently understand, I'm sure that I have some of this wrong;
1. At the Prague meeting the general issue of Client Credentials removal from document was brought up, Thomas took the action item from the meeting to redraft the section that was removed. Thomas provided that. What Thomas provided is a replacement for the current section 3 in the latest draft. 2. As Eran points out there are several parts to this issue, 1st issue is the thread going back to Yaron's text proposal ( http://www.ietf.org/mail-archive/web/oauth/current/msg03363.html ) which was added and then removed (which were both done w/o consensus) which is authenticating with a access token request with two assertions, one from the client and one from the resource owner, the 2nd part is about authentication with id and secret and the 3rd part is about authentication with assertion. 3. The replacement Section 3 introduces the notion client identity and authentication and provides a means to specify a client identity and secret used for authentication and also provided is a means for client authentication using assertions (such as SAML). I believe the way the replacement section 3 is worded it would solve the issue that Yaron was trying to solve and a extension could be posible. 4. So with the current text in section 3 and section 4.5 we can't do 2 assertions since it uses grant_type=assertion. So I'm not sure that an extension based upon the current draft would help solve the problem. So a possible issue would be if you added something like 4.4.3 to 4.5 the extension would have to conform to this, do we expect all extensions to define this in the way they want? From: Dick Hardt [mailto:[email protected]] Sent: Tuesday, April 19, 2011 2:06 PM To: Eran Hammer-Lahav; Anthony Nadalin Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 Resolves *my* confusion. :) Tony: apologies if you covered this in earlier posts, but if 4.5 does not solve your use case, would you clarify what else is needed? Are you unhappy that it is labeled an extension? -- Dick On 2011-04-19, at 2:00 PM, Eran Hammer-Lahav wrote: So your suggestions is to add something like 4.4.3 to 4.5? That sounds like a good idea. Would that resolve the potential confusion here? EHL From: Dick Hardt <[email protected]<mailto:[email protected]>> Date: Tue, 19 Apr 2011 13:25:15 -0700 To: Eran Hammer-lahav <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, oauth <[email protected]<mailto:[email protected]>> Subject: Re: [OAUTH-WG] Revised Section 3 Thanks for clarifying. Given how you have broken out Section 3 from the rest of the flow, I missed 4.5. It is not clear in 4.5 that an access token is returned since in the previous sections, there is a separate request and response section. What is the response supposed to look like when using an access token? Some of the confusion here may be that 4.5 is not as complete as the other sections. -- Dick On 2011-04-19, at 12:27 PM, Eran Hammer-Lahav wrote: Yes, you are confused... WRAP section 5.2 defines an assertion authorization grant type which is provided in OAuth 2.0 via two parts: 1. v2 extensible grant types [1], which provides the wrap_assertion_format parameter functionality. You simply provide a URI to identify the assertion format and include it using the grant_type parameter. No additional parameters needed. 2. SAML bearer assertion grant type document [2] which provides the wrap_assertion parameter functionality via the assertion parameter. The assertion parameter is defined in the context of the SAML extension, but is registered as a general purpose parameter and available for any future assertion grant types if they so desire. This thread (and open issue) is about a new (to WRAP and OAuth 2.0 pre -11) client authentication method using assertions. It can be combined with the WRAP functionality described above to produce requests with two separate assertions (in the same request). The two functionalities has nothing to do with one another except that both use assertions as each assertions serves a completely different purpose (one for client authentication, and the other for access authorization). Therefore, this is new functionality that was never discussed or suggested before Yaron Goland proposal was submitted and added to -11 and later removed in -12. And to prevent a broken record reply I'll add: both actions, taken by me, were done without working group consensus. So while adding and removing the section between -11 and -12 was not proper IETF editorial process, the end result is nevertheless the same - the section is out of the document pending working group consensus for inclusion. EHL [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.5 [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03 -----Original Message----- From: Dick Hardt [mailto:[email protected]] Sent: Tuesday, April 19, 2011 11:59 AM To: Eran Hammer-Lahav Cc: David Recordon; oauth Subject: Re: [OAUTH-WG] Revised Section 3 On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote: -----Original Message----- From: Dick Hardt [mailto:[email protected]] Sent: Tuesday, April 19, 2011 11:37 AM The feature described was in OAuth-WRAP which was a basis for OAuth 2.0. Can you please point me to where this feature was in WRAP? I can't find it. http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2 ... or am I confused about what we are talking about changing in Section 3?
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
