Subject: Re: [OAUTH-WG] Registration: Scope Values

From: "Manger, James H" <[email-masked]>
Date: Mon, 15 Apr 2013 10:23:23 +1000

Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.

So ideally registration should accept rules for matching scopes, as opposed to actual scope values.

You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").

Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.

--
James Manger

---

From: Justin Richer <[email-masked]>
Date: Mon, 15 Apr 2013 09:54:39 -0400

You are correct that the idea behind the "scope" parameter at 
registration is a constraint on authorization-time scopes that are made 
available. It's both a means for the client to request a set of valid 
scopes and for the server to provision (and echo back to the client) a 
set of valid scopes.

I *really* don't want to try to define a matching language for scope 
expressions. For that to work, all servers would need to be able to 
process the regular expressions for all clients, even if the servers 
themselves only support simple-string scope values. Any regular 
expression syntax we pick here is guaranteed to be incompatible with 
something, and I think the complexity doesn't buy much. Also, I think 
you suddenly have a potential security issue if you have a bad regex in 
place on either end.

As it stands today, the server can interpret the incoming registration 
scopes and enforce them however it wants to. The real trick comes not 
from assigning the values to a particular client but to enforcing them, 
and I think that's always going to be service-specific. We're just not 
as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose the 
following text for that section:

    scope
       OPTIONAL.  Space separated list of scope values (as described in
       OAuth 2.0Section 3.3 [RFC6749]  <http://tools.ietf.org/html/rfc6749#section-3.3>) that the client can use when
       requesting access tokens.  As scope values are service-specific,
       the Authorization Server MAY define its own matching rules when
       determining if a scope value used during an authorization request
       is valid according to the scope values assigned during
       registration. Possible matching rules include wildcard patterns,
       regular expressions, or exactly matching the string. If omitted,
       an Authorization Server MAY register a Client with a default
       set of scopes.

Comments? Improvements?

  -- Justin

On 04/14/2013 08:23 PM, Manger, James H wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Tim Bray <[email-masked]>
Date: Mon, 15 Apr 2013 07:13:59 -0700

This, as written, has zero interoperability.  I think this feature can
really only be made useful in the case where scopes are fixed strings.

-T
On Apr 15, 2013 6:54 AM, "Justin Richer" <[email-masked]> wrote:

> scopes and for the server to provision (and echo back to the client) a set
> of valid scopes.
>
> expressions. For that to work, all servers would need to be able to process
> the regular expressions for all clients, even if the servers themselves
> only support simple-string scope values. Any regular expression syntax we
> pick here is guaranteed to be incompatible with something, and I think the
> complexity doesn't buy much. Also, I think you suddenly have a potential
> security issue if you have a bad regex in place on either end.
>
> scopes and enforce them however it wants to. The real trick comes not from
> assigning the values to a particular client but to enforcing them, and I
> think that's always going to be service-specific. We're just not as clear
> on that as we could be.
>
>       OAuth 2.0 Section 3.3 [RFC6749] <http://tools.ietf.org/html/rfc6749#section-3.3>) that the client can use when
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 15 Apr 2013 10:15:57 -0400

Scopes aren't meant to be interoperable between services since they're 
necessarily API-specific. The only interoperable bit is that there's 
*some* place to put the values and that it's expressed as a bag of 
space-separated strings. How those strings get interpreted and enforced 
(which is really what's at stake here) is up to the AS and PR (or a 
higher-level protocol like UMA).

  -- Justin

On 04/15/2013 10:13 AM, Tim Bray wrote:
> On Apr 15, 2013 6:54 AM, "Justin Richer" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     registration is a constraint on authorization-time scopes that are
>     made available. It's both a means for the client to request a set
>     of valid scopes and for the server to provision (and echo back to
>     the client) a set of valid scopes.
>
>     I *really* don't want to try to define a matching language for
>     scope expressions. For that to work, all servers would need to be
>     able to process the regular expressions for all clients, even if
>     the servers themselves only support simple-string scope values.
>     Any regular expression syntax we pick here is guaranteed to be
>     incompatible with something, and I think the complexity doesn't
>     buy much. Also, I think you suddenly have a potential security
>     issue if you have a bad regex in place on either end.
>
>     As it stands today, the server can interpret the incoming
>     registration scopes and enforce them however it wants to. The real
>     trick comes not from assigning the values to a particular client
>     but to enforcing them, and I think that's always going to be
>     service-specific. We're just not as clear on that as we could be.
>
>     After looking over everyone's comments so far, I'd like to propose
>     the following text for that section:
>
>
>         scope
>>     [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Tim Bray <[email-masked]>
Date: Mon, 15 Apr 2013 07:33:03 -0700

No, I mean it’s not interoperable at the software-developer level.  I can’t
register scopes at authorization time with any predictable effect that I
can write code to support, either client or server side, without
out-of-line non-interoperable knowledge about the behavior of the server.

I guess I’m just not used to OAuth’s culture of having no expectation that
things will be specified tightly enough that I can write code to implement
as specified.  -T

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <[email-masked]> wrote:

> necessarily API-specific. The only interoperable bit is that there's *some*
> place to put the values and that it's expressed as a bag of space-separated
> strings. How those strings get interpreted and enforced (which is really
> what's at stake here) is up to the AS and PR (or a higher-level protocol
> like UMA).
>
>  -- Justin
>
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 15 Apr 2013 10:35:11 -0400

What would you suggest for wording here, then? Keeping in mind that we 
cannot (and don't want to) prohibit expression-based scopes.

  -- Justin

On 04/15/2013 10:33 AM, Tim Bray wrote:
> No, I mean it’s not interoperable at the software-developer level.  I 
> can’t register scopes at authorization time with any predictable 
> effect that I can write code to support, either client or server side, 
> without out-of-line non-interoperable knowledge about the behavior of 
> the server.
>
> I guess I’m just not used to OAuth’s culture of having no expectation 
> that things will be specified tightly enough that I can write code to 
> implement as specified.  -T
>
>
> On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <[email-masked] 
>     Scopes aren't meant to be interoperable between services since
>     they're necessarily API-specific. The only interoperable bit is
>     that there's *some* place to put the values and that it's
>     expressed as a bag of space-separated strings. How those strings
>     get interpreted and enforced (which is really what's at stake
>     here) is up to the AS and PR (or a higher-level protocol like UMA).
>
>      -- Justin
>
>
>>     This, as written, has zero interoperability.  I think this
>>     feature can really only be made useful in the case where scopes
>>     are fixed strings.
>>
>>     -T
>>
>>         registration is a constraint on authorization-time scopes
>>         that are made available. It's both a means for the client to
>>         request a set of valid scopes and for the server to provision
>>         (and echo back to the client) a set of valid scopes.
>>
>>         I *really* don't want to try to define a matching language
>>         for scope expressions. For that to work, all servers would
>>         need to be able to process the regular expressions for all
>>         clients, even if the servers themselves only support
>>         simple-string scope values. Any regular expression syntax we
>>         pick here is guaranteed to be incompatible with something,
>>         and I think the complexity doesn't buy much. Also, I think
>>         you suddenly have a potential security issue if you have a
>>         bad regex in place on either end.
>>
>>         registration scopes and enforce them however it wants to. The
>>         real trick comes not from assigning the values to a
>>         particular client but to enforcing them, and I think that's
>>         always going to be service-specific. We're just not as clear
>>         on that as we could be.
>>
>>         After looking over everyone's comments so far, I'd like to
>>         propose the following text for that section:
>>
>>
>>             scope

---

From: Justin Richer <[email-masked]>
Date: Mon, 15 Apr 2013 11:04:52 -0400

On 04/15/2013 10:52 AM, Tim Bray wrote:
> I’d use the existing wording; it’s perfectly clear.  Failing that, if 
> there’s strong demand for registration of structured scopes, bless the 
> use of regexes, either PCREs or some careful subset.

Thanks for the feedback -- Of these two choices, I'd rather leave it as-is.

>
> However, I’d subtract the sentence “If omitted, an Authorization 
> Server MAY register a Client with a default set of  scopes.”  It adds 
> no value; if the client doesn’t declare scopes, the client doesn’t 
> declare scopes, that’s all.  -T

Remember, all of these fields aren't just for the client *request*, 
they're also for the server's *response* to either a POST, PUT, or GET 
request. (I didn't realize it, but perhaps the wording as stated right 
now doesn't make that clear -- I need to fix that.) The value that it 
adds is if the client doesn't ask for any particular scopes, the server 
can still assign it scopes and the client can do something smart with 
that. Dumb clients are allowed to ignore it if it doesn't mean anything 
to them.

This is how our server implementation actually works right now. If the 
client doesn't ask for anything specific at registration, the server 
hands it a bag of "default" scopes. Same thing happens at auth time -- 
if the client doesn't ask for any particular scopes, the server hands it 
all of its registered scopes as a default. Granted, on our server, 
scopes are just simple strings right now, so they get compared at the 
auth endpoint with an exact string-match metric and set-based logic.

  -- Justin

>
>
> On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <[email-masked] 
>     What would you suggest for wording here, then? Keeping in mind
>     that we cannot (and don't want to) prohibit expression-based scopes.
>
>      -- Justin
>
>
>>     No, I mean it’s not interoperable at the software-developer
>>     level.  I can’t register scopes at authorization time with any
>>     predictable effect that I can write code to support, either
>>     client or server side, without out-of-line non-interoperable
>>     knowledge about the behavior of the server.
>>
>>     I guess I’m just not used to OAuth’s culture of having no
>>     expectation that things will be specified tightly enough that I
>>     can write code to implement as specified.  -T
>>
>>
>>         Scopes aren't meant to be interoperable between services
>>         since they're necessarily API-specific. The only
>>         interoperable bit is that there's *some* place to put the
>>         values and that it's expressed as a bag of space-separated
>>         strings. How those strings get interpreted and enforced
>>         (which is really what's at stake here) is up to the AS and PR
>>         (or a higher-level protocol like UMA).
>>
>>          -- Justin
>>
>>
>>>         feature can really only be made useful in the case where
>>>         scopes are fixed strings.
>>>
>>>         -T
>>>
>>>             You are correct that the idea behind the "scope"
>>>             parameter at registration is a constraint on
>>>             authorization-time scopes that are made available. It's
>>>             both a means for the client to request a set of valid
>>>             scopes and for the server to provision (and echo back to
>>>             I *really* don't want to try to define a matching
>>>             language for scope expressions. For that to work, all
>>>             servers would need to be able to process the regular
>>>             expressions for all clients, even if the servers
>>>             themselves only support simple-string scope values. Any
>>>             regular expression syntax we pick here is guaranteed to
>>>             be incompatible with something, and I think the
>>>             complexity doesn't buy much. Also, I think you suddenly
>>>             have a potential security issue if you have a bad regex
>>>             in place on either end.
>>>
>>>             As it stands today, the server can interpret the
>>>             incoming registration scopes and enforce them however it
>>>             wants to. The real trick comes not from assigning the
>>>             values to a particular client but to enforcing them, and
>>>             I think that's always going to be service-specific.
>>>             We're just not as clear on that as we could be.
>>>
>>>             After looking over everyone's comments so far, I'd like
>>>             to propose the following text for that section:
>>>
>>>
>>>                 scope

---

From: Mike Jones <[email-masked]>
Date: Mon, 15 Apr 2013 16:44:15 +0000

I think that the existing wording is superior to the proposed changed wording.  The existing wording is:

   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>) that the client is declaring that
      it may use when requesting access tokens.  If omitted, an
      Authorization Server MAY register a Client with a default set of
      scopes.

For instance, the current “client is declaring” wording will always be correct, whereas as the change to “client can use” wording implies a restriction on client behavior that is not always applicable.  The “client is declaring” wording was specific and purposefully chosen, and I think should be retained.  In particular, we can’t do anything that implies that only the registered scopes values can be used.  At the OAuth spec level, this is a hint as to possible future client behavior – not a restriction on future client behavior.

Also, for the reasons that Tim stated, I’m strongly against any “matching” or “regex” language in the spec pertaining to scopes – as it’s not actionable.

So I’d propose that we leave the existing scope wording in place.  Alternatively, I’d also be fine with deleting this feature entirely, as I don’t think it’s useful in the general case.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; [email-masked]
Subject: Re: [OAUTH-WG] Registration: Scope Values

I’d use the existing wording; it’s perfectly clear.  Failing that, if there’s strong demand for registration of structured scopes, bless the use of regexes, either PCREs or some careful subset.

However, I’d subtract the sentence “If omitted, an Authorization Server MAY register a Client with a default set of  scopes.”  It adds no value; if the client doesn’t declare scopes, the client doesn’t declare scopes, that’s all.  -T

Remember, all of these fields aren't just for the client *request*, they're also for the server's *response* to either a POST, PUT, or GET request. (I didn't realize it, but perhaps the wording as stated right now doesn't make that clear -- I need to fix that.) The value that it adds is if the client doesn't ask for any particular scopes, the server can still assign it scopes and the client can do something smart with that. Dumb clients are allowed to ignore it if it doesn't mean anything to them.

This is how our server implementation actually works right now. If the client doesn't ask for anything specific at registration, the server hands it a bag of "default" scopes. Same thing happens at auth time -- if the client doesn't ask for any particular scopes, the server hands it all of its registered scopes as a default. Granted, on our server, scopes are just simple strings right now, so they get compared at the auth endpoint with an exact string-match metric and set-based logic.

 -- Justin

On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
What would you suggest for wording here, then? Keeping in mind that we cannot (and don't want to) prohibit expression-based scopes.

 -- Justin

On 04/15/2013 10:33 AM, Tim Bray wrote:
No, I mean it’s not interoperable at the software-developer level.  I can’t register scopes at authorization time with any predictable effect that I can write code to support, either client or server side, without out-of-line non-interoperable knowledge about the behavior of the server.

I guess I’m just not used to OAuth’s culture of having no expectation that things will be specified tightly enough that I can write code to implement as specified.  -T

On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Scopes aren't meant to be interoperable between services since they're necessarily API-specific. The only interoperable bit is that there's *some* place to put the values and that it's expressed as a bag of space-separated strings. How those strings get interpreted and enforced (which is really what's at stake here) is up to the AS and PR (or a higher-level protocol like UMA).

 -- Justin

This, as written, has zero interoperability.  I think this feature can really only be made useful in the case where scopes are fixed strings.

-T
On Apr 15, 2013 6:54 AM, "Justin Richer" <[email-masked]<mailto:[email-masked]>> wrote:
You are correct that the idea behind the "scope" parameter at registration is a constraint on authorization-time scopes that are made available. It's both a means for the client to request a set of valid scopes and for the server to provision (and echo back to the client) a set of valid scopes.

I *really* don't want to try to define a matching language for scope expressions. For that to work, all servers would need to be able to process the regular expressions for all clients, even if the servers themselves only support simple-string scope values. Any regular expression syntax we pick here is guaranteed to be incompatible with something, and I think the complexity doesn't buy much. Also, I think you suddenly have a potential security issue if you have a bad regex in place on either end.

As it stands today, the server can interpret the incoming registration scopes and enforce them however it wants to. The real trick comes not from assigning the values to a particular client but to enforcing them, and I think that's always going to be service-specific. We're just not as clear on that as we could be.

After looking over everyone's comments so far, I'd like to propose the following text for that section:

   scope

      OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>) that the client can use when

      set of scopes.

Comments? Improvements?

 -- Justin

--

James Manger

OAuth mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: Tim Bray <[email-masked]>
Date: Mon, 15 Apr 2013 09:54:38 -0700

On Mon, Apr 15, 2013 at 9:44 AM, Mike Jones <[email-masked]>wrote:

>  So I’d propose that we leave the existing scope wording in place.
> Alternatively, I’d also be fine with deleting this feature entirely, as I
> don’t think it’s useful in the general case.
>

I think we might well have a use for this, so that’s something of an
existence proof.  So I’d prefer if we could leave it in. -T

>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Justin Richer
> *Sent:* Monday, April 15, 2013 8:05 AM
> *To:* Tim Bray; [email-masked]
>
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values****
>
>  ** **
>
> ****
> there’s strong demand for registration of structured scopes, bless the use
> of regexes, either PCREs or some careful subset.****
>
>
> ****
> ** **
> However, I’d subtract the sentence “If omitted, an Authorization Server
> MAY register a Client with a default set of  scopes.”  It adds no value; if
> the client doesn’t declare scopes, the client doesn’t declare scopes,
> that’s all.  -T****
>
>
> request. (I didn't realize it, but perhaps the wording as stated right now
> doesn't make that clear -- I need to fix that.) The value that it adds is
> if the client doesn't ask for any particular scopes, the server can still
> assign it scopes and the client can do something smart with that. Dumb
> clients are allowed to ignore it if it doesn't mean anything to them.
>
> client doesn't ask for anything specific at registration, the server hands
> it a bag of "default" scopes. Same thing happens at auth time -- if the
> client doesn't ask for any particular scopes, the server hands it all of
> its registered scopes as a default. Granted, on our server, scopes are just
> simple strings right now, so they get compared at the auth endpoint with an
> exact string-match metric and set-based logic.
>
>  -- Justin
>
>
> ****
>
> ** **
>
> On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <[email-masked]> wrote:*
> ***
>
>  -- Justin ****
> ** **
> On 04/15/2013 10:33 AM, Tim Bray wrote:****
>
> can’t register scopes at authorization time with any predictable effect
> that I can write code to support, either client or server side, without
> ****
> ** **
> as specified.  -T****
> ** **
> On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <[email-masked]> wrote:*
> ***
>
>  -- Justin ****
> ** **
> On 04/15/2013 10:13 AM, Tim Bray wrote:****
>
> really only be made useful in the case where scopes are fixed strings.****
>
> -T****
>
> On Apr 15, 2013 6:54 AM, "Justin Richer" <[email-masked]> wrote:****
>
> You are correct that the idea behind the "scope" parameter at registration
> is a constraint on authorization-time scopes that are made available. It's
> both a means for the client to request a set of valid scopes and for the
> server to provision (and echo back to the client) a set of valid scopes.
>
> ****
>    scope****
>       OPTIONAL.  Space separated list of scope values (as described in****
>
>       OAuth 2.0 Section 3.3 [RFC6749] <http://tools.ietf.org/html/rfc6749#section-3.3>) that the client can use when ****
>
>       requesting access tokens.  As scope values are service-specific, ****
>
>       the Authorization Server MAY define its own matching rules when****
>
>       determining if a scope value used during an authorization request****
>
>       is valid according to the scope values assigned during ****
>
>       registration. Possible matching rules include wildcard patterns,****
>
>       regular expressions, or exactly matching the string. If omitted, ****
>
>       an Authorization Server MAY register a Client with a default ****
>
>       set of scopes.****
>
>
> Comments? Improvements?
>
>  -- Justin
>
> ****
>
> On 04/14/2013 08:23 PM, Manger, James H wrote:****
>
> Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.****
>
> ** **
>
> So ideally registration should accept rules for matching scopes, as opposed to actual scope values.****
>
> ** **
>
> You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").****
>
> ** **
>
> Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.****
>
> ** **
>
> --****
>
> James Manger****
>
> _______________________________________________****
>
> OAuth mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ** **
>
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 15 Apr 2013 12:56:50 -0400

I absolutely do not want to delete this feature, as (having implemented 
it) I think it's very useful. This is a very established pattern in 
manual registration: I know of many, many OAuth2 servers and clients 
that are set up where the client must pre-register a set of scopes.

I don't like the language of "the client is declaring" because it's too 
one-sided. The client might not have declared anything, and it might be 
the server that's declaring something to the client. Deleting the "is 
declaring" bit removes that unintended restriction of the language while 
keeping the original meaning intact. I actually thought that I had fixed 
that before the last draft went in but apparently I missed this one.

I will work on clarifying the intent of the whole metadata set in its 
introductory paragraph(s) so that it's clear that all of these fields 
are used in both of these situations:

  1) The client declaring to the server its desire to use a particular value
  2) The server declaring to the client that it has been registered with 
a particular value

This should hopefully clear up the issue in the editor's note that I 
currently have at the top of that section right now, too.

Mike, since you were the one who originally brought up the issue, and 
you're fine with the existing text, can I take this as closed now? 
Assuming that you agree with deleting "is declaring" for reasons stated 
above, I'm fine with leaving everything else as is and staying quiet on 
what the server has to do with the scopes.

  -- Justin

On 04/15/2013 12:44 PM, Mike Jones wrote:
>       OAuth 2.0 Section 3.3 [RFC6749] 
> <http://tools.ietf.org/html/rfc6749#section-3.3>) that the client is 
> declaring that
>
> For instance, the current “client is declaring” wording will always be 
> correct, whereas as the change to “client can use” wording implies a 
> restriction on client behavior that is not always applicable.  The 
> “client is declaring” wording was specific and purposefully chosen, 
> and I think should be retained.  In particular, we can’t do anything 
> that implies that only the registered scopes values can be used.  At 
> the OAuth spec level, this is a hint as to possible future client 
> behavior – not a restriction on future client behavior.
>
> Also, for the reasons that Tim stated, I’m strongly against any 
> “matching” or “regex” language in the spec pertaining to scopes – as 
> it’s not actionable.
>
> Alternatively, I’d also be fine with deleting this feature entirely, 
> as I don’t think it’s useful in the general case.
>
> -- Mike
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Justin Richer
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>
> adds is if the client doesn't ask for any particular scopes, the 
> server can still assign it scopes and the client can do something 
> smart with that. Dumb clients are allowed to ignore it if it doesn't 
> mean anything to them.
>
> if the client doesn't ask for any particular scopes, the server hands 
> it all of its registered scopes as a default. Granted, on our server, 
>     No, I mean it’s not interoperable at the software-developer level.
>      I can’t register scopes at authorization time with any
>     predictable effect that I can write code to support, either client
>     or server side, without out-of-line non-interoperable knowledge
>     about the behavior of the server.
>
>         registration is a constraint on authorization-time scopes that
>         are made available. It's both a means for the client to
>         scope expressions. For that to work, all servers would need to
>         be able to process the regular expressions for all clients,
>         even if the servers themselves only support simple-string
>         scope values. Any regular expression syntax we pick here is
>         guaranteed to be incompatible with something, and I think the
>         complexity doesn't buy much. Also, I think you suddenly have a
>         potential security issue if you have a bad regex in place on
>         either end.
>
>         real trick comes not from assigning the values to a particular
>         client but to enforcing them, and I think that's always going
>         to be service-specific. We're just not as clear on that as we
>         could be.
>

---

From: prateek mishra <[email-masked]>
Date: Mon, 15 Apr 2013 13:00:29 -0400

+1
> For instance, the current "client is declaring" wording will always be 
> correct, whereas as the change to "client can use" wording implies a 
> "client is declaring" wording was specific and purposefully chosen, 
> and I think should be retained.  In particular, we can't do anything 
> behavior -- not a restriction on future client behavior.
>
> Also, for the reasons that Tim stated, I'm strongly against any 
> "matching" or "regex" language in the spec pertaining to scopes -- as 
> it's not actionable.
>
> So I'd propose that we leave the existing scope wording in place.  
> Alternatively, I'd also be fine with deleting this feature entirely, 
> as I don't think it's useful in the general case.
>
> -- Mike
>
> I'd use the existing wording; it's perfectly clear.  Failing that, if 
> there's strong demand for registration of structured scopes, bless the 
> However, I'd subtract the sentence "If omitted, an Authorization 
> Server MAY register a Client with a default set of  scopes."  It adds 
> no value; if the client doesn't declare scopes, the client doesn't 
> declare scopes, that's all.  -T
>
>
>     No, I mean it's not interoperable at the software-developer level.
>      I can't register scopes at authorization time with any
>     I guess I'm just not used to OAuth's culture of having no

---

From: Mike Jones <[email-masked]>
Date: Mon, 15 Apr 2013 17:29:55 +0000

We could fix the one-sided language by changing
“Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>) that the client is declaring that it may use when requesting access tokens.”
to
“Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>) that the client is declaring to the server that it may use when requesting access tokens and that the server is declaring to the client that it is registered to use when requesting access tokens.”.

Again, I chose the “registered to use” language carefully – because in the general case it’s not a restriction on the values that the client can use – just a statement by the server to the client that it is registered to use those particular values.  In both cases, the parties are making declarations to one another.

If you adopt that language (or keep the original language), then yes, I’d consider this closed.

                                                            -- Mike

From: Justin Richer [mailto:[email-masked]]
Sent: Monday, April 15, 2013 9:57 AM
To: Mike Jones
Cc: Tim Bray; [email-masked]
Subject: Re: [OAUTH-WG] Registration: Scope Values

I absolutely do not want to delete this feature, as (having implemented it) I think it's very useful. This is a very established pattern in manual registration: I know of many, many OAuth2 servers and clients that are set up where the client must pre-register a set of scopes.

I don't like the language of "the client is declaring" because it's too one-sided. The client might not have declared anything, and it might be the server that's declaring something to the client. Deleting the "is declaring" bit removes that unintended restriction of the language while keeping the original meaning intact. I actually thought that I had fixed that before the last draft went in but apparently I missed this one.

I will work on clarifying the intent of the whole metadata set in its introductory paragraph(s) so that it's clear that all of these fields are used in both of these situations:

 1) The client declaring to the server its desire to use a particular value
 2) The server declaring to the client that it has been registered with a particular value

This should hopefully clear up the issue in the editor's note that I currently have at the top of that section right now, too.

Mike, since you were the one who originally brought up the issue, and you're fine with the existing text, can I take this as closed now? Assuming that you agree with deleting "is declaring" for reasons stated above, I'm fine with leaving everything else as is and staying quiet on what the server has to do with the scopes.

 -- Justin

   scope

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Registration: Scope Values

 -- Justin

 -- Justin

 -- Justin

-T

   scope

      set of scopes.

Comments? Improvements?

 -- Justin

--

James Manger

OAuth mailing list

---

From: John Bradley <[email-masked]>
Date: Mon, 15 Apr 2013 16:24:05 -0300

I think the below is a bit clearer than the existing language.    I can live with either.

John B.

On 2013-04-15, at 2:29 PM, Mike Jones <[email-masked]> wrote:

> “Space separated list of scope values (as described in OAuth 2.0Section 3.3 [RFC6749]) that the client is declaring that it may use when requesting access tokens.”
> to
> “Space separated list of scope values (as described in OAuth 2.0Section 3.3 [RFC6749]) that the client is declaring to the server that it may use when requesting access tokens and that the server is declaring to the client that it is registered to use when requesting access tokens.”.
>  
>       OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that
> On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <[email-masked]> wrote:
>       OAuth 2.0 Section 3.3 [RFC6749]) that the client can use when

---

From: Justin Richer <[email-masked]>
Date: Mon, 15 Apr 2013 15:28:50 -0400

I think that because the "declaration" issue affects all parameters in 
the list, not just scope, we should adopt this in a higher level 
paragraph and leave it out of the individual parameter descriptions. 
Thus, something like this inserted as the second paragraph in section 2:

    The client metadata values serve two parallel purposes in the
    overall OAuth Dynamic Registration protocol:

      - the Client requesting its desired values for each parameter to
    the Authorization Server in a [register] or [update] request,
      - the Authorization Server informing the Client of the current
    values of each parameter that the Client has been registered to use
    through a [client information response].

    An Authorization Server MAY override any value that a Client
    requests during the registration process (including any omitted
    values) and replace the requested value with a default. The
    normative indications in the following list apply to the Client's
    declaration of its desired values.

    The Authorization Server SHOULD provide documentation for any fields
    that it requires to be filled in by the client or to have particular
    values or formats. Extensions and profiles...

And then remove the sidedness-language from the scope parameter and any 
other parameters where it might have crept in inadvertently.

  -- Justin

On 04/15/2013 01:29 PM, Mike Jones wrote:
> “Space separated list of scope values (as described in OAuth 2.0 
> Section 3.3 [RFC6749] 
> declaring that it may use when requesting access tokens.”
>
> to
>
> “Space separated list of scope values (as described in OAuth 2.0 
> Section 3.3 [RFC6749] 
> declaring to the server that it may use when requesting access tokens 
> and that the server is declaring to the client that it is registered 
> to use when requesting access tokens.”.
>
> Again, I chose the “registered to use” language carefully – because in 
> the general case it’s not a restriction on the values that the client 
> can use – just a statement by the server to the client that it is 
> registered to use those particular values.  In both cases, the parties 
> are making declarations to one another.
>
> *From:*Justin Richer [mailto:[email-masked]]
> *Sent:* Monday, April 15, 2013 9:57 AM
> *To:* Mike Jones
> *Cc:* Tim Bray; [email-masked]
> I absolutely do not want to delete this feature, as (having 
> implemented it) I think it's very useful. This is a very established 
> pattern in manual registration: I know of many, many OAuth2 servers 
> and clients that are set up where the client must pre-register a set 
> of scopes.
>
> I don't like the language of "the client is declaring" because it's 
> too one-sided. The client might not have declared anything, and it 
> might be the server that's declaring something to the client. Deleting 
> the "is declaring" bit removes that unintended restriction of the 
> language while keeping the original meaning intact. I actually thought 
> that I had fixed that before the last draft went in but apparently I 
> missed this one.
>
> Assuming that you agree with deleting "is declaring" for reasons 
> stated above, I'm fine with leaving everything else as is and staying 
> quiet on what the server has to do with the scopes.
>
>  -- Justin
>
>     I think that the existing wording is superior to the proposed
>     changed wording.  The existing wording is:
>
>        scope
>
>     <http://tools.ietf.org/html/rfc6749#section-3.3>) that the client
>     is declaring that
>
>     For instance, the current “client is declaring” wording will
>     always be correct, whereas as the change to “client can use”
>     wording implies a restriction on client behavior that is not
>     always applicable.  The “client is declaring” wording was specific
>     and purposefully chosen, and I think should be retained.  In
>     particular, we can’t do anything that implies that only the
>     registered scopes values can be used.  At the OAuth spec level,
>     this is a hint as to possible future client behavior – not a
>     restriction on future client behavior.
>
>     “matching” or “regex” language in the spec pertaining to scopes –
>     as it’s not actionable.
>
>     Alternatively, I’d also be fine with deleting this feature
>     entirely, as I don’t think it’s useful in the general case.
>
>     -- Mike
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] *On Behalf Of *Justin Richer
>     *To:* Tim Bray; [email-masked] <mailto:[email-masked]>
>     I’d use the existing wording; it’s perfectly clear.  Failing that,
>     if there’s strong demand for registration of structured scopes,
>     bless the use of regexes, either PCREs or some careful subset.
>
>
>     Server MAY register a Client with a default set of  scopes.”  It
>     adds no value; if the client doesn’t declare scopes, the client
>     doesn’t declare scopes, that’s all.  -T
>
>
>     Remember, all of these fields aren't just for the client
>     *request*, they're also for the server's *response* to either a
>     POST, PUT, or GET request. (I didn't realize it, but perhaps the
>     wording as stated right now doesn't make that clear -- I need to
>     fix that.) The value that it adds is if the client doesn't ask for
>     any particular scopes, the server can still assign it scopes and
>     the client can do something smart with that. Dumb clients are
>     allowed to ignore it if it doesn't mean anything to them.
>
>     This is how our server implementation actually works right now. If
>     the client doesn't ask for anything specific at registration, the
>     server hands it a bag of "default" scopes. Same thing happens at
>     auth time -- if the client doesn't ask for any particular scopes,
>     the server hands it all of its registered scopes as a default.
>     Granted, on our server, scopes are just simple strings right now,
>     so they get compared at the auth endpoint with an exact
>     string-match metric and set-based logic.
>
>      -- Justin
>
>
>
>         expectation that things will be specified tightly enough that
>         I can write code to implement as specified.  -T
>
>         On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>         they're necessarily API-specific. The only interoperable bit
>         is that there's *some* place to put the values and that it's
>         expressed as a bag of space-separated strings. How those
>         strings get interpreted and enforced (which is really what's
>         at stake here) is up to the AS and PR (or a higher-level
>         protocol like UMA).
>
>          -- Justin
>
>             On Apr 15, 2013 6:54 AM, "Justin Richer"
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>             You are correct that the idea behind the "scope" parameter
>             at registration is a constraint on authorization-time
>             scopes that are made available. It's both a means for the
>             client to request a set of valid scopes and for the server
>             to provision (and echo back to the client) a set of valid
>             scopes.
>
>             simple-string scope values. Any regular expression syntax
>             we pick here is guaranteed to be incompatible with
>             something, and I think the complexity doesn't buy much.
>             Also, I think you suddenly have a potential security issue
>             if you have a bad regex in place on either end.
>
>             registration scopes and enforce them however it wants to.
>             The real trick comes not from assigning the values to a
>             particular client but to enforcing them, and I think
>             that's always going to be service-specific. We're just not

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 Apr 2013 15:28:19 +0000

Thanks, Justin.  I agree with the need for the generic two-sided language.  I’d still keep this language for scope, because we want to capture the “declaring” aspect in this case:

You should probably also reinforce that scope values are service-specific and may not consist only of a static set of string values, and that therefore, in some cases, an exhaustive list of registered scope values is not possible.

                                                            -- Mike

From: Justin Richer [mailto:[email-masked]]
Sent: Monday, April 15, 2013 12:29 PM
To: Mike Jones
Cc: Tim Bray; [email-masked]
Subject: Re: [OAUTH-WG] Registration: Scope Values

I think that because the "declaration" issue affects all parameters in the list, not just scope, we should adopt this in a higher level paragraph and leave it out of the individual parameter descriptions. Thus, something like this inserted as the second paragraph in section 2:
The client metadata values serve two parallel purposes in the overall OAuth Dynamic Registration protocol:

 - the Client requesting its desired values for each parameter to the Authorization Server in a [register] or [update] request,
 - the Authorization Server informing the Client of the current values of each parameter that the Client has been registered to use through a [client information response].

An Authorization Server MAY override any value that a Client requests during the registration process (including any omitted values) and replace the requested value with a default. The normative indications in the following list apply to the Client's declaration of its desired values.

The Authorization Server SHOULD provide documentation for any fields that it requires to be filled in by the client or to have particular values or formats. Extensions and profiles...

And then remove the sidedness-language from the scope parameter and any other parameters where it might have crept in inadvertently.

 -- Justin

                                                            -- Mike

From: Justin Richer [mailto:[email-masked]]
Sent: Monday, April 15, 2013 9:57 AM
To: Mike Jones
Cc: Tim Bray; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Registration: Scope Values

 -- Justin

   scope

                                                            -- Mike

 -- Justin

 -- Justin

 -- Justin

-T

   scope

      set of scopes.

Comments? Improvements?

 -- Justin

--

James Manger

OAuth mailing list

---

From: Tim Bray <[email-masked]>
Date: Thu, 18 Apr 2013 08:36:04 -0700

On the server-to-client side, what does “registered to use” mean?  Does it
mean that the client should assume that any scopes not on the list WILL not
be granted, MAY not be granted.... or what?  Is this already covered
elsewhere? -T

On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones <[email-masked]>wrote:

>  Thanks, Justin.  I agree with the need for the generic two-sided
> language.  I’d still keep this language for scope, because we want to
> capture the “declaring” aspect in this case:****
>
> ** **
>
> “Space separated list of scope values (as described in OAuth 2.0 Section 3.3
> [RFC6749] <http://tools.ietf.org/html/rfc6749#section-3.3>) that the
> client is declaring to the server that it may use when requesting access
> tokens and that the server is declaring to the client that it is registered
> to use when requesting access tokens.”.****
>
> ** **
>
> You should probably also reinforce that scope values are service-specific
> and may not consist only of a static set of string values, and that
> therefore, in some cases, an exhaustive list of registered scope values is
> not possible.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Justin Richer [mailto:[email-masked]]
> *Sent:* Monday, April 15, 2013 12:29 PM
>
> *To:* Mike Jones
> I think that because the "declaration" issue affects all parameters in the
> list, not just scope, we should adopt this in a higher level paragraph and
> leave it out of the individual parameter descriptions. Thus, something like
> this inserted as the second paragraph in section 2:****
>
>  - the Client requesting its desired values for each parameter to the
> Authorization Server in a [register] or [update] request,
>  - the Authorization Server informing the Client of the current values of
> each parameter that the Client has been registered to use through a [client
> information response].
>
> An Authorization Server MAY override any value that a Client requests
> during the registration process (including any omitted values) and replace
> the requested value with a default. The normative indications in the
> following list apply to the Client's declaration of its desired values.
>
> The Authorization Server SHOULD provide documentation for any fields that
> it requires to be filled in by the client or to have particular values or
> formats. Extensions and profiles...****
>
>
>  -- Justin****
> On 04/15/2013 01:29 PM, Mike Jones wrote:****
>
> We could fix the one-sided language by changing****
>
> “Space separated list of scope values (as described in OAuth 2.0 Section 3.3
> [RFC6749] <http://tools.ietf.org/html/rfc6749#section-3.3>) that the
> client is declaring that it may use when requesting access tokens.”****
>
> to****
>
> “Space separated list of scope values (as described in OAuth 2.0 Section 3.3
> [RFC6749] <http://tools.ietf.org/html/rfc6749#section-3.3>) that the
> client is declaring to the server that it may use when requesting access
> tokens and that the server is declaring to the client that it is registered
> to use when requesting access tokens.”.****
>
>  ****
>
> Again, I chose the “registered to use” language carefully – because in the
> general case it’s not a restriction on the values that the client can use –
> just a statement by the server to the client that it is registered to use
> those particular values.  In both cases, the parties are making
> declarations to one another.****
>
>  ****
>
> If you adopt that language (or keep the original language), then yes, I’d
> consider this closed.****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* Justin Richer [mailto:[email-masked] <[email-masked]>]
> it) I think it's very useful. This is a very established pattern in manual
> registration: I know of many, many OAuth2 servers and clients that are set
> up where the client must pre-register a set of scopes.
>
> one-sided. The client might not have declared anything, and it might be the
> server that's declaring something to the client. Deleting the "is
> introductory paragraph(s) so that it's clear that all of these fields are
> used in both of these situations:
>
> you're fine with the existing text, can I take this as closed now? Assuming
> that you agree with deleting "is declaring" for reasons stated above, I'm
> fine with leaving everything else as is and staying quiet on what the
> server has to do with the scopes.
>
>  -- Justin
>
>
> ****
>
> On 04/15/2013 12:44 PM, Mike Jones wrote:****
>
> I think that the existing wording is superior to the proposed changed
> wording.  The existing wording is:****
>
>  ****
>
>    scope****
>
>       OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>)
> that the client is declaring that****
>
>       it may use when requesting access tokens.  If omitted, an****
>
>       Authorization Server MAY register a Client with a default set of****
>
>       scopes.****
>
>  ****
>
> restriction on client behavior that is not always applicable.  The “client
> is declaring” wording was specific and purposefully chosen, and I think
> should be retained.  In particular, we can’t do anything that implies that
> only the registered scopes values can be used.  At the OAuth spec level,
> this is a hint as to possible future client behavior – not a restriction on
> future client behavior.****
>
>  ****
>
> Also, for the reasons that Tim stated, I’m strongly against any “matching”
> or “regex” language in the spec pertaining to scopes – as it’s not
> actionable.****
>
>  ****
>
> don’t think it’s useful in the general case.****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Justin Richer

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 Apr 2013 15:55:03 +0000

I don’t think it’s possible to define what it means in an interoperable way because OAuth didn’t specify scopes in an interoperable way.  No, I don’t like that either, but I think that’s where things are.  That’s why I was advocating deleting this registration feature entirely.

But understanding it might be useful in some contexts, I’m OK keeping it, provided we be clear that the semantics of “registered to use” are service-specific.

                                                            -- Mike

From: Tim Bray [mailto:[email-masked]]
Sent: Thursday, April 18, 2013 8:36 AM
To: Mike Jones
Cc: Justin Richer; [email-masked]
Subject: Re: [OAUTH-WG] Registration: Scope Values

On the server-to-client side, what does “registered to use” mean?  Does it mean that the client should assume that any scopes not on the list WILL not be granted, MAY not be granted.... or what?  Is this already covered elsewhere? -T

On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Thanks, Justin.  I agree with the need for the generic two-sided language.  I’d still keep this language for scope, because we want to capture the “declaring” aspect in this case:

                                                            -- Mike

From: Justin Richer [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, April 15, 2013 12:29 PM

To: Mike Jones

 -- Justin

                                                            -- Mike

 -- Justin

   scope

                                                            -- Mike

 -- Justin

 -- Justin

 -- Justin

-T

   scope

      set of scopes.

Comments? Improvements?

 -- Justin

--

James Manger

OAuth mailing list

---

From: Tim Bray <[email-masked]>
Date: Thu, 18 Apr 2013 09:03:49 -0700

I’m unconvinced, Mike.  Obviously you’re right about the looseness of
OAuth2 scope specification, but this is a very specific semantic of what
happens when you register, and I don’t think we’re bound by history here.
If we can’t safely say anything about what the list of scopes means, then
I'm with you let's take them out.  But the most obvious intended semantic
is (from the client) “I promise to ask only for these” and from the server
“These are the only ones I’ll give you tokens for.”  Or does someone have
use-cases for an alternative semantic?

To make this concrete, I propose the following:

“Space-separated list of scope values (as described in OAuth 2.0 Section 3.3
[RFC6749] <http://tools.ietf.org/html/rfc6749#section-3.3>) that the client
is declaring to the server that it will restrict itself to when requesting
access tokens, and that the server is declaring to the client that it is
registered to use when requesting access tokens.  Clients SHOULD assume
that servers will refuse to grant access tokens for scopes not in the list
provided by the server.”

**

On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones <[email-masked]>wrote:

>  I don’t think it’s possible to define what it means in an interoperable
> way because OAuth didn’t specify scopes in an interoperable way.  No, I
> don’t like that either, but I think that’s where things are.  That’s why I
> was advocating deleting this registration feature entirely.****
>
> ** **
>
> But understanding it might be useful in some contexts, I’m OK keeping it,
> provided we be clear that the semantics of “registered to use” are
> service-specific.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Tim Bray [mailto:[email-masked]]
> *Sent:* Thursday, April 18, 2013 8:36 AM
> *To:* Mike Jones
> *Cc:* Justin Richer; [email-masked]
>
> elsewhere? -T****
> On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones <[email-masked]>
> wrote:****
>
> *Sent:* Monday, April 15, 2013 12:29 PM****
>
>
> *To:* Mike Jones

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 18 Apr 2013 16:13:42 +0000

If I don’t specify a scope, then the server can allocate a default (or default set), thus that breaks the semantics you describe

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Bray
Sent: Thursday, April 18, 2013 9:04 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Registration: Scope Values

I’m unconvinced, Mike.  Obviously you’re right about the looseness of OAuth2 scope specification, but this is a very specific semantic of what happens when you register, and I don’t think we’re bound by history here.   If we can’t safely say anything about what the list of scopes means, then I'm with you let's take them out.  But the most obvious intended semantic is (from the client) “I promise to ask only for these” and from the server “These are the only ones I’ll give you tokens for.”  Or does someone have use-cases for an alternative semantic?

To make this concrete, I propose the following:
“Space-separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>) that the client is declaring to the server that it will restrict itself to when requesting access tokens, and that the server is declaring to the client that it is registered to use when requesting access tokens.  Clients SHOULD assume that servers will refuse to grant access tokens for scopes not in the list provided by the server.”

On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I don’t think it’s possible to define what it means in an interoperable way because OAuth didn’t specify scopes in an interoperable way.  No, I don’t like that either, but I think that’s where things are.  That’s why I was advocating deleting this registration feature entirely.

                                                            -- Mike

From: Tim Bray [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, April 18, 2013 8:36 AM
To: Mike Jones
Cc: Justin Richer; [email-masked]<mailto:[email-masked]>

                                                            -- Mike

To: Mike Jones

 -- Justin

                                                            -- Mike

 -- Justin

   scope

                                                            -- Mike

 -- Justin

 -- Justin

 -- Justin

-T

   scope

      set of scopes.

Comments? Improvements?

 -- Justin

--

James Manger

OAuth mailing list

---

From: Phil Hunt <[email-masked]>
Date: Thu, 18 Apr 2013 09:18:03 -0700

There are a number of cases that all demand a more parsable scope. 

One of the cases is multi resource scopes. 

Would it not be reasonable to develop another draft that defines a simple json structure that allows different uris to be matched with specific scope values?

I also wonder if registration is the place to redefine or further define scope. 

IOW a separate draft can be totally optional. But can be used by multi-resource sites to solve oauth2s limited scope capability. 

Phil

On 2013-04-18, at 9:03, Tim Bray <[email-masked]> wrote:

> “Space-separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the server that it will restrict itself to when requesting access tokens, and that the server is declaring to the client that it is registered to use when requesting access tokens.  Clients SHOULD assume that servers will refuse to grant access tokens for scopes not in the list provided by the server.”
> 
> 
> 
> 
> 
> On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones <[email-masked]> wrote:
>> On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones <[email-masked]> wrote:
>> 
>> “Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the server that it may use when requesting access tokens and that the server is declaring to the client that it is registered to use when requesting access tokens.”.
>> 
>>  
>> 
>> “Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that it may use when requesting access tokens.”
>> 
>> to
>> 
>> “Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring to the server that it may use when requesting access tokens and that the server is declaring to the client that it is registered to use when requesting access tokens.”.
>> 
>>  
>>

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 18 Apr 2013 16:25:53 +0000

I agree that we shouldn't try to "solve" scope in registration. I think it makes the most sense for registration to be as hands-off about scope as core OAuth is.

 -- Justin

On Apr 18, 2013, at 12:18 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On 2013-04-18, at 9:03, Tim Bray <[email-masked]<mailto:[email-masked]>> wrote:

                                                            -- Mike

                                                            -- Mike

To: Mike Jones

 -- Justin

                                                            -- Mike

 -- Justin

   scope

                                                            -- Mike

 -- Justin

 -- Justin

 -- Justin

-T

   scope

      set of scopes.

Comments? Improvements?

 -- Justin

--

James Manger

OAuth mailing list

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 18 Apr 2013 16:25:53 +0000

This doesn't actually break the semantics because the client MUST accept what the server tells it over anything that it asks for in the first place. The server has the final say. So in this case, if your client asks for nothing, the server says "A B C", the client now knows it can ask for "A B C" scopes.

I'm still in favor of not putting the restricting language in the scope definition at all, instead have it say something like:

“Space-separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>) that the Client can use when requesting access tokens from the Authorization Server. As scope values are service specific, the means of the Authorization Server enforcing this restriction are outside the scope of this specification.”

Couple this with the overall paragraph that says that the client is requesting values that the server is potentially overriding with its declarations, and I think that addresses everything without getting into confusing language that doesn't add to interoperability.

 -- Justin

On Apr 18, 2013, at 12:13 PM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tim Bray
Sent: Thursday, April 18, 2013 9:04 AM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Registration: Scope Values

                                                            -- Mike

                                                            -- Mike

To: Mike Jones

 -- Justin

                                                            -- Mike

 -- Justin

   scope

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]On Behalf Of Justin Richer
Sent: Monday, April 15, 2013 8:05 AM
To: Tim Bray; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Registration: Scope Values

 -- Justin

 -- Justin

 -- Justin

-T

   scope

      set of scopes.

Comments? Improvements?

 -- Justin

--

James Manger

OAuth mailing list

---

From: Tim Bray <[email-masked]>
Date: Thu, 18 Apr 2013 09:26:01 -0700

Hm... how so?  If a server is able to specify in advance which set of
scopes it will honor (which may or may not be related to what the client
specified in the registration) I can see that being useful.  I don’t see a
requirement for a linkage between the client’s request and the server’s
response.  -T

On Thu, Apr 18, 2013 at 9:13 AM, Anthony Nadalin <[email-masked]>wrote:

>  If I don’t specify a scope, then the server can allocate a default (or
> default set), thus that breaks the semantics you describe****
>
> ** **
>
> Of *Tim Bray
> *Sent:* Thursday, April 18, 2013 9:04 AM
> *To:* Mike Jones
> *Cc:* [email-masked]
>
> use-cases for an alternative semantic?****
>
> ** **
>
> To make this concrete, I propose the following:****
>
> client is declaring to the server that it will restrict itself to when
> requesting access tokens, and that the server is declaring to the client
> that it is registered to use when requesting access tokens.  Clients
> SHOULD assume that servers will refuse to grant access tokens for scopes
> not in the list provided by the server.”****
>
> ** **
>
> ** **
>
> On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones <[email-masked]>
> wrote:****
>
> *Cc:* Justin Richer; [email-masked]****
>
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 18 Apr 2013 16:31:35 +0000

Client asks for nothing and the server returns “A”, thus does not match your “I promise to ask only for these” and from the server “These are the only ones I’ll give you tokens for.”” As the client may also ask for X and get X.

From: Tim Bray [mailto:[email-masked]]
Sent: Thursday, April 18, 2013 9:26 AM
To: Anthony Nadalin
Cc: Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] Registration: Scope Values

Hm... how so?  If a server is able to specify in advance which set of scopes it will honor (which may or may not be related to what the client specified in the registration) I can see that being useful.  I don’t see a requirement for a linkage between the client’s request and the server’s response.  -T

On Thu, Apr 18, 2013 at 9:13 AM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
If I don’t specify a scope, then the server can allocate a default (or default set), thus that breaks the semantics you describe

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tim Bray
Sent: Thursday, April 18, 2013 9:04 AM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>

                                                            -- Mike

                                                            -- Mike

To: Mike Jones

 -- Justin

                                                            -- Mike

 -- Justin

   scope

                                                            -- Mike

 -- Justin

 -- Justin

 -- Justin

-T

   scope

      set of scopes.

Comments? Improvements?

 -- Justin

--

James Manger

OAuth mailing list

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 Apr 2013 17:04:28 +0000

Saying anything normative about "enforcing restrictions" is going beyond RFC 6749 semantics.  Indeed, you'd said that "I agree that we shouldn't try to "solve" scope in registration.", but talking about restrictions is going down the slippery "solving it" path.

At most we can say that the two parties are making declarations to one another about scopes that they may choose to use, but we can't assume that this is an exclusive list and that other scope values such as "urn:example:channel=HBO&urn:example:rating=G,PG-13" might not be used, even if the client registers saying that it intends to use the "OATC" scope value.  We could maybe even say that some services may use a static set of scopes and might choose to limit the scopes that a client may use to those that it declared to the server or to those that the server returned to the client.  That's a HINT that some services might do this.  But we can't say anything normative about such possible behaviors, because it goes beyond RFC 6749.

                                                            -- Mike

From: Richer, Justin P. [mailto:[email-masked]]
Sent: Thursday, April 18, 2013 9:26 AM
To: Anthony Nadalin
Cc: Tim Bray; Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] Registration: Scope Values

"Space-separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>) that the Client can use when requesting access tokens from the Authorization Server. As scope values are service specific, the means of the Authorization Server enforcing this restriction are outside the scope of this specification."

 -- Justin

If I don't specify a scope, then the server can allocate a default (or default set), thus that breaks the semantics you describe

I'm unconvinced, Mike.  Obviously you're right about the looseness of OAuth2 scope specification, but this is a very specific semantic of what happens when you register, and I don't think we're bound by history here.   If we can't safely say anything about what the list of scopes means, then I'm with you let's take them out.  But the most obvious intended semantic is (from the client) "I promise to ask only for these" and from the server "These are the only ones I'll give you tokens for."  Or does someone have use-cases for an alternative semantic?

To make this concrete, I propose the following:
"Space-separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>) that the client is declaring to the server that it will restrict itself to when requesting access tokens, and that the server is declaring to the client that it is registered to use when requesting access tokens.  Clients SHOULD assume that servers will refuse to grant access tokens for scopes not in the list provided by the server."

On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I don't think it's possible to define what it means in an interoperable way because OAuth didn't specify scopes in an interoperable way.  No, I don't like that either, but I think that's where things are.  That's why I was advocating deleting this registration feature entirely.

But understanding it might be useful in some contexts, I'm OK keeping it, provided we be clear that the semantics of "registered to use" are service-specific.

                                                            -- Mike

On the server-to-client side, what does "registered to use" mean?  Does it mean that the client should assume that any scopes not on the list WILL not be granted, MAY not be granted.... or what?  Is this already covered elsewhere? -T

On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Thanks, Justin.  I agree with the need for the generic two-sided language.  I'd still keep this language for scope, because we want to capture the "declaring" aspect in this case:

"Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>) that the client is declaring to the server that it may use when requesting access tokens and that the server is declaring to the client that it is registered to use when requesting access tokens.".

                                                            -- Mike

To: Mike Jones

 -- Justin
On 04/15/2013 01:29 PM, Mike Jones wrote:
We could fix the one-sided language by changing
"Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>) that the client is declaring that it may use when requesting access tokens."
to
"Space separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>) that the client is declaring to the server that it may use when requesting access tokens and that the server is declaring to the client that it is registered to use when requesting access tokens.".

Again, I chose the "registered to use" language carefully - because in the general case it's not a restriction on the values that the client can use - just a statement by the server to the client that it is registered to use those particular values.  In both cases, the parties are making declarations to one another.

If you adopt that language (or keep the original language), then yes, I'd consider this closed.

                                                            -- Mike

 -- Justin

   scope

For instance, the current "client is declaring" wording will always be correct, whereas as the change to "client can use" wording implies a restriction on client behavior that is not always applicable.  The "client is declaring" wording was specific and purposefully chosen, and I think should be retained.  In particular, we can't do anything that implies that only the registered scopes values can be used.  At the OAuth spec level, this is a hint as to possible future client behavior - not a restriction on future client behavior.

Also, for the reasons that Tim stated, I'm strongly against any "matching" or "regex" language in the spec pertaining to scopes - as it's not actionable.

So I'd propose that we leave the existing scope wording in place.  Alternatively, I'd also be fine with deleting this feature entirely, as I don't think it's useful in the general case.

                                                            -- Mike

I'd use the existing wording; it's perfectly clear.  Failing that, if there's strong demand for registration of structured scopes, bless the use of regexes, either PCREs or some careful subset.

However, I'd subtract the sentence "If omitted, an Authorization Server MAY register a Client with a default set of  scopes."  It adds no value; if the client doesn't declare scopes, the client doesn't declare scopes, that's all.  -T

 -- Justin

 -- Justin

On 04/15/2013 10:33 AM, Tim Bray wrote:
No, I mean it's not interoperable at the software-developer level.  I can't register scopes at authorization time with any predictable effect that I can write code to support, either client or server side, without out-of-line non-interoperable knowledge about the behavior of the server.

I guess I'm just not used to OAuth's culture of having no expectation that things will be specified tightly enough that I can write code to implement as specified.  -T

 -- Justin

-T

   scope

      set of scopes.

Comments? Improvements?

 -- Justin

--

James Manger

OAuth mailing list

---

From: Tim Bray <[email-masked]>
Date: Thu, 18 Apr 2013 10:09:48 -0700

OK, I went in a corner and thought about this:

   1. We currently are an OAuth 2 provider for a wide range of resources,
   and we’re feeling the demand for a registration endpoint.  Registration
   endpoints are tricky and involve legal (Terms-of-service) and business
   issues.
   2. I’m thinking that if we do get into registration, it’s going to be
   super helpful, when someone wants to register for a Client ID/Secret, to
   know what they’re going to use it for.  I suspect our business/legal
   thinking would be very different between someone registering to access G+,
   and someone registering to use the big advertising APIs.
   3. So we could probably make good use of a client-asserted list of “what
   we’re going to ask for” and feel comfy in rejecting token requests from
   clients for scopes that aren’t on the list they registered with.  Or even
   rejecting registrations if we don’t like their list of scopes.
   4. On the other hand, we could probably also solve the problem by having
   a separate registration endpoint for each API.
   5. I’m having real trouble thinking of good use that a client could make
   of a server-provided list of scopes that they are prepared to give tokens
   for.
   6. It’s also the case that people are going to insist on using tokens
   with fancy internal structures, and there’s no good interoperable way to
   use these registration-time scope lists to deal with this situation.
   7. I’d really like to stop the OAuth bleeding by resisting putting
   anything in the spec that doesn’t have crisply defined and interoperable
   semantics.

So, absent more plausible use cases, I’d be comfy with:

   1. Dropping the whole registration-time list of scopes, as Mike
   suggested, or
   2. Dropping the server-to-client part of it, and for client-to-server
   specify the semantic that the client MUST NOT request tokens for scopes not
   in the registration-time list, or
   3. Retaining both directions only if they come with crisply defined
   interoperable semantics

On Thu, Apr 18, 2013 at 9:31 AM, Anthony Nadalin <[email-masked]>wrote:

>  Client asks for nothing and the server returns “A”, thus does not match
> your “I promise to ask only for these” and from the server “These are the
> only ones I’ll give you tokens for.”” As the client may also ask for X and
> get X.****
>
> ** **
>
> *Sent:* Thursday, April 18, 2013 9:26 AM
> *To:* Anthony Nadalin
> *Cc:* Mike Jones; [email-masked]
>
> response.  -T****
> On Thu, Apr 18, 2013 at 9:13 AM, Anthony Nadalin <[email-masked]>
> wrote:****
>
> *Cc:* [email-masked]****
> On 04/15/2013 10:52 AM, Tim Bray wrote:****
>
> following text for that section:****
>
>    scope****
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 18 Apr 2013 13:47:06 -0400

Thing is, there's nothing normative about the enforcing statement that I 
made below, so I don't think it's any more restrictive than RFC 6749 
which lets the AS replace a client's requested scopes at the time of 
token issuance with whatever it pleases. But that said, I'd be just as 
happy to leave it like this with no further restrictions:

Space-separated list of scope values (as described in OAuth 2.0 
Section 3.3 [RFC6749] <http://tools.ietf.org/html/rfc6749#section-3.3>) 
that the Client can use when requesting access tokens from the 
Authorization Server.

And call it a day. This parallels the text for grant_types ("Array of 
OAuth 2.0 grant types that the Client may use [when accessing the Token 
Endpoint].") and response_types ("Array of the OAuth 2.0 response types 
that the Client may use [when accessing the Authorization Endpoint]."), 
and I think this is the correct approach. I only started to add the 
restrictive text because I thought that people were making the argument 
that it was necessary -- I'd rather not have it.

Plus, it's an optional field in the metadata, so if you've got 
structured scopes where this doesn't make sense, don't use it. If you 
don't do a per-client scope restriction, don't use it.

The interoperability is defined in light of the interoperability of 
scopes themselves: this is a field to request/grant a bag of strings 
that only make sense in light of a given API. For that to make real 
sense, I think that we need to differentiate an OAuth client as a 
generic *library* from an OAuth client as a generic accessing 
*application*. It's very useful for a generic *library* that handles the 
authorization layer for an application to have a slot for registering 
scopes and finding out what scopes the app's been registered for. It's 
up to the app (not the library) to figure out how to translate those 
into scopes to ask for at authorization time. Sometimes that means just 
passing the string, and sometimes it means the construction of a 
structured value like 
"urn:example:channel=HBO&urn:example:rating=G,PG-13". The library 
doesn't care, the application does, and we should focus on 
interoperability from the library's perspective. Similarly, on the 
server side, the libraries will tell you the bag of scopes that the 
client was registered for, and what bag of scopes the client asked for 
during authorization. It's up to the server *application* to harmonize 
those two in a way that makes sense for the API that it's protecting. 
Just like it's up to the protected resource *application* to figure out 
what a scope means in a given context.

So let's just leave it unrestricted but keep the slot for communicating 
this piece of information with the same semantics that the communication 
between the client and server take on for every other field: client asks 
for a thing, server says that client actually gets a thing, and it's 
implicitly up to the server to do the right thing and enforce things in 
a way that makes sense for the application no matter what the client does.

To take Tony's example, client requests no scopes at registration, 
server grants scope "A" at registration. Client then requests scope "X" 
at authorization, server is free to deny the request (invalid_scope 
error), allow authorization because it knows how "A" and "X" are 
related, require user intervention, or really, whatever it likes. The 
libraries, where I argue the interoperability cries really matter, don't 
care, and shouldn't care.

  -- Justin

On 04/18/2013 01:04 PM, Mike Jones wrote:
>
> Saying anything normative about "enforcing restrictions" is going 
> beyond RFC 6749 semantics.  Indeed, you'd said that "I agree that we 
> shouldn't try to "solve" scope in registration.", but talking about 
> restrictions is going down the slippery "solving it" path.
>
> At most we can say that the two parties are making declarations to one 
> another about scopes that they may choose to use, but we can't assume 
> that this is an exclusive list and that other scope values such as 
> "urn:example:channel=HBO&urn:example:rating=G,PG-13" might not be 
> used, even if the client registers saying that it intends to use the 
> "OATC" scope value.  We could maybe even say that some services may 
> use a static set of scopes and might choose to limit the scopes that a 
> client may use to those that it declared to the server or to those 
> that the server returned to the client.  That's a HINT that some 
> services might do this.  But we can't say anything normative about 
> such possible behaviors, because it goes beyond RFC 6749.
>
> -- Mike
>
> *From:*Richer, Justin P. [mailto:[email-masked]]
> *Cc:* Tim Bray; Mike Jones; [email-masked]
> This doesn't actually break the semantics because the client MUST 
> accept what the server tells it over anything that it asks for in the 
> first place. The server has the final say. So in this case, if your 
> client asks for nothing, the server says "A B C", the client now knows 
> it can ask for "A B C" scopes.
>
> I'm still in favor of not putting the restricting language in the 
> scope definition at all, instead have it say something like:
>
>     "Space-separated list of scope values (as described in OAuth 2.0
>     Section 3.3 [RFC6749]
>     <http://tools.ietf.org/html/rfc6749#section-3.3>) that the Client
>     can use when requesting access tokens from the Authorization
>     Server. As scope values are service specific, the means of the
>     Authorization Server enforcing this restriction are outside the
>     scope of this specification."
>
> Couple this with the overall paragraph that says that the client is 
> requesting values that the server is potentially overriding with its 
> declarations, and I think that addresses everything without getting 
> into confusing language that doesn't add to interoperability.
>
>  -- Justin
>
> If I don't specify a scope, then the server can allocate a default (or 
> default set), thus that breaks the semantics you describe
>
> [mailto:[email-masked] <mailto:[email-masked]>]*On Behalf 
> Of*Tim Bray
> *Sent:*Thursday, April 18, 2013 9:04 AM
> *To:*Mike Jones
> *Cc:[email-masked] <mailto:[email-masked]>
> *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
> I'm unconvinced, Mike.  Obviously you're right about the looseness of 
> OAuth2 scope specification, but this is a very specific semantic of 
> what happens when you register, and I don't think we're bound by 
> history here.   If we can't safely say anything about what the list of 
> scopes means, then I'm with you let's take them out.  But the most 
> obvious intended semantic is (from the client) "I promise to ask only 
> for these" and from the server "These are the only ones I'll give you 
> tokens for."  Or does someone have use-cases for an alternative semantic?
>
> "Space-separated list of scope values (as described in OAuth 2.0 
> Section 3.3 [RFC6749] 
> declaring to the server that it will restrict itself to when 
> requesting access tokens, and that the server is declaring to the 
> client that it is registered to use when requesting access tokens. 
> Clients SHOULD assume that servers will refuse to grant access tokens 
> for scopes not in the list provided by the server."
>
> On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I don't think it's possible to define what it means in an
>     interoperable way because OAuth didn't specify scopes in an
>     interoperable way.  No, I don't like that either, but I think
>     that's where things are.  That's why I was advocating deleting
>     this registration feature entirely.
>
>     But understanding it might be useful in some contexts, I'm OK
>     keeping it, provided we be clear that the semantics of "registered
>     to use" are service-specific.
>
>     -- Mike
>
>     *From:*Tim Bray [mailto:[email-masked] <mailto:[email-masked]>]
>     *Sent:*Thursday, April 18, 2013 8:36 AM
>     *To:*Mike Jones
>     *Cc:*Justin Richer;[email-masked] <mailto:[email-masked]>
>
>
>     *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
>     On the server-to-client side, what does "registered to use" mean?
>      Does it mean that the client should assume that any scopes not on
>     the list WILL not be granted, MAY not be granted.... or what?  Is
>     this already covered elsewhere? -T
>
>     On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>     language.  I'd still keep this language for scope, because we want
>     to capture the "declaring" aspect in this case:
>
>     "Space separated list of scope values (as described in OAuth
>     2.0Section 3.3 [RFC6749]
>     is declaring to the server that it may use when requesting access
>     tokens and that the server is declaring to the client that it is
>     registered to use when requesting access tokens.".
>
>     You should probably also reinforce that scope values are
>     service-specific and may not consist only of a static set of
>     string values, and that therefore, in some cases, an exhaustive
>     list of registered scope values is not possible.
>
>     -- Mike
>
>     *From:*Justin Richer [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Sent:*Monday, April 15, 2013 12:29 PM
>
>
>     *To:*Mike Jones
>     *Cc:*Tim Bray;[email-masked] <mailto:[email-masked]>
>     *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
>     I think that because the "declaration" issue affects all
>     parameters in the list, not just scope, we should adopt this in a
>     higher level paragraph and leave it out of the individual
>     parameter descriptions. Thus, something like this inserted as the
>     second paragraph in section 2:
>
>     values of each parameter that the Client has been registered to
>     use through a [client information response].
>
>     The Authorization Server SHOULD provide documentation for any
>     fields that it requires to be filled in by the client or to have
>     particular values or formats. Extensions and profiles...
>
>
>     And then remove the sidedness-language from the scope parameter
>     and any other parameters where it might have crept in inadvertently.
>
>      -- Justin
>
>         "Space separated list of scope values (as described in OAuth
>         2.0Section 3.3 [RFC6749]
>         <http://tools.ietf.org/html/rfc6749#section-3.3>) that the
>         client is declaring that it may use when requesting access
>         tokens."
>
>         to
>
>         "Space separated list of scope values (as described in OAuth
>         2.0Section 3.3 [RFC6749]
>         <http://tools.ietf.org/html/rfc6749#section-3.3>) that the
>         client is declaring to the server that it may use when
>         requesting access tokens and that the server is declaring to
>         the client that it is registered to use when requesting access
>         tokens.".
>
>         Again, I chose the "registered to use" language carefully --
>         because in the general case it's not a restriction on the
>         values that the client can use -- just a statement by the
>         server to the client that it is registered to use those
>         particular values.  In both cases, the parties are making
>         declarations to one another.
>
>         *Sent:*Monday, April 15, 2013 9:57 AM
>         *To:*Mike Jones
>         *Cc:*Tim Bray;[email-masked] <mailto:[email-masked]>
>         *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
>         implemented it) I think it's very useful. This is a very
>         established pattern in manual registration: I know of many,
>         many OAuth2 servers and clients that are set up where the
>         client must pre-register a set of scopes.
>
>         I don't like the language of "the client is declaring" because
>         it's too one-sided. The client might not have declared
>         anything, and it might be the server that's declaring
>         something to the client. Deleting the "is declaring" bit
>         removes that unintended restriction of the language while
>         keeping the original meaning intact. I actually thought that I
>         had fixed that before the last draft went in but apparently I
>         missed this one.
>
>         I will work on clarifying the intent of the whole metadata set
>         in its introductory paragraph(s) so that it's clear that all
>         of these fields are used in both of these situations:
>
>         This should hopefully clear up the issue in the editor's note
>         that I currently have at the top of that section right now, too.
>
>         Mike, since you were the one who originally brought up the
>         issue, and you're fine with the existing text, can I take this
>         as closed now? Assuming that you agree with deleting "is
>         declaring" for reasons stated above, I'm fine with leaving
>         everything else as is and staying quiet on what the server has
>         to do with the scopes.
>
>          -- Justin
>
>             I think that the existing wording is superior to the
>             proposed changed wording.  The existing wording is:
>
>                scope
>
>                   OAuth 2.0Section 3.3 [RFC6749]
>             <http://tools.ietf.org/html/rfc6749#section-3.3>) that the
>             client is declaring that
>
>             For instance, the current "client is declaring" wording
>             will always be correct, whereas as the change to "client
>             can use" wording implies a restriction on client behavior
>             that is not always applicable.  The "client is declaring"
>             wording was specific and purposefully chosen, and I think
>             should be retained.  In particular, we can't do anything
>             that implies that only the registered scopes values can be
>             used.  At the OAuth spec level, this is a hint as to
>             possible future client behavior -- not a restriction on
>             future client behavior.
>
>             Also, for the reasons that Tim stated, I'm strongly
>             against any "matching" or "regex" language in the spec
>             pertaining to scopes -- as it's not actionable.
>
>             So I'd propose that we leave the existing scope wording in
>             place.  Alternatively, I'd also be fine with deleting this
>             feature entirely, as I don't think it's useful in the
>             general case.
>
>             -- Mike
>
>             *From:[email-masked]
>             <mailto:[email-masked]>[mailto:[email-masked]]*On
>             Behalf Of*Justin Richer
>             *Sent:*Monday, April 15, 2013 8:05 AM
>             *To:*Tim Bray;[email-masked] <mailto:[email-masked]>
>             *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>
>             I'd use the existing wording; it's perfectly clear.
>              Failing that, if there's strong demand for registration
>             of structured scopes, bless the use of regexes, either
>             PCREs or some careful subset.
>
>
>             However, I'd subtract the sentence "If omitted, an
>             Authorization Server MAY register a Client with a default
>             set of  scopes."  It adds no value; if the client doesn't
>             declare scopes, the client doesn't declare scopes, that's
>             all.  -T
>
>
>             *request*, they're also for the server's *response* to
>             either a POST, PUT, or GET request. (I didn't realize it,
>             but perhaps the wording as stated right now doesn't make
>             that clear -- I need to fix that.) The value that it adds
>             is if the client doesn't ask for any particular scopes,
>             the server can still assign it scopes and the client can
>             do something smart with that. Dumb clients are allowed to
>             ignore it if it doesn't mean anything to them.
>
>             This is how our server implementation actually works right
>             now. If the client doesn't ask for anything specific at
>             registration, the server hands it a bag of "default"
>             scopes. Same thing happens at auth time -- if the client
>             doesn't ask for any particular scopes, the server hands it
>             all of its registered scopes as a default. Granted, on our
>             server, scopes are just simple strings right now, so they
>             get compared at the auth endpoint with an exact
>             On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer
>             What would you suggest for wording here, then? Keeping in
>             mind that we cannot (and don't want to) prohibit
>             expression-based scopes.
>
>              -- Justin
>
>                 No, I mean it's not interoperable at the
>                 software-developer level.  I can't register scopes at
>                 authorization time with any predictable effect that I
>                 can write code to support, either client or server
>                 side, without out-of-line non-interoperable knowledge
>                 I guess I'm just not used to OAuth's culture of having
>                 no expectation that things will be specified tightly
>                 enough that I can write code to implement as
>                 specified.  -T
>
>                 Scopes aren't meant to be interoperable between
>                 services since they're necessarily API-specific. The
>                 only interoperable bit is that there's *some* place to
>                 put the values and that it's expressed as a bag of
>                 space-separated strings. How those strings get
>                 interpreted and enforced (which is really what's at
>                 stake here) is up to the AS and PR (or a higher-level
>                 protocol like UMA).
>
>                  -- Justin
>
>                     This, as written, has zero interoperability. I
>                     think this feature can really only be made useful
>                     in the case where scopes are fixed strings.
>
>                     -T
>
>                     authorization-time scopes that are made available.
>                     It's both a means for the client to request a set
>                     of valid scopes and for the server to provision
>                     language for scope expressions. For that to work,
>                     all servers would need to be able to process the
>                     regular expressions for all clients, even if the
>                     servers themselves only support simple-string
>                     scope values. Any regular expression syntax we
>                     pick here is guaranteed to be incompatible with
>                     something, and I think the complexity doesn't buy
>                     much. Also, I think you suddenly have a potential
>                     incoming registration scopes and enforce them
>                     however it wants to. The real trick comes not from
>                     assigning the values to a particular client but to
>                     enforcing them, and I think that's always going to
>                     be service-specific. We're just not as clear on
>                     that as we could be.
>
>                     After looking over everyone's comments so far, I'd
>                     like to propose the following text for that section:
>
>
>                         scope
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 Apr 2013 17:52:45 +0000

I could live with it if you expanded the text slightly as follows.  Otherwise people will keep asking questions that they deserve an answer to, even if the answer is "see the service documentation".

Space-separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>) that the Client can use when requesting access tokens from the Authorization Server.  The semantics of this list are service specific.

                                                                -- Mike

From: Justin Richer [mailto:[email-masked]]
Sent: Thursday, April 18, 2013 10:47 AM
To: Mike Jones
Cc: Anthony Nadalin; Tim Bray; [email-masked]
Subject: Re: [OAUTH-WG] Registration: Scope Values

Thing is, there's nothing normative about the enforcing statement that I made below, so I don't think it's any more restrictive than RFC 6749 which lets the AS replace a client's requested scopes at the time of token issuance with whatever it pleases. But that said, I'd be just as happy to leave it like this with no further restrictions:

Space-separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]<http://tools.ietf.org/html/rfc6749#section-3.3>) that the Client can use when requesting access tokens from the Authorization Server.

And call it a day. This parallels the text for grant_types ("Array of OAuth 2.0 grant types that the Client may use [when accessing the Token Endpoint].") and response_types ("Array of the OAuth 2.0 response types that the Client may use [when accessing the Authorization Endpoint]."), and I think this is the correct approach. I only started to add the restrictive text because I thought that people were making the argument that it was necessary -- I'd rather not have it.

Plus, it's an optional field in the metadata, so if you've got structured scopes where this doesn't make sense, don't use it. If you don't do a per-client scope restriction, don't use it.

The interoperability is defined in light of the interoperability of scopes themselves: this is a field to request/grant a bag of strings that only make sense in light of a given API. For that to make real sense, I think that we need to differentiate an OAuth client as a generic *library* from an OAuth client as a generic accessing *application*. It's very useful for a generic *library* that handles the authorization layer for an application to have a slot for registering scopes and finding out what scopes the app's been registered for. It's up to the app (not the library) to figure out how to translate those into scopes to ask for at authorization time. Sometimes that means just passing the string, and sometimes it means the construction of a structured value like "urn:example:channel=HBO&urn:example:rating=G,PG-13". The library doesn't care, the application does, and we should focus on interoperability from the library's perspective. Similarly, on the server side, the libraries will tell you the bag of scopes that the client was registered for, and what bag of scopes the client asked for during authorization. It's up to the server *application* to harmonize those two in a way that makes sense for the API that it's protecting. Just like it's up to the protected resource *application* to figure out what a scope means in a given context.

So let's just leave it unrestricted but keep the slot for communicating this piece of information with the same semantics that the communication between the client and server take on for every other field: client asks for a thing, server says that client actually gets a thing, and it's implicitly up to the server to do the right thing and enforce things in a way that makes sense for the application no matter what the client does.

To take Tony's example, client requests no scopes at registration, server grants scope "A" at registration. Client then requests scope "X" at authorization, server is free to deny the request (invalid_scope error), allow authorization because it knows how "A" and "X" are related, require user intervention, or really, whatever it likes. The libraries, where I argue the interoperability cries really matter, don't care, and shouldn't care.

 -- Justin

                                                            -- Mike

From: Richer, Justin P. [mailto:[email-masked]]
Sent: Thursday, April 18, 2013 9:26 AM
To: Anthony Nadalin
Cc: Tim Bray; Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Registration: Scope Values

 -- Justin

                                                            -- Mike

                                                            -- Mike

To: Mike Jones

 -- Justin

                                                            -- Mike

 -- Justin

   scope

                                                            -- Mike

 -- Justin

 -- Justin

 -- Justin

-T

   scope

      set of scopes.

Comments? Improvements?

 -- Justin

--

James Manger

OAuth mailing list

---

From: Phil Hunt <[email-masked]>
Date: Thu, 18 Apr 2013 10:54:07 -0700

Why not:

> "A value corresponding to scope as described in OAuth 2, Section 3.3 [RFC6749]. The registered Client may use these to indicate all of the scopes that a client MAY use when requesting tokens from an Authorization Server."

In the above, I avoid re-defining scope at all. However describing why they are included in registration is useful.  IMHO I think scope at registration is useful for life-cycle approval workflows.

In some cases you could say they are also the default list, but I'm not sure it helps inter-operability so its not clear it needs to be mentioned.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-04-18, at 10:47 AM, Justin Richer wrote:

> Space-separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the Client can use when requesting access tokens from the Authorization Server.
> 
>> Saying anything normative about “enforcing restrictions” is going beyond RFC 6749 semantics.  Indeed, you’d said that “I agree that we shouldn't try to "solve" scope in registration.”, but talking about restrictions is going down the slippery “solving it” path.
>>  
>> At most we can say that the two parties are making declarations to one another about scopes that they may choose to use, but we can’t assume that this is an exclusive list and that other scope values such as “urn:example:channel=HBO&urn:example:rating=G,PG-13” might not be used, even if the client registers saying that it intends to use the “OATC” scope value.  We could maybe even say that some services may use a static set of scopes and might choose to limit the scopes that a client may use to those that it declared to the server or to those that the server returned to the client.  That’s a HINT that some services might do this.  But we can’t say anything normative about such possible behaviors, because it goes beyond RFC 6749.
>>  
>>                                                             -- Mike
>>  
>> “Space-separated list of scope values (as described in OAuth 2.0 Section 3.3 [RFC6749]) that the Client can use when requesting access tokens from the Authorization Server. As scope values are service specific, the means of the Authorization Server enforcing this restriction are outside the scope of this specification.”
>>  
>> On Apr 18, 2013, at 12:13 PM, Anthony Nadalin <[email-masked]> wrote:
>> 
>> 
>> From: [email-masked] [mailto:[email-masked]]On Behalf Of Justin Richer

---

From: Tim Bray <[email-masked]>
Date: Thu, 18 Apr 2013 10:56:46 -0700

On Thu, Apr 18, 2013 at 10:47 AM, Justin Richer <[email-masked]> wrote:

> It's very useful for a generic *library* that handles the authorization
> layer for an application to have a slot for registering scopes and finding
> out what scopes the app's been registered for.
>

I don’t see how it’s useful in the slightest if there’s no defined semantic
for what “registration” actually means, i.e. what result is to be expected
when sending or receiving a list of scopes.   -T

>  Saying anything normative about “enforcing restrictions” is going beyond
> RFC 6749 semantics.  Indeed, you’d said that “I agree that we shouldn't
> try to "solve" scope in registration.”, but talking about restrictions is
> going down the slippery “solving it” path.****
>
> ** **
>
> another about scopes that they may choose to use, but we can’t assume that
> this is an exclusive list and that other scope values such as “
> urn:example:channel=HBO&urn:example:rating=G,PG-13” might not be used,
> even if the client registers saying that it intends to use the “OATC” scope
> value.  We could maybe even say that some services may use a static set of
> scopes and might choose to limit the scopes that a client may use to those
> that it declared to the server or to those that the server returned to the
> client.  That’s a HINT that some services might do this.  But we can’t say
> anything normative about such possible behaviors, because it goes beyond
> RFC 6749.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Richer, Justin P. [mailto:[email-masked] <[email-masked]>]
> This doesn't actually break the semantics because the client MUST accept
> what the server tells it over anything that it asks for in the first place.
> The server has the final say. So in this case, if your client asks for
> nothing, the server says "A B C", the client now knows it can ask for "A B
> C" scopes. ****
>
> ** **
>
> I'm still in favor of not putting the restricting language in the scope
> definition at all, instead have it say something like:****
>
> ** **
>
> Client can use when requesting access tokens from the Authorization Server.
> As scope values are service specific, the means of the Authorization Server
> enforcing this restriction are outside the scope of this specification.”**
> **
>
> ** **
>
> declarations, and I think that addresses everything without getting into
> confusing language that doesn't add to interoperability. ****
>
> ** **
>
>  -- Justin****
>
> ** **
>
> On Apr 18, 2013, at 12:13 PM, Anthony Nadalin <[email-masked]>
> wrote:****
>
>
>
> ****
>
> *From:* [email-masked] [mailto:oauth <oauth>[email-masked]] *On
> Behalf Of *Tim Bray
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>
> ]*On Behalf Of *Justin Richer

---

From: Justin Richer <[email-masked]>
Date: Thu, 18 Apr 2013 13:59:31 -0400

I would be fine with that addendum.

  -- Justin

On 04/18/2013 01:52 PM, Mike Jones wrote:
>
> I could live with it if you expanded the text slightly as follows.  
> Otherwise people will keep asking questions that they deserve an 
> answer to, even if the answer is "see the service documentation".
>
> <http://tools.ietf.org/html/rfc6749#section-3.3>) that the Client can 
> use when requesting access tokens from the Authorization Server.  The 
> semantics of this list are service specific.
>
> -- Mike
>
> *Sent:* Thursday, April 18, 2013 10:47 AM
> *To:* Mike Jones
> *Cc:* Anthony Nadalin; Tim Bray; [email-masked]
> Thing is, there's nothing normative about the enforcing statement that 
> I made below, so I don't think it's any more restrictive than RFC 6749 
> <http://tools.ietf.org/html/rfc6749#section-3.3>) that the Client can 
> use when requesting access tokens from the Authorization Server.
>
> OAuth 2.0 grant types that the Client may use [when accessing the 
> Token Endpoint].") and response_types ("Array of the OAuth 2.0 
> response types that the Client may use [when accessing the 
> Authorization Endpoint]."), and I think this is the correct approach. 
> I only started to add the restrictive text because I thought that 
> people were making the argument that it was necessary -- I'd rather 
> not have it.
>
>   
>
> *application*. It's very useful for a generic *library* that handles 
> the authorization layer for an application to have a slot for 
> registering scopes and finding out what scopes the app's been 
> registered for. It's up to the app (not the library) to figure out how 
> to translate those into scopes to ask for at authorization time. 
> Sometimes that means just passing the string, and sometimes it means 
> the construction of a structured value like 
> Just like it's up to the protected resource *application* to figure 
> out what a scope means in a given context.
>
> So let's just leave it unrestricted but keep the slot for 
> communicating this piece of information with the same semantics that 
> the communication between the client and server take on for every 
> other field: client asks for a thing, server says that client actually 
> gets a thing, and it's implicitly up to the server to do the right 
> thing and enforce things in a way that makes sense for the application 
> no matter what the client does.
>
> server grants scope "A" at registration. Client then requests scope 
> "X" at authorization, server is free to deny the request 
> (invalid_scope error), allow authorization because it knows how "A" 
> and "X" are related, require user intervention, or really, whatever it 
> likes. The libraries, where I argue the interoperability cries really 
> matter, don't care, and shouldn't care.
>
>  -- Justin
>
>     beyond RFC 6749 semantics.  Indeed, you'd said that "I agree that
>     we shouldn't try to "solve" scope in registration.", but talking
>     about restrictions is going down the slippery "solving it" path.
>
>     At most we can say that the two parties are making declarations to
>     one another about scopes that they may choose to use, but we can't
>     assume that this is an exclusive list and that other scope values
>     such as "urn:example:channel=HBO&urn:example:rating=G,PG-13" might
>     not be used, even if the client registers saying that it intends
>     to use the "OATC" scope value.  We could maybe even say that some
>     services may use a static set of scopes and might choose to limit
>     the scopes that a client may use to those that it declared to the
>     server or to those that the server returned to the client.  That's
>     a HINT that some services might do this.  But we can't say
>     anything normative about such possible behaviors, because it goes
>     beyond RFC 6749.
>
>     -- Mike
>
>     *Cc:* Tim Bray; Mike Jones; [email-masked] <mailto:[email-masked]>
>     accept what the server tells it over anything that it asks for in
>     the first place. The server has the final say. So in this case, if
>     your client asks for nothing, the server says "A B C", the client
>     now knows it can ask for "A B C" scopes.
>
>         "Space-separated list of scope values (as described in OAuth
>         2.0 Section 3.3 [RFC6749]
>         Client can use when requesting access tokens from the
>         Authorization Server. As scope values are service specific,
>         the means of the Authorization Server enforcing this
>         restriction are outside the scope of this specification."
>
>     Couple this with the overall paragraph that says that the client
>     is requesting values that the server is potentially overriding
>     with its declarations, and I think that addresses everything
>     without getting into confusing language that doesn't add to
>     interoperability.
>
>      -- Justin
>
>     On Apr 18, 2013, at 12:13 PM, Anthony Nadalin
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>
>     If I don't specify a scope, then the server can allocate a default
>     (or default set), thus that breaks the semantics you describe
>
>     [mailto:[email-masked] <mailto:[email-masked]>]*On
>     Behalf Of*Tim Bray
>     I'm unconvinced, Mike.  Obviously you're right about the looseness
>     of OAuth2 scope specification, but this is a very specific
>     semantic of what happens when you register, and I don't think
>     we're bound by history here.   If we can't safely say anything
>     about what the list of scopes means, then I'm with you let's take
>     them out.  But the most obvious intended semantic is (from the
>     client) "I promise to ask only for these" and from the server
>     "These are the only ones I'll give you tokens for."  Or does
>     someone have use-cases for an alternative semantic?
>
>     is declaring to the server that it will restrict itself to when
>     Clients SHOULD assume that servers will refuse to grant access
>     tokens for scopes not in the list provided by the server."
>
>         keeping it, provided we be clear that the semantics of
>         "registered to use" are service-specific.
>
>         -- Mike
>
>         On the server-to-client side, what does "registered to use"
>         mean?  Does it mean that the client should assume that any
>         scopes not on the list WILL not be granted, MAY not be
>         granted.... or what?  Is this already covered elsewhere? -T
>
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>         Thanks, Justin.  I agree with the need for the generic
>         two-sided language.  I'd still keep this language for scope,
>         because we want to capture the "declaring" aspect in this case:
>
>         string values, and that therefore, in some cases, an
>         exhaustive list of registered scope values is not possible.
>
>         -- Mike
>
>         parameters in the list, not just scope, we should adopt this
>         in a higher level paragraph and leave it out of the individual
>         parameter descriptions. Thus, something like this inserted as
>         the second paragraph in section 2:
>
>          - the Client requesting its desired values for each parameter
>         to the Authorization Server in a [register] or [update] request,
>          - the Authorization Server informing the Client of the
>         current values of each parameter that the Client has been
>         registered to use through a [client information response].
>
>         requests during the registration process (including any
>         omitted values) and replace the requested value with a
>         default. The normative indications in the following list apply
>         to the Client's declaration of its desired values.
>
>         fields that it requires to be filled in by the client or to
>         have particular values or formats. Extensions and profiles...
>
>
>         And then remove the sidedness-language from the scope
>         parameter and any other parameters where it might have crept
>         in inadvertently.
>
>          -- Justin
>
>             "Space separated list of scope values (as described in
>             "Space separated list of scope values (as described in
>             requesting access tokens and that the server is declaring
>             to the client that it is registered to use when requesting
>             access tokens.".
>
>             Again, I chose the "registered to use" language carefully
>             -- because in the general case it's not a restriction on
>             the values that the client can use -- just a statement by
>             the server to the client that it is registered to use
>             those particular values.  In both cases, the parties are
>             making declarations to one another.
>
>             If you adopt that language (or keep the original
>             language), then yes, I'd consider this closed.
>
>             -- Mike
>
>             I absolutely do not want to delete this feature, as
>             (having implemented it) I think it's very useful. This is
>             a very established pattern in manual registration: I know
>             of many, many OAuth2 servers and clients that are set up
>             where the client must pre-register a set of scopes.
>
>             I don't like the language of "the client is declaring"
>             because it's too one-sided. The client might not have
>             declared anything, and it might be the server that's
>             declaring something to the client. Deleting the "is
>             declaring" bit removes that unintended restriction of the
>             language while keeping the original meaning intact. I
>             actually thought that I had fixed that before the last
>             draft went in but apparently I missed this one.
>
>             I will work on clarifying the intent of the whole metadata
>             set in its introductory paragraph(s) so that it's clear
>             that all of these fields are used in both of these situations:
>
>             This should hopefully clear up the issue in the editor's
>             note that I currently have at the top of that section
>             right now, too.
>
>             issue, and you're fine with the existing text, can I take
>             this as closed now? Assuming that you agree with deleting
>             "is declaring" for reasons stated above, I'm fine with
>             leaving everything else as is and staying quiet on what
>             the server has to do with the scopes.
>
>              -- Justin
>
>                 <http://tools.ietf.org/html/rfc6749#section-3.3>) that
>                 the client is declaring that
>
>                 For instance, the current "client is declaring"
>                 wording will always be correct, whereas as the change
>                 to "client can use" wording implies a restriction on
>                 client behavior that is not always applicable.  The
>                 "client is declaring" wording was specific and
>                 purposefully chosen, and I think should be retained. 
>                 In particular, we can't do anything that implies that
>                 only the registered scopes values can be used.  At the
>                 OAuth spec level, this is a hint as to possible future
>                 client behavior -- not a restriction on future client
>                 behavior.
>
>                 So I'd propose that we leave the existing scope
>                 wording in place.  Alternatively, I'd also be fine
>                 with deleting this feature entirely, as I don't think
>                 it's useful in the general case.
>
>                 -- Mike
>
>                  Failing that, if there's strong demand for
>                 registration of structured scopes, bless the use of
>                 regexes, either PCREs or some careful subset.
>
>
>                 Authorization Server MAY register a Client with a
>                 default set of  scopes."  It adds no value; if the
>                 client doesn't declare scopes, the client doesn't
>                 Remember, all of these fields aren't just for the
>                 client *request*, they're also for the server's
>                 *response* to either a POST, PUT, or GET request. (I
>                 didn't realize it, but perhaps the wording as stated
>                 right now doesn't make that clear -- I need to fix
>                 that.) The value that it adds is if the client doesn't
>                 ask for any particular scopes, the server can still
>                 assign it scopes and the client can do something smart
>                 with that. Dumb clients are allowed to ignore it if it
>                 doesn't mean anything to them.
>
>                 This is how our server implementation actually works
>                 right now. If the client doesn't ask for anything
>                 specific at registration, the server hands it a bag of
>                 "default" scopes. Same thing happens at auth time --
>                 if the client doesn't ask for any particular scopes,
>                 the server hands it all of its registered scopes as a
>                 default. Granted, on our server, scopes are just
>                 simple strings right now, so they get compared at the
>                 What would you suggest for wording here, then? Keeping
>                 in mind that we cannot (and don't want to) prohibit
>                 expression-based scopes.
>
>                  -- Justin
>
>                     software-developer level.  I can't register scopes
>                     at authorization time with any predictable effect
>                     that I can write code to support, either client or
>                     server side, without out-of-line non-interoperable
>                     I guess I'm just not used to OAuth's culture of
>                     having no expectation that things will be
>                     specified tightly enough that I can write code to
>                     services since they're necessarily API-specific.
>                     The only interoperable bit is that there's *some*
>                     place to put the values and that it's expressed as
>                     a bag of space-separated strings. How those
>                     strings get interpreted and enforced (which is
>                     really what's at stake here) is up to the AS and
>                     PR (or a higher-level protocol like UMA).
>
>                      -- Justin
>
>                         think this feature can really only be made
>                         useful in the case where scopes are fixed strings.
>
>                         -T
>
>                         You are correct that the idea behind the
>                         "scope" parameter at registration is a
>                         constraint on authorization-time scopes that
>                         are made available. It's both a means for the
>                         client to request a set of valid scopes and
>                         for the server to provision (and echo back to
>                         I *really* don't want to try to define a
>                         matching language for scope expressions. For
>                         that to work, all servers would need to be
>                         able to process the regular expressions for
>                         all clients, even if the servers themselves
>                         only support simple-string scope values. Any
>                         regular expression syntax we pick here is
>                         guaranteed to be incompatible with something,
>                         and I think the complexity doesn't buy much.
>                         Also, I think you suddenly have a potential
>                         As it stands today, the server can interpret
>                         the incoming registration scopes and enforce
>                         them however it wants to. The real trick comes
>                         not from assigning the values to a particular
>                         client but to enforcing them, and I think
>                         that's always going to be service-specific.
>                         After looking over everyone's comments so far,
>                         I'd like to propose the following text for
>                         that section:
>
>
>
>                             scope
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 18 Apr 2013 14:05:02 -0400

I wholeheartedly agree that scope at registration is a useful part of 
the lifecycle (and indeed, a required part of our own implementation of 
this very functionality). But the way I read it, the requirement of "all 
scopes ... MAY use" is too restrictive and it's open to 
misinterpretation, I think. If a client registers for "A" but asks for 
"A:b?param=foo", is that OK? This is the pattern that we've been talking 
about using with Blue Button [1], but it seems precluded by this 
definition if you've got a tight definition of "MAY use". In the case of 
simple strings, it's adequate, and I think that's the common case, but 
we don't want to restrict the usefulness of this field to the simple 
case. I had tried to address this with enumerating string matching and 
other things, others have suggested defining a regular expression 
language, but at the end of the day I don't think any of that actually 
buys you much interoperability.

  -- Justin

[1] http://blue-button.github.io/blue-button-plus-pull/

On 04/18/2013 01:54 PM, Phil Hunt wrote:
> Why not:
>
>> "A value corresponding to scope as described in OAuth 2, Section 3.3 
>> [RFC6749]. The registered Client may use these to indicate all of the 
>> scopes that a client MAY use when requesting tokens from an 
>> Authorization Server."
>
> In the above, I avoid re-defining scope at all. However describing why 
> they are included in registration is useful.  IMHO I think scope at 
> registration is useful for life-cycle approval workflows.
>
> In some cases you could say they are also the default list, but I'm 
> not sure it helps inter-operability so its not clear it needs to be 
> mentioned.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>> Thing is, there's nothing normative about the enforcing statement 
>> that I made below, so I don't think it's any more restrictive than 
>> RFC 6749 which lets the AS replace a client's requested scopes at the 
>> time of token issuance with whatever it pleases. But that said, I'd 
>> be just as happy to leave it like this with no further restrictions:
>>
>> registered for. It's up to the app (not the library) to figure out 
>> how to translate those into scopes to ask for at authorization time. 
>> client was registered for, and what bag of scopes the client asked 
>> for during authorization. It's up to the server *application* to 
>> harmonize those two in a way that makes sense for the API that it's 
>> protecting. Just like it's up to the protected resource *application* 
>> to figure out what a scope means in a given context.
>>
>> other field: client asks for a thing, server says that client 
>> actually gets a thing, and it's implicitly up to the server to do the 
>> right thing and enforce things in a way that makes sense for the 
>> application no matter what the client does.
>>
>> and "X" are related, require user intervention, or really, whatever 
>> it likes. The libraries, where I argue the interoperability cries 
>> really matter, don't care, and shouldn't care.
>>
>>  -- Justin
>>
>>> Saying anything normative about “enforcing restrictions” is going 
>>> beyond RFC 6749 semantics.  Indeed, you’d said that “I agree that we 
>>> shouldn't try to "solve" scope in registration.”, but talking about 
>>> restrictions is going down the slippery “solving it” path.
>>>
>>> one another about scopes that they may choose to use, but we can’t 
>>> such as “urn:example:channel=HBO&urn:example:rating=G,PG-13” might 
>>> not be used, even if the client registers saying that it intends to 
>>> use the “OATC” scope value.  We could maybe even say that some 
>>> server or to those that the server returned to the client.  That’s a 
>>> HINT that some services might do this.  But we can’t say anything 
>>> normative about such possible behaviors, because it goes beyond RFC 
>>> 6749.
>>>
>>> -- Mike
>>>
>>>     “Space-separated list of scope values (as described in OAuth 2.0
>>>     Section 3.3 [RFC6749]
>>>     Authorization Server. As scope values are service specific, the
>>>     means of the Authorization Server enforcing this restriction are
>>>     outside the scope of this specification.”
>>>
>>> If I don’t specify a scope, then the server can allocate a default 
>>> I’m unconvinced, Mike.  Obviously you’re right about the looseness 
>>> of OAuth2 scope specification, but this is a very specific semantic 
>>> of what happens when you register, and I don’t think we’re bound by 
>>> history here. If we can’t safely say anything about what the list of 
>>> obvious intended semantic is (from the client) “I promise to ask 
>>> only for these” and from the server “These are the only ones I’ll 
>>> give you tokens for.”  Or does someone have use-cases for an 
>>> alternative semantic?
>>>
>>> “Space-separated list of scope values (as described in OAuth 2.0 
>>> Section 3.3 [RFC6749] 
>>> tokens for scopes not in the list provided by the server.”
>>>
>>>     I don’t think it’s possible to define what it means in an
>>>     interoperable way because OAuth didn’t specify scopes in an
>>>     interoperable way.  No, I don’t like that either, but I think
>>>     that’s where things are. That’s why I was advocating deleting
>>>     But understanding it might be useful in some contexts, I’m OK
>>>     “registered to use” are service-specific.
>>>
>>>     -- Mike
>>>
>>>     On the server-to-client side, what does “registered to use”
>>>     language.  I’d still keep this language for scope, because we
>>>     want to capture the “declaring” aspect in this case:
>>>
>>>     “Space separated list of scope values (as described in OAuth
>>>     2.0Section 3.3 [RFC6749]
>>>     requesting access tokens and that the server is declaring to the
>>>     client that it is registered to use when requesting access tokens.”.
>>>
>>>     parameters in the list, not just scope, we should adopt this in
>>>     a higher level paragraph and leave it out of the individual
>>>     normative indications in the following list apply to the
>>>     Client's declaration of its desired values.
>>>
>>>         “Space separated list of scope values (as described in OAuth
>>>         2.0Section 3.3 [RFC6749]
>>>         tokens.”
>>>         “Space separated list of scope values (as described in OAuth
>>>         2.0Section 3.3 [RFC6749]
>>>         the client that it is registered to use when requesting
>>>         access tokens.”.
>>>
>>>         Again, I chose the “registered to use” language carefully –
>>>         because in the general case it’s not a restriction on the
>>>         values that the client can use – just a statement by the
>>>         actually thought that I had fixed that before the last draft
>>>         went in but apparently I missed this one.
>>>
>>>         set in its introductory paragraph(s) so that it's clear that
>>>         all of these fields are used in both of these situations:
>>>
>>>         note that I currently have at the top of that section right
>>>         now, too.
>>>
>>>         leaving everything else as is and staying quiet on what the
>>>             default set of
>>>             For instance, the current “client is declaring” wording
>>>             will always be correct, whereas as the change to “client
>>>             can use” wording implies a restriction on client
>>>             behavior that is not always applicable.  The “client is
>>>             declaring” wording was specific and purposefully chosen,
>>>             and I think should be retained. In particular, we can’t
>>>             do anything that implies that only the registered scopes
>>>             values can be used. At the OAuth spec level, this is a
>>>             hint as to possible future client behavior – not a
>>>             Also, for the reasons that Tim stated, I’m strongly
>>>             against any “matching” or “regex” language in the spec
>>>             pertaining to scopes – as it’s not actionable.
>>>
>>>             So I’d propose that we leave the existing scope wording
>>>             in place.  Alternatively, I’d also be fine with deleting
>>>             this feature entirely, as I don’t think it’s useful in
>>>             the general case.
>>>
>>>             -- Mike
>>>
>>>             I’d use the existing wording; it’s perfectly clear.
>>>              Failing that, if there’s strong demand for registration
>>>             However, I’d subtract the sentence “If omitted, an
>>>             default set of  scopes.”  It adds no value; if the
>>>             client doesn’t declare scopes, the client doesn’t
>>>             either a POST, PUT, or GET request. (I didn't realize
>>>             it, but perhaps the wording as stated right now doesn't
>>>             make that clear -- I need to fix that.) The value that
>>>             it adds is if the client doesn't ask for any particular
>>>             scopes, the server can still assign it scopes and the
>>>             client can do something smart with that. Dumb clients
>>>             are allowed to ignore it if it doesn't mean anything to
>>>             them.
>>>
>>>             "default" scopes. Same thing happens at auth time -- if
>>>             the client doesn't ask for any particular scopes, the
>>>             server hands it all of its registered scopes as a
>>>             default. Granted, on our server, scopes are just simple
>>>             strings right now, so they get compared at the auth
>>>             endpoint with an exact string-match metric and set-based
>>>             logic.
>>>
>>>              -- Justin
>>>
>>>
>>>
>>>                 No, I mean it’s not interoperable at the
>>>                 software-developer level.  I can’t register scopes
>>>                 I guess I’m just not used to OAuth’s culture of
>>>                 having no expectation that things will be specified
>>>                 tightly enough that I can write code to implement as
>>>                 specified.  -T
>>>
>>>                 only interoperable bit is that there's *some* place
>>>                 to put the values and that it's expressed as a bag
>>>                 of space-separated strings. How those strings get
>>>                 stake here) is up to the AS and PR (or a
>>>                     authorization-time scopes that are made
>>>                     available. It's both a means for the client to
>>>                     request a set of valid scopes and for the server
>>>                     to provision (and echo back to the client) a set
>>>                     of valid scopes.
>>>
>>>                     that to work, all servers would need to be able
>>>                     to process the regular expressions for all
>>>                     clients, even if the servers themselves only
>>>                     support simple-string scope values. Any regular
>>>                     expression syntax we pick here is guaranteed to
>>>                     complexity doesn't buy much. Also, I think you
>>>                     suddenly have a potential security issue if you
>>>                     have a bad regex in place on either end.
>>>
>>>                     however it wants to. The real trick comes not
>>>                     from assigning the values to a particular client
>>>                     but to enforcing them, and I think that's always
>>>                     going to be service-specific. We're just not as
>>>                     clear on that as we could be.
>>>
>>>                     I'd like to propose the following text for that
>>>                     section:
>>>
>>>
>>>                         scope
>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 18 Apr 2013 14:15:26 -0400

Say you're building an application that uses a particular API. You'll be 
building that application to access that API and do stuff. You use 
libraries to handle the OAuth bits for that API, so you do something like:

clientProperties = oauth2.register("http://server/register", "My 
Client", "a b c d", ["http://client/return"]);

The server registers you, and clientProperties gets a client_id, a 
client_name of "My Client", and a scope field of "a b d" since the 
server said you couldn't dynamically register for "c" for whatever reason.

Now let's say that you use the library to request authorization to do 
something on the API. Your app can look inside of clientProperties.scope 
to see what scopes you can do something with. This will have the string 
"a b", which means something (to the app) in the context of the API it's 
registering for, and it knows it wants a token for "a b". Apps are going 
to need to know that, but the library will do what the app tells it to. 
So the app calls the library:

oauth2.authorize("http://server/authorize", "code", "a b", 
"http://client/return", "STATEVALUE@#$I(RJ@#")

A dumb app could even pass in whatever the value of 
clientProperties.scope is (or a blank value) to try to get all of its 
scopes. Or the app could know that the scopes are structured and call:

oauth2.authorize("http://server/authorize", "code", "a:read 
b:readwrite", "http://client/return", "STATEVALUE@#$I(RJ@#")

Eventually you get back a code, then a token:

token = oauth2.token("http://server/token", code, clientProperties)

(note that clientProperties will have the client_id, client_secret, 
redirect_uri, and anything else needed here.)

Now, this token will *also* have a "scope" field. Let's say that the 
user only authorized you for scope "a". If you want to be smart about 
it, you can avoid calling endpoints that require "b". Or you could just 
try it and be prepared to deal with a failing token, like all OAuth 
clients must be able to do anyway.

I hope this makes sense, please forgive the off-the-cuff pseudocode.

  -- Justin

On 04/18/2013 01:56 PM, Tim Bray wrote:
> On Thu, Apr 18, 2013 at 10:47 AM, Justin Richer <[email-masked] 
>     It's very useful for a generic *library* that handles the
>     authorization layer for an application to have a slot for
>     registered for.
> I don’t see how it’s useful in the slightest if there’s no defined 
> semantic for what “registration” actually means, i.e. what result is 
> to be expected when sending or receiving a list of scopes.   -T
>
>
>
>
>>     beyond RFC 6749 semantics.  Indeed, you’d said that “I agree that
>>     we shouldn't try to "solve" scope in registration.”, but talking
>>     about restrictions is going down the slippery “solving it” path.
>>
>>     At most we can say that the two parties are making declarations
>>     to one another about scopes that they may choose to use, but we
>>     can’t assume that this is an exclusive list and that other scope
>>     values such as
>>     “urn:example:channel=HBO&urn:example:rating=G,PG-13” might not be
>>     used, even if the client registers saying that it intends to use
>>     the “OATC” scope value.  We could maybe even say that some
>>     server or to those that the server returned to the client. 
>>     That’s a HINT that some services might do this.  But we can’t say
>>     the first place. The server has the final say. So in this case,
>>     if your client asks for nothing, the server says "A B C", the
>>     client now knows it can ask for "A B C" scopes.
>>
>>         “Space-separated list of scope values (as described in OAuth
>>         restriction are outside the scope of this specification.”
>>
>>     If I don’t specify a scope, then the server can allocate a
>>     default (or default set), thus that breaks the semantics you describe
>>
>>     I’m unconvinced, Mike.  Obviously you’re right about the
>>     looseness of OAuth2 scope specification, but this is a very
>>     specific semantic of what happens when you register, and I don’t
>>     think we’re bound by history here.   If we can’t safely say
>>     anything about what the list of scopes means, then I'm with you
>>     let's take them out.  But the most obvious intended semantic is
>>     (from the client) “I promise to ask only for these” and from the
>>     server “These are the only ones I’ll give you tokens for.”  Or
>>     does someone have use-cases for an alternative semantic?
>>
>>     client that it is registered to use when requesting access
>>     tokens. Clients SHOULD assume that servers will refuse to grant
>>     access tokens for scopes not in the list provided by the server.”
>>
>>         that’s where things are.  That’s why I was advocating
>>         deleting this registration feature entirely.
>>
>>         two-sided language.  I’d still keep this language for scope,
>>         because we want to capture the “declaring” aspect in this case:
>>
>>         in a higher level paragraph and leave it out of the
>>         individual parameter descriptions. Thus, something like this
>>         inserted as the second paragraph in section 2:
>>
>>          - the Client requesting its desired values for each
>>         parameter to the Authorization Server in a [register] or
>>         [update] request,
>>         default. The normative indications in the following list
>>         apply to the Client's declaration of its desired values.
>>
>>             “Space separated list of scope values (as described in
>>             the client is declaring that it may use when requesting
>>             access tokens.”
>>
>>             to
>>
>>             “Space separated list of scope values (as described in
>>             the client is declaring to the server that it may use
>>             when requesting access tokens and that the server is
>>             declaring to the client that it is registered to use when
>>             requesting access tokens.”.
>>
>>             Again, I chose the “registered to use” language carefully
>>             – because in the general case it’s not a restriction on
>>             the values that the client can use – just a statement by
>>             language), then yes, I’d consider this closed.
>>
>>             -- Mike
>>
>>             I will work on clarifying the intent of the whole
>>             metadata set in its introductory paragraph(s) so that
>>             it's clear that all of these fields are used in both of
>>             these situations:
>>
>>             Mike, since you were the one who originally brought up
>>             the issue, and you're fine with the existing text, can I
>>             take this as closed now? Assuming that you agree with
>>             deleting "is declaring" for reasons stated above, I'm
>>             fine with leaving everything else as is and staying quiet
>>             on what the server has to do with the scopes.
>>
>>              -- Justin
>>
>>                 <http://tools.ietf.org/html/rfc6749#section-3.3>)
>>                 that the client is declaring that
>>
>>                 For instance, the current “client is declaring”
>>                 to “client can use” wording implies a restriction on
>>                 “client is declaring” wording was specific and
>>                 In particular, we can’t do anything that implies that
>>                 only the registered scopes values can be used.  At
>>                 the OAuth spec level, this is a hint as to possible
>>                 future client behavior – not a restriction on future
>>                 client behavior.
>>
>>                 against any “matching” or “regex” language in the
>>                 spec pertaining to scopes – as it’s not actionable.
>>
>>                 So I’d propose that we leave the existing scope
>>                 wording in place. Alternatively, I’d also be fine
>>                 with deleting this feature entirely, as I don’t think
>>                 it’s useful in the general case.
>>
>>                 -- Mike
>>
>>                  Failing that, if there’s strong demand for
>>                 that.) The value that it adds is if the client
>>                 doesn't ask for any particular scopes, the server can
>>                 still assign it scopes and the client can do
>>                 something smart with that. Dumb clients are allowed
>>                 to ignore it if it doesn't mean anything to them.
>>
>>                 specific at registration, the server hands it a bag
>>                 of "default" scopes. Same thing happens at auth time
>>                 -- if the client doesn't ask for any particular
>>                 scopes, the server hands it all of its registered
>>                 scopes as a default. Granted, on our server, scopes
>>                 are just simple strings right now, so they get
>>                 compared at the auth endpoint with an exact
>>                 What would you suggest for wording here, then?
>>                 Keeping in mind that we cannot (and don't want to)
>>                 prohibit expression-based scopes.
>>
>>                  -- Justin
>>
>>                     software-developer level.  I can’t register
>>                     scopes at authorization time with any predictable
>>                     effect that I can write code to support, either
>>                     client or server side, without out-of-line
>>                     non-interoperable knowledge about the behavior of
>>                     the server.
>>
>>                     place to put the values and that it's expressed
>>                     as a bag of space-separated strings. How those
>>                         This, as written, has zero interoperability.
>>                         I think this feature can really only be made
>>                         them however it wants to. The real trick
>>                         comes not from assigning the values to a
>>                         particular client but to enforcing them, and
>>                         I think that's always going to be
>>                         After looking over everyone's comments so
>>                         far, I'd like to propose the following text
>>                         for that section:
>>
>>
>>                             scope
>>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 18 Apr 2013 11:17:57 -0700 (PDT)

Justin,

I agree. Even in my attempt I was too restrictive. 
>>> "A value corresponding to scope as described in OAuth 2, Section 3.3 [RFC6749]. Scope is provided as a way to indicate the maximum features a client may access with scope when requesting access tokens from an OAuth 2 authorization server.

Hopefully someone can simplify further.

What I've not said, but I don't think it needs to be in the spec is that:

* The registration life-cycle management could define what scope a client uses out-of-band (e.g. could be policy driven)
* The registration with scope could also imply a default set of scopes.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-04-18, at 11:05 AM, Justin Richer wrote:

> I wholeheartedly agree that scope at registration is a useful part of the lifecycle (and indeed, a required part of our own implementation of this very functionality). But the way I read it, the requirement of "all scopes ... MAY use" is too restrictive and it's open to misinterpretation, I think. If a client registers for "A" but asks for "A:b?param=foo", is that OK? This is the pattern that we've been talking about using with Blue Button [1], but it seems precluded by this definition if you've got a tight definition of "MAY use". In the case of simple strings, it's adequate, and I think that's the common case, but we don't want to restrict the usefulness of this field to the simple case. I had tried to address this with enumerating string matching and other things, others have suggested defining a regular expression language, but at the end of the day I don't think any of that actually buys you much interoperability.
> 
>  -- Justin
>

---

From: Tim Bray <[email-masked]>
Date: Thu, 18 Apr 2013 11:22:26 -0700

On Thu, Apr 18, 2013 at 11:15 AM, Justin Richer <[email-masked]> wrote:

> clientProperties = oauth2.register("http://server/register"<http://server/register>,
> "My Client", "a b c d", ["http://client/return" <http://client/return>]);
>
> client_name of "My Client", and a scope field of "a b d" since the server
> said you couldn't dynamically register for "c" for whatever reason.
>
> something on the API. Your app can look inside of clientProperties.scope to
> see what scopes you can do something with.
>

So, your implication is that when the server says “a b d” that means that
you’d better not ask for any other scopes.  I agree.  This seems like the
only useful interpretation. So why shouldn’t we say that in the spec?  -T

> This will have the string "a b", which means something (to the app) in the
> context of the API it's registering for, and it knows it wants a token for
> "a b". Apps are going to need to know that, but the library will do what
> the app tells it to. So the app calls the library:
>
> oauth2.authorize("http://server/authorize" <http://server/authorize>,
> "code", "a b", "http://client/return" <http://client/return>, "STATEVALUE@
> #$I(RJ@#")
>
> A dumb app could even pass in whatever the value of clientProperties.scope
> is (or a blank value) to try to get all of its scopes. Or the app could
> know that the scopes are structured and call:
>
> oauth2.authorize("http://server/authorize" <http://server/authorize>,
> "code", "a:read b:readwrite", "http://client/return"<http://client/return>,
> "STATEVALUE@#$I(RJ@#")
>
> token = oauth2.token("http://server/token" <http://server/token>, code,
> clientProperties)
>
> Now, this token will *also* have a "scope" field. Let's say that the user
> only authorized you for scope "a". If you want to be smart about it, you
> can avoid calling endpoints that require "b". Or you could just try it and
> be prepared to deal with a failing token, like all OAuth clients must be
> able to do anyway.
>
> semantic for what “registration” actually means, i.e. what result is to be
> expected when sending or receiving a list of scopes.   -T
>
>
>>
>>
>>
>> RFC 6749.
>> C" scopes.
>> definition at all, instead have it say something like:
>>
>>
>>
>> enforcing this restriction are outside the scope of this specification.”
>>
>>
>>
>> confusing language that doesn't add to interoperability.
>>
>>
>>
>>  -- Justin
>>
>>
>>
>> not in the list provided by the server.”
>>
>>
>>
>>
>>
>> was advocating deleting this registration feature entirely.
>>
>>
>>
>> service-specific.
>> On the server-to-client side, what does “registered to use” mean?  Does
>> it mean that the client should assume that any scopes not on the list WILL
>> not be granted, MAY not be granted.... or what?  Is this already covered
>> elsewhere? -T
>>
>>
>>
>> capture the “declaring” aspect in this case:
>>
>>
>>
>> not possible.
>> the list, not just scope, we should adopt this in a higher level paragraph
>> and leave it out of the individual parameter descriptions. Thus, something
>> like this inserted as the second paragraph in section 2:
>>
>> formats. Extensions and profiles...
>>
>>
>> client is declaring that it may use when requesting access tokens.”
>>
>> to
>>
>> the general case it’s not a restriction on the values that the client can
>> use – just a statement by the server to the client that it is registered to
>> use those particular values.  In both cases, the parties are making
>> consider this closed.
>> wording.  The existing wording is:
>>
>>
>>
>>    scope
>>
>> “matching” or “regex” language in the spec pertaining to scopes – as it’s
>> not actionable.
>>
>>
>>
>> of regexes, either PCREs or some careful subset.
>>
>>
>> that’s all.  -T

---

From: Justin Richer <[email-masked]>
Date: Thu, 18 Apr 2013 14:46:47 -0400

On 04/18/2013 02:22 PM, Tim Bray wrote:
> On Thu, Apr 18, 2013 at 11:15 AM, Justin Richer <[email-masked] 
>     clientProperties = oauth2.register("http://server/register"
>     <http://server/register>, "My Client", "a b c d",
>     ["http://client/return" <http://client/return>]);
>
>     Now let's say that you use the library to request authorization to
>     do something on the API. Your app can look inside of
>     clientProperties.scope to see what scopes you can do something with.
>
>
> So, your implication is that when the server says “a b d” that means 
> that you’d better not ask for any other scopes.  I agree.  This seems 
> like the only useful interpretation. So why shouldn’t we say that in 
> the spec?  -T

See the rest of the example below: I don't think we can usefully say 
that because it's too easy to interpret "a:read b:readwrite" as separate 
scopes from "a b", but in the context of some applications it might not 
be. What's really going on here, that I tried to demonstrate, is that 
there are several sets of scopes at play:

  A: what the client asks for at registration
  B: what the server gives the client at registration
  C: what the client asks for at authorization
  D: what the user/server give the client at authorization
  E: what the server gives the client at the token endpoint

I think that the registration spec should really only deal with A and B, 
and that's it. It can point out (mostly in the overall section) that 
these are probably useful for getting things done in steps C, D, and E, 
since this is the justification for having this as a registration-time 
parameter. Any attempts I've seen so far to have *useful* language 
around tying B to D (what's really at stake here) have been horribly 
complicated, overly restrictive, or red herrings that don't actually do 
what they say.

And the server can't depend on the client not asking for a scope it 
didn't register for and needs to be prepared for that case, so it 
doesn't really buy you anything saying that the client normatively 
*can't* ask for other scopes, because it can always try. A server might 
even give the client one of those extra scopes in certain circumstances 
(some special wildcard value, pattern matching against a policy engine, 
consultation with a guru), but all of this is API specific. The OAuth 
level of processing just knows that there's a scope there, and I'm fine 
with that.

  -- Justin

>
>     This will have the string "a b", which means something (to the
>     app) in the context of the API it's registering for, and it knows
>     it wants a token for "a b". Apps are going to need to know that,
>     but the library will do what the app tells it to. So the app calls
>     the library:
>
>     oauth2.authorize("http://server/authorize"
>     <http://server/authorize>, "code", "a b", "http://client/return"
>     <http://client/return>, "STATEVALUE@#$I(RJ@#")
>
>     clientProperties.scope is (or a blank value) to try to get all of
>     its scopes. Or the app could know that the scopes are structured
>     and call:
>
>     oauth2.authorize("http://server/authorize"
>     <http://server/authorize>, "code", "a:read b:readwrite",
>     "http://client/return" <http://client/return>, "STATEVALUE@#$I(RJ@#")
>
>     token = oauth2.token("http://server/token" <http://server/token>,
>     code, clientProperties)
>
>     (note that clientProperties will have the client_id,
>     client_secret, redirect_uri, and anything else needed here.)
>
>     Now, this token will *also* have a "scope" field. Let's say that
>     the user only authorized you for scope "a". If you want to be
>     smart about it, you can avoid calling endpoints that require "b".
>     Or you could just try it and be prepared to deal with a failing
>     token, like all OAuth clients must be able to do anyway.
>
>>     On Thu, Apr 18, 2013 at 10:47 AM, Justin Richer
>>     I don’t see how it’s useful in the slightest if there’s no
>>     defined semantic for what “registration” actually means, i.e.
>>     what result is to be expected when sending or receiving a list of
>>     scopes.   -T
>>
>>
>>
>>
>>>         Saying anything normative about “enforcing restrictions” is
>>>         going beyond RFC 6749 semantics.  Indeed, you’d said that “I
>>>         agree that we shouldn't try to "solve" scope in
>>>         registration.”, but talking about restrictions is going down
>>>         the slippery “solving it” path.
>>>
>>>         At most we can say that the two parties are making
>>>         declarations to one another about scopes that they may
>>>         choose to use, but we can’t assume that this is an exclusive
>>>         list and that other scope values such as
>>>         “urn:example:channel=HBO&urn:example:rating=G,PG-13” might
>>>         not be used, even if the client registers saying that it
>>>         intends to use the “OATC” scope value.  We could maybe even
>>>         say that some services may use a static set of scopes and
>>>         might choose to limit the scopes that a client may use to
>>>         those that it declared to the server or to those that the
>>>         server returned to the client.  That’s a HINT that some
>>>         services might do this.  But we can’t say anything normative
>>>         about such possible behaviors, because it goes beyond RFC 6749.
>>>
>>>         -- Mike
>>>
>>>         <mailto:[email-masked]>
>>>         This doesn't actually break the semantics because the client
>>>         MUST accept what the server tells it over anything that it
>>>         asks for in the first place. The server has the final say.
>>>         So in this case, if your client asks for nothing, the server
>>>         says "A B C", the client now knows it can ask for "A B C"
>>>         scopes.
>>>
>>>         I'm still in favor of not putting the restricting language
>>>         in the scope definition at all, instead have it say
>>>         something like:
>>>
>>>             “Space-separated list of scope values (as described in
>>>             the Client can use when requesting access tokens from
>>>             the Authorization Server. As scope values are service
>>>             specific, the means of the Authorization Server
>>>         Couple this with the overall paragraph that says that the
>>>         client is requesting values that the server is potentially
>>>         overriding with its declarations, and I think that addresses
>>>         everything without getting into confusing language that
>>>         doesn't add to interoperability.
>>>
>>>          -- Justin
>>>
>>>         <mailto:[email-masked]>
>>>         specific semantic of what happens when you register, and I
>>>         don’t think we’re bound by history here.   If we can’t
>>>         safely say anything about what the list of scopes means,
>>>         then I'm with you let's take them out.  But the most obvious
>>>         intended semantic is (from the client) “I promise to ask
>>>         only for these” and from the server “These are the only ones
>>>         I’ll give you tokens for.”  Or does someone have use-cases
>>>         for an alternative semantic?
>>>
>>>         client is declaring to the server that it will restrict
>>>         itself to when requesting access tokens, and that the server
>>>         is declaring to the client that it is registered to use when
>>>         requesting access tokens. Clients SHOULD assume that servers
>>>         will refuse to grant access tokens for scopes not in the
>>>         list provided by the server.”
>>>
>>>             I don’t think it’s possible to define what it means in
>>>             an interoperable way because OAuth didn’t specify scopes
>>>             in an interoperable way.  No, I don’t like that either,
>>>             but I think that’s where things are. That’s why I was
>>>             advocating deleting this registration feature entirely.
>>>
>>>             But understanding it might be useful in some contexts,
>>>             I’m OK keeping it, provided we be clear that the
>>>             semantics of “registered to use” are service-specific.
>>>
>>>             -- Mike
>>>
>>>             On the server-to-client side, what does “registered to
>>>             use” mean?  Does it mean that the client should assume
>>>             that any scopes not on the list WILL not be granted, MAY
>>>             not be granted.... or what?  Is this already covered
>>>             elsewhere? -T
>>>
>>>             two-sided language.  I’d still keep this language for
>>>             scope, because we want to capture the “declaring” aspect
>>>             in this case:
>>>
>>>             declaring to the client that it is registered to use
>>>             when requesting access tokens.”.
>>>
>>>             service-specific and may not consist only of a static
>>>             set of string values, and that therefore, in some cases,
>>>             an exhaustive list of registered scope values is not
>>>             possible.
>>>
>>>             -- Mike
>>>
>>>             parameters in the list, not just scope, we should adopt
>>>             this in a higher level paragraph and leave it out of the
>>>             individual parameter descriptions. Thus, something like
>>>             this inserted as the second paragraph in section 2:
>>>
>>>             The client metadata values serve two parallel purposes
>>>             in the overall OAuth Dynamic Registration protocol:
>>>
>>>             current values of each parameter that the Client has
>>>             been registered to use through a [client information
>>>             response].
>>>
>>>             An Authorization Server MAY override any value that a
>>>             Client requests during the registration process
>>>             (including any omitted values) and replace the requested
>>>             value with a default. The normative indications in the
>>>             The Authorization Server SHOULD provide documentation
>>>             for any fields that it requires to be filled in by the
>>>             client or to have particular values or formats.
>>>             Extensions and profiles...
>>>
>>>
>>>             parameter and any other parameters where it might have
>>>             crept in inadvertently.
>>>
>>>              -- Justin
>>>
>>>                 “Space separated list of scope values (as described
>>>                 in OAuth 2.0Section 3.3 [RFC6749]
>>>                 that the client is declaring that it may use when
>>>                 requesting access tokens.”
>>>
>>>                 to
>>>
>>>                 “Space separated list of scope values (as described
>>>                 in OAuth 2.0Section 3.3 [RFC6749]
>>>                 that the client is declaring to the server that it
>>>                 may use when requesting access tokens and that the
>>>                 server is declaring to the client that it is
>>>                 registered to use when requesting access tokens.”.
>>>
>>>                 Again, I chose the “registered to use” language
>>>                 carefully – because in the general case it’s not a
>>>                 restriction on the values that the client can use –
>>>                 just a statement by the server to the client that it
>>>                 is registered to use those particular values.  In
>>>                 both cases, the parties are making declarations to
>>>                 one another.
>>>
>>>                 (having implemented it) I think it's very useful.
>>>                 This is a very established pattern in manual
>>>                 registration: I know of many, many OAuth2 servers
>>>                 and clients that are set up where the client must
>>>                 pre-register a set of scopes.
>>>
>>>                 I don't like the language of "the client is
>>>                 declaring" because it's too one-sided. The client
>>>                 might not have declared anything, and it might be
>>>                 the server that's declaring something to the client.
>>>                 Deleting the "is declaring" bit removes that
>>>                 unintended restriction of the language while keeping
>>>                 the original meaning intact. I actually thought that
>>>                 I had fixed that before the last draft went in but
>>>                 apparently I missed this one.
>>>
>>>                 metadata set in its introductory paragraph(s) so
>>>                 that it's clear that all of these fields are used in
>>>                 both of these situations:
>>>
>>>                 This should hopefully clear up the issue in the
>>>                 editor's note that I currently have at the top of
>>>                 that section right now, too.
>>>
>>>                 Mike, since you were the one who originally brought
>>>                 up the issue, and you're fine with the existing
>>>                 text, can I take this as closed now? Assuming that
>>>                 you agree with deleting "is declaring" for reasons
>>>                 stated above, I'm fine with leaving everything else
>>>                 as is and staying quiet on what the server has to do
>>>                 with the scopes.
>>>
>>>                  -- Justin
>>>
>>>                     I think that the existing wording is superior to
>>>                     the proposed changed wording.  The existing
>>>                     wording is:
>>>
>>>                     scope
>>>
>>>                     wording will always be correct, whereas as the
>>>                     change to “client can use” wording implies a
>>>                     restriction on client behavior that is not
>>>                     always applicable. The “client is declaring”
>>>                     wording was specific and purposefully chosen,
>>>                     and I think should be retained. In particular,
>>>                     we can’t do anything that implies that only the
>>>                     registered scopes values can be used. At the
>>>                     OAuth spec level, this is a hint as to possible
>>>                     future client behavior – not a restriction on
>>>                     future client behavior.
>>>
>>>                     Also, for the reasons that Tim stated, I’m
>>>                     strongly against any “matching” or “regex”
>>>                     language in the spec pertaining to scopes – as
>>>                     it’s not actionable.
>>>
>>>                     wording in place. Alternatively, I’d also be
>>>                     fine with deleting this feature entirely, as I
>>>                     I’d use the existing wording; it’s perfectly
>>>                     clear.  Failing that, if there’s strong demand
>>>                     for registration of structured scopes, bless the
>>>                     However, I’d subtract the sentence “If omitted,
>>>                     an Authorization Server MAY register a Client
>>>                     with a default set of  scopes.”  It adds no
>>>                     value; if the client doesn’t declare scopes, the
>>>                     client doesn’t declare scopes, that’s all.  -T
>>>
>>>
>>>                     Remember, all of these fields aren't just for
>>>                     the client *request*, they're also for the
>>>                     server's *response* to either a POST, PUT, or
>>>                     GET request. (I didn't realize it, but perhaps
>>>                     the wording as stated right now doesn't make
>>>                     that clear -- I need to fix that.) The value
>>>                     that it adds is if the client doesn't ask for
>>>                     any particular scopes, the server can still
>>>                     assign it scopes and the client can do something
>>>                     smart with that. Dumb clients are allowed to
>>>                     This is how our server implementation actually
>>>                     works right now. If the client doesn't ask for
>>>                     anything specific at registration, the server
>>>                     hands it a bag of "default" scopes. Same thing
>>>                     happens at auth time -- if the client doesn't
>>>                     ask for any particular scopes, the server hands
>>>                     it all of its registered scopes as a default.
>>>                     Granted, on our server, scopes are just simple
>>>                     strings right now, so they get compared at the
>>>                     Keeping in mind that we cannot (and don't want
>>>                     to) prohibit expression-based scopes.
>>>
>>>                      -- Justin
>>>
>>>                         scopes at authorization time with any
>>>                         predictable effect that I can write code to
>>>                         support, either client or server side,
>>>                         without out-of-line non-interoperable
>>>                         I guess I’m just not used to OAuth’s culture
>>>                         of having no expectation that things will be
>>>                         specified tightly enough that I can write
>>>                         code to implement as specified.  -T
>>>
>>>                         Scopes aren't meant to be interoperable
>>>                         between services since they're necessarily
>>>                         API-specific. The only interoperable bit is
>>>                         that there's *some* place to put the values
>>>                         and that it's expressed as a bag of
>>>                         space-separated strings. How those strings
>>>                         get interpreted and enforced (which is
>>>                         really what's at stake here) is up to the AS
>>>                         and PR (or a higher-level protocol like UMA).
>>>
>>>                          -- Justin
>>>
>>>                             This, as written, has zero
>>>                             interoperability. I think this feature
>>>                             can really only be made useful in the
>>>                             case where scopes are fixed strings.
>>>
>>>                             -T
>>>
>>>                             constraint on authorization-time scopes
>>>                             that are made available. It's both a
>>>                             means for the client to request a set of
>>>                             valid scopes and for the server to
>>>                             provision (and echo back to the client)
>>>                             a set of valid scopes.
>>>
>>>                             matching language for scope expressions.
>>>                             For that to work, all servers would need
>>>                             to be able to process the regular
>>>                             expressions for all clients, even if the
>>>                             servers themselves only support
>>>                             simple-string scope values. Any regular
>>>                             something, and I think the complexity
>>>                             doesn't buy much. Also, I think you
>>>                             suddenly have a potential security issue
>>>                             think that's always going to be