> 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: 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
