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

[agks mehx <[e-mail]>]

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 <[e-mail]> 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-mail]>
> *To:* "[e-mail]" <[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]] On Behalf
> > Of Phil Hunt
> > Sent: Tuesday, January 10, 2012 11:33 AM
> > To: SM
> > Cc: [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
> > [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]
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>