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

From: agks mehx <[email-masked]>
Date: Sun, 8 Jan 2012 14:12:50 -0800

My client implementation per latest draft did not work against a major
vendor's server implementation.

This was because the vendor REQUIRES the scope parameter in the initial
request.  If I do not supply the scope parameter, it calls back the URL
with an error response stating that the request is invalid:

error=invalid_request&error_description=Missing+required+parameter:+scope

I reported this to the vendor and the vendor claims that the IETF draft
specification says scope is OPTIONAL and that means the vendor is free to
make it required in a conforming implementation.

After a careful reading of the relevant sections of the draft
specification, I do not believe that is what is the intent of the
specification.  It says "OPTIONAL" is to be interpreted per RFC2119, which
in turn says: "an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which does not
include the option (except, of course, for the feature the option
provides.)"

This leads me to believe that if I do not supply scope I should not get an
error -- I may not be able to perform any API calls but I should get a
token back that proves to me that the user was *some* user at the vendor.

Could you please clarify or disambiguate?

---

From: SM <[email-masked]>
Date: Mon, 09 Jan 2012 07:39:02 -0800

At 14:12 08-01-2012, agks mehx wrote:
>I reported this to the vendor and the vendor claims that the IETF 
>draft specification says scope is OPTIONAL and that means the vendor 
>is free to make it required in a conforming implementation.

If a bit is said to be optional, it means that it will not cause any 
interoperability issues if that bit is added or not added.  If the 
vendor claims that the bit is required in a conforming 
implementation, they are free to do so as the decision about what 
conforms of what does not conform is theirs alone.

 From your message, it is not clear whether you are:

   (i)  Asking for a clarification in a specification; or

   (ii) Trying to resolve a disagreement with a vendor.

Regards,
-sm

---

From: Eran Hammer <[email-masked]>
Date: Mon, 9 Jan 2012 09:04:35 -0700

In general, you are correct. However in this case, since OAuth 2.0 does not attempt to guarantee interop between a generic client and any vendor, the vendor has the right to define its own requirements as long as they are within the spec boundaries.

For example, a vendor can define a missing or empty scope to mean no scope and reject the request. That's allowed since the definition of scope is left for the vendor to define.

Personally, I would not write a server implementation with this behavior and instead define a default scope that's sufficient in most cases.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of agks mehx
Sent: Sunday, January 08, 2012 2:13 PM
To: [email-masked]
Subject: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

My client implementation per latest draft did not work against a major vendor's server implementation.

This was because the vendor REQUIRES the scope parameter in the initial request.  If I do not supply the scope parameter, it calls back the URL with an error response stating that the request is invalid:

I reported this to the vendor and the vendor claims that the IETF draft specification says scope is OPTIONAL and that means the vendor is free to make it required in a conforming implementation.

After a careful reading of the relevant sections of the draft specification, I do not believe that is what is the intent of the specification.  It says "OPTIONAL" is to be interpreted per RFC2119, which in turn says: "an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)"

This leads me to believe that if I do not supply scope I should not get an error -- I may not be able to perform any API calls but I should get a token back that proves to me that the user was *some* user at the vendor.

---

From: agks mehx <[email-masked]>
Date: Mon, 9 Jan 2012 16:17:48 -0800

Hi SM and Eran,

I am confused again, after re-reading Eran's response, whether or not an
implementation that rejects *missing* (as opposed to empty) scope is
conformant or not.  (Eran, your response was a bit ambiguous on whether an
implementation is free to error out on an missing scope parameter or not --
I can clearly see it is free to error out on an empty scope parameter, but
that's a different situation than the one I am concerned about.)

The vendor definitely gives a higher priority to claiming conformance and I
believe they would change their implementation, but they believe they are
conformant.

I do feel the IETF Working Group should make this part of the spec less
ambiguous -- why not just make 'scope' REQUIRED and end the misery?  Or,
make it clear that an implementation is not conformant to the spec if it
requires optional parameters?

Additionally, I will resend a use-case for the no-scope parameter because
my earlier reply unintentionally went privately to Eran and not to the list:

I can suggest a spec modification that says that an implementation MUST
accept a request without a scope parameter, in which case one possibility
for an implementing server is to return an access token or code that does
not allow any operations.  The purpose of this otherwise "useless"
token/code is that the OAuth server confirms that the user is *some* user
without any information on *which* user it is.  (If the user is not
authenticated by the vendor then of course no valid token/code is returned.)

An example might help:  Facebook, when it started, would manage social
networks based on college email domain -- harvard.edu, etc.  Facebook used
to do it by asking for your email address and sending a confirmation mail.
 But what if I wanted to tell Facebook just the fact that I was at foo.edu but
I did not want to share my email address with Facebook, or any other unique
identifier?  If the spec required implementations to work without a scope
parameter, it would solve this use case perfectly.  Facebook wouldn't
really care about my school email address or unique id -- I could use my
non-school personal email and all Facebook wanted to know was whether I
should be in that school network or not simply by using the barebones
no-scope OAuth request.

Vendors do not lose anything if the spec requires such no-scope requests to
be fulfilled. They are merely confirming that a user is *some* user with
the user's consent.  There are valid cases on the client side such as
determining network membership without needing network identity.  And it
cleans out the optional semantics of scope.

Users win in that they have a way to confirm network membership without
having to reveal a unique identifier.

Clients win in that users will be more willing to confirm network
membership if they are not also required to reveal a unique identitfier.

This is off-the-cuff but I will be very happy to formalize it and present
it to the list.  I hope the essential concept made it through my writing!

A.

On Mon, Jan 9, 2012 at 3:47 PM, SM <[email-masked]> wrote:

> Hello,
>
> At 15:14 09-01-2012, agks mehx wrote:
>
>> Thank you for the response.  If I understand correctly, the vendor is
>> correctly that their implementation conforms to the specification even
>> though it rejects requests that do not specify the scope parameter.  That
>> answers my question.
>>
>
> The better answer is from Eran ( http://www.ietf.org/mail-**
> archive/web/oauth/current/**msg08194.html<http://www.ietf.org/mail-archive/web/oauth/current/msg08194.html>).
>
>
>  Whether I was asking for (i) a clarification; or (ii) trying to resolve a
>> disagreement.  I think I was trying to verify whether indeed there was a
>> disagreement. I. e. whether my understanding of the specification was
>> correct or not.  It seems I was mistaken in understanding the spec.
>>
>
> See comment below.
>
>
>  There is no disagreement with the vendor at this point because the two
>> responses from this list indicate that the vendor is right.  (I still don't
>> understand why scope isn't made a required parameter in the specification
>> so that such confusion can be avoided, but that's a minor point.)
>>
>
> You locked in on the term "optional" without going into the details of the
> draft.  I would not claim conformance with a specification if my API
> specifies that the optional parts are required as someone writing an
> implementation from the draft will run into the same problem as you.
>  Saying that the vendor is wrong will not get them to fix it.
>
> Regards,
> -sm
>

---

From: William Mills <[email-masked]>
Date: Mon, 9 Jan 2012 16:53:06 -0800 (PST)

There are definitely use cases for un-scoped credentials, which the implementations I have seen implement as an empty scope.  Are you worried specifically about the scope parameter in the HTTP requests, or as represented in the credential used to access the PR?

________________________________
 From: agks mehx <[email-masked]>
To: SM <[email-masked]>; Eran Hammer <[email-masked]>; [email-masked] 
Sent: Monday, January 9, 2012 4:17 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

Hi SM and Eran,

I am confused again, after re-reading Eran's response, whether or not an implementation that rejects *missing* (as opposed to empty) scope is conformant or not.  (Eran, your response was a bit ambiguous on whether an implementation is free to error out on an missing scope parameter or not -- I can clearly see it is free to error out on an empty scope parameter, but that's a different situation than the one I am concerned about.)

The vendor definitely gives a higher priority to claiming conformance and I believe they would change their implementation, but they believe they are conformant.

I do feel the IETF Working Group should make this part of the spec less ambiguous -- why not just make 'scope' REQUIRED and end the misery?  Or, make it clear that an implementation is not conformant to the spec if it requires optional parameters?

Additionally, I will resend a use-case for the no-scope parameter because my earlier reply unintentionally went privately to Eran and not to the list:

I can suggest a spec modification that says that an implementation MUST accept a request without a scope parameter, in which case one possibility for an implementing server is to return an access token or code that does not allow any operations.  The purpose of this otherwise "useless" token/code is that the OAuth server confirms that the user is *some* user without any information on *which* user it is.  (If the user is not authenticated by the vendor then of course no valid token/code is returned.)

An example might help:  Facebook, when it started, would manage social networks based on college email domain -- harvard.edu, etc.  Facebook used to do it by asking for your email address and sending a confirmation mail.  But what if I wanted to tell Facebook just the fact that I was at foo.edu but I did not want to share my email address with Facebook, or any other unique identifier?  If the spec required implementations to work without a scope parameter, it would solve this use case perfectly.  Facebook wouldn't really care about my school email address or unique id -- I could use my non-school personal email and all Facebook wanted to know was whether I should be in that school network or not simply by using the barebones no-scope OAuth request.

Vendors do not lose anything if the spec requires such no-scope requests to be fulfilled. They are merely confirming that a user is *some* user with the user's consent.  There are valid cases on the client side such as determining network membership without needing network identity.  And it cleans out the optional semantics of scope.

Users win in that they have a way to confirm network membership without having to reveal a unique identifier.

Clients win in that users will be more willing to confirm network membership if they are not also required to reveal a unique identitfier.

This is off-the-cuff but I will be very happy to formalize it and present it to the list.  I hope the essential concept made it through my writing!

A.

Hello,
>Thank you for the response.  If I understand correctly, the vendor is correctly that their implementation conforms to the specification even though it rejects requests that do not specify the scope parameter.  That answers my question.
>>
>
The better answer is from Eran ( http://www.ietf.org/mail-archive/web/oauth/current/msg08194.html ).
>
>
>
>Whether I was asking for (i) a clarification; or (ii) trying to resolve a disagreement.  I think I was trying to verify whether indeed there was a disagreement. I. e. whether my understanding of the specification was correct or not.  It seems I was mistaken in understanding the spec.
>>
>
See comment below.
>
>
>
>There is no disagreement with the vendor at this point because the two responses from this list indicate that the vendor is right.  (I still don't understand why scope isn't made a required parameter in the specification so that such confusion can be avoided, but that's a minor point.)
>>
>
You locked in on the term "optional" without going into the details of the draft.  I would not claim conformance with a specification if my API specifies that the optional parts are required as someone writing an implementation from the draft will run into the same problem as you.  Saying that the vendor is wrong will not get them to fix it.
>-sm 

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: agks mehx <[email-masked]>
Date: Mon, 9 Jan 2012 17:44:35 -0800

scope parameter in the HTTP requests.

Two choices stand out to me:  (a) keep the scope parameter truly optional
which implies requiring all implementations to implement un-scoped
credentials;  (b) make the scope parameter REQUIRED thus removing the
confusion and letting implementations choose whether or not they want to
allow an empty scope.

The former, (a), imposes a little bit of extra work for implementations but
benefits users, clients, and arguably implementations, by allowing the
un-scoped credentials use-case.

The latter, (b), merely improves the quality of the specification -- I do
not see what purpose is served by calling the scope parameter OPTIONAL when
vendors are free to require it as they please and still claim conformance.

On Mon, Jan 9, 2012 at 4:53 PM, William Mills <[email-masked]> wrote:

> There are definitely use cases for un-scoped credentials, which the
> implementations I have seen implement as an empty scope.  Are you worried
> specifically about the scope parameter in the HTTP requests, or as
> represented in the credential used to access the PR?
>
>   ------------------------------
> *From:* agks mehx <[email-masked]>
> *To:* SM <[email-masked]>; Eran Hammer <[email-masked]>;
> [email-masked]
> *Sent:* Monday, January 9, 2012 4:17 PM
> *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
> Specification
>
> Hi SM and Eran,
>
> The vendor definitely gives a higher priority to claiming conformance and
> I believe they would change their implementation, but they believe they are
> conformant.
>
> networks based on college email domain -- harvard.edu, etc.  Facebook
> used to do it by asking for your email address and sending a confirmation
> mail.  But what if I wanted to tell Facebook just the fact that I was at
> foo.edu but I did not want to share my email address with Facebook, or
> any other unique identifier?  If the spec required implementations to work
> without a scope parameter, it would solve this use case perfectly.
>  Facebook wouldn't really care about my school email address or unique id
> -- I could use my non-school personal email and all Facebook wanted to know
> was whether I should be in that school network or not simply by using the
> barebones no-scope OAuth request.
>
> Vendors do not lose anything if the spec requires such no-scope requests
> to be fulfilled. They are merely confirming that a user is *some* user with
> The better answer is from Eran (
> http://www.ietf.org/mail-archive/web/oauth/current/msg08194.html ).
>
>

---

From: William Mills <[email-masked]>
Date: Mon, 9 Jan 2012 17:51:54 -0800 (PST)

Re your "a" below: No, implementations may issue scoped credentials if they have a default scope.  It says elsewhere in the spec that the scope issued by the server may not match the requested scope, which is why the server returns a scope value.  This is for informational purposes only for the client so it can know what scopes it should already have.

You don't have to support empty scopes, and it would be completely valid for the auth server to reject a request for an unknown scope, which could include the empty scope if the auth server doesn't support it.

-bill

________________________________
 From: agks mehx <[email-masked]>
To: William Mills <[email-masked]>; [email-masked] 
Cc: SM <[email-masked]>; Eran Hammer <[email-masked]> 
Sent: Monday, January 9, 2012 5:44 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

Two choices stand out to me:  (a) keep the scope parameter truly optional which implies requiring all implementations to implement un-scoped credentials;  (b) make the scope parameter REQUIRED thus removing the confusion and letting implementations choose whether or not they want to allow an empty scope.

The former, (a), imposes a little bit of extra work for implementations but benefits users, clients, and arguably implementations, by allowing the un-scoped credentials use-case.

The latter, (b), merely improves the quality of the specification -- I do not see what purpose is served by calling the scope parameter OPTIONAL when vendors are free to require it as they please and still claim conformance.

See comment below.

---

From: agks mehx <[email-masked]>
Date: Mon, 9 Jan 2012 17:57:36 -0800

That's fine and still consistent with the essence of (a), which is to
require implementations to accept requests without a scope parameter.  If
an implementation chooses to issue scoped credentials, that's perfectly
fine.

My focus is solely on whether the scope parameter should be termed as
OPTIONAL or REQUIRED within the specification.

Perhaps, (b) is a better choice -- to make it REQUIRED?

On Mon, Jan 9, 2012 at 5:51 PM, William Mills <[email-masked]> wrote:

> Re your "a" below: No, implementations may issue scoped credentials if
> they have a default scope.  It says elsewhere in the spec that the scope
> issued by the server may not match the requested scope, which is why the
> server returns a scope value.  This is for informational purposes only for
> the client so it can know what scopes it should already have.
>
> You don't have to support empty scopes, and it would be completely valid
> for the auth server to reject a request for an unknown scope, which could
> include the empty scope if the auth server doesn't support it.
>
> -bill
>
> *To:* William Mills <[email-masked]>; [email-masked]
> *Cc:* SM <[email-masked]>; Eran Hammer <[email-masked]>
> *Sent:* Monday, January 9, 2012 5:44 PM
>
> The former, (a), imposes a little bit of extra work for implementations
> but benefits users, clients, and arguably implementations, by allowing the
> On Mon, Jan 9, 2012 at 4:53 PM, William Mills <[email-masked]>wrote:
>

---

From: William Mills <[email-masked]>
Date: Mon, 9 Jan 2012 18:24:36 -0800 (PST)

I am just not yet convinced that it should be REQUIRED.  I think the fact that we have default language for servers to insert a NULL value for omitted params is sufficient.  Do we need that here too?  Would that make it clearer?

Sent: Monday, January 9, 2012 5:57 PM

That's fine and still consistent with the essence of (a), which is to require implementations to accept requests without a scope parameter.  If an implementation chooses to issue scoped credentials, that's perfectly fine.

My focus is solely on whether the scope parameter should be termed as OPTIONAL or REQUIRED within the specification.

See comment below.

---

From: agks mehx <[email-masked]>
Date: Mon, 9 Jan 2012 22:45:12 -0800

Please allow me to step-back and present the issue again in a different way:

I think of Section 4.1.1 as an API specification.  In my entire career as a
programmer I have never encountered an API specification that said that
some parameters were optional yet callers were required to specify them by
implementations that claimed conformance.

You all are more knowledgeable and experienced with this specification than
I am, and I am not sure I am presenting my case sufficiently, but my gut
instinct as a programmer tells me something is wrong with either the
specification, or the implementation's claim of conformance.

If you think other programmers will find themselves similarly puzzled,
please fix the specification (I don't know what is the fix but I am
convinced a fix is needed if implementations as discussed earlier can be
said to be confirming while they require optional parameters.)

Thanks for listening so far. I rest my case.

On Mon, Jan 9, 2012 at 6:24 PM, William Mills <[email-masked]> wrote:

> I am just not yet convinced that it should be REQUIRED.  I think the fact
> that we have default language for servers to insert a NULL value for
> omitted params is sufficient.  Do we need that here too?  Would that make
> it clearer?
>
> *Sent:* Monday, January 9, 2012 5:57 PM
>
> On Mon, Jan 9, 2012 at 5:51 PM, William Mills <[email-masked]>wrote:
>

---

From: William Mills <[email-masked]>
Date: Tue, 10 Jan 2012 09:19:57 -0800 (PST)

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.  

________________________________
 From: agks mehx <[email-masked]>
To: William Mills <[email-masked]>; Eran Hammer <[email-masked]>; [email-masked] 
Cc: SM <[email-masked]> 
Sent: Monday, January 9, 2012 10:45 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

I think of Section 4.1.1 as an API specification.  In my entire career as a programmer I have never encountered an API specification that said that some parameters were optional yet callers were required to specify them by implementations that claimed conformance.

You all are more knowledgeable and experienced with this specification than I am, and I am not sure I am presenting my case sufficiently, but my gut instinct as a programmer tells me something is wrong with either the specification, or the implementation's claim of conformance.

If you think other programmers will find themselves similarly puzzled, please fix the specification (I don't know what is the fix but I am convinced a fix is needed if implementations as discussed earlier can be said to be confirming while they require optional parameters.)

See comment below.

---

From: SM <[email-masked]>
Date: Tue, 10 Jan 2012 10:56:37 -0800

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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 10 Jan 2012 11:32:48 -0800

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
[email-masked]

On 2012-01-10, at 10:56 AM, SM wrote:

> 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

---

From: Eran Hammer <[email-masked]>
Date: Tue, 10 Jan 2012 14:15:13 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Phil Hunt
> Sent: Tuesday, January 10, 2012 11:33 AM
> To: SM
> Cc: [email-masked]
> 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 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
> [email-masked]
> 
> 
> 
> 
> 
> >> 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

---

From: William Mills <[email-masked]>
Date: Tue, 10 Jan 2012 16:02:21 -0800 (PST)

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 <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Tuesday, January 10, 2012 1:15 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

EHL

---

From: agks mehx <[email-masked]>
Date: Tue, 10 Jan 2012 16:18:10 -0800

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 <[email-masked]> 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."
>
> *From:* Eran Hammer <[email-masked]>
> *To:* "[email-masked]" <[email-masked]>
> *Sent:* Tuesday, January 10, 2012 1:15 PM
>
> 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.
>
> 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.
>
> when
> about

---

From: William Mills <[email-masked]>
Date: Tue, 10 Jan 2012 16:30:48 -0800 (PST)

Wups, there's a must in there that should be MUST.

________________________________
 From: agks mehx <[email-masked]>
To: William Mills <[email-masked]>; Eran Hammer <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, January 10, 2012 4:18 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

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."

>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.

---

From: Eran Hammer <[email-masked]>
Date: Tue, 10 Jan 2012 18:24:03 -0700

I don't like 'empty scope' as it is undefined. I prefer 'default scope'.

EHL

From: William Mills [mailto:[email-masked]]
Sent: Tuesday, January 10, 2012 4:02 PM
To: Eran Hammer; [email-masked]
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

"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."

________________________________
From: Eran Hammer <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 10, 2012 1:15 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

EHL

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of Phil Hunt
> Cc: [email-masked]<mailto:[email-masked]>
> www.independentid.com<http://www.independentid.com>
> [email-masked]<mailto:[email-masked]>
>
>
>
>
>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Tue, 10 Jan 2012 23:57:54 -0800 (PST)

"Null string", "empty string", or "server defined default value" all work.  Default scope doesn't do it for me.

________________________________
 From: Eran Hammer <[email-masked]>
To: William Mills <[email-masked]>; "[email-masked]" <[email-masked]> 
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:[email-masked]] 
Sent: Tuesday, January 10, 2012 4:02 PM
To: Eran Hammer; [email-masked]
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

 

From:Eran Hammer <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Tuesday, January 10, 2012 1:15 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

EHL

---

From: Eran Hammer <[email-masked]>
Date: Fri, 20 Jan 2012 13:32:58 -0700

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:[email-masked]]
Sent: Tuesday, January 10, 2012 11:58 PM
To: Eran Hammer; [email-masked]
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

To: William Mills <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

EHL

From: William Mills [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, January 10, 2012 4:02 PM
To: Eran Hammer; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

EHL

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 20 Jan 2012 17:58:23 -0500

(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

Igor

On 1/20/2012 3:32 PM, Eran Hammer wrote:
> *From:*William Mills [mailto:[email-masked]]
> *Sent:* Tuesday, January 10, 2012 11:58 PM
> *To:* Eran Hammer; [email-masked]
> *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 <[email-masked] <mailto:[email-masked]>>
> *To:* William Mills <[email-masked] 
> <mailto:[email-masked]>>; "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *Sent:* Tuesday, January 10, 2012 5:24 PM
> *Subject:* RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity 
> in Specification
>
> *From:*William Mills [mailto:[email-masked]] 
> <mailto:[mailto:[email-masked]]>
> *Sent:* Tuesday, January 10, 2012 4:02 PM
> *To:* Eran Hammer; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity 
> in Specification
>
> 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."
>
> ------------------------------------------------------------------------
>
> *From:*Eran Hammer <[email-masked] <mailto:[email-masked]>>
> *To:* "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> *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.
>
> 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.
>
> > From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] On Behalf
> > Of Phil Hunt
> > Cc: [email-masked] <mailto:[email-masked]>
> > www.independentid.com <http://www.independentid.com>
> > [email-masked] <mailto:[email-masked]>
> >
> >
> >
> >
> >
> > > [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: William Mills <[email-masked]>
Date: Fri, 20 Jan 2012 21:02:56 -0800 (PST)

Works for me.

Sent: Friday, January 20, 2012 12:32 PM

EHL

 
 
EHL

 

EHL

---

From: Andreas Åkre Solberg <[email-masked]>
Date: Mon, 23 Jan 2012 10:23:24 +0100

Den 20. jan. 2012 kl. 21:32 skrev Eran Hammer:

>           indicating an invalid scope.

Will this change imply that implementing a more dynamic approach to issuing scopes, such as in example asking the user which scope should be issued to the consumer, will be explicitly disallowed, while it was accepted before this text was added?

I think this section of the text does not solve the initial problem that started this thread, and I think it adds unneccessary restrictions.

>  The authorization server SHOULD document its scope

This makes more sense to me.

Andreas

---

From: Eran Hammer <[email-masked]>
Date: Mon, 23 Jan 2012 08:33:21 -0700

It doesn't disallow asking the user. The server is allowed to ignore the scope requested by the client. It can also define 'default scope' to mean 'prompt user' and document that.

EHL

> From: Andreas Åkre Solberg [mailto:[email-masked]]
> Sent: Monday, January 23, 2012 1:23 AM
> To: Eran Hammer
> Cc: William Mills; [email-masked]
> Will this change imply that implementing a more dynamic approach to issuing
> scopes, such as in example asking the user which scope should be issued to
> the consumer, will be explicitly disallowed, while it was accepted before this
> text was added?
> 
> I think this section of the text does not solve the initial problem that started
> this thread, and I think it adds unneccessary restrictions.
>