Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-22.txt

[Julian Reschke <[e-mail]>]

On 2012-07-17 19:15, Mike Jones wrote:
> For clarity of discussion, the definition in question is:
>       b64token    = 1*( ALPHA / DIGIT /
>                         "-" / "." / "_" / "~" / "+" / "/" ) *"="
>
> Note that b64token is a liberal syntax intended to permit base64 encoded content (hence the inclusion of the "+" and "/" characters and the optional trailing "=" characters), base64url encoded content (hence the inclusion of the "-" and "_" characters) and other URL-safe productions (hence the inclusion of the "." and "~" characters).
>
> Its use is definitely not intended to be restricted to base64 encoded content, per RFC 4648. If it were so restricted (by not allowing ".", for instance), this would exclude the use of JWTs as bearer tokens, for instance, which is something we *definitely* want to allow.
>
> As a result, I don't think adding a reference to RFC 4648 is either necessary or appropriate.
>
> Julian may be able to provide more background.

That is correct, in that the constraint on the token contents seems to 
be defined elsewhere.

That being said, by changing the reference from HTTPbis to 2617 you 
broke the spec:

    The "Authorization" header field uses the framework defined by
    HTTP/1.1 [RFC2617] as follows:

      b64token    = 1*( ALPHA / DIGIT /
                        "-" / "." / "_" / "~" / "+" / "/" ) *"="
      credentials = "Bearer" 1*SP b64token

...because in RFC 2617, exactly that syntax is not allowed:

      credentials = auth-scheme #auth-param
      auth-param     = token "=" ( token | quoted-string )

I have to say that I'm a bit surprised by that change (was there any 
public discussion about it?). It is probably possible to fix this 
without having to reference HTTPbis, but, I'm not totally sure about why 
you would want that.

(Note that the spec can be approved before HTTPbis, it just would have 
to wait for RFC publication a bit longer)

Best regards, Julian