token_type is defined in the core spec only and indicates the token type
to the client and not the resource server.
So either the core spec defines a way to distinguish token types towards
resource servers (probably by utilizing the token_type parameter) or the
respective schemes (BEARER, MAC) define ways to recognize the differences.
regards,
Torsten.
Am 16.06.2011 15:38, schrieb Doug Tangren:
-Doug Tangren
http://lessis.mehe
Just one question:
Is the assumption of the group that bearer tokens are the only
type of tokens to be used in conjunction with URI query
parameters? Otherwise, a mechanism is needed to distinguish bearer
and other tokens, e.g. another parameter (token_type?).
I thought the idea was that token_type was a way to define general
extensions which define protocols to provide access_tokens to
resources servicers.
I think its up to the provider of access_tokens to document which of
these token_types they support and how to distinguish them if there
are multiple token_types what use access_tokens in query parameters. I
think its up to the extension authors to provide a consistent naming
scheme with the base oauth2's defined vocabulary.
Where it gets confusing, is when multiple token_type extensions all
use different vocabulary for roughly the same thing. I say that in
regards to the naming of query parameters.
_______________________________________________
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
