Re: [OAUTH-WG] VOTE: Token type response parameter

+1 on #3

from an enterprise perspective, we really dont want applications/clients 
to have embedded knowledge of the security model for any target resource.

As I understand this proposal, this would allow a security component at 
the client site/device to discover and create the right type of token 
(bearer/hok, SAML,/JSON) and then bind it appropriately to the resource 
request.

- prateek
> The new draft will include a new token_type response parameter. In my original proposal I suggested making this an optional response parameter with a default value of 'bearer' or 'plain' to keep existing -10 implementation compliant with -11.
>
> Options are:
>
> 1. Missing type response parameter means bearer token
> 2. Missing type response parameter means whatever the service default token type is
> 3. Servers must include an explicit token type with each response, where each token spec (bearer, signed, etc.) register their own type name
> 4. No token type. Type is determined by other attributes (such as secret and hash algorithm name).
>
> #1 and #3 are the most consistent with current design and best for interop. #1 requires no changes to -10 code, but leads to ugly spec organization (it links the bearer token spec with the framework spec).
>
> I'm strongly in favor of #3 as existing clients will ignore this and just assume bearer. Any server introducing a new token type will need to change clients anyway. Servers will need to be changed to add the new parameter but that's a trivial change (and -11 includes some normative changes already - all minor).
>
> So +1 on #3 for me.
>
> Please register your preference.
>
> EHL
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>   