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