Re: [OAUTH-WG] resource server id needed?

[Eve Maler]

The "scope flow" is intended to carry this information, and the authz 
manager/server compares the requested scope to a known mapping of protected 
resources to resource servers. (We're still working out details, and also 
trying to keep up with the changes to the OAuth2 substrate...)

Eve

On 3 Aug 2010, at 7:04 AM, Torsten Lodderstedt wrote:

> I mean address as in "uniquely label".
> 
> Based on your explanation I assume you address resources instead of resource 
> servers. Correct? What parameter of the end-user authorization flow is used 
> to indicate the resource URL to the authz server. The scope?
> 
> regards,
> Torsten.
> 
> 
> 
> Am 02.08.2010 um 02:16 schrieb Eve Maler :
> 
>> I'm not sure if you mean "address" as in "handle", or "address" as in 
>> "uniquely label", but... UMA's first step involves a user-delegated 
>> introduction of a resource server to an authorization server as a special 
>> kind of client of it, using an OAuth2 web server flow with dynamic client 
>> registration as necessary. As part of this overall process, the resource 
>> server can tell the authorization server specifically which resource URLs 
>> are protected thereby (one way to do this is to wield its just-acquired 
>> access token at a protected resource registration endpoint at the authz 
>> server). Access tokens given to requesters (the real end-of-the-line 
>> clients) for accessing these resources are currently assumed to be given out 
>> on a per-resource-server basis, and each resource is uniquely associated 
>> with a single resource server and uniquely protected by a single 
>> authorization server, so there is no ambiguity. I suppose a resource server 
>> namespace could allow for higher-order aggregation as discussed below but I 
>> would personally prefer baby steps when it comes to the amount of dynamicism 
>> we're already assuming...
>> 
>> If you want to follow along with the UMA work, we have floated a number of 
>> spec drafts for these portions of our Step 1, and should shortly (within a 
>> day or so) have a more fleshed-out resource registration draft ready. We're 
>> not just cataloguing the resource URLs, but also the possible methods for 
>> accessing them; our assumption to date, as noted previously on this list, 
>> has been that the simple set of HTTP methods can get everyone really far -- 
>> but mindful of the need in OAuth-land for arbitrary "space-delimited list of 
>> strings" for scope, the current nascent draft allows for this.
>> 
>>  Eve
>> 
>> On 28 Jul 2010, at 11:32 PM, Torsten Lodderstedt wrote:
>> 
>>> Eve,
>>> 
>>> how does UMA plan to address resource servers during the OAuth end-user 
>>> authorization process?
>>> 
>>> regards,
>>> Torsten.
>>> 
>>> Am 29.07.2010 02:37, schrieb Eve Maler:
 
 Belatedly...  Sorry if I sound like a broken record on this, but: Most of 
 UMA's use involve letting a user introduce their various hosts 
 (UMA-flavored resource servers) to their single chosen "authorization 
 manager" (UMA-flavored authorization server), by treating the former as a 
 dynamically introduced OAuth client of the latter. This sounds an awful 
 lot like the question originally posed in this thread. We have exactly the 
 problem of figuring out how the host can tell the AM what resources the AM 
 should be protecting and what can be done to them, which we've begun to 
 solve with what we're calling a "resource registration API" (RRAPI).
 
 (BTW, we're also working on an I-D to submit here that proposes a solution 
 for discovery/dynamic registration that meets our needs. Hoping it can 
 feed into Eran's discovery work.)
 
  Eve
 
 On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote:
 
> thanks for sharing your thoughts.
> 
> Differentiating resource servers by using different end-user 
> authorization endpoint URLs is an option. I dont't know how this will 
> work in conjunction with discovery, especially since this differentiation 
> might by required on other endpoints, too. For example, if a client wants 
> to obtain an access token for the end-user's credentials, it has to 
> identify the resource server also on the tokens endpoint. There might be 
> additional endpoint for other flows with similar requirements, e.g. the 
> device flow.
> 
> Based on your proposal, a derived solution could be to define a standard 
> parameter "resourceserver" and to state how clients should use this 
> parameter on the different endpoints. On the coding level, there would be 
> no difference to your proposal :-) But the client would be able to 
> construct such a URL on its own.
> 
> Authorizing access for different resource servers is indeed an issue for 
> me. How would you propose to add the namespace? Shall the scope obtained 
> from the resource server already contain such a namespace are shall there 
> 

Re: [OAUTH-WG] resource server id needed?

[Torsten Lodderstedt]

I mean address as in "uniquely label".

Based on your explanation I assume you address resources instead of resource 
servers. Correct? What parameter of the end-user authorization flow is used to 
indicate the resource URL to the authz server. The scope?

regards,
Torsten.



Am 02.08.2010 um 02:16 schrieb Eve Maler :

> I'm not sure if you mean "address" as in "handle", or "address" as in 
> "uniquely label", but... UMA's first step involves a user-delegated 
> introduction of a resource server to an authorization server as a special 
> kind of client of it, using an OAuth2 web server flow with dynamic client 
> registration as necessary. As part of this overall process, the resource 
> server can tell the authorization server specifically which resource URLs are 
> protected thereby (one way to do this is to wield its just-acquired access 
> token at a protected resource registration endpoint at the authz server). 
> Access tokens given to requesters (the real end-of-the-line clients) for 
> accessing these resources are currently assumed to be given out on a 
> per-resource-server basis, and each resource is uniquely associated with a 
> single resource server and uniquely protected by a single authorization 
> server, so there is no ambiguity. I suppose a resource server namespace could 
> allow for higher-order aggregation as discussed below but I would personally 
> prefer baby steps when it comes to the amount of dynamicism we're already 
> assuming...
> 
> If you want to follow along with the UMA work, we have floated a number of 
> spec drafts for these portions of our Step 1, and should shortly (within a 
> day or so) have a more fleshed-out resource registration draft ready. We're 
> not just cataloguing the resource URLs, but also the possible methods for 
> accessing them; our assumption to date, as noted previously on this list, has 
> been that the simple set of HTTP methods can get everyone really far -- but 
> mindful of the need in OAuth-land for arbitrary "space-delimited list of 
> strings" for scope, the current nascent draft allows for this.
> 
>   Eve
> 
> On 28 Jul 2010, at 11:32 PM, Torsten Lodderstedt wrote:
> 
>> Eve,
>> 
>> how does UMA plan to address resource servers during the OAuth end-user 
>> authorization process?
>> 
>> regards,
>> Torsten.
>> 
>> Am 29.07.2010 02:37, schrieb Eve Maler:
>>> 
>>> Belatedly...  Sorry if I sound like a broken record on this, but: Most of 
>>> UMA's use involve letting a user introduce their various hosts 
>>> (UMA-flavored resource servers) to their single chosen "authorization 
>>> manager" (UMA-flavored authorization server), by treating the former as a 
>>> dynamically introduced OAuth client of the latter. This sounds an awful lot 
>>> like the question originally posed in this thread. We have exactly the 
>>> problem of figuring out how the host can tell the AM what resources the AM 
>>> should be protecting and what can be done to them, which we've begun to 
>>> solve with what we're calling a "resource registration API" (RRAPI).
>>> 
>>> (BTW, we're also working on an I-D to submit here that proposes a solution 
>>> for discovery/dynamic registration that meets our needs. Hoping it can feed 
>>> into Eran's discovery work.)
>>> 
>>>  Eve
>>> 
>>> On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote:
>>> 
 thanks for sharing your thoughts.
 
 Differentiating resource servers by using different end-user authorization 
 endpoint URLs is an option. I dont't know how this will work in 
 conjunction with discovery, especially since this differentiation might by 
 required on other endpoints, too. For example, if a client wants to obtain 
 an access token for the end-user's credentials, it has to identify the 
 resource server also on the tokens endpoint. There might be additional 
 endpoint for other flows with similar requirements, e.g. the device flow.
 
 Based on your proposal, a derived solution could be to define a standard 
 parameter "resourceserver" and to state how clients should use this 
 parameter on the different endpoints. On the coding level, there would be 
 no difference to your proposal :-) But the client would be able to 
 construct such a URL on its own.
 
 Authorizing access for different resource servers is indeed an issue for 
 me. How would you propose to add the namespace? Shall the scope obtained 
 from the resource server already contain such a namespace are shall there 
 be a rule to construct such namespaced-ed scopes in the spec?
 
 regards,
 Torsten.
 
 Am 25.07.2010 19:11, schrieb Andrew Arnott:
> 
> It seems to me that if one auth server can create tokens for a diverse 
> set of resource servers, then why not have different user authorization 
> endpoint URLs for each type of resource server, as an added 
> differentiator for the scope (a namespace, if you will)?
> 
> So supp

Re: [OAUTH-WG] resource server id needed?

[Eve Maler]

I'm not sure if you mean "address" as in "handle", or "address" as in "uniquely 
label", but... UMA's first step involves a user-delegated introduction of a 
resource server to an authorization server as a special kind of client of it, 
using an OAuth2 web server flow with dynamic client registration as necessary. 
As part of this overall process, the resource server can tell the authorization 
server specifically which resource URLs are protected thereby (one way to do 
this is to wield its just-acquired access token at a protected resource 
registration endpoint at the authz server). Access tokens given to requesters 
(the real end-of-the-line clients) for accessing these resources are currently 
assumed to be given out on a per-resource-server basis, and each resource is 
uniquely associated with a single resource server and uniquely protected by a 
single authorization server, so there is no ambiguity. I suppose a resource 
server namespace could allow for higher-order aggregation as discussed below 
but I would personally prefer baby steps when it comes to the amount of 
dynamicism we're already assuming...

If you want to follow along with the UMA work, we have floated a number of spec 
drafts for these portions of our Step 1, and should shortly (within a day or 
so) have a more fleshed-out resource registration draft ready. We're not just 
cataloguing the resource URLs, but also the possible methods for accessing 
them; our assumption to date, as noted previously on this list, has been that 
the simple set of HTTP methods can get everyone really far -- but mindful of 
the need in OAuth-land for arbitrary "space-delimited list of strings" for 
scope, the current nascent draft allows for this.

Eve

On 28 Jul 2010, at 11:32 PM, Torsten Lodderstedt wrote:

> Eve,
> 
> how does UMA plan to address resource servers during the OAuth end-user 
> authorization process?
> 
> regards,
> Torsten.
> 
> Am 29.07.2010 02:37, schrieb Eve Maler:
>> 
>> Belatedly...  Sorry if I sound like a broken record on this, but: Most of 
>> UMA's use involve letting a user introduce their various hosts (UMA-flavored 
>> resource servers) to their single chosen "authorization manager" 
>> (UMA-flavored authorization server), by treating the former as a dynamically 
>> introduced OAuth client of the latter. This sounds an awful lot like the 
>> question originally posed in this thread. We have exactly the problem of 
>> figuring out how the host can tell the AM what resources the AM should be 
>> protecting and what can be done to them, which we've begun to solve with 
>> what we're calling a "resource registration API" (RRAPI).
>> 
>> (BTW, we're also working on an I-D to submit here that proposes a solution 
>> for discovery/dynamic registration that meets our needs. Hoping it can feed 
>> into Eran's discovery work.)
>> 
>>  Eve
>> 
>> On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote:
>> 
>>> thanks for sharing your thoughts.
>>> 
>>> Differentiating resource servers by using different end-user authorization 
>>> endpoint URLs is an option. I dont't know how this will work in conjunction 
>>> with discovery, especially since this differentiation might by required on 
>>> other endpoints, too. For example, if a client wants to obtain an access 
>>> token for the end-user's credentials, it has to identify the resource 
>>> server also on the tokens endpoint. There might be additional endpoint for 
>>> other flows with similar requirements, e.g. the device flow.
>>> 
>>> Based on your proposal, a derived solution could be to define a standard 
>>> parameter "resourceserver" and to state how clients should use this 
>>> parameter on the different endpoints. On the coding level, there would be 
>>> no difference to your proposal :-) But the client would be able to 
>>> construct such a URL on its own.
>>> 
>>> Authorizing access for different resource servers is indeed an issue for 
>>> me. How would you propose to add the namespace? Shall the scope obtained 
>>> from the resource server already contain such a namespace are shall there 
>>> be a rule to construct such namespaced-ed scopes in the spec?
>>> 
>>> regards,
>>> Torsten.
>>> 
>>> Am 25.07.2010 19:11, schrieb Andrew Arnott:
 
 It seems to me that if one auth server can create tokens for a diverse set 
 of resource servers, then why not have different user authorization 
 endpoint URLs for each type of resource server, as an added differentiator 
 for the scope (a namespace, if you will)?
 
 So suppose one auth server serves two different photo services, both using 
 overlapping scopes such that a client requesting access of some scope is 
 otherwise ambiguous between which resource server the client needs access 
 to.  The auth server that serves both resource servers could have two end 
 user authorization endpoints:
 http://auth.server.org/authorize?resourceserver=1
 http://auth.server.org/authorize?resou

Re: [OAUTH-WG] resource server id needed?

[Torsten Lodderstedt]

Eve,

how does UMA plan to address resource servers during the OAuth end-user 
authorization process?


regards,
Torsten.

Am 29.07.2010 02:37, schrieb Eve Maler:
Belatedly...  Sorry if I sound like a broken record on this, but: Most 
of UMA's use involve letting a user introduce their various hosts 
(UMA-flavored resource servers) to their single chosen "authorization 
manager" (UMA-flavored authorization server), by treating the former 
as a dynamically introduced OAuth client of the latter. This sounds an 
awful lot like the question originally posed in this thread. We have 
exactly the problem of figuring out how the host can tell the AM what 
resources the AM should be protecting and what can be done to them, 
which we've begun to solve with what we're calling a "resource 
registration API" (RRAPI).


(BTW, we're also working on an I-D to submit here that proposes a 
solution for discovery/dynamic registration that meets our needs. 
Hoping it can feed into Eran's discovery work.)


Eve

On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote:


thanks for sharing your thoughts.

Differentiating resource servers by using different end-user 
authorization endpoint URLs is an option. I dont't know how this will 
work in conjunction with discovery, especially since this 
differentiation might by required on other endpoints, too. For 
example, if a client wants to obtain an access token for the 
end-user's credentials, it has to identify the resource server also 
on the tokens endpoint. There might be additional endpoint for other 
flows with similar requirements, e.g. the device flow.


Based on your proposal, a derived solution could be to define a 
standard parameter "resourceserver" and to state how clients should 
use this parameter on the different endpoints. On the coding level, 
there would be no difference to your proposal :-) But the client 
would be able to construct such a URL on its own.


Authorizing access for different resource servers is indeed an issue 
for me. How would you propose to add the namespace? Shall the scope 
obtained from the resource server already contain such a namespace 
are shall there be a rule to construct such namespaced-ed scopes in 
the spec?


regards,
Torsten.

Am 25.07.2010 19:11, schrieb Andrew Arnott:
It seems to me that if one auth server can create tokens for a 
diverse set of resource servers, then why not have different user 
authorization endpoint URLs for each type of resource server, as an 
added differentiator for the scope (a namespace, if you will)?


So suppose one auth server serves two different photo services, both 
using overlapping scopes such that a client requesting access of 
some scope is otherwise ambiguous between which resource server the 
client needs access to.  The auth server that serves both resource 
servers could have two end user authorization endpoints:

http://auth.server.org/authorize?resourceserver=1
http://auth.server.org/authorize?resourceserver=2

And that way the auth server knows exactly what the client needs.

The only scenario this doesn't allow for is for a user to authorize 
a client's access to /both/ resource servers in one redirect.  If 
this were an issue, perhaps you can apply a namespace-like prefix to 
each scope substring:


rs1:photo:read rs2:photo:read

Which would serve a similar purpose.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the 
death your right to say it." - S. G. Tallentyre



On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:


no one else in the group having an opinion on this topic?



Am 15.07.2010 20:14, schrieb Marius Scurtescu:

On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>>  wrote:

As I have written in my reply to Marius's posting.
I'm fine with including
server ids in scopes. But this requires a definition
of the scope's syntax
and semantics in the spec. Otherwise, scope
interpretation (and server
identification) will be deployment specific.

Sure, it is deployment specific, but why is that an issue?

In your case, the authz server and all the resource
servers are
managed by the same organization, right?

Do clients need to be aware of the actual resource server?

You can probably create a separate spec that defines
scope syntax for
this purpose, if really needed. Does it have to be in core?

Marius


Solving the challenge I described in a deployment specific
way is not an issue. But the consequence is that authz
server, resource servers and clients are tight together.

Let me ask you one question: Why are we working together
towards a standard protocol? I can tell you my expect

Re: [OAUTH-WG] resource server id needed?

[Eve Maler]

Belatedly...  Sorry if I sound like a broken record on this, but: Most of UMA's 
use involve letting a user introduce their various hosts (UMA-flavored resource 
servers) to their single chosen "authorization manager" (UMA-flavored 
authorization server), by treating the former as a dynamically introduced OAuth 
client of the latter. This sounds an awful lot like the question originally 
posed in this thread. We have exactly the problem of figuring out how the host 
can tell the AM what resources the AM should be protecting and what can be done 
to them, which we've begun to solve with what we're calling a "resource 
registration API" (RRAPI).

(BTW, we're also working on an I-D to submit here that proposes a solution for 
discovery/dynamic registration that meets our needs. Hoping it can feed into 
Eran's discovery work.)

Eve

On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote:

> thanks for sharing your thoughts.
> 
> Differentiating resource servers by using different end-user authorization 
> endpoint URLs is an option. I dont't know how this will work in conjunction 
> with discovery, especially since this differentiation might by required on 
> other endpoints, too. For example, if a client wants to obtain an access 
> token for the end-user's credentials, it has to identify the resource server 
> also on the tokens endpoint. There might be additional endpoint for other 
> flows with similar requirements, e.g. the device flow.
> 
> Based on your proposal, a derived solution could be to define a standard 
> parameter "resourceserver" and to state how clients should use this parameter 
> on the different endpoints. On the coding level, there would be no difference 
> to your proposal :-) But the client would be able to construct such a URL on 
> its own.
> 
> Authorizing access for different resource servers is indeed an issue for me. 
> How would you propose to add the namespace? Shall the scope obtained from the 
> resource server already contain such a namespace are shall there be a rule to 
> construct such namespaced-ed scopes in the spec?
> 
> regards,
> Torsten.
> 
> Am 25.07.2010 19:11, schrieb Andrew Arnott:
>> 
>> It seems to me that if one auth server can create tokens for a diverse set 
>> of resource servers, then why not have different user authorization endpoint 
>> URLs for each type of resource server, as an added differentiator for the 
>> scope (a namespace, if you will)?
>> 
>> So suppose one auth server serves two different photo services, both using 
>> overlapping scopes such that a client requesting access of some scope is 
>> otherwise ambiguous between which resource server the client needs access 
>> to.  The auth server that serves both resource servers could have two end 
>> user authorization endpoints:
>> http://auth.server.org/authorize?resourceserver=1
>> http://auth.server.org/authorize?resourceserver=2
>> 
>> And that way the auth server knows exactly what the client needs.
>> 
>> The only scenario this doesn't allow for is for a user to authorize a 
>> client's access to both resource servers in one redirect.  If this were an 
>> issue, perhaps you can apply a namespace-like prefix to each scope substring:
>> 
>> rs1:photo:read rs2:photo:read
>> 
>> Which would serve a similar purpose.
>> 
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death 
>> your right to say it." - S. G. Tallentyre
>> 
>> 
>> On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt 
>>  wrote:
>> no one else in the group having an opinion on this topic?
>> 
>> 
>> 
>> Am 15.07.2010 20:14, schrieb Marius Scurtescu:
>> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
>>   wrote:
>> As I have written in my reply to Marius's posting. I'm fine with including
>> server ids in scopes. But this requires a definition of the scope's syntax
>> and semantics in the spec. Otherwise, scope interpretation (and server
>> identification) will be deployment specific.
>> Sure, it is deployment specific, but why is that an issue?
>> 
>> In your case, the authz server and all the resource servers are
>> managed by the same organization, right?
>> 
>> Do clients need to be aware of the actual resource server?
>> 
>> You can probably create a separate spec that defines scope syntax for
>> this purpose, if really needed. Does it have to be in core?
>> 
>> Marius
>> 
>> Solving the challenge I described in a deployment specific way is not an 
>> issue. But the consequence is that authz server, resource servers and 
>> clients are tight together.
>> 
>> Let me ask you one question: Why are we working together towards a standard 
>> protocol? I can tell you my expectations: I hope there will be broad support 
>> not only by libraries, but also by ready-to-use services and clients, so we 
>> could integrate such services into our deployment easily. Moreover, I would 
>> like to see OAuth to be included in application/service protocols like 
>> PortableContacts, S

Re: [OAUTH-WG] resource server id needed?

[Torsten Lodderstedt]

thanks for sharing your thoughts.

Differentiating resource servers by using different end-user 
authorization endpoint URLs is an option. I dont't know how this will 
work in conjunction with discovery, especially since this 
differentiation might by required on other endpoints, too. For example, 
if a client wants to obtain an access token for the end-user's 
credentials, it has to identify the resource server also on the tokens 
endpoint. There might be additional endpoint for other flows with 
similar requirements, e.g. the device flow.


Based on your proposal, a derived solution could be to define a standard 
parameter "resourceserver" and to state how clients should use this 
parameter on the different endpoints. On the coding level, there would 
be no difference to your proposal :-) But the client would be able to 
construct such a URL on its own.


Authorizing access for different resource servers is indeed an issue for 
me. How would you propose to add the namespace? Shall the scope obtained 
from the resource server already contain such a namespace are shall 
there be a rule to construct such namespaced-ed scopes in the spec?


regards,
Torsten.

Am 25.07.2010 19:11, schrieb Andrew Arnott:
It seems to me that if one auth server can create tokens for a diverse 
set of resource servers, then why not have different user 
authorization endpoint URLs for each type of resource server, as an 
added differentiator for the scope (a namespace, if you will)?


So suppose one auth server serves two different photo services, both 
using overlapping scopes such that a client requesting access of some 
scope is otherwise ambiguous between which resource server the client 
needs access to.  The auth server that serves both resource servers 
could have two end user authorization endpoints:

http://auth.server.org/authorize?resourceserver=1
http://auth.server.org/authorize?resourceserver=2

And that way the auth server knows exactly what the client needs.

The only scenario this doesn't allow for is for a user to authorize a 
client's access to /both/ resource servers in one redirect.  If this 
were an issue, perhaps you can apply a namespace-like prefix to each 
scope substring:


rs1:photo:read rs2:photo:read

Which would serve a similar purpose.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the 
death your right to say it." - S. G. Tallentyre



On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:


no one else in the group having an opinion on this topic?



Am 15.07.2010 20:14, schrieb Marius Scurtescu:

On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>>
 wrote:

As I have written in my reply to Marius's posting. I'm
fine with including
server ids in scopes. But this requires a definition
of the scope's syntax
and semantics in the spec. Otherwise, scope
interpretation (and server
identification) will be deployment specific.

Sure, it is deployment specific, but why is that an issue?

In your case, the authz server and all the resource
servers are
managed by the same organization, right?

Do clients need to be aware of the actual resource server?

You can probably create a separate spec that defines scope
syntax for
this purpose, if really needed. Does it have to be in core?

Marius


Solving the challenge I described in a deployment specific way
is not an issue. But the consequence is that authz server,
resource servers and clients are tight together.

Let me ask you one question: Why are we working together
towards a standard protocol? I can tell you my expectations: I
hope there will be broad support not only by libraries, but
also by ready-to-use services and clients, so we could
integrate such services into our deployment easily. Moreover,
I would like to see OAuth to be included in
application/service protocols like PortableContacts, SIP,
WebDAV, IMAP, ...

So what if I would like to use standard clients to access our
services? Using scopes for specifying resource server id's in
this case is also simple - if you take an isolated view. But
since scopes may be used to specifiy a lot of other things,
like resources, permissions, and durations, handling w/o a
more detailed spec will in practice be impossible.

Suppose a WebDAV service for media data access. Any WebDAV
client knows the WebDAV protocol (== interface), e.g. the
supported methods (GET, PUT, POST, DELETE, COPY, MOVE) and how
to traverse directories. So it is sufficient to configure the
client with

Re: [OAUTH-WG] resource server id needed?

[Andrew Arnott]

It seems to me that if one auth server can create tokens for a diverse set
of resource servers, then why not have different user authorization endpoint
URLs for each type of resource server, as an added differentiator for the
scope (a namespace, if you will)?

So suppose one auth server serves two different photo services, both using
overlapping scopes such that a client requesting access of some scope is
otherwise ambiguous between which resource server the client needs access
to.  The auth server that serves both resource servers could have two end
user authorization endpoints:
http://auth.server.org/authorize?resourceserver=1
http://auth.server.org/authorize?resourceserver=2

And that way the auth server knows exactly what the client needs.

The only scenario this doesn't allow for is for a user to authorize a
client's access to *both* resource servers in one redirect.  If this were an
issue, perhaps you can apply a namespace-like prefix to each scope
substring:

rs1:photo:read rs2:photo:read

Which would serve a similar purpose.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre


On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> no one else in the group having an opinion on this topic?
>
>
>
>  Am 15.07.2010 20:14, schrieb Marius Scurtescu:
>>
>>> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
>>>   wrote:
>>>
 As I have written in my reply to Marius's posting. I'm fine with
 including
 server ids in scopes. But this requires a definition of the scope's
 syntax
 and semantics in the spec. Otherwise, scope interpretation (and server
 identification) will be deployment specific.

>>> Sure, it is deployment specific, but why is that an issue?
>>>
>>> In your case, the authz server and all the resource servers are
>>> managed by the same organization, right?
>>>
>>> Do clients need to be aware of the actual resource server?
>>>
>>> You can probably create a separate spec that defines scope syntax for
>>> this purpose, if really needed. Does it have to be in core?
>>>
>>> Marius
>>>
>>
>> Solving the challenge I described in a deployment specific way is not an
>> issue. But the consequence is that authz server, resource servers and
>> clients are tight together.
>>
>> Let me ask you one question: Why are we working together towards a
>> standard protocol? I can tell you my expectations: I hope there will be
>> broad support not only by libraries, but also by ready-to-use services and
>> clients, so we could integrate such services into our deployment easily.
>> Moreover, I would like to see OAuth to be included in application/service
>> protocols like PortableContacts, SIP, WebDAV, IMAP, ...
>>
>> So what if I would like to use standard clients to access our services?
>> Using scopes for specifying resource server id's in this case is also simple
>> - if you take an isolated view. But since scopes may be used to specifiy a
>> lot of other things, like resources, permissions, and durations, handling
>> w/o a more detailed spec will in practice be impossible.
>>
>> Suppose a WebDAV service for media data access. Any WebDAV client knows
>> the WebDAV protocol (== interface), e.g. the supported methods (GET, PUT,
>> POST, DELETE, COPY, MOVE) and how to traverse directories. So it is
>> sufficient to configure the client with the URL of my personal web storage.
>> To start with let's assume, scopes are used to designate resource servers
>> only. So the server's scope could be "webstorage".
>>
>>WWW-Authenticate OAuth realm='webstorage' scope="webstorage"
>>
>> The client could just pass this parameter to the authz server and
>> everything is fine.
>>
>> On the next level, let's assume the (future) WebDAV standard with
>> OAuth-support uses one permission per method type. So the full scope could
>> be as follows:
>>
>>WWW-Authenticate OAuth realm='webstorage' scope="webstorage:GET
>> webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY
>> webstorage:MOVE"
>>
>> Passing this scope w/o any unmodified to the authz server is not an issue.
>> But this implies the client asks for full access to the users media storage.
>> Since our client is a gallery application, it requires the "GET" permission
>> only. How does the client know which of the scope values to pick for the
>> end-user authorization process? It must somehow select "webstorage:GET".
>>
>> But how?
>>
>> In my personal opinion, clients should be enabled to interpret, combine
>> and even create scopes. And yes, this should go to the core of the spec.
>>
>> regards,
>> Torsten.
>>
>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___

Re: [OAUTH-WG] resource server id needed?

[David Recordon]

I don't have a need for anything beyond the scope parameter here.


On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> no one else in the group having an opinion on this topic?
>
>
>
>  Am 15.07.2010 20:14, schrieb Marius Scurtescu:
>>
>>> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
>>>   wrote:
>>>
 As I have written in my reply to Marius's posting. I'm fine with
 including
 server ids in scopes. But this requires a definition of the scope's
 syntax
 and semantics in the spec. Otherwise, scope interpretation (and server
 identification) will be deployment specific.

>>> Sure, it is deployment specific, but why is that an issue?
>>>
>>> In your case, the authz server and all the resource servers are
>>> managed by the same organization, right?
>>>
>>> Do clients need to be aware of the actual resource server?
>>>
>>> You can probably create a separate spec that defines scope syntax for
>>> this purpose, if really needed. Does it have to be in core?
>>>
>>> Marius
>>>
>>
>> Solving the challenge I described in a deployment specific way is not an
>> issue. But the consequence is that authz server, resource servers and
>> clients are tight together.
>>
>> Let me ask you one question: Why are we working together towards a
>> standard protocol? I can tell you my expectations: I hope there will be
>> broad support not only by libraries, but also by ready-to-use services and
>> clients, so we could integrate such services into our deployment easily.
>> Moreover, I would like to see OAuth to be included in application/service
>> protocols like PortableContacts, SIP, WebDAV, IMAP, ...
>>
>> So what if I would like to use standard clients to access our services?
>> Using scopes for specifying resource server id's in this case is also simple
>> - if you take an isolated view. But since scopes may be used to specifiy a
>> lot of other things, like resources, permissions, and durations, handling
>> w/o a more detailed spec will in practice be impossible.
>>
>> Suppose a WebDAV service for media data access. Any WebDAV client knows
>> the WebDAV protocol (== interface), e.g. the supported methods (GET, PUT,
>> POST, DELETE, COPY, MOVE) and how to traverse directories. So it is
>> sufficient to configure the client with the URL of my personal web storage.
>> To start with let's assume, scopes are used to designate resource servers
>> only. So the server's scope could be "webstorage".
>>
>>WWW-Authenticate OAuth realm='webstorage' scope="webstorage"
>>
>> The client could just pass this parameter to the authz server and
>> everything is fine.
>>
>> On the next level, let's assume the (future) WebDAV standard with
>> OAuth-support uses one permission per method type. So the full scope could
>> be as follows:
>>
>>WWW-Authenticate OAuth realm='webstorage' scope="webstorage:GET
>> webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY
>> webstorage:MOVE"
>>
>> Passing this scope w/o any unmodified to the authz server is not an issue.
>> But this implies the client asks for full access to the users media storage.
>> Since our client is a gallery application, it requires the "GET" permission
>> only. How does the client know which of the scope values to pick for the
>> end-user authorization process? It must somehow select "webstorage:GET".
>>
>> But how?
>>
>> In my personal opinion, clients should be enabled to interpret, combine
>> and even create scopes. And yes, this should go to the core of the spec.
>>
>> regards,
>> Torsten.
>>
>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Torsten Lodderstedt]

no one else in the group having an opinion on this topic?



Am 15.07.2010 20:14, schrieb Marius Scurtescu:

On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
  wrote:
As I have written in my reply to Marius's posting. I'm fine with 
including
server ids in scopes. But this requires a definition of the scope's 
syntax

and semantics in the spec. Otherwise, scope interpretation (and server
identification) will be deployment specific.

Sure, it is deployment specific, but why is that an issue?

In your case, the authz server and all the resource servers are
managed by the same organization, right?

Do clients need to be aware of the actual resource server?

You can probably create a separate spec that defines scope syntax for
this purpose, if really needed. Does it have to be in core?

Marius


Solving the challenge I described in a deployment specific way is not 
an issue. But the consequence is that authz server, resource servers 
and clients are tight together.


Let me ask you one question: Why are we working together towards a 
standard protocol? I can tell you my expectations: I hope there will 
be broad support not only by libraries, but also by ready-to-use 
services and clients, so we could integrate such services into our 
deployment easily. Moreover, I would like to see OAuth to be included 
in application/service protocols like PortableContacts, SIP, WebDAV, 
IMAP, ...


So what if I would like to use standard clients to access our 
services? Using scopes for specifying resource server id's in this 
case is also simple - if you take an isolated view. But since scopes 
may be used to specifiy a lot of other things, like resources, 
permissions, and durations, handling w/o a more detailed spec will in 
practice be impossible.


Suppose a WebDAV service for media data access. Any WebDAV client 
knows the WebDAV protocol (== interface), e.g. the supported methods 
(GET, PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. 
So it is sufficient to configure the client with the URL of my 
personal web storage. To start with let's assume, scopes are used to 
designate resource servers only. So the server's scope could be 
"webstorage".


WWW-Authenticate OAuth realm='webstorage' scope="webstorage"

The client could just pass this parameter to the authz server and 
everything is fine.


On the next level, let's assume the (future) WebDAV standard with 
OAuth-support uses one permission per method type. So the full scope 
could be as follows:


WWW-Authenticate OAuth realm='webstorage' scope="webstorage:GET 
webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY 
webstorage:MOVE"


Passing this scope w/o any unmodified to the authz server is not an 
issue. But this implies the client asks for full access to the users 
media storage. Since our client is a gallery application, it requires 
the "GET" permission only. How does the client know which of the scope 
values to pick for the end-user authorization process? It must somehow 
select "webstorage:GET".


But how?

In my personal opinion, clients should be enabled to interpret, 
combine and even create scopes. And yes, this should go to the core of 
the spec.


regards,
Torsten.




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Torsten Lodderstedt]

Am 16.07.2010 19:00, schrieb Brian Eaton:

On Fri, Jul 16, 2010 at 9:41 AM, Torsten Lodderstedt
  wrote:
   

then we should put those use cases and requirements on the table and try to
find a solution fulfilling these different needs. That's what (from my point
of view) standard definition is all about.

What do you think?
 

Sounds fine to me.  I don't think we could realistically target the
work for the core oauth spec.  An extension would work well.
   


Why not?

And if an extension is the right place to define scope syntax and 
semantics, then I would suggest to move the scope parameter(s) to that 
extension, too. A scope parameter without a clear definition in the core 
endangers interoperability.



For my future use cases, at any rate, the core oauth spec is fine.
the web-server flow and the user-agent flow are both compatible with
what I'd want to do.
   


Regarding relations between authz servers, resource server and clients, 
we have the following requirements:


We definitely need support for deployments w/ 1 authz server, n 
resources servers, and m clients. At least resource servers and clients 
must be identifiable at the protocol level. I don't prefer a certain way 
of resource server identification: dedicated server_ids, including the 
server id within scopes or any other solution is acceptable.


We would like to see support for specifying permissions on resource 
servers. I think scope would be the natural way of specifying them.


What do others think?

regards,
Torsten.


Cheers,
Brian
   




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Brian Eaton]

On Fri, Jul 16, 2010 at 9:41 AM, Torsten Lodderstedt
 wrote:
> then we should put those use cases and requirements on the table and try to
> find a solution fulfilling these different needs. That's what (from my point
> of view) standard definition is all about.
>
> What do you think?

Sounds fine to me.  I don't think we could realistically target the
work for the core oauth spec.  An extension would work well.

For my future use cases, at any rate, the core oauth spec is fine.
the web-server flow and the user-agent flow are both compatible with
what I'd want to do.

Cheers,
Brian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Torsten Lodderstedt]

Am 16.07.2010 18:35, schrieb Brian Eaton:

On Fri, Jul 16, 2010 at 4:47 AM,  wrote:
   

+1 to Thorstens statement. There are use cases beyond local deployments.
 

Definitely.

For example, I'm interested in deployments where neither clients nor
resource servers need secret keys.  This makes adding new clients and
resource servers trivial.

The challenge here is that even though lots of people are interested
in various semantics for "scope", and various types of relations
between clients, resource servers, and authorization servers, not
everyone has the same use cases and requirements.
   


then we should put those use cases and requirements on the table and try 
to find a solution fulfilling these different needs. That's what (from 
my point of view) standard definition is all about.


What do you think?

regards,
Torsten.


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
   


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Brian Eaton]

On Fri, Jul 16, 2010 at 4:47 AM,   wrote:
> +1 to Thorstens statement. There are use cases beyond local deployments.

Definitely.

For example, I'm interested in deployments where neither clients nor
resource servers need secret keys.  This makes adding new clients and
resource servers trivial.

The challenge here is that even though lots of people are interested
in various semantics for "scope", and various types of relations
between clients, resource servers, and authorization servers, not
everyone has the same use cases and requirements.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Wolfgang.Steigerwald]

+1 to Thorstens statement. There are use cases beyond local deployments.

Best regards

 Wolfgang


-Ursprüngliche Nachricht-
Von: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] Im Auftrag von 
Torsten Lodderstedt
Gesendet: Freitag, 16. Juli 2010 00:49
An: Marius Scurtescu
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] resource server id needed?

Am 15.07.2010 20:14, schrieb Marius Scurtescu:
> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
>   wrote:
>
>> As I have written in my reply to Marius's posting. I'm fine with including
>> server ids in scopes. But this requires a definition of the scope's syntax
>> and semantics in the spec. Otherwise, scope interpretation (and server
>> identification) will be deployment specific.
>>  
> Sure, it is deployment specific, but why is that an issue?
>
> In your case, the authz server and all the resource servers are
> managed by the same organization, right?
>
> Do clients need to be aware of the actual resource server?
>
> You can probably create a separate spec that defines scope syntax for
> this purpose, if really needed. Does it have to be in core?
>
> Marius
>

Solving the challenge I described in a deployment specific way is not an 
issue. But the consequence is that authz server, resource servers and 
clients are tight together.

Let me ask you one question: Why are we working together towards a 
standard protocol? I can tell you my expectations: I hope there will be 
broad support not only by libraries, but also by ready-to-use services 
and clients, so we could integrate such services into our deployment 
easily. Moreover, I would like to see OAuth to be included in 
application/service protocols like PortableContacts, SIP, WebDAV, IMAP, ...

So what if I would like to use standard clients to access our services? 
Using scopes for specifying resource server id's in this case is also 
simple - if you take an isolated view. But since scopes may be used to 
specifiy a lot of other things, like resources, permissions, and 
durations, handling w/o a more detailed spec will in practice be impossible.

Suppose a WebDAV service for media data access. Any WebDAV client knows 
the WebDAV protocol (== interface), e.g. the supported methods (GET, 
PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. So it is 
sufficient to configure the client with the URL of my personal web 
storage. To start with let's assume, scopes are used to designate 
resource servers only. So the server's scope could be "webstorage".

 WWW-Authenticate OAuth realm='webstorage' scope="webstorage"

The client could just pass this parameter to the authz server and 
everything is fine.

On the next level, let's assume the (future) WebDAV standard with 
OAuth-support uses one permission per method type. So the full scope 
could be as follows:

 WWW-Authenticate OAuth realm='webstorage' scope="webstorage:GET 
webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY 
webstorage:MOVE"

Passing this scope w/o any unmodified to the authz server is not an 
issue. But this implies the client asks for full access to the users 
media storage. Since our client is a gallery application, it requires 
the "GET" permission only. How does the client know which of the scope 
values to pick for the end-user authorization process? It must somehow 
select "webstorage:GET".

But how?

In my personal opinion, clients should be enabled to interpret, combine 
and even create scopes. And yes, this should go to the core of the spec.

regards,
Torsten.




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Torsten Lodderstedt]

Am 15.07.2010 20:14, schrieb Marius Scurtescu:

On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
  wrote:
   

As I have written in my reply to Marius's posting. I'm fine with including
server ids in scopes. But this requires a definition of the scope's syntax
and semantics in the spec. Otherwise, scope interpretation (and server
identification) will be deployment specific.
 

Sure, it is deployment specific, but why is that an issue?

In your case, the authz server and all the resource servers are
managed by the same organization, right?

Do clients need to be aware of the actual resource server?

You can probably create a separate spec that defines scope syntax for
this purpose, if really needed. Does it have to be in core?

Marius
   


Solving the challenge I described in a deployment specific way is not an 
issue. But the consequence is that authz server, resource servers and 
clients are tight together.


Let me ask you one question: Why are we working together towards a 
standard protocol? I can tell you my expectations: I hope there will be 
broad support not only by libraries, but also by ready-to-use services 
and clients, so we could integrate such services into our deployment 
easily. Moreover, I would like to see OAuth to be included in 
application/service protocols like PortableContacts, SIP, WebDAV, IMAP, ...


So what if I would like to use standard clients to access our services? 
Using scopes for specifying resource server id's in this case is also 
simple - if you take an isolated view. But since scopes may be used to 
specifiy a lot of other things, like resources, permissions, and 
durations, handling w/o a more detailed spec will in practice be impossible.


Suppose a WebDAV service for media data access. Any WebDAV client knows 
the WebDAV protocol (== interface), e.g. the supported methods (GET, 
PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. So it is 
sufficient to configure the client with the URL of my personal web 
storage. To start with let's assume, scopes are used to designate 
resource servers only. So the server's scope could be "webstorage".


WWW-Authenticate OAuth realm='webstorage' scope="webstorage"

The client could just pass this parameter to the authz server and 
everything is fine.


On the next level, let's assume the (future) WebDAV standard with 
OAuth-support uses one permission per method type. So the full scope 
could be as follows:


WWW-Authenticate OAuth realm='webstorage' scope="webstorage:GET 
webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY 
webstorage:MOVE"


Passing this scope w/o any unmodified to the authz server is not an 
issue. But this implies the client asks for full access to the users 
media storage. Since our client is a gallery application, it requires 
the "GET" permission only. How does the client know which of the scope 
values to pick for the end-user authorization process? It must somehow 
select "webstorage:GET".


But how?

In my personal opinion, clients should be enabled to interpret, combine 
and even create scopes. And yes, this should go to the core of the spec.


regards,
Torsten.




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Marius Scurtescu]

On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
 wrote:
> As I have written in my reply to Marius's posting. I'm fine with including
> server ids in scopes. But this requires a definition of the scope's syntax
> and semantics in the spec. Otherwise, scope interpretation (and server
> identification) will be deployment specific.

Sure, it is deployment specific, but why is that an issue?

In your case, the authz server and all the resource servers are
managed by the same organization, right?

Do clients need to be aware of the actual resource server?

You can probably create a separate spec that defines scope syntax for
this purpose, if really needed. Does it have to be in core?

Marius
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Ivan Pulleyn]

On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

>  As I have written in my reply to Marius's posting. I'm fine with including
> server ids in scopes. But this requires a definition of the scope's syntax
> and semantics in the spec. Otherwise, scope interpretation (and server
> identification) will be deployment specific.
>
>
Yes, I believe the definition of scope implies this.

Ivan...
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Torsten Lodderstedt]

As I have written in my reply to Marius's posting. I'm fine with 
including server ids in scopes. But this requires a definition of the 
scope's syntax and semantics in the spec. Otherwise, scope 
interpretation (and server identification) will be deployment specific.


In your example, ':' is used as delimiter between server id and (I 
guess) resource id. I could also imagine to use another syntax, like 
::.


regards,
Torsten.


Am 15.07.2010 15:30, schrieb Eran Hammer-Lahav:

No. It is.

Let me ask you this: why can't you use 'photos:server1' and 
'photos:server2' as scopes?


EHL


On 7/14/10 10:49 PM, "Torsten Lodderstedt"  
wrote:


Did I get you right? Your answer is: Oauth is not suited for
deployments with different resource servers which rely in a single
authz server?

I don't know why you categorize this as  "complex". Is it so
unusual to have let's say mail, webstorage, telephony, and payment
services?

At Deutsche Telekom, we operate such a deployment (with much more
different resource servers) and I had hoped to move our token
service towards OAuth v2.

So would you recommend me zo stick to our proprietary protocol?

regards,
Torsten.



Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav
:

> If your deployment is that complicated, even my discovery
proposal is not going to help you...
>
> EHL
>
>
>
> On Jul 14, 2010, at 18:37, "Marius Scurtescu"
 wrote:
>
>> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
>>  wrote:
>>> I have a question concerning the OAuth philosophy: How many
resource servers
>>> may be managed by a single OAuth authorization server? (a) A
single resource
>>> server or (b) several of them exposing different resource types?
>>>
>>> If the answer is (b) then how is a particular resource server
identified in
>>> the protocol? Clients have Ids, end-users as well (at least in
a future
>>> protocol extension), but what about resource server Ids?
>>>
>>> I think resource servers must be identifiable in multi-server
deployments
>>> for several reasons:
>>> - Interpretation of the scope parameter should be resource
server specific -
>>> "read" may have different meanings in mail and address book
>>> - An authorization server probably wants to apply
server-specific security
>>> policy, e.g. different access token durations
>>> - It will be possible to create special tokens per server
>>>
>>> I think we should introduce a resource server id in the authz
and access
>>> token request.
>>>
>>> Any thoughts?
>>
>> I think the scope fills this role. Scopes implemented as URIs, for
>> example, allow the authz server to map them to resource servers.
>>
>> Marius
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Eran Hammer-Lahav]

No. It is.

Let me ask you this: why can't you use 'photos:server1' and 'photos:server2' as 
scopes?

EHL


On 7/14/10 10:49 PM, "Torsten Lodderstedt"  wrote:

Did I get you right? Your answer is: Oauth is not suited for deployments with 
different resource servers which rely in a single authz server?

I don't know why you categorize this as  "complex". Is it so unusual to have 
let's say mail, webstorage, telephony, and payment services?

At Deutsche Telekom, we operate such a deployment (with much more different 
resource servers) and I had hoped to move our token service towards OAuth v2.

So would you recommend me zo stick to our proprietary protocol?

regards,
Torsten.



Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav :

> If your deployment is that complicated, even my discovery proposal is not 
> going to help you...
>
> EHL
>
>
>
> On Jul 14, 2010, at 18:37, "Marius Scurtescu"  wrote:
>
>> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
>>  wrote:
>>> I have a question concerning the OAuth philosophy: How many resource servers
>>> may be managed by a single OAuth authorization server? (a) A single resource
>>> server or (b) several of them exposing different resource types?
>>>
>>> If the answer is (b) then how is a particular resource server identified in
>>> the protocol? Clients have Ids, end-users as well (at least in a future
>>> protocol extension), but what about resource server Ids?
>>>
>>> I think resource servers must be identifiable in multi-server deployments
>>> for several reasons:
>>> - Interpretation of the scope parameter should be resource server specific -
>>> "read" may have different meanings in mail and address book
>>> - An authorization server probably wants to apply server-specific security
>>> policy, e.g. different access token durations
>>> - It will be possible to create special tokens per server
>>>
>>> I think we should introduce a resource server id in the authz and access
>>> token request.
>>>
>>> Any thoughts?
>>
>> I think the scope fills this role. Scopes implemented as URIs, for
>> example, allow the authz server to map them to resource servers.
>>
>> Marius
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Torsten Lodderstedt]

Marius Scurtescu schrieb:

On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
 wrote:
  

I have a question concerning the OAuth philosophy: How many resource servers
may be managed by a single OAuth authorization server? (a) A single resource
server or (b) several of them exposing different resource types?

If the answer is (b) then how is a particular resource server identified in
the protocol? Clients have Ids, end-users as well (at least in a future
protocol extension), but what about resource server Ids?

I think resource servers must be identifiable in multi-server deployments
for several reasons:
- Interpretation of the scope parameter should be resource server specific -
"read" may have different meanings in mail and address book
- An authorization server probably wants to apply server-specific security
policy, e.g. different access token durations
- It will be possible to create special tokens per server

I think we should introduce a resource server id in the authz and access
token request.

Any thoughts?



I think the scope fills this role. Scopes implemented as URIs, for
example, allow the authz server to map them to resource servers.

Marius
  
That's an option indeed and would very much like to adopt it. But is the 
current draft specific enough to make that work?


Let's take the example of a valid scope Eran gave in on of his recent 
postings:


“friends:read:2d photos:write:1y”

Where would you include the resource server's URI? I assume in front of 
every value, like this:


“http://myserver.example.com/friends:read:2d 
http://myserver.example.com/photos:write:1y”


Let's now take this example one step further and extend the first 
resource description.


“http://myserver.example.com/friends/max.mustermann/:read:2d 
http://myserver.example.com/photos:write:1y”


How shall a standard compliant authz server parse that scope? And what 
is the resource server part? The host part only or everything up to the 
last '/'?
BTW: This example assumes ':' as internal delimiter between resources, 
permissions and durations.


In my opinion, in order to support the use case I described, we have to 
come up with a more detailed specification of the syntax and semantics 
of scopes.


What do you think?

regards,
Torsten.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[William Mills]

No hang on.  A single auth server should be able to handle man resource
servers.

It only gets hairy I think if you want multiple auth servers. 

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 
> On Behalf Of Torsten Lodderstedt
> Sent: Wednesday, July 14, 2010 10:50 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] resource server id needed?
> 
> Did I get you right? Your answer is: Oauth is not suited for 
> deployments with different resource servers which rely in a 
> single authz server?
> 
> I don't know why you categorize this as  "complex". Is it so 
> unusual to have let's say mail, webstorage, telephony, and 
> payment services?
> 
> At Deutsche Telekom, we operate such a deployment (with much 
> more different resource servers) and I had hoped to move our 
> token service towards OAuth v2. 
> 
> So would you recommend me zo stick to our proprietary protocol?
> 
> regards,
> Torsten.
> 
> 
> 
> Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav 
> :
> 
> > If your deployment is that complicated, even my discovery 
> proposal is not going to help you... 
> > 
> > EHL
> > 
> > 
> > 
> > On Jul 14, 2010, at 18:37, "Marius Scurtescu" 
>  wrote:
> > 
> >> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt 
> >>  wrote:
> >>> I have a question concerning the OAuth philosophy: How 
> many resource 
> >>> servers may be managed by a single OAuth authorization 
> server? (a) A 
> >>> single resource server or (b) several of them exposing 
> different resource types?
> >>> 
> >>> If the answer is (b) then how is a particular resource server 
> >>> identified in the protocol? Clients have Ids, end-users 
> as well (at 
> >>> least in a future protocol extension), but what about 
> resource server Ids?
> >>> 
> >>> I think resource servers must be identifiable in multi-server 
> >>> deployments for several reasons:
> >>> - Interpretation of the scope parameter should be resource server 
> >>> specific - "read" may have different meanings in mail and address 
> >>> book
> >>> - An authorization server probably wants to apply server-specific 
> >>> security policy, e.g. different access token durations
> >>> - It will be possible to create special tokens per server
> >>> 
> >>> I think we should introduce a resource server id in the authz and 
> >>> access token request.
> >>> 
> >>> Any thoughts?
> >> 
> >> I think the scope fills this role. Scopes implemented as URIs, for 
> >> example, allow the authz server to map them to resource servers.
> >> 
> >> Marius
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[William Mills]

I haven't seen the proposed discovery stuff yet, but discovery in the
SASL stuff will solve this, and so would discovery advertized from the
resource server. 

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 
> On Behalf Of Torsten Lodderstedt
> Sent: Wednesday, July 14, 2010 10:50 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] resource server id needed?
> 
> Did I get you right? Your answer is: Oauth is not suited for 
> deployments with different resource servers which rely in a 
> single authz server?
> 
> I don't know why you categorize this as  "complex". Is it so 
> unusual to have let's say mail, webstorage, telephony, and 
> payment services?
> 
> At Deutsche Telekom, we operate such a deployment (with much 
> more different resource servers) and I had hoped to move our 
> token service towards OAuth v2. 
> 
> So would you recommend me zo stick to our proprietary protocol?
> 
> regards,
> Torsten.
> 
> 
> 
> Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav 
> :
> 
> > If your deployment is that complicated, even my discovery 
> proposal is not going to help you... 
> > 
> > EHL
> > 
> > 
> > 
> > On Jul 14, 2010, at 18:37, "Marius Scurtescu" 
>  wrote:
> > 
> >> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt 
> >>  wrote:
> >>> I have a question concerning the OAuth philosophy: How 
> many resource 
> >>> servers may be managed by a single OAuth authorization 
> server? (a) A 
> >>> single resource server or (b) several of them exposing 
> different resource types?
> >>> 
> >>> If the answer is (b) then how is a particular resource server 
> >>> identified in the protocol? Clients have Ids, end-users 
> as well (at 
> >>> least in a future protocol extension), but what about 
> resource server Ids?
> >>> 
> >>> I think resource servers must be identifiable in multi-server 
> >>> deployments for several reasons:
> >>> - Interpretation of the scope parameter should be resource server 
> >>> specific - "read" may have different meanings in mail and address 
> >>> book
> >>> - An authorization server probably wants to apply server-specific 
> >>> security policy, e.g. different access token durations
> >>> - It will be possible to create special tokens per server
> >>> 
> >>> I think we should introduce a resource server id in the authz and 
> >>> access token request.
> >>> 
> >>> Any thoughts?
> >> 
> >> I think the scope fills this role. Scopes implemented as URIs, for 
> >> example, allow the authz server to map them to resource servers.
> >> 
> >> Marius
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Luke Shepard]

Yeah ... seems like OAuth is definitely suited for different resource services 
- as written, scope takes care of that. For instance Facebook offers messages, 
photos, and a bunch of other services, across two different APIs (the Graph and 
REST) and we distinguish permissions using scope.

As others have asked, why can't you just have a bunch of different scopes like 
read_mail, read_webstorage, read_phone, etc?


On Jul 14, 2010, at 10:54 PM, Ivan Pulleyn wrote:



On Wed, Jul 14, 2010 at 10:49 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
Did I get you right? Your answer is: Oauth is not suited for deployments with 
different resource servers which rely in a single authz server?

I don't know why you categorize this as  "complex". Is it so unusual to have 
let's say mail, webstorage, telephony, and payment services?

At Deutsche Telekom, we operate such a deployment (with much more different 
resource servers) and I had hoped to move our token service towards OAuth v2.

So would you recommend me zo stick to our proprietary protocol?


I'm confused why scope isn't sufficient for your needs.

Ivan...


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Ivan Pulleyn]

On Wed, Jul 14, 2010 at 10:49 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> Did I get you right? Your answer is: Oauth is not suited for deployments
> with different resource servers which rely in a single authz server?
>
> I don't know why you categorize this as  "complex". Is it so unusual to
> have let's say mail, webstorage, telephony, and payment services?
>
> At Deutsche Telekom, we operate such a deployment (with much more different
> resource servers) and I had hoped to move our token service towards OAuth
> v2.
>
> So would you recommend me zo stick to our proprietary protocol?
>
>
I'm confused why scope isn't sufficient for your needs.

Ivan...
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Torsten Lodderstedt]

Did I get you right? Your answer is: Oauth is not suited for deployments with 
different resource servers which rely in a single authz server?

I don't know why you categorize this as  "complex". Is it so unusual to have 
let's say mail, webstorage, telephony, and payment services?

At Deutsche Telekom, we operate such a deployment (with much more different 
resource servers) and I had hoped to move our token service towards OAuth v2. 

So would you recommend me zo stick to our proprietary protocol?

regards,
Torsten.



Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav :

> If your deployment is that complicated, even my discovery proposal is not 
> going to help you... 
> 
> EHL
> 
> 
> 
> On Jul 14, 2010, at 18:37, "Marius Scurtescu"  wrote:
> 
>> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
>>  wrote:
>>> I have a question concerning the OAuth philosophy: How many resource servers
>>> may be managed by a single OAuth authorization server? (a) A single resource
>>> server or (b) several of them exposing different resource types?
>>> 
>>> If the answer is (b) then how is a particular resource server identified in
>>> the protocol? Clients have Ids, end-users as well (at least in a future
>>> protocol extension), but what about resource server Ids?
>>> 
>>> I think resource servers must be identifiable in multi-server deployments
>>> for several reasons:
>>> - Interpretation of the scope parameter should be resource server specific -
>>> "read" may have different meanings in mail and address book
>>> - An authorization server probably wants to apply server-specific security
>>> policy, e.g. different access token durations
>>> - It will be possible to create special tokens per server
>>> 
>>> I think we should introduce a resource server id in the authz and access
>>> token request.
>>> 
>>> Any thoughts?
>> 
>> I think the scope fills this role. Scopes implemented as URIs, for
>> example, allow the authz server to map them to resource servers.
>> 
>> Marius
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Eran Hammer-Lahav]

If your deployment is that complicated, even my discovery proposal is not going 
to help you... 

EHL



On Jul 14, 2010, at 18:37, "Marius Scurtescu"  wrote:

> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
>  wrote:
>> I have a question concerning the OAuth philosophy: How many resource servers
>> may be managed by a single OAuth authorization server? (a) A single resource
>> server or (b) several of them exposing different resource types?
>> 
>> If the answer is (b) then how is a particular resource server identified in
>> the protocol? Clients have Ids, end-users as well (at least in a future
>> protocol extension), but what about resource server Ids?
>> 
>> I think resource servers must be identifiable in multi-server deployments
>> for several reasons:
>> - Interpretation of the scope parameter should be resource server specific -
>> "read" may have different meanings in mail and address book
>> - An authorization server probably wants to apply server-specific security
>> policy, e.g. different access token durations
>> - It will be possible to create special tokens per server
>> 
>> I think we should introduce a resource server id in the authz and access
>> token request.
>> 
>> Any thoughts?
> 
> I think the scope fills this role. Scopes implemented as URIs, for
> example, allow the authz server to map them to resource servers.
> 
> Marius
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] resource server id needed?

[Marius Scurtescu]

On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
 wrote:
> I have a question concerning the OAuth philosophy: How many resource servers
> may be managed by a single OAuth authorization server? (a) A single resource
> server or (b) several of them exposing different resource types?
>
> If the answer is (b) then how is a particular resource server identified in
> the protocol? Clients have Ids, end-users as well (at least in a future
> protocol extension), but what about resource server Ids?
>
> I think resource servers must be identifiable in multi-server deployments
> for several reasons:
> - Interpretation of the scope parameter should be resource server specific -
> "read" may have different meanings in mail and address book
> - An authorization server probably wants to apply server-specific security
> policy, e.g. different access token durations
> - It will be possible to create special tokens per server
>
> I think we should introduce a resource server id in the authz and access
> token request.
>
> Any thoughts?

I think the scope fills this role. Scopes implemented as URIs, for
example, allow the authz server to map them to resource servers.

Marius
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] resource server id needed?

[Torsten Lodderstedt]

I have a question concerning the OAuth philosophy: How many resource 
servers may be managed by a single OAuth authorization server? (a) A 
single resource server or (b) several of them exposing different 
resource types?


If the answer is (b) then how is a particular resource server identified 
in the protocol? Clients have Ids, end-users as well (at least in a 
future protocol extension), but what about resource server Ids?


I think resource servers must be identifiable in multi-server 
deployments for several reasons:
- Interpretation of the scope parameter should be resource server 
specific - "read" may have different meanings in mail and address book
- An authorization server probably wants to apply server-specific 
security policy, e.g. different access token durations

- It will be possible to create special tokens per server

I think we should introduce a resource server id in the authz and access 
token request.


Any thoughts?

regards,
Torsten.


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth