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

["Manger, James H" <[e-mail]>]

>> 2. The ABNF for <credentials> does not comply with RFC 2617 "HTTP Authentication".

> So where are we on this?  Any progress?

Some progress.
draft-ietf-oauth-v2-bearer-09 defines the “Authorization: Bearer ...” request header to match draft-ietf-httpbis-p7-auth. It uses <b64token> for the access token.
The spec is not quite right as it also includes a comma-separated list of name=value pairs <#auth-param> as another option for the header, without any hint about how this works for the Bearer scheme.

Still to do:
Change
credentials = "Bearer" 1*SP ( b64token / #auth-param )
to
credentials = "Bearer" 1*SP b64token
It would also be worth explicitly stating the restrictions on access tokens that the Bearer scheme applies over what OAuth core allows, which is any Unicode string. The Bearer spec requires an access token to match <b64token>. This does not have to be base64 (or base64url), but it can only use 68 ASCII chars (plus “=”’s at the end). Section 4.1.1 “The “Bearer” OAuth Access Token Type” is probably the place to mention the restrictions. Suggested text:

  “When the type is “bearer” the “access_token” value MUST match the <b64token> ABNF [draft-ietf-httpbis-p7-auth], which allows the 66 unreserved URI characters plus a few others so it can hold a base64 or base64url encoding [RFC4648]. Using a base64url encoding without padding (or a few base64url encoded items separated by dots) is RECOMMENDED as it avoids the need for any escaping in most situations.”

Probably need to add RFC 4648 “The Base16, Base32, and Base64 Data Encodings” as an informative reference if including this suggested text.

--
James Manger