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 <dick.ha...@gmail.com> > Date: Tue, 19 Apr 2011 13:25:15 -0700 > To: Eran Hammer-lahav <e...@hueniverse.com> > Cc: "record...@gmail.com" <record...@gmail.com>, oauth <oauth@ietf.org> > 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:dick.ha...@gmail.com] >>>> 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:dick.ha...@gmail.com] >>>>>> 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
