Thanks for the rapid turnover!

One additional item I just noticed: the reference to [I-D.draft-ietf-oauth-v2-http-mac] is out of date. It should be draft-ietf-oauth-v2-http-mac-04, not -01.

More inline, stripping all but what I'm responding to:

On Dec 17, 2013, at 6:24 PM, Bill Mills <wmills@yahoo-inc.com> wrote:

> MAJOR:
> 
> * Removing the GS2-header (which was done in revision -11) also removed the ability for the client to specify an authorization identity.  If the lack of an authorization identity is acceptable (and I suspect it is not for some), then the document needs to state these mechanisms do not support authz-id.
> 
> [wmills] This is addressed in 3.2.1 of -12  authz-id is possible in some OAuth schemes.
> 

Section 3.2.1. talks about authentication identities (authn-id), not authorization identities (authz-id).  The two are different: authn-id is who holds the credentials (such as they are in OAuth) and authz-id is whom the authn-id is acting as.

The more I read that section, the less convinced I am that it meets the requirements for SASL mechanisms (RFC 4422 § 5).  Identities (at least authn-id, and often authzid) are provided for all other SASL mechanisms, and all of the SASL-using protocols I'm familiar with rely on an identity coming out of the SASL exchange.

I understand that the access token itself is not guaranteed to contain this information, but at some level the resource server needs to be able to associate the SASL authentication credentials (OAuth access token) with an authentication and/or authorization identity.  From what I've seen of existing OAuth software, there is some way to determine an identity -- if not encoded directly in the access token, then by agreement between the resource server and the authorization server (e.g., REST APIs specific to the authorization server).

I suppose one possible transposition is for the authn-id to be the OAuth client identity and the authz-id to be the OAuth resource owner identity.  I personally don't find this mapping interesting or appropriate, and doesn't account for the resource owner acting as a different identity within the context of the SASL-using application.

A possible starting point for text (not sure where in 3.2.1. to place it):

""""
The authentication identity is determined by the resource server using information associated with the access token. This information might be encoded within the access token itself, or the resource server might obtain the information from the authorization server through other means. The specific method is outside the scope of this work.
""""

This still doesn't account for the authorization identity. This could be handled by adding a new kvpair (e.g., "authzid") and maybe some language about how the resource server might validate/verify its use against the provided credentials.

Or, I'm just tilting at windmills.

> * In section 3.2.2. Server Response to Failed Authentication, returning a space-separated list for the "scope" field is NOT RECOMMENDED, but also says the lack of a "scope" (value or field) implies the client SHOULD request tokens that are unscoped (empty list of scopes).  However, RFC 6749 § 3.3 does not permit unscoped tokens; the ABNF does not allow for "scope=" (i.e., the empty list), and the text regarding the lack of scope means the authorization server uses a default scope value (or fails authorization outright).  To me, this seems like a contradiction that would lead to interoperability problems.
> 
> [wmills] "scope" is an optional parameter, so if you want an empty value you don't send scope at all.
> 

My apologies for not being clear.

As I read the document, there are two ways I can see how to interpret the term "unscoped":

1. scope of "" during the authorization request
2. omit the scope from the authorization request

The first is clearly in violation of RFC 6749 (the ABNF requires at least one scope-token, and the scope-token requires at least one printable non-whitespace ACII character).  The second, however, seems to invite failure because the authorization server MUST either use the default scope (if it has one) or fail authorization.

According to this document, the resource server providing a scope of something other than "" is NOT RECOMMENDED.  That means (as I interpret from RFC 2119) that "I can try to return a non-empty scope, but it will likely cause problems in most cases".

This document states that clients that receive an error response with an empty scope (or no scope at all) SHOULD omit the scope from the authorization request (since, again, specifying a scope of "" violates RFC 6749).  SHOULD means (as I interpret from RFC 2119) that "I can try to specify a scope anyway, but it will likely cause problems in most cases".

I am then balancing all this against what I've experienced with already deployed OAuth frameworks: not specifying a scope results in a failure from the authorization server.  Many -- if not most -- OAuth client libraries won't send an authorization request with a scope specified.

This is the interoperability problem I see in this document.  It seems (to me) that it is destined to cause confusion and at best, and non-functioning (if following the SHOULDs and NOT RECOMMENDEDs) or non-compliant (ignoring the SHOULDs and NOT RECOMMENDEDs) code at worst.

I think this could be fixed by either removing the NOT RECOMMENDED about presenting a space-separated list for scope, or by changing the SHOULD to a MAY regarding what the client sends for the authorization request. I think it would also help to define what unscoped means, or not use the term at all.

Suggested starting point for text (replacing all of section 3.2.2):

""""
For a failed authentication the server returns a JSON [RFC4627] formatted error result, and fails the authentication. The error result consists of the following values:

    status (REQUIRED):
        The authorization error code. Valid error codes are defined in the IANA "OAuth Extensions Error Registry" specified in the OAuth 2 core specification. 
    scope (OPTIONAL):
        An OAuth scope which is valid to access the service. This may be empty or a space separated list. Use of a space separated list is NOT RECOMMENDED. 

If the resource server provides a scope value that is not the empty string then the client MUST always request scoped tokens from the token endpoint. If the resource server provides no scope to the client then the client MAY omit the scope from the authorization request.
""""

> * In section 1. Introduction, SMTP is mentioned with a citation but without a definition (unlike SASL and IMAP immediately preceding).
> 
> [wmills] I see "SMTP [RFC5321]" there
> 

What I see:

* Simple Authentication and Security Layer (SASL) [RFC4422]
* Internet Message Access Protocol (IMAP) [RFC3501]
* SMTP [RFC5321]

One of these things is not like the others (-:

This is very clearly a nit.  The lack of consistency erks me somewhat, but I doubt it truly matters.


- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.