When a client app gets an OAuth2 token response it needs to know what to do next. In particular, which authentication *protocol* it should use with the received credential. I thought this was what token_type was designed for, hence my suggestion that it hold an HTTP authentication scheme name.
A totally separate piece of information is what is the internal format of a token. Is it a random index to server-side state, or a JWT, or a base64-encoded SAML message? This information could be helpful for protected resource servers if they trust multiple authorization servers. It might be helpful to some client apps, though most should be able to treat a token as an opaque blob. Mike Jones though this was what token_type was designed for. These two uses are quite separate. A bearer token could use a JWT, SWT, SAML, or random-string syntax. Similarly, an "id" in a MAC scheme (or the user-id in the BASIC scheme) could be a JWT, SWT, SAML, or random-string. Conversely, knowing a token is in JWT format doesn't tell a client app if it should sent the token in a "Authorization: BEARER ..." header, or a oauth_token=.. query-string/body parameter, or in a "Authorization: MAC ..." header along with a signature. Marius, I certainly do NOT want new HTTP schemes to be invented every time an authorization server comes up with a new internal structure for its tokens/ids. If we need to indicate the internal structure of a token/id (and assuming self-describing syntaxes are insufficient), then we need a parameter that is *separate* from the indication of the authentication protocol. Looks like we need two parameters: * scheme * token_format -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
