Subject: [OAUTH-WG] Registration: Scope Values

From: Justin Richer <[email-masked]>
Date: Fri, 12 Apr 2013 14:24:55 -0400

Currently, the Dynamic Registration draft defines a "scope" value as 
part of the client metadata table, with the following definition:

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

The idea here is that a client can request a particular set of available 
scopes from the AS (analogous as to what's available from many/most 
manual registration pages today), and the AS can communicate back to the 
client what scopes it's allowed to ask for at authz time. In a 
strictly-enforced implementation, the client wouldn't be able to ask for 
any scopes that it wasn't registered for in the first place.

However, it's been brought up in some side conversations that the 
language as found in the DynReg spec might get in the way of people 
using the "scope" field as an expression language. That is to say, you 
could have a scope like "send_email_to:[email-masked]" where the 
email address portion is variable, or something like "read:*" which 
stands in for any scopes starting with "read:" like "read:profile", 
"read:lists", etc. Precluding this behavior wasn't my intent, and a 
liberal interpretation of the text as-written would (I believe) lead to 
this being perfectly OK. Namely:

Client requests and is granted a service specific scope value like 
"send_email_to" in registration. At runtime, the client knows how to 
turn "send_email_to" into "send_email_to:[email-masked]", and the 
AS knows that a client that's been granted "send_email_to" can ask for 
"send_email_to:[email-masked]". The fact that "send_email_to" 
expands into an expression language is something specific to the 
service, and I personally think it's up to the service to document 
"register for this" and "ask for this at authn time" for clients, since 
this is all part of the API more than it is part of the underlying OAuth 
protocol. OAuth merely provides a handy place to communicate these 
values in an interoperable way, the values themselves aren't intended to 
be interoperable.

But my question to the group is simple: how can we rework the "scope" 
metadata claim such that it works in both the simple "bag of discreet 
strings" approach to scope as well as the "list of expressions" 
approach? Does the language need to change at all?

  -- Justin

---

From: Tim Bray <[email-masked]>
Date: Fri, 12 Apr 2013 11:31:21 -0700

Speaking for myself, I have considerable concern about Turing-complete
programming languages starting to emerge inside scope strings, which I
think is probably a symptom of bad engineering.  I really like the idea of
specifying the scopes you’re going to ask for at registration time, and if
that also gets in the way of what I’ll call “scope creep” (snicker), that
feels like a feature not a bug.  Anyhow, in practical terms, I can’t see
how you could extend this specify-at-registration-time feature much without
stepping on a very slippery complexity slope.

-T

On Fri, Apr 12, 2013 at 11:24 AM, Justin Richer <[email-masked]> wrote:

>  Currently, the Dynamic Registration draft defines a "scope" value as part
> of the client metadata table, with the following definition:
>
>    scope
>       OAuth 2.0 Section 3.3 [RFC6749] <http://tools.ietf.org/html/rfc6749#section-3.3>) that the client is declaring that
> scopes from the AS (analogous as to what's available from many/most manual
> registration pages today), and the AS can communicate back to the client
> what scopes it's allowed to ask for at authz time. In a strictly-enforced
> implementation, the client wouldn't be able to ask for any scopes that it
> wasn't registered for in the first place.
>
> However, it's been brought up in some side conversations that the language
> as found in the DynReg spec might get in the way of people using the
> "scope" field as an expression language. That is to say, you could have a
> scope like "send_email_to:[email-masked]"<send_email_to:[email-masked]>where the email address portion is variable, or something like "read:*"
> which stands in for any scopes starting with "read:" like "read:profile",
> "read:lists", etc. Precluding this behavior wasn't my intent, and a liberal
> interpretation of the text as-written would (I believe) lead to this being
> perfectly OK. Namely:
>
> "send_email_to" in registration. At runtime, the client knows how to turn
> "send_email_to" into "send_email_to:[email-masked]"<send_email_to:[email-masked]>,
> and the AS knows that a client that's been granted "send_email_to" can ask
> for "send_email_to:[email-masked]"<send_email_to:[email-masked]>.
> The fact that "send_email_to" expands into an expression language is
> something specific to the service, and I personally think it's up to the
> service to document "register for this" and "ask for this at authn time"
> for clients, since this is all part of the API more than it is part of the
> underlying OAuth protocol. OAuth merely provides a handy place to
> communicate these values in an interoperable way, the values themselves
> aren't intended to be interoperable.
>
>
> strings" approach to scope as well as the "list of expressions" approach?
> Does the language need to change at all?
>
>  -- Justin
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 12 Apr 2013 18:46:28 +0000

Tim, if you look at the scope examples in http://tools.ietf.org/html/rfc6750#section-3, you’ll see that one of them, from the Open Authentication Technology Committee (OATC) Online Multimedia Authorization Protocol [OMAP], does use non-static scope values to convey parameters:
scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"

Also, if you look at the OAuth usage survey results collected during IETF 86 in http://self-issued.info/misc/OAuth%20Feature%20Matrix%20-%20All.xlsx (cell G145), you’ll see that the OpenESPI “Smart Grid” specs also use scope values to convey structured information.

The horse has left the barn on requiring scope values to be static strings.  RFC 6749 didn’t do it and lots of implementations are conveying structured information there.  As Justin is bringing up, the OAuth Registration spec shouldn’t do anything to preclude this usage.

                                                            Cheers,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Bray
Sent: Friday, April 12, 2013 11:31 AM
To: Justin Richer
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Registration: Scope Values

Speaking for myself, I have considerable concern about Turing-complete programming languages starting to emerge inside scope strings, which I think is probably a symptom of bad engineering.  I really like the idea of specifying the scopes you’re going to ask for at registration time, and if that also gets in the way of what I’ll call “scope creep” (snicker), that feels like a feature not a bug.  Anyhow, in practical terms, I can’t see how you could extend this specify-at-registration-time feature much without stepping on a very slippery complexity slope.

-T

On Fri, Apr 12, 2013 at 11:24 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Currently, the Dynamic Registration draft defines a "scope" value as part of the client metadata table, with the following definition:

   scope

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

      scopes.

The idea here is that a client can request a particular set of available scopes from the AS (analogous as to what's available from many/most manual registration pages today), and the AS can communicate back to the client what scopes it's allowed to ask for at authz time. In a strictly-enforced implementation, the client wouldn't be able to ask for any scopes that it wasn't registered for in the first place.

However, it's been brought up in some side conversations that the language as found in the DynReg spec might get in the way of people using the "scope" field as an expression language. That is to say, you could have a scope like "send_email_to:[email-masked]"<mailto:send_email_to:[email-masked]> where the email address portion is variable, or something like "read:*" which stands in for any scopes starting with "read:" like "read:profile", "read:lists", etc. Precluding this behavior wasn't my intent, and a liberal interpretation of the text as-written would (I believe) lead to this being perfectly OK. Namely:

Client requests and is granted a service specific scope value like "send_email_to" in registration. At runtime, the client knows how to turn "send_email_to" into "send_email_to:[email-masked]"<mailto:send_email_to:[email-masked]>, and the AS knows that a client that's been granted "send_email_to" can ask for "send_email_to:[email-masked]"<mailto:send_email_to:[email-masked]>. The fact that "send_email_to" expands into an expression language is something specific to the service, and I personally think it's up to the service to document "register for this" and "ask for this at authn time" for clients, since this is all part of the API more than it is part of the underlying OAuth protocol. OAuth merely provides a handy place to communicate these values in an interoperable way, the values themselves aren't intended to be interoperable.

But my question to the group is simple: how can we rework the "scope" metadata claim such that it works in both the simple "bag of discreet strings" approach to scope as well as the "list of expressions" approach? Does the language need to change at all?

 -- Justin

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

---

From: "Donald F Coffin" <[email-masked]>
Date: Fri, 12 Apr 2013 12:39:05 -0700

+1

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

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

From: Tim Bray [mailto:[email-masked]] 
Sent: Friday, April 12, 2013 11:31 AM
To: Justin Richer
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Registration: Scope Values

-T

   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section <http://tools.ietf.org/html/rfc6749#section-3.3>  3.3 [RFC6749]) 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.

However, it's been brought up in some side conversations that the language as found in the DynReg spec might get in the way of people using the "scope" field as an expression language. That is to say, you could have a scope like  <mailto:send_email_to:[email-masked]> "send_email_to:[email-masked]" where the email address portion is variable, or something like "read:*" which stands in for any scopes starting with "read:" like "read:profile", "read:lists", etc. Precluding this behavior wasn't my intent, and a liberal interpretation of the text as-written would (I believe) lead to this being perfectly OK. Namely:

Client requests and is granted a service specific scope value like "send_email_to" in registration. At runtime, the client knows how to turn "send_email_to" into  <mailto:send_email_to:[email-masked]> "send_email_to:[email-masked]", and the AS knows that a client that's been granted "send_email_to" can ask for  <mailto:send_email_to:[email-masked]> "send_email_to:[email-masked]". The fact that "send_email_to" expands into an expression language is something specific to the service, and I personally think it's up to the service to document "register for this" and "ask for this at authn time" for clients, since this is all part of the API more than it is part of the underlying OAuth protocol. OAuth merely provides a handy place to communicate these values in an interoperable way, the values themselves aren't intended to be interoperable. 

 -- Justin

---

From: "Donald F Coffin" <[email-masked]>
Date: Fri, 12 Apr 2013 12:40:25 -0700

+1

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

From: Mike Jones [mailto:[email-masked]] 
Sent: Friday, April 12, 2013 11:46 AM
To: Tim Bray; Justin Richer
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Registration: Scope Values

                                                            Cheers,

                                                            -- Mike

-T

   scope

 -- Justin

---

From: Justin Richer <[email-masked]>
Date: Fri, 12 Apr 2013 15:48:31 -0400

The question refers to the Dynamic Registration draft specifically, 
since that's what's still editable. RFC6749 treats scopes as bags of 
strings that are specific to the API that they're protecting, which lets 
them be either static strings or expressions (or, really, whatever you 
like them to be). The problem is that the Dynamic Registration draft 
isn't defining just the conveyance of the scope string during the 
authorization process, it's got to have language on what a scope is 
*for* in order for it to make sense in registration. In other words, 
what does it mean to be "registered" with a scope? What does it mean to 
ask for a scope at registration time? What does it mean for a server to 
"grant" a scope at registration time?

I had thought that the current language (which is mostly lifted from 
RFC6749) was sufficient, but there's been question as to its intent, so 
I want to make sure that it's very clear that Dynamic Registration is as 
hands-off about scope values as RFC6749 is.

  -- Justin

On 04/12/2013 03:38 PM, Donald F Coffin wrote:
>
> Justin,
>
> While I understand the need to clarify the usage of the scope 
> metadata, I'm not clear on whether your question refers to the Dynamic 
> Registration draft or to RFC 6749?
>
> The current language of the Dynamic Registration draft to describe the 
> scope metadata usage is the same language used to describe the scope 
> parameter that appears in Section 3.3 of RFC 6749.  If the Dynamic 
> Registration draft uses language different than what is contained in 
> the scope parameter definition of RFC 6749 additional confusion about 
> the usage of the scope parameter may arise.  Perhaps the best way to 
> address the issue within the Dynamic Registration draft is to provide 
> an explanation.  The examples you provided in your posting could 
> easily be included in the Dynamic Registration draft and would achieve 
> the desired effect of demonstrating how the OAuth 2.0 scope parameter 
> might be used.
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
> REMI Networks
>
> Email: [email-masked] 
> <mailto:[email-masked]>
>
> *From:*Justin Richer [mailto:[email-masked]]
> *Sent:* Friday, April 12, 2013 11:25 AM
> *To:* [email-masked]
> *Subject:* [OAUTH-WG] Registration: Scope Values
>
> The idea here is that a client can request a particular set of 
> available scopes from the AS (analogous as to what's available from 
> many/most manual registration pages today), and the AS can communicate 
> back to the client what scopes it's allowed to ask for at authz time. 
> In a strictly-enforced implementation, the client wouldn't be able to 
> ask for any scopes that it wasn't registered for in the first place.
>
> could have a scope like "send_email_to:[email-masked]" 
> <mailto:send_email_to:[email-masked]> where the email address 
> portion is variable, or something like "read:*" which stands in for 
> any scopes starting with "read:" like "read:profile", "read:lists", 
> etc. Precluding this behavior wasn't my intent, and a liberal 
> interpretation of the text as-written would (I believe) lead to this 
> being perfectly OK. Namely:
>
> turn "send_email_to" into "send_email_to:[email-masked]" 
> <mailto:send_email_to:[email-masked]>, and the AS knows that a 
> client that's been granted "send_email_to" can ask for 
> "send_email_to:[email-masked]" 
> <mailto:send_email_to:[email-masked]>. The fact that 
> "send_email_to" expands into an expression language is something 
> specific to the service, and I personally think it's up to the service 
> to document "register for this" and "ask for this at authn time" for 
> clients, since this is all part of the API more than it is part of the 
> communicate these values in an interoperable way, the values 
> themselves aren't intended to be interoperable.
>
>

---

From: "Donald F Coffin" <[email-masked]>
Date: Fri, 12 Apr 2013 13:25:00 -0700

Justin,

Thanks for the clarification.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

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

From: Justin Richer [mailto:[email-masked]] 
Sent: Friday, April 12, 2013 12:49 PM
To: Donald F Coffin
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Registration: Scope Values

The question refers to the Dynamic Registration draft specifically, since
that's what's still editable. RFC6749 treats scopes as bags of strings that
are specific to the API that they're protecting, which lets them be either
static strings or expressions (or, really, whatever you like them to be).
The problem is that the Dynamic Registration draft isn't defining just the
conveyance of the scope string during the authorization process, it's got to
have language on what a scope is *for* in order for it to make sense in
registration. In other words, what does it mean to be "registered" with a
scope? What does it mean to ask for a scope at registration time? What does
it mean for a server to "grant" a scope at registration time? 

I had thought that the current language (which is mostly lifted from
RFC6749) was sufficient, but there's been question as to its intent, so I
want to make sure that it's very clear that Dynamic Registration is as
hands-off about scope values as RFC6749 is.

 -- Justin

Justin,

While I understand the need to clarify the usage of the scope metadata, I'm
not clear on whether your question refers to the Dynamic Registration draft
or to RFC 6749?  

The current language of the Dynamic Registration draft to describe the scope
metadata usage is the same language used to describe the scope parameter
that appears in Section 3.3 of RFC 6749.  If the Dynamic Registration draft
uses language different than what is contained in the scope parameter
definition of RFC 6749 additional confusion about the usage of the scope
parameter may arise.  Perhaps the best way to address the issue within the
Dynamic Registration draft is to provide an explanation.  The examples you
provided in your posting could easily be included in the Dynamic
Registration draft and would achieve the desired effect of demonstrating how
the OAuth 2.0 scope parameter might be used.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

From: Justin Richer [mailto:[email-masked]] 
Sent: Friday, April 12, 2013 11:25 AM
To: [email-masked]
Subject: [OAUTH-WG] Registration: Scope Values

Currently, the Dynamic Registration draft defines a "scope" value as part of
the client metadata table, with the following definition:

   scope
      OPTIONAL.  Space separated list of scope values (as described in
      OAuth 2.0 Section <http://tools.ietf.org/html/rfc6749#section-3.3>
3.3 [RFC6749]) 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.

However, it's been brought up in some side conversations that the language
as found in the DynReg spec might get in the way of people using the "scope"
field as an expression language. That is to say, you could have a scope like
<mailto:send_email_to:[email-masked]>
"send_email_to:[email-masked]" where the email address portion is
variable, or something like "read:*" which stands in for any scopes starting
with "read:" like "read:profile", "read:lists", etc. Precluding this
behavior wasn't my intent, and a liberal interpretation of the text
as-written would (I believe) lead to this being perfectly OK. Namely:

Client requests and is granted a service specific scope value like
"send_email_to" in registration. At runtime, the client knows how to turn
"send_email_to" into  <mailto:send_email_to:[email-masked]>
"send_email_to:[email-masked]", and the AS knows that a client that's
been granted "send_email_to" can ask for
<mailto:send_email_to:[email-masked]>
"send_email_to:[email-masked]". The fact that "send_email_to" expands
into an expression language is something specific to the service, and I
personally think it's up to the service to document "register for this" and
"ask for this at authn time" for clients, since this is all part of the API
more than it is part of the underlying OAuth protocol. OAuth merely provides
a handy place to communicate these values in an interoperable way, the
values themselves aren't intended to be interoperable. 

 -- Justin