Mark,
ยง5.1.1 (where the ABNF for credentials is defined) will move out of the OAuth
core spec in the doc split.
I would like to see the bearer spec use a non-OAuth scheme name when it defines
its Authorization header.
I strongly favour restricting tokens to a much smaller alphabet, such as the 66
unreserved chars (A-Z a-z 0-9 - _ . ~). Anything more means we need escaping
mechanisms in all the places a token can go. Anything more still doesn't
support arbitrary binary data or arbitrary Unicode text so you still need an
encoding such as base64url.
Supporting 'quoted-string' would not be strictly necessary for an access-token
parameter if values were restricted to those 66 chars. However, I would be
happy enough to require parsers to support (token | quoted-string).
I don't think we need 'realm' as an auth-key. It is defined for
WWW-Authenticate response headers, but isn't necessary for Authorization
request headers.
I'm in favour of only using name=value pairs after the scheme name, even if
there is only 1 parameter (the bearer token). It enables parameters to be added
in the future.
My variant of your proposal:
credentials = "BEARER" RWS #auth-param
auth-param = auth-key "=" ( token | quoted-string )
auth-key = "a" | future-key
future-key = token
The "a" parameter holds an access token that MUST only consist of chars from
the set of 66 unreserved chars [should probably express that in the ABNF].
Examples:
Authorization: BEARER a=vF9dft4qmT
Authorization: BEARER a="vF9dft4qmT"
--
James Manger
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Mark
Lentczner
Sent: Thursday, 28 October 2010 10:44 AM
To: [email protected]
Subject: [OAUTH-WG] OAuth v2 Authorization Header Credentials
In my work implementing OAuth v2 to draft 10, I have had to review the
definition of credentials included in an Authorization header. I
believe this current definition has some significant issues for
parsers. However, with some small clean up of the definition, proposed
below, I believe that the credentials can be made robust and more
compatible for existing and future implementations.
...
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
