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

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

[written while in transit, delivery will be delayed]

Thanks for the clarifications. A few comments and questions inline,
other topics elided for brevity.

On 3/25/11 1:42 AM, Eran Hammer-Lahav wrote:
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Peter Saint-Andre
>> Sent: Wednesday, March 23, 2011 2:27 PM
> 
>> 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.

Section 1.4 is about authorization grants and Section 1.5 is about
refresh tokens, so I assumed that the latter is not included in the
former. Thus my confusion.

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

Now that you phrase it that way, it makes sense (no in-band discovery
needed). Perhaps add a parenthetical phrase such as:

   The authorization server SHOULD NOT issue client credentials to
   clients incapable of keeping their secrets confidential (e.g., as
   determined when the client registers with the authorization server).

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

OK, I just worry about saying the same thing in different places but in
slightly different ways. We'll want to harmonize them at the end (could
be handled via XML entities within the source document).

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

WFM.

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

OK.

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

I think that's fine here given that these are the usernames and
passwords of automated clients, not human users (as RFC 2277 says,
"internationalization is for humans").

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

Not yet. I'll give it more thought.

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

This was a bone of contention during IESG discussions of what became RFC
5988, so the language from the latter spec should be less controversial.

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

So will draft-ietf-oauth-v2-bearer be fixed?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/