+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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
