Nice summary, thanks Brian! I think there is a third issue as well, i.e. what the use case for client_id actually is.
I think Chuck's use case has client_id used to disambiguate the purpose of the SAML assertion. We have a similar use case, both for SAML assertions and three-legged OAuth approvals, but I don't think overloading client_id for that is wise. Cheers, Brian On Thu, Jul 8, 2010 at 3:34 PM, Chuck Mortimore <cmortim...@salesforce.com>wrote: > That sounds like a very accurate description to me. > > -cmort > > > > On 7/8/10 3:27 PM, "Brian Campbell" <bcampb...@pingidentity.com> wrote: > > Maybe I'm the only one having a hard time following this thread but I > suspect I'm not alone. I'm going to try and just summarize the > issues - mostly for my own edification but hopefully this may help > others too. Please let me know if I'm off base. > > The thread originally started with a discussion of the assertion grant > type as it's now called in -09 section 4.1.3 @ > http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 and > there seemed to be two points of contention specifically about it: > > 1) Should returning a refresh token be allowed? Currently the text > in that section says, "The authorization server SHOULD NOT issue a > refresh token." Some folks feel that is sufficient but some feel it > should be a MUST NOT. > > 2) Should client authentication be required/optional/forbidden when > requesting an access token via an assertion grant type. The text in > -09 makes it sound like it might be mandatory (because of text in > http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4 maybe?). > No one thinks mandatory is a good idea. Eran indicated that the > intent was for it to be optional and -10 would reflect that. Some > people feel that client authentication in the assertion grant type is > necessary/confusing and should explicitly forbidden rather than just > optional. > > > More recently the thread has turned to a discussion of client > authentication and if/how the spec should allow for clients to > authenticate themselves to the token endpoint using means other than > the client_secret. Section 2 > http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2 leaves the > means of client authentication pretty open, it seems, but then only > provides normative guidance for "Basic Client Credentials" in section > 2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2.1 > > I believe that Yaron is auguring for a something that might become a > section 2.2 called "Assertion Client Credentials." But this is not > related to the assertion grant type (especially if client > authentication is forbidden from that grant type request). > > > How's my characterization of this? If it's accurate, I think there's > value in realizing that there are two pretty distinct issues in > question here and I feel like some of the conversations around > "assertions" have been confused by mixing the two. I'm not, at this > point, arguing the merits of anything - just first trying to make sure > we are arguing about the same things. > > -Brian Campbell > > On Thu, Jul 8, 2010 at 1:32 PM, Yaron Goland <yar...@microsoft.com> wrote: > > Here is what I think happened. > > > > In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format > arguments were used to allow clients to authenticate themselves to token > endpoints in two legged OAuth scenarios. > > > > In OAuth 2.0 two legged OAuth as a separate definition was removed and > instead merged into three legged OAuth (something that I think is a > feature). But in making this transition the original wrap_assertion and > wrap_assertion_format arguments got turned into assertion_type and > assertion. > > > > But (and this part is tricky so please read carefully) assertion_type and > assertion were part of the grant_type structure which was not used for AuthN > (the way client_id/client_secret are) but rather for AuthZ (like refresh > tokens). > > > > Having assertion/assertion_type was still a very good improvement in the > protocol since we have plenty of real world scenarios where we need to use > assertions for AuthZ but the change left a big hole - how do use an > assertion for AuthN? > > > > That's where the client_assertion/client_assertion_type come in. > > > > So the whole confusion really seems to have come about because OAuth in > doing a good thing (unifying 2 and 3 legged patterns) ended up moving > assertions from AuthN to AuthZ, which was actually a new (and useful) > feature but as a consequence created a hole that didn't exist with WRAP when > dealing with AuthN. > > > > So by putting in client_assertion/client_assertion_type and keeping > assertion/assertion_type we get the best of all worlds. We can now use > assertions for both AuthN and AuthZ. > > > > Yaron > > > >> -----Original Message----- > >> From: oauth-boun...@ietf.org > >> [mailto:oauth-boun...@ietf.org<oauth-boun...@ietf.org>] > On Behalf > >> Of Brian Eaton > >> Sent: Wednesday, July 07, 2010 2:03 PM > >> To: Eran Hammer-Lahav > >> Cc: Hannes Tschofenig; OAuth WG > >> Subject: Re: [OAUTH-WG] assertion profile changes > >> > >> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav > >> <e...@hueniverse.com> wrote: > >> > It is pretty much the same as originally proposed. Any recent changes > >> > are an oversight, not any intentional change. Since it was proposed, > >> > the only change made (with full consensus) was to allow client > >> > authentication as an optional request parameter, as well as allow a > >> > refresh token as an optional response parameter. > >> > >> Can you point me to the e-mail threads that reached consensus on using > >> client authentication? > >> > >> Can you point me to the e-mail threads that reached consensus on > returning > >> a refresh token? > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
