On Wed, Oct 12, 2011 at 5:38 PM, Manger, James H <james.h.man...@team.telstra.com> wrote: >> One possible syntax is: >> >> Bearer access_token=xyz_-123,more_info=pdq >> >> Ultimately though, the format of the bearer token is outside of the scope of >> the spec, and up to the participants to determine, including whether to use >> b64token syntax or params syntax. > > > It is great to see an example explaining the intention of the "b64token / > #auth-param" part of the draft. These details need to be in the spec. Draft 9 > makes no mention of an "access_token" parameter for the HTTP header -- in > sharp contrast to mentioning such a parameter for the URI query string and > POST body mechanisms. Can the "access_token" value be a <token> (as in the > above example)? Can it be a <quoted-string>? Can it use RFC5987 (eg > access_token*=UTF-8''...)? > > Can a client choose the b64token or auth-param option, implying servers MUST > support both? Or is it the other way around: servers only have to support > b64token so existing servers are compliant without requiring any changes? > > I thought the consensus was that bearer tokens were so simple that "Bearer > <b64token>" was sufficient. In the unlikely event that more parameters were > required in future, a new scheme (eg Bearer2) could be defined. If this is no > longer the consensus then lets:
While I much prefer what you suggest below (and it was suggested before), I think it is too late for that. It will force existing deployments to implement ambiguous parsing code. Let's stick with "Bearer <b64token>". If this is the only option, do we have to limit the token chars to b64? If more flexibility is needed then we can define a new scheme for that. Marius > > 1. Define a single syntax that servers MUST support. > Authorization: Bearer a="<access_token>" > > 2. Use a short parameter name, such as "a", saving 10-bytes per request over > "access_token". The long name is needed in a URI query string or POST body so > the parameter is unambiguous amongst any number of other application-specific > parameters. In a Bearer HTTP header there is no such possibility of confusion. > > 3. Don't allow the value to be either a <token> or <quoted-string> -- just > pick one (I suggest <quoted-string>). It doesn't help developers or interop > to offer a pointless choice. > > 4. Allow future comma-separated parameters, and state that unrecognized > parameters MUST be ignored. > > 5. Add an informative note that some servers might also accept a header of > the form "Bearer <access_token>", but clients using this form are not > compliant to this spec. > > 6. Explicitly state that when the type is "bearer" in an OAuth2 token > response, the "access_token" MUST only consist of characters that can be > represented in a <quoted-string>, ie %x20-7E (assuming <quoted-string> was > picked at #3). > > 7. Recommend that a base64url encoding without padding (of binary data or of > UTF-8 encoded text) is a good choice for an "access_token" value (or a few > base64url encoded segments separated by dots) as it avoids the need to escape > characters in most situations. > > -- > 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
