On 04/06/2010 11:50 PM, Eran Hammer-Lahav wrote:
That's only when you need to trust the client. If your requirements demand
registration, discovery is mostly pointless (other than dynamic configuration).
At the risk of comparing apples and pears - many large-scale SAML
deployments rely on di
Yes, if we go with RFC 2617, then--and please correct me if I am
wrong--it looks to me that *realm* here means pretty much the same thing
as *Kerberos realm*. I strongly agree on getting the definition clear,
and I agree that nothing should be "opaque."
(I as puzzled by the quoted exchange, an
On Tue, Apr 6, 2010 at 3:12 PM, Eran Hammer-Lahav wrote:
> I am still waiting for someone to show how a scope parameter with an opaque
> value helps interop, where every single example requires the client to know
> how to construct this opaque string. OAuth libraries will need to support
> extensi
Thanks John.
I tend to agree that realm comes with a lot of baggage and is probably not
going to work given people's expectations. After all, they are not likely to
study 2617 before implementing OAuth.
The point of my proposal was to show one aspect of scope in which the client is
being told
I am still waiting for someone to show how a scope parameter with an opaque
value helps interop, where every single example requires the client to know how
to construct this opaque string. OAuth libraries will need to support extension
parameters - that's a given. So how is this not an extension
On Tue, Apr 6, 2010 at 2:42 PM, Eran Hammer-Lahav wrote:
> The question is how your APIs are structure. Do you have APIs that require
> multiple “scopes” in a single call?
Things can get even more complicated. When the user grants access for
the client, the approval page should list all the scope
That's only when you need to trust the client. If your requirements demand
registration, discovery is mostly pointless (other than dynamic configuration).
EHL
On 4/6/10 6:58 AM, "Brian Eaton" wrote:
Web clients are expected to have secrets or to have otherwise
registered with the AS. In orde
The question is how your APIs are structure. Do you have APIs that require
multiple "scopes" in a single call?
EHL
On 4/6/10 8:29 AM, "Luke Shepard" wrote:
For Facebook at least, we are currently planning to use scope as a
comma-separated list of permissions from this set:
http://wiki.devel
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
t
For Facebook at least, we are currently planning to use scope as a
comma-separated list of permissions from this set:
http://wiki.developers.facebook.com/index.php/Extended_permissions
For instance:
oauth_scope=read_stream,email,photo_upload
I'm not sure if that maps to realm exactly.
On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote:
>
>
>
> On 4/2/10 3:27 PM, "Dick Hardt" 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
> n
Web clients are expected to have secrets or to have otherwise
registered with the AS. In order for them to use those secrets, they
need to know the AS URL.
Cheers,
Brian
On Tue, Apr 6, 2010 at 1:23 AM, Eran Hammer-Lahav wrote:
> Why?
>
>
> On 4/6/10 12:58 AM, "Brian Eaton" wrote:
>
> On Tue, A
Why?
On 4/6/10 12:58 AM, "Brian Eaton" wrote:
On Tue, Apr 6, 2010 at 12:47 AM, Eran Hammer-Lahav wrote:
> That's the same as what I have in the draft, only with a single endpoint
> instead of two. Since we already have a 'mode' parameter (which I am
> renaming to 'type'), that single endpoint
On Tue, Apr 6, 2010 at 12:47 AM, Eran Hammer-Lahav wrote:
> That’s the same as what I have in the draft, only with a single endpoint
> instead of two. Since we already have a ‘mode’ parameter (which I am
> renaming to ‘type’), that single endpoint can speak more than one flow.
Note that the disco
That's the same as what I have in the draft, only with a single endpoint
instead of two. Since we already have a 'mode' parameter (which I am renaming
to 'type'), that single endpoint can speak more than one flow.
EHL
On 4/6/10 12:37 AM, "Brian Eaton" wrote:
On Tue, Apr 6, 2010 at 12:13 AM,
On Tue, Apr 6, 2010 at 12:13 AM, Eran Hammer-Lahav wrote:
> Yep. I'm trying to remove the need for a more complex discovery.
Not sure we need to do anything, discovery is pretty simple already.
We've been talking a bit about how to enable OAuth for IMAP:
http://tech.groups.yahoo.com/group/sasl_o
On 4/2/10 3:27 PM, "Dick Hardt" 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. For any other scope attribute we need to first define it.
EHL
> On
opaque="5ccc069c403ebaf9f0171e9517f40e41"
>>
>> regards,
>> Torsten.
>>> Presumably, the realm was used to discover the token issuance endpoints.
>>> Why wouldn't the discovered URL of the access token endpoint dictate
>>> realm, and w
Hi Eran,
On Apr 2, 2010, at 12:18 PM, Eran Hammer-Lahav wrote:
> This is half baked but I wanted to get people's reaction:
>
> Clients tries accessing a resource with or without an access token:
>
> GET /resource/1 HTTP/1.1
> Host: server.example.com
>
> The server replies with:
>
> HTTP/1.1
ot;
regards,
Torsten.
Presumably, the realm was used to discover the token issuance endpoints.
Why wouldn't the discovered URL of the access token endpoint dictate
realm, and why can't the realm then be implicit beyond discovery?
-Original Message-
From: Eran Hammer-Lahav
To: OAuth W
beyond discovery?
-----Original Message-
From: Eran Hammer-Lahav
To: OAuth WG
Subject: [OAUTH-WG] Scope using Realm idea
Date: Fri, 2 Apr 2010 09:18:36 -0700
This is half baked but I wanted to get people's reaction:
Clients tries accessing a resource with or without an access tok
There are times when a resource may have different scope for different kinds of
access. realm != scope
On 2010-04-02, at 2:45 PM, Igor Faynberg wrote:
>
>
> I don't see any problem at all.
>
> Igor
>
> David Recordon wrote:
>> Assuming that this is mean to replace the scope parameter?
>>
>>
I don't see any problem at all.
Igor
David Recordon wrote:
Assuming that this is mean to replace the scope parameter?
On Fri, Apr 2, 2010 at 9:18 AM, Eran Hammer-Lahav wrote:
This is half baked but I wanted to get people's reaction:
Clients tries accessing a resource with or without an
Assuming that this is mean to replace the scope parameter?
On Fri, Apr 2, 2010 at 9:18 AM, Eran Hammer-Lahav wrote:
> This is half baked but I wanted to get people's reaction:
>
> Clients tries accessing a resource with or without an access token:
>
> GET /resource/1 HTTP/1.1
> Host: server.exa
[OAUTH-WG] Scope using Realm idea
Date: Fri, 2 Apr 2010 09:18:36 -0700
This is half baked but I wanted to get people's reaction:
Clients tries accessing a resource with or without an access token:
GET /resource/1 HTTP/1.1
Host: server.example.com
The server replies with:
HTTP/1.1 401 Una
This is half baked but I wanted to get people's reaction:
Clients tries accessing a resource with or without an access token:
GET /resource/1 HTTP/1.1
Host: server.example.com
The server replies with:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: OAuth realm='example'
Clients requests an
26 matches
Mail list logo
