Thanks Dan.
> -----Original Message-----
> From: Dan Winship [mailto:[email protected]]
> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
