<hat type='AD'/> On 3/2/11 12:32 AM, Hannes Tschofenig wrote: > This is a Last Call for comments on > > http://www.ietf.org/id/draft-ietf-oauth-v2-13.txt > > Please have your comments in no later than March 16. > > Do remember to send a note in if you have read the document and have no > other comments other than "its ready to go" - we need those as much as we > need "I found a problem". > > Thanks! > Hannes & Blaine
Sorry about the late comments. Overall the spec is much improved from the last time I read it. Naturally we all await the addition of the security considerations section, so I won't comment on those aspects until I've had a chance to read draft-lodderstedt-oauth-security in the next few days. Also I won't comment on aspects that others have raised in during WGLC. Here are a few additional points... 1. I think it would help in the Introduction to state specifically that this protocol is designed for use on the web and with HTTP (i.e., use with other application protocols is out of scope). 2. I find the concept of "implicit grant" to be a bit foggy in Section 1.4.2. A forward reference to Section 4.2 might help. (Also, it would be good to reference draft-ietf-websec-origin from Section 4.2.) 3. In the definition of "token endpoint" in Section 2, should "used to exchange an authorization grant for an access token" be "used to exchange an authorization grant or refresh token for an access token"? 4. In Section 2.1, a reference to RFC 2616 would be nice at "authorization server MUST support the use of the HTTP "GET" method". 5. Section 3 states: The authorization server SHOULD NOT issue client credentials to clients incapable of keeping their secrets confidential. How does the authorization server know that a client is not capable of keeping its secrets confidential? 6. Section 3.2 states: In cases where client password authentication is not suitable or sufficient, the authorization server MAY support other existing HTTP authentication schemes or define new methods. What is meant by "new methods"? 7. The various subsections of Section 4 have lots of repeated text for the parameter definitions (e.g., "client_id" and "scope", as well as the error codes). I think it would be cleaner to define these once and reference those definitions throughout the spec. 8. The various subsections of Section 4 also provide conflicting information about various parameter values. For example, Section 4.1.1 says of "response_type" that it "MUST be set to "code"" whereas Section 4.2.1 says "MUST be set to "token"". It would reduce the possibility of confusion to say "When the request is an authorization request, the response_type MUST be set to "code"" or somesuch. 9. What is the expected lifetime of access tokens? Does it make sense to have expires_at (in UTC) instead of, or in addition to, expires_in (a number of seconds)? 10. In Section 4.3.2 there is an open issue regarding internationalization of the client's username and password. What is the current thinking about a resolution? 11. In Section 5.1, a reference to RFC 2616 would be good regarding the HTTP "Cache-Control" response header field. 12. In Section 7, a reference to RFC 2671 would be good regarding the HTTP "Authorization" request header. 13. In Section 8.2, are we really recommending "x_"? I must finish work on draft-saintandre-xdash-considered-harmful... 14. In Sections 10.1 and 10.2, I'm uncomfortable with this text: Before a period of 14 days has passed, the Designated Expert(s) will either approve or deny the registration request, communicating this decision both to the review list and to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the i...@iesg.org mailing list) for resolution. I suggest that we re-use the text from RFC 5988: Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app-...@tools.ietf.org email address or directly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the i...@iesg.org mailing list). 15. Section 10.2.1 says: Parameter usage location: The location(s) where parameter can be used. The possible locations are: authorization request, authorization response, token request, or token response. Are those the only allowable locations? I notice that the bearer token spec adds a locations of "resource request" and "resource response". I'm not quite saying we need a registry of locations, but it might be good to have a well-defined way of adding to the list of allowable locations (otherwise a document like the bearer spec might need to say that it updates the base spec). 16. In Section 11.1, I think RFC 2616 needs to be a normative reference. That's it for now! Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth