To directly address the 3 issues in Brian C's summary: 1) I haven't seen any strong use-cases for the issuing of refresh tokens either, but we do find the SHOULD NOT language to be strong enough.
2) We support client_id being optional, and will have need for it. No support for mandatory, nor do we have any intent to use client_secret with this flow. 3) Yaron's suggestion of adding assertion as an authentication type does have some merit. It basically would allow an alternate client authentication mechanism beyond the client_secret, allowing for a variety of strategies that would keep the secret off the wire. One approach would be to: * Add optional language to section 2 as Yaron has suggested. Personally I would stick with name/value definitions of "assertion_format" and "assertion" parameters as defined in 4.1.3 These could be used as an alternative for client authentication in any request that normally used client_secret. For instance, you could send a grant_type=authorization-code and include an assertion to identify the client, rather than the shared secret. * Change the authorization grant_type to make client_id optional (already planned), and simply reference assertion & assertion_format from section 2 as mandatory. This seems like it would meet the goals of the folks that want to do 2-legged oauth with assertions, by leaving the fundamentals of section 4.1.3 in place, as well as expand the capabilities for assertions to be used as authentication, which is what Yaron is asking for. -cmort On 7/9/10 1:49 AM, "Mark Mcgloin" <[email protected]> wrote: 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
