Sounds very good: "... MAY include or omit the scope parameter. If omitted, the server must process the request using an empty scope as the default."
On Tue, Jan 10, 2012 at 4:02 PM, William Mills <wmi...@yahoo-inc.com> wrote: > 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> > *To:* "oauth@ietf.org" <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] On Behalf > > Of Phil Hunt > > Sent: Tuesday, January 10, 2012 11:33 AM > > To: SM > > Cc: 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 > > 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 > > > 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 > > > > _______________________________________________ > 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
