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 protected] [mailto:[email protected]] 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:
"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 protected]> wrote:
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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
