To understand your thinking a little more, Eran, as a not-hypothetical thought
experiment, how would you recommend that people specify JSON Web Tokens (JWTs)
in a parallel manner to your description below of using the MAC token type?
Would they use a token_type=JWT parameter to specify the token
My assumption about the new token_type parameter is that it would be used to
communicate the data type of the token -- not the class of the token. I was
imagining token_type values like:
SWT
JWT
urn:oasis:names:tc:SAML:1.0:assertion
urn:oasis:names:tc:SAML:2.0:ass
1. Minor formatting issue: section 1.2, "authorization code" and
"access grant" need a new line before the definition.
2. The new token_type parameter is required in responses from the
server. If the server supports multiple formats, which one will be
used? In this case, would it make sense to all
How about:
- keeping the scheme "OAuth2", for both WWW-Authenticate and Authorization
- define both as name/value pairs (WWW-Authenticate is already)
- require that one of the pairs be "type="
For example:
WWW-Authenticate: OAuth2 type=bearer
Authorization: OAuth2 token=vF9dft4qmT, type=bearer
Ma
Abstain. (The reason: I cannot predict how the tokens will evolve.)
Igor
On Thu, 2010-12-02 at 16:04 -0500, Eran Hammer-Lahav wrote:
I'm defining a new token type: MAC based on my previous HTTP Token
authentication draft (which in turn was based on 1.0a HMAC-SHA1). This is being
drafted
Please see my e-mail to this list from Oct 27th with the subject "OAuth v2
Authorization Header Credentials". It outlines several major problems in the
parsing of the Authorization header that were in OAuth v2 draft 10, and are
still present in this new bearer draft.
That e-mail also proposes a so
