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
