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
