Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

[Julian Reschke <[e-mail]>]

On 2011-10-13 02:38, Manger, James H 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:
>
> 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.


+1

Except for:

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


...allow both, because otherwise you'll need custom parsers to process 
the header field.

Best regards, Julian