Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

[Igor Faynberg <[e-mail]>]

(Strictly editorial.)

Just to make the first sentence easiery to parse, I suggest to clarify 
the scope (no pan intended) of "MUST."  I read it the server MUST either 
process the request OR fail it.  If so, maybe just inserting the word 
either would do the job.  I would also change punctuation to delineate 
the "using" and "indicating" clauses. Probably putting both clauses in 
parentheses will make it easier than adding an extra comma.  Another 
thing that I found stands in the way of is whether it is really "invalid 
scope [value]."  Maybe it is better to indicate that no scope value has 
been supplied?

As a developer I see the benefit of requiring a default value, 
incidentally, but since there is an option, I think it might be better 
to describe the error in a straight-forward way.

The suggested text:

           If the client omits the scope parameter when requesting 
authorization, the authorization

           server MUST either process the request (using a pre-defined 
default scope value) or fail the request

           (indicating that the scope value is missing). The 
authorization server SHOULD document its scope

           requirements and default value (if defined).



Igor

On 1/20/2012 3:32 PM, Eran Hammer wrote:
>
> New text added to Access Token Scope section:
>
>           If the client omits the scope parameter when requesting 
> authorization, the authorization
>
>           server MUST process the request using a pre-defined default 
> value, or fail the request
>
>           indicating an invalid scope. The authorization server SHOULD 
> document its scope
>
>           requirements and default value (if defined).
>
> EHL
>
> *From:*William Mills [mailto:[e-mail]]
> *Sent:* Tuesday, January 10, 2012 11:58 PM
> *To:* Eran Hammer; [e-mail]
> *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity 
> in Specification
>
> "Null string", "empty string", or "server defined default value" all 
> work.  Default scope doesn't do it for me.
>
> ------------------------------------------------------------------------
>
> *From:*Eran Hammer <[e-mail] <mailto:[e-mail]>>
> *To:* William Mills <[e-mail] 
> <mailto:[e-mail]>>; "[e-mail] 
> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> *Sent:* Tuesday, January 10, 2012 5:24 PM
> *Subject:* RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity 
> in Specification
>
> I don’t like ‘empty scope’ as it is undefined. I prefer ‘default scope’.
>
> EHL
>
> *From:*William Mills [mailto:[e-mail]] 
> <mailto:[mailto:[e-mail]]>
> *Sent:* Tuesday, January 10, 2012 4:02 PM
> *To:* Eran Hammer; [e-mail] <mailto:[e-mail]>
> *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity 
> in Specification
>
> On your #1, I don't agree that an empty scope is useless.  There are 
> comparable implementations that use an empty scope to be a wildcard 
> scope.  I'd say,
>
> "The client can MAY include or omit the scope parameter. If omitted, 
> the server must process the request using an empty scope as the 
> default.  The server then processes the request either issuing a grant 
> with it's default scope as defined by the server or failing the 
> request indicating an invalid scope requested."
>
> That language isn't quite right, but I think it's clear.
>
> ------------------------------------------------------------------------
>
> *From:*Eran Hammer <[e-mail] <mailto:[e-mail]>>
> *To:* "[e-mail] <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>>
> *Sent:* Tuesday, January 10, 2012 1:15 PM
> *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity 
> in Specification
>
>
> I don't think the issue here is about the scope value, but who does 
> the OPTIONAL designation applies to. IOW, is it optional for the 
> server to support/require it, or is it optional for the client to 
> include or omit it.
>
> The intention was to make it optional for the authorization server to 
> make all decisions about the parameter, including making it required. 
> But the text is confusing since the text is aimed directly at the 
> client when making the request.
>
> We need to clarify this and the options are:
>
> 1. The client can decide if they want to include or omit the scope 
> parameter. If omitted, the server must process the request using some 
> documented default scope. This default scope can be an empty scope 
> rendering the token useless for anything other than verifying user 
> authentication.
>
> 2. The server can declare scope to be a required parameter in which 
> case the client must include it or the request will fail. In this 
> case, we should make the text clearer that clients to find out if the 
> particular server requires it.
>
> #1 is better for interoperability, #2 is more in the spirit of the 
> parameter discussions so far.
>
> EHL
>
> > -----Original Message-----
> > From: [e-mail] <mailto:[e-mail]> 
> [mailto:[e-mail] <mailto:[e-mail]>] On Behalf
> > Of Phil Hunt
> > Sent: Tuesday, January 10, 2012 11:33 AM
> > To: SM
> > Cc: [e-mail] <mailto:[e-mail]>
> > Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
> > Specification
> >
> > The underlying issue is that there was a decision not to in any way
> > standardize values for scope.
> >
> > I agreed this was reasonable since the underlying resource APIs are 
> likely to
> > be very specific requiring some degree of prior knowledge by the 
> client app
> > developer. Thus the resource server OAuth infrastructure is free to 
> decide
> > what are and are not acceptable values including missing or null 
> values for
> > scope.
> >
> > I think the specification is acceptable as it is.
> >
> > I note that other specifications that layer on top of OAuth2 such as 
> OpenID
> > Connect may choose to strictly define acceptable values for scope. 
> This type
> > of layering works well in my opinion.
> >
> > Phil
> >
> > @independentid
> > www.independentid.com <http://www.independentid.com>
> > [e-mail] <mailto:[e-mail]>
> >
> >
> >
> >
> >
> > On 2012-01-10, at 10:56 AM, SM wrote:
> >
> > > At 09:19 10-01-2012, William Mills wrote:
> > >> That does clear it up!  If the implementation returns a proper 
> error when
> > the scope is omitted then it will be in conformance.  Sending an 
> error result
> > for the empty scope is valid.
> > >
> > > Yes.
> > >
> > > It is not possible to get a clear view of the specs if the 
> discussion about
> > "ambiguity" relies on the meaning of the word "OPTIONAL" only.  If 
> there is a
> > problem, then clarifying text could be used to fix it instead of 
> changing the
> > requirements.
> > >
> > > Regards,
> > > -sm
> > > _______________________________________________
> > > OAuth mailing list
> > > [e-mail] <mailto:[e-mail]>
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth