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
<resource server>:<resource>:<permissions>.
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" <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?
regards,
Torsten.
Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav
<e...@hueniverse.com>:
> 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"
<mscurte...@google.com> wrote:
>
>> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
>> <tors...@lodderstedt.net> 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
