[OAUTH-WG] ABNF in draft 11

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

Eran,

> I will be publishing -11 this week no matter what shape the draft is in
> as it now includes many normative changes collected over the past few months.

You are probably still editing this text (https://github.com/theRazorBlade/draft-ietf-oauth/blob/master/draft-ietf-oauth-v2.txt) but here are some comments on the ABNF (mainly in section 6.2 "The WWW-Authenticate Response Header Field"):

The "error", "error_description", "error_uri", "scope", and extra parameters in a "WWW-Authenticate: OAuth2 ..." header have to appear in this order according to the ABNF. I think it would be better if they could appear in any order.

The ABNF implies there will be a extra leading comma (now that the mandatory "realm" attribute has been dropped), eg WWW-Authenticate: OAuth2 ,error="xyz".

Defining the "error" value as a <token>, but in double quotes is weird. I believe the idea is that header parameter values are either <token>s (no quotes) or <quoted-string>s (in double quotes).

The <scope> rule is missing the parameter name: scope = "scope" "=" ...
Its value is also strange. One choice is a <quoted-value>, which doesn't involve any quoting!

I think it would be better to simply make all these parameter values <quoted-string>s.

I assume the <credentials> and <access-token> rules should be removed as they will appear in the other part after the spec split.

Any new parameter value (defined with the <param-value> rule in section 7.3) should match <token> | <quoted-string>, not the OAuth-specific <quoted-value> rule.

Using <quoted-value> as a parameter value is not really legal as RFC2617 (and draft-ietf-httpbis-p7-auth-12) require <token> | <quoted-string> for parameter values. <quoted-value> includes characters not in <token>.

I guess it is too late to use space-separated or semicolon-separated parameters, instead of comma-separated parameters, to avoid confusion when multiple WWW-Authenticate headers are combined as HTTP intermediaries are allowed to do (in which case their values are separated with commas). [Not too late for OAuth, but too late for HTTP auth in general]



What error is returned when a request has no authentication?
The status code should be a 401 so the closest error is "invalid_token", though it is not really appropriate.

It is such a shame a WWW-Authentication response header can give details about OAuth errors, but not providing the basic OAuth information such as a user authorization URI, a client credential swap URI, and a token refresh URI.

--
James Manger