Thanks for your comments, James. Responses to them, which reflect the content
of draft 09, follow inline.
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Manger, James H
Sent: Thursday, July 28, 2011 8:51 PM
To: [email protected]
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments
My working group last call comments on draft-ietf-oauth-v2-bearer-08.txt:
1. Mentioning that this is an HTTP authentication mechanism in the title and/or
abstract would be useful to the wider IETF (& beyond) audience.
Title:
"The BEARER HTTP authentication mechanism for use with OAuth 2"
Abstract:
"This specification describes how to use bearer tokens in
HTTP requests to access OAuth 2 protected resources."
[Personally, I wouldn't bother mentioning OAuth at all here, but others seem to
want this context restriction.]
I revised the abstract wording, per your suggestion. I also added the word
"Authorization" to the title so that it is exactly parallel with the core OAuth
2.0 spec. This parallelism clearly tying the two specifications together is
likely more important for adopters of the specification than including "HTTP
Authentication" in the title.
2. The ABNF for <credentials> does not comply with RFC 2617 "HTTP
Authentication". And even though RFC 2617 is broken is this aspect, the BEARER
spec doesn't comply with the errata (still broken) or the more likely fixes
proposed for HTTPbis [draft-ietf-httpbis-p7-auth].
I expect HTTPbis to allow a base64-like-blob consistently in Authorization and
WWW-Authenticate headers (to accommodate BASIC and NTLM). Multiple
WWW-Authenticate headers can have their values combined, separated by commas.
They can also have quoted-string parameters. To be able to parse this, requires
disallowing commas and double-quotes from the base64-like-blob (and hence from
<access-token>) at a minimum; only allowing equals at the end also helps.
The current approach in the bearer spec disallows all but 94 chars/bytes. I
suggest reducing this to 69. Something in between (eg 91 chars, dropping comma,
quote, and slash) might work. None of these options are materially easier than
the others for a token issuer; and less symbols just means less risk of
escaping problems elsewhere (eg allowing "<" in an access token will wreck
someone's XML somewhere, for no benefit).
Suggestion:
access-token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="
<access-token> includes the 66 unreserved URI characters plus a few others.
It can hold a base64, base64url (URL and filename safe alphabet),
base32, or base16 (hex) encoding, with or without padding, but
excluding whitespace [RFC4648].
Thanks for pointing this out. I changed the credentials syntax to the
following, which directly uses the syntax in draft-ietf-httpbis-p7-auth-16 (and
so invents no new syntax):
credentials = "Bearer" 1*SP ( b64token / #auth-param )
2b. If 2 is not accepted (and assuming HTTPbis will allow any content after the
scheme name in a Authorization header) can we please not misuse the
<quoted-char> label when no quoting is going on. The following is a better
equivalent:
access-token = 1*(%x21-7E) ; ASCII, except controls, space, or delete
N/A
3. Drop '\' from the allowed chars in a scope value, to avoid clashing with the
HTTP quoted-string escaping mechanism (and don't use the <quoted-char> label
when no quoting is going on).
scope-v = 1*(%x21 / %x23-5B / %x5D-7E); excludes space and " and \
The place to make syntax changes to the scope value is in the OAuth 2.0 core
spec - not the bearer token spec. No change made.
4. Section 3.3 "Summary of Recommendations" sensibly says clients "MUST ensure
that bearer tokens are not leaked to *unintended parties*" and correctly notes
that this is "the primary security consideration" that underlies all the
others. So it is a glaring hole that OAuth2 fails to tell the client who the
intended parties are when issuing a bearer token.
This comment does not include a specific recommendation for a change to the
spec, and so is not actionable.
--
James Manger
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
