(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:wmi...@yahoo-inc.com]
*Sent:* Tuesday, January 10, 2012 11:58 PM
*To:* Eran Hammer; oauth@ietf.org
*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...@hueniverse.com <mailto:e...@hueniverse.com>>
*To:* William Mills <wmi...@yahoo-inc.com
<mailto:wmi...@yahoo-inc.com>>; "oauth@ietf.org
<mailto:oauth@ietf.org>" <oauth@ietf.org <mailto:oauth@ietf.org>>
*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:wmi...@yahoo-inc.com]
<mailto:[mailto:wmi...@yahoo-inc.com]>
*Sent:* Tuesday, January 10, 2012 4:02 PM
*To:* Eran Hammer; oauth@ietf.org <mailto:oauth@ietf.org>
*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...@hueniverse.com <mailto:e...@hueniverse.com>>
*To:* "oauth@ietf.org <mailto:oauth@ietf.org>" <oauth@ietf.org
<mailto:oauth@ietf.org>>
*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: oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] On Behalf
> Of Phil Hunt
> Sent: Tuesday, January 10, 2012 11:33 AM
> To: SM
> Cc: oauth@ietf.org <mailto:oauth@ietf.org>
> 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>
> phil.h...@oracle.com <mailto:phil.h...@oracle.com>
>
>
>
>
>
> 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
> > OAuth@ietf.org <mailto:OAuth@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
