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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
