Re: [OAUTH-WG] Change grant_type="none" to something less confusing

I don't have anything against this approach but I suspect others might. I think a few examples would be useful to demonstrate these ideas.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Manger, James H
> Sent: Monday, July 19, 2010 6:26 PM
> To: OAuth WG
> Subject: Re: [OAUTH-WG] Change grant_type="none" to something less
> confusing
> 
> grant_type=client_credential sounds ok.
> An even better approach to addressing the discussions about grant_type and
> assertions would be to focus on the *token response* as a standalone media
> type, instead of focusing on a common token endpoint.
> 
> I don't think requiring the same token endpoint for the different flows is
> actually that helpful for anyone -- and it has caused confusion/complexity by
> *coupling* a variety of quite disparate flows (with a continuing debate on
> what is core vs extension).
> 
> Any particular app is likely to only be interested in one section 4 flow
> ("Obtaining an access token").
> Services are free to use a common base URI for any section 4 flows even if
> that commonality isn't required by the spec.
> 
> A common token URI might help if there was a single way to discover it for all
> flows. So far there isn't, and I doubt there needs to be, nor should be.
> Discovering a token endpoint by itself is not that useful. A client needs to
> know which flows work at that endpoint. Was discovery mentions a specific
> flow, it may as well provide the endpoint for that flow.
> 
> * The token endpoint to send an authorization code could be "discovered"
> from the code itself (make the code a URI).
> * The token endpoint for an assertion flow could be discovered in the same
> place that describes the required assertion profile -- perhaps WS-
> MetadataExchange?
> * The token endpoint to refresh a token should be discovered when the
> token is initially provided (ie as part of the token response media type --
> make the token info self-descriptive).
> * The token endpoint for a client to use on its own behalf should be provided
> as part of the signal that says the client needs to make this swap (eg a WWW-
> Auth response, either the same or different from the WWW-Auth response
> signalling user-delegation is supported).
> 
> 
> draft-campbell-oauth-saml, for instance, could define an HTTP request with
> assertion_type and assertion parameters, and state that the result uses the
> token response media type. The media type is a cleaner dividing line
> between draft-campbell-oauth-saml and OAuth2 core.
> 
> 
> --
> James Manger
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth