Re: [OAUTH-WG] Token Access Authentication Scheme Draft

[Eran Hammer-Lahav <[e-mail]>]

Thanks Dan.

> -----Original Message-----
> From: Dan Winship [mailto:[e-mail]]
> Sent: Tuesday, December 08, 2009 11:00 AM

> If Token/OAuth is not intended for use with Proxy-Authenticate/Proxy-
> Authorization, then you should say that explicitly near the beginning, and if
> not, then everywhere you say "WWW-Authenticate" or "Authorization", you
> need to allow for the proxy versions as well. (Maybe just by saying
> "whenever I say WWW-Authenticate, I mean 'either WWW-Authenticate or
> Proxy-Authenticate'.")

I'll get to this if this draft ever makes it to the other side.

> I know you said you don't care about typos, but "OWF" should be "OWS".
> 
> "rsassa-pkcs1-v1.5-sha-256" is way too long a name. :)

Trying to be descriptive. The current RSA-SHA1 means nothing without reading the spec (it might as well be 'R1').
 
> The grammar for method-list says
> 
>     method-list     = "method" "=" <"> 1#method-name <">
> 
> where "1#method-name" in RFC2616 ABNF means a comma-delimited list of
> method-name. But the text (4.2) and the example quoted above use a
> space-delimited list. (Likewise with coverage-list.)

Right. I wanted it to be space-delimited.
 
> The first paragraph of section 5 seems to say that clients MUST include a
> Authorization header when requesting a protected resource even if they
> don't know that it's protected. :)

Changed to 'when making an authenticated request'.

> In theory, the information in the Authentication-Error response could just be
> included in WWW-Authenticate...

I am actually going to try and use Authentication-Info (expending its use beyond Digest and making it applicable for errors, not just success). Keeping this in a separate header makes it easier I think to parse the challenge. No strong feelings here.

> If error-message is supposed to be localized then you should allow for the
> RFC 2183 grammar (or eventually, the grammar from the RFC that draft-
> reschke-rfc2183-in-http becomes).

OK.

> The "normalized request string" says it includes both the hostname and the
> request URI, which would be redundant. Maybe when you say "request
> resource URI" you mean just the Request-URI production from the Request-
> Line (ie, the path+query), not the actual complete request URI?

Yeah, that's what I mean.

> You should clarify that. Although if the user is behind a proxy then the
> Request-URI will be a complete URI rather than just the path+query. So you
> might want to say something like "the path and query components of the
> request URI, as they appear in the Request-Line"?

                The request Request-URI exactly as it appears on HTTP Request-Line as defined by
                RFC2616> section 5.1.2.

> There have been interoperability problems with Digest auth digest
> computation because people weren't sure if the quotes around attribute
> values were considered part of the value or not when computing the hash.
> You should be explicit.

We didn't get this one in OAuth 1.0 (plenty of other issues)... seems like an odd thing to fail on. I'll note it.

> "Any authentication attribute, with the exception of the "auth", which is
> assigned a value (including default values), are added to the normalized
> request string as follows" is hard to understand. I think what you mean is
> "Any attribute which is present in the Authorization header, with the
> exception of "auth", is added to the normalized request string as follows".

Ok.

> Hm... although 7.1 seems to suggest something else.
> I'm not at all sure what attributes are supposed to be included in the
> normalized request string now.

Fixed.

> Would probably be good to have an example of computing the string.

If this makes it to the other side, I'll add plenty of examples in the spirit of draft-hammer-oauth.

EHL