I had a hard time following some of this but I’ll try to clarify. From: Anthony Nadalin <[email protected]<mailto:[email protected]>> Date: Wed, 20 Apr 2011 16:05:02 -0700 To: Dick Hardt <[email protected]<mailto:[email protected]>>, Eran Hammer-lahav <[email protected]<mailto:[email protected]>> Cc: OAuth WG <[email protected]<mailto:[email protected]>> Subject: RE: [OAUTH-WG] Revised Section 3
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 This is the only requirement driving this open issue. The new proposed text does not change any other normative part of v2. One additional note is that this doesn't mean the client has to use two assertions, but that there are two assertions and each serves a different purpose (authenticate the client, denote the resource owner authorization). the 2nd part is about authentication with id and secret I assume you are referring to the client password credentials section? and the 3rd part is about authentication with assertion. Not sure what you mean here, but if you mean authenticating a client using an assertion, that's already covered by the first part. If you mean using an assertion as the resource owner authorization, that's covered by 4.5 and the 'assertion' extension parameter. 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). The replacement only adds the assertion part. The rest is already in v2. The new text includes some other useful prose, but that's purely editorial. 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. True, in that it bring's Yaron's proposal back practically unchanged (normative language wise). 4. So with the current text in section 3 and section 4.5 we can’t do 2 assertions True to the extent it doesn't specify it. since it uses grant_type=assertion. Nothing uses that. The 'assertion' grant type has been replaced with a more generic extension mechanism. Basically, we combined the 'grant_type' and 'assertion_type' parameters into a single extension point. So what was previously sent like this: grant_type=assertion&assertion_type=http://some.assertion.type.uri Is now send as: grant_type=http://some.assertion.type.uri This change was made in –12 with WG consensus. At the time, the 'assertion' parameter was relocated to the SAML draft. So I’m not sure that an extension based upon the current draft would help solve the problem. An extension grant type (which is the mechanism used by the SAML draft) will not be suitable here. This use care requires defining a new way to authentication HTTP requests (traditional client authentication) using assertions, similar to how Basic is used to authenticate requests using a username and password. 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? Adding 4.4.3-like text to 4.5 does not have *any* normative implications. Section 4.5 provides an extension point to the token endpoint. Section 4.4.3 merely states the obvious in how responses to token requests are handled. Adding it will be done purely for clarity. So I agree that the current specification doesn't address the use case of using an assertion to authenticate the client. Beyond that we disagree on everything else related to how to address it. EHL 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
