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: [email protected] [mailto:[email protected]] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
