Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

[Peter Saint-Andre <[e-mail]>]

<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 [e-mail] 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
   [e-mail] 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 [e-mail] 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/