Re: [OAUTH-WG] Simpilfying use of assertions when requesting an access token

While making the spec somewhat shorter, it doesn't make it more readable or easier to implement. Getting rid of the assertion grant type and sub type parameter makes that part simpler and makes extensions more intuitive. I have looked into most abstraction ideas and have rules most of them out because they hurt the readability of the spec, even if they make it more consistent.

In -11 I am moving half way back to separate profiles for each flow.

EHL

> -----Original Message-----
> From: David Waite [mailto:david@alkaline-solutions.com]
> Sent: Friday, September 10, 2010 12:37 AM
> To: OAuth WG (oauth@ietf.org)
> Cc: Eran Hammer-Lahav
> Subject: Re: [OAUTH-WG] Simpilfying use of assertions when requesting an
> access token
> 
> I think combining the grant_type and assertion_type together is a great idea.
> However, I have recently been wondering if it would be a good idea to unify
> all the access grants to use the same parameters.
> 
> For instance, you could have the parameters:
> 
> 	grant_type - the type of access grant (of course)
> 	grant_qualifier - an identifier or URI associated with the grant
> 	grant_value - the data (such as an opaque or secret value) used for a
> particular type of access grant
> 
> So for the grant types mentioned below, you would have:
> 
> 	password:
> 		a grant_qualifier of the user identifier, and a grant_value of
> their password
> 
> 	client_credentials:
> 		a grant_qualifier of the client identifier, and a grant_value of
> the shared secret
> 
> 	refresh_token:
> 		no grant_qualifier, a grant_value of the refresh token
> 
> 	authorization_code:
> 		a grant_qualifier of the callback URI used to return the
> authorization code to the client, and a grant_value of the actual code
> 
> 	<SAML assertion extension URI>:
> 		no grant_qualifier, a grant_value of the assertion as a string
> 
> This would seem to have the following benefits:
> 	- A number of query parameters defined to be used only in cases of a
> particular grant_type value would be eliminated
> 	- The qualifier/value would provide a guideline for structuring new
> grant types
> 	- The "grant_" prefix for the parameters could provide a logical
> grouping for any additional parameters, if a new grant type required more
> than the qualifier/value pair above.
> 
> I must admit however, I had difficulty figuring out how to phrase 'qualifier' so
> that it would apply to a callback URI. I think it makes sense in that an
> authorization code is issued against and only valid for a specific callback URI,
> but would understand if this came off feeling like overloading that
> parameter.
> 
> -David Waite
> 
> On Sep 2, 2010, at 3:11 PM, Eran Hammer-Lahav wrote:
> 
> > I would like to make this change in -11:
> >
> > Instead of the current user of the 'assertion' grant type -
> >
> >   POST /token HTTP/1.1
> >   Host: server.example.com
> >   Content-Type: application/x-www-form-urlencoded
> >
> >   grant_type=assertion&
> >
> assertion_type=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertio
> n&
> >   assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D
> >
> > Drop the 'assertion' grant type and put the assertion type directly in the
> grant_type parameter:
> >
> >   POST /token HTTP/1.1
> >   Host: server.example.com
> >   Content-Type: application/x-www-form-urlencoded
> >
> >
> grant_type=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertion&
> >   assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D
> >
> > In other words, the grant_type parameter value will be defined as:
> >
> > -          authorization_code
> > -          password
> > -          client_credentials
> > -          refresh_token
> > -          an abolute URI (extensions)
> >
> > I considered turning all the values into URIs but found it to be counter-
> intuitive. The practice of using "official" short names and extension URIs is
> well established and is already the general architecture used here. This just
> makes it cleaner.
> >
> > I ran this idea by Brian Campbell and Chuck Mortimore who are generally
> supportive of the idea.
> >
> > Any objections?
> >
> > EHL
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth