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
