Answers inline: 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? Yes 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 Correct. If this isn't a standard by the time the bearer token spec, becomes an RFC I assume this definition will be pulled into the spec. 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. Good catch. I think this should have been 2616. 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
