RFC 2617 defines what a realm is - a set of resources sharing the same set
of credentials. It saves the client the need to prompt the user again for
their credentials when browsing a site across resources. Because sending
credentials to the wrong place is dangerous, realms are hard to use because
the client must take into account more than just the same realm but also the
domain name, etc.
Most of the example people gave for their use of scope where in practice a
segment ('photos', 'contacts', etc.). Usually each of these groups use
different APIs (a single API call that can bring both a photo and contact,
but only a photo if using a limited token without contact access, is rare).
This is why I suggested using realm as a well defined subset of what people
here refer to as 'scope'.
I don't like the idea of defining a parameter that requires internal
structure as opaque and leaving it up to the individual services to define.
This doesn't help interop. If you have to define the structure of the scope
parameter, you might as well define the parameter as well.
The argument that having a consistent parameter with an opaque value help
libraries is silly. Good libraries will pass along any custom parameters
they found to the higher level. This adds nothing but is likely to cause
problems when people code libraries with scope structure specific to one
company. It will also cause confusion when two scopes mean completely
different things across services.
EHL
On 4/6/10 8:03 AM, "Dick Hardt" <dick.ha...@gmail.com> wrote:
>
>
> On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote:
>
>>
>>
>>
>> On 4/2/10 3:27 PM, "Dick Hardt" <dick.ha...@gmail.com> wrote:
>>
>>> There are times when a resource may have different scope for different kinds
>>> of access. realm != scope
>>
>> No. Realm is a subset. It is what people define as the protected segment
>> name.
>
> Different Protected Resources could require the same scope, so I see realm
> and scope as being orthogonal.
>
>> For any other scope attribute we need to first define it.
>
> Why? Scope will often be application specific.
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
