So just to make sure that I'm clear... The following is ok...
The AS and RO decide that the token will be comprised of both a name
and value part. So the whole token looks like
'token=asfd2353fasdfa235q54rdasf'. From the protocol perspective,
the access token is the entire string, even if it looks like to the
developer that only the 'asfd2353fasdfa235q54rdasf' part is the
token. As a developer I find this confusing, but I think I now
understand why the 'token=asfd2353fasdfa235q54rdasf' is legal.
The key is that the client has to treat the response from the AS as
opaque (as Paul mentioned) and just put it in the Authorization header
as 'Authorization: Bearer <token>" regardless of what the resulting
header looks like.
Thanks,
George
On 5/25/11 1:15 PM, Mike Jones wrote:
What you quoted below was the acceptable syntax. The Authorization Server and
the Resource Server still need to agree upon the semantics of the bearer token
exchanged.
-- Mike
-----Original Message-----
From: John Kemp [mailto:j...@jkemp.net]
Sent: Wednesday, May 25, 2011 10:11 AM
To: Mike Jones
Cc: Marius Scurtescu; George Fletcher; OAuth WG
Subject: Re: [OAUTH-WG] bearer token authorization header
On May 24, 2011, at 4:04 PM, Mike Jones wrote:
George, you are correct that resources and clients must agree upon the format
of the bearer token to achieve interoperability. The means for achieving this
agreement is out of the scope of this document.
I thought the means for achieving IOP was quite precisely described in the
production below (excerpted from 2.1 of
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04):
credentials = "Bearer" RWS access-token
access-token = 1*( quoted-char /<"> )
quoted-char = "!" / "#" / "$" / "%" / "&" / "'" / "("
/ ")" / "*" / "+" / "-" / "." / "/" / DIGIT
/ ":" / "<" / "=" /">" / "?" / "@" / ALPHA
/ "[" / "]" / "^" / "_" / "`" / "{" / "|"
/ "}" / "~" / "\" / "," / ";"
- John
-- Mike
-----Original Message-----
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Tuesday, May 24, 2011 11:28 AM
To: George Fletcher
Cc: Mike Jones; OAuth WG
Subject: Re: [OAUTH-WG] bearer token authorization header
The "printable non-whitespace ASCII characters" represents the access token,
which is supposed to be opaque. I don't think this affects libraries.
Marius
On Tue, May 24, 2011 at 10:24 AM, George Fletcher<gffle...@aol.com> wrote:
Do I understand this correctly that each resource owner can define
it's own format for the "printable non-whitespace ASCII characters"?
It seems like that would make it difficult for clients to use
standard libraries because the Authorization header format could be
different on a per resource/host basis.
Thanks,
George
On 5/23/11 3:10 PM, Mike Jones wrote:
[snip]
The fact that there is no escaping mechanism can potentially create
problems. The list of allowed characters is spelled out, but what if
some implementation uses other characters? Using a name value pair
and proper escaping is much safer IMO. For example:
Bearer token=dfgh76dfghdfg
or
Bearer token="dfgh76dfghdfg"
The value above can be either a token or a quoted string. HTTP header
parsers know how to parse tokens and quoted strings so an implementor
has a better chance of doing it right.
Mark Lentczner started a thread on this regard a few moths ago, James
Manger replied and suggested something similar:
http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html
If it is too late to switch to a name/value pair, then I think we
should at least clean up the references.
The definition allows the access token to be any string of one or
more printable non-whitespace ASCII characters. Thus, legal access
token strings include ones like the ones you are asking for, such as:
param="value"
-- Mike
-----Original Message-----
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Monday, May 09, 2011 10:32 AM
To: OAuth WG; Mike Jones
Cc: Mark Lentczner; Manger, James H
Subject: bearer token authorization header
I am working through version 04 of the Bearer Token draft:
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04
Not sure how to interpret the authorization header grammar described
in section 2.1. The intent seems to be for something like:
Bearer dfgh76dfghdfg
After the scheme name, "Bearer", there is a required whitespace
followed by the actual token. The token is represented by a sequence
of printable characters, no escaping. No spaces or other elements are
allowed after the token. Is that correct?
RWS is not defined, I assume it is the "required whitespace" from
section
1.2.2 of:
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13
There is a reference to RFC2617, but not sure why. That seems to
imply that a list of values can be specified, which is not the case.
The fact that there is no escaping mechanism can potentially create
problems. The list of allowed characters is spelled out, but what if
some implementation uses other characters? Using a name value pair
and proper escaping is much safer IMO. For example:
Bearer token=dfgh76dfghdfg
or
Bearer token="dfgh76dfghdfg"
The value above can be either a token or a quoted string. HTTP header
parsers know how to parse tokens and quoted strings so an implementor
has a better chance of doing it right.
Mark Lentczner started a thread on this regard a few moths ago, James
Manger replied and suggested something similar:
http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html
If it is too late to switch to a name/value pair, then I think we
should at least clean up the references.
Marius
_______________________________________________
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
