Agree, good summary Brian C I still haven't seen the use case for refresh tokens with assertion flow! We can control that server side but it is easier to just implement the spec as is.
It seems insecure granting a refresh token with potentially longer life than the assertion. Do people intent on using refresh tokens with assertions intend to link the two? Regards Mark McGloin On 08/07/2010 23:49 Brian Eaton 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. Cheers, Brian On Thu, Jul 8, 2010 at 3:34 PM, Chuck Mortimore <[email protected]> wrote: That sounds like a very accurate description to me. -cmort On 7/8/10 3:27 PM, "Brian Campbell" <[email protected]> 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
