On 7/8/10 3:49 PM, "Brian Eaton" <bea...@google.com> wrote: 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. I really wouldn't characterize my use-case as disambiguating the purpose. I really need it to look up the "client" configuration. In my particular use-case ( customers posting SAML assertions with subjects that are only unique when namespaced to a particular IDP ), the client is really defined as a SAML IDP, and I'd be looking up it's metadata based upon the client_id. This seems appropriate to me. -cmort 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 <http://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 <http://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 <http://oauth-boun...@ietf.org> >> [mailto: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 <http://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 <http://OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <http://OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org <http://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
