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
