Subject: [OAUTH-WG] The meaning of scope

From: Yaron Goland <[email-masked]>
Date: Thu, 8 Jul 2010 17:37:44 +0000

Today the definition of scope is vague. But I have seen mails on this list (such as Lukas Rosenstock's post http://www.ietf.org/mail-archive/web/oauth/current/msg03560.html which is just one example) that assert that scope represents the permissions that a client is requesting.

When we use scope (going back to its introduction in WRAP) we used it primary for two legged OAuth as a way for a client to tell a token endpoint what audience (in the SAML sense) it wanted a token for. This had nothing to do with the specific permission being requested. We used other claims for that.

I am not asking the group to agree with our usage. But I do want to check if the language in the spec (which really doesn't define scope very tightly) is actually consistent with what is in people's heads. Does the group see scope as a generally undefined entity that has to be defined in context (one such context could be that scope represents requested permissions) or do they see it just as a place to stick requested permissions?

                What say you?

                                Thanks,

                                                Yaron

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 8 Jul 2010 11:05:42 -0700

To me, scope means "the stuff being accessed", but can also mean permissions, duration, etc. I raised this issue a while back but since we could not agree on what exactly is included in scope, it was left vague. The key is the space-delimited values and how they relate to each other ("a b" covers "a" and "b" and is the same as "b a"). That is all the interop help the spec currently provides.

This definition doesn't work well with generic permissions or duration. For example:

"friends photos read 2days" doesn't really work because "read" and "2days" don't hold on their own. On the other hand:

"friends:read:2d photos:write:1y" does work.

If someone needs a global permission or duration, they can define an extension parameter but I have not seen any APIs where this was needed, and where the above example will not work. I think there is value in more standardization here but I don't have the use cases to suggest what it should look like.

EHL

On 7/8/10 10:37 AM, "Yaron Goland" <[email-masked]> wrote:

                What say you?

                                Thanks,

                                                Yaron

---

From: "William Mills" <[email-masked]>
Date: Thu, 8 Jul 2010 11:18:22 -0700

Leaving it loosely defined is good in my opinion.  
 
The way I see scope is as a way to limit the power of a token.  Examples
of this might be "mail" to limit to only accessing e-mail, or
"read-only" for something like a calendar sync application pulling
events out of an online calendar.  My mental model of scope does not
include expiration, since I believe tokens themselves should have
embedded timestamps if you want to support expiration.  

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eran Hammer-Lahav
	Sent: Thursday, July 08, 2010 11:06 AM
	To: Yaron Goland; OAuth WG
	Subject: Re: [OAUTH-WG] The meaning of scope

	To me, scope means "the stuff being accessed", but can also mean
permissions, duration, etc. I raised this issue a while back but since
we could not agree on what exactly is included in scope, it was left
vague. The key is the space-delimited values and how they relate to each
other ("a b" covers "a" and "b" and is the same as "b a"). That is all
the interop help the spec currently provides.
	
	This definition doesn't work well with generic permissions or
duration. For example:
	
	"friends photos read 2days" doesn't really work because "read"
and "2days" don't hold on their own. On the other hand:

	If someone needs a global permission or duration, they can
define an extension parameter but I have not seen any APIs where this
was needed, and where the above example will not work. I think there is
value in more standardization here but I don't have the use cases to
suggest what it should look like.
	
	EHL

		Today the definition of scope is vague. But I have seen
mails on this list (such as Lukas Rosenstock's post
http://www.ietf.org/mail-archive/web/oauth/current/msg03560.html which
is just one example) that assert that scope represents the permissions
that a client is requesting.
		 
		When we use scope (going back to its introduction in
WRAP) we used it primary for two legged OAuth as a way for a client to
tell a token endpoint what audience (in the SAML sense) it wanted a
token for. This had nothing to do with the specific permission being
requested. We used other claims for that.
		 
		I am not asking the group to agree with our usage. But I
do want to check if the language in the spec (which really doesn't
define scope very tightly) is actually consistent with what is in
people's heads. Does the group see scope as a generally undefined entity
that has to be defined in context (one such context could be that scope
represents requested permissions) or do they see it just as a place to
stick requested permissions? 
		 
		                What say you?
		 
		                                Thanks,
		 
		                                                Yaron

---

From: Diogo Almeida <[email-masked]>
Date: Fri, 9 Jul 2010 12:56:49 +0100

Hello,

Even though I realize that the small open-source lib developer voice might not carry much weight, I would to make a small contribution to this thread, presenting the WG with the mechanics we currently use to support scopes in our soon to release -09  Ruby provider lib:

1) a provider registers the clients, assigning them an ID and Secret
2) as with most membership and roles, the provider sets the possible scope of action for a given client ("outer bound")
3) we allow the provider to define system wide default scopes, or per client
4) when an authorization request comes in, we validate the client and the user authentication
4.1) in this same request the client sends an optional scope (eg friends photos videos extended_user_info)
5) the provider then checks the requested scope
5.1) validates it based on the "outer bound"
5.2) the computed scope is validated against the user (eg some users might not want to make their extended user info, such as email, available to the client)
6) we generate the authorization code and, in this case, redirect with the scope "friends photos"

It's -indeed- quite an assumption we're making here [eventually a wrong one], as it limits the use of scope in our implementation to the permissions. For instance, we, for now, left out the "duration scopes" suggested by Eran in his previous email.

It would be very valuable for us to have more explicit texts regarding the use of scopes.

Best regards,
Diogo Almeida

On Jul 8, 2010, at 7:18 PM, William Mills wrote:

> The way I see scope is as a way to limit the power of a token.  Examples of this might be "mail" to limit to only accessing e-mail, or "read-only" for something like a calendar sync application pulling events out of an online calendar.  My mental model of scope does not include expiration, since I believe tokens themselves should have embedded timestamps if you want to support expiration. 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
> To me, scope means “the stuff being accessed”, but can also mean permissions, duration, etc. I raised this issue a while back but since we could not agree on what exactly is included in scope, it was left vague. The key is the space-delimited values and how they relate to each other (“a b” covers “a” and “b” and is the same as “b a”). That is all the interop help the spec currently provides.
> 
> This definition doesn’t work well with generic permissions or duration. For example:
> 
> “friends photos read 2days” doesn’t really work because “read” and “2days” don’t hold on their own. On the other hand:
> 
> “friends:read:2d photos:write:1y” does work.
> 
> If someone needs a global permission or duration, they can define an extension parameter but I have not seen any APIs where this was needed, and where the above example will not work. I think there is value in more standardization here but I don’t have the use cases to suggest what it should look like.
> 
> EHL
> 
> 
> Today the definition of scope is vague. But I have seen mails on this list (such as Lukas Rosenstock’s post http://www.ietf.org/mail-archive/web/oauth/current/msg03560.html which is just one example) that assert that scope represents the permissions that a client is requesting.
>  
> I am not asking the group to agree with our usage. But I do want to check if the language in the spec (which really doesn’t define scope very tightly) is actually consistent with what is in people’s heads. Does the group see scope as a generally undefined entity that has to be defined in context (one such context could be that scope represents requested permissions) or do they see it just as a place to stick requested permissions? 
>  
>                 What say you?
>  
>                                 Thanks,
>  
>                                                 Yaron
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth