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

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Peter Saint-Andre
> Sent: Wednesday, March 23, 2011 2:27 PM

> 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).

        This specification is designed for use with HTTP <xref target='RFC2616' />. The use of
        OAuth with any transport protocol other than HTTP is undefined.

> 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.)

New first paragraph for 1.4.2:

            When an access token is issued to the client directly as the result of the resource
            owner authorization, without an intermediary authorization grant (such as an
            authorization code), the grant is considered implicit.

I did my best to avoid any forward references, and the reference to same origin policy was dropped so not sure where the reference to draft-ietf-websec-origin fit.

> 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"?

I guess. A refresh token is an authorization grant of sorts.

> 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?

Ask. Most services ask about the client type in their registration process.

> 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"?

New schemes, parameters, etc.

> 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.

Tried that. It was nicer for the editor but much less readable. Most people are not expected to read the entire specification, just the parts they care about. This is the result of many long rewrites.
 
> 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.

Added to 2.1:

   The REQUIRED "response_type" request parameter is used to identify
   which grant type the client is requesting: authorization code or
   implicit, described in Section 4.1.1 and Section 4.2.1 respectively.
   If the request is missing the "response_type" parameter, the
   authorization server SHOULD return an error response as described in
   Section 4.1.2.1.

> 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)?

Lifetime is out of scope. As for the parameter, we had a few long threads and the conclusion was that expires_in is easier to issue and as easy to parse. The client can always take the Date header and add the value to it. In low latency environments, this reduces the need for clock synchronization since the value is relative.

> 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?

Nothing. Leave it where HTTP Basic left it. Not ideal but after almost a year, no one offered a text (including the person who raised the issue).

> 13. In Section 8.2, are we really recommending "x_"? I must finish work on
> draft-saintandre-xdash-considered-harmful...

It's the simplest way to curve out a namespace for vendor specific parameters that have no value or place being registered. We can't use URI's for parameter names (that would be awful). Got other suggestions?

> 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.

It's from RFC 5785 which was negotiated with the IESG before RFC 5988. I'll make the switch to 5988.

> 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).

The bearer token proposal to extend the locations available is in violation of the protocol and specification architecture. It is just a really bad idea. Specifically, the idea of any registry defining HTTP URI query request parameters is a violation of the provider's namespace. We can define a registry for OAuth endpoints but not for protected resources which may not even support any URI query or form-encoded body parameters. Doing so would REQUIRE updating 2616.

There are no use cases or requirements for extending the locations and no extensibility is needed.

EHL