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
