I think clarification text makes sense here because we're importing a
term from a foreign spec -- b64token -- that overlaps with a term
meaning something quite different in our spec -- token. We can't really
change either of these terms, so we need to separate them some other way.
-- Justin
On 03/06/2012 11:29 AM, Paul Madsen wrote:
as one of the unnamed 'confused colleagues', I'd welcome clarification
paul
On 3/6/12 11:23 AM, Brian Campbell wrote:
Thanks Mike, I think changing the example would be helpful.
However I think that including some text along the lines of what James
suggested would also be very valuable. I agree that the connection
between OAuth and Bearer could and should be made more explicit. And
that the implications of the b64token syntax, particularly on what AS
can use to construct ATs, could/should be made more clear.
I can propose some specific text (building on James') if others in the WG agree?
On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones<michael.jo...@microsoft.com> wrote:
I'm fine with changing the example to make it clearer that b64token allows a
wider range of characters than just those legal for base64 and base64url
encodings of data values.
I'll add it to my to-do list for any additional edits for the Bearer spec.
-- Mike
-----Original Message-----
From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Monday, March 05, 2012 3:33 PM
To: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bearer
Brian,
On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer
Tokens"* I've encountered several people (including myself) who have
made the assumption that the name b64token implies that some kind of
base64 encoding/decoding on the access token is taking place between
the client and RS.
Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,
however, I see that b64token is just an ABNF syntax definition
allowing for characters typically used in base64, base64url, etc.. So
the b64token doesn't define any encoding or decoding but rather just
defines what characters can be used in the part of the Authorization
header that will contain the access token.
Do I read this correctly?
Yes.
If so, I feel like some additional clarifying text in the Bearer
Tokens draft might help avoid what is (based on my small sample) a
common point of misunderstanding.
Changing the example bearer token should be a simple way to avoid some
confusion by showing that it does not have to be base64 encoding. How about
changing:
Authorization: Bearer vF9dft4qmT
to
Authorization: Bearer vF9.dft4.qmT
The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how
OAuth and Bearer connect. It could explicitly state that the string value of the "access_token"
member of an access token response is the bearer token. The "access_token" string value (after
unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such
text could be put in ยง5.1.1 where the "Bearer" OAuth access token type is defined.
Also, does the use of b64token implicitly limit the allowed characters
that an AS can use to construct a bearer access token?
Yes.
*http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1
**
http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1
--
James Manger
_______________________________________________
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
_______________________________________________
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
