[Wg-uma] Terminology and identity (!) progress

Joe Andrieu joe at switchbook.com
Mon Sep 7 11:38:42 PDT 2009


The identity of the Requesting Service is relevant, but if they are not 
the endpoint of the authorization, then things get complicated.

With OAUTH, the presumption is that there is live interaction with the 
controlling human (of both resources) at the time of provisioning. In 
the simplest case, that translates into http redirects to log in to 
service B while authorizing access to service B for service A.  In this 
case, I am both the Requesting User and the Authorizing User.

However, that is actually a special case of authorizing another user on 
service B.

I am most definitely /not/ providing blanket authorization for Service A 
to do whatever it wants with my content.

To be more concrete, if Service A is Ping.fm and Service B is Twitter. 
When I use OAUTH to provision my Ping account with access to Twitter, 
I'm not giving Ping unlimited access to my twitter account for use by 
any of their users. I'm giving them the right to post as directed by the 
/user logged in at Ping at the time OAUTH is invoked/.

The presumption in the usage pattern is that /I/ am that user.

I think with UMA we are, in part, wrestling with the question "what if 
that user is /not/ me?"

I don't want to dive into the details of solving that... because that's 
the work ahead of us, but I think the terminology we are settling into 
needs to work for this case.

This is especially true if the legal entity of the Requesting Service 
wants to pass liability on to the Requesting User (as, I believe, most 
will want to do).

Hence, a distinction between the "Requesting Service" and a "Requesting 
User" make sense to me. Also, I think the "user agent" and 
"authentication service" are reasonable terms for acknowledging the 
interaction between users and their services.

I think however, I just added the distinction between the Authorizing 
User and the Requesting User.

So, here's a new stack (using letters), intentionally ignoring the 
Authentication Services.

A. Authorizing User
B. Authorizing User Agent
C. AU Authentication Service
D. Authorization Manager
E. AM Authentication Service
F. Host
G. RS Authentication Service
H. Requesting Service
I. RU Authentication Service
J. Requesting User Agent
K. Requesting User

The presumption in this remains that the AM, Host, and Requesting 
Service are all automated systems (they are their own agents with 
intermediary user agents and hence act on their own credentialed authority).

Or without all the Authentication Services:
A. Authorizing User
B. Authorizing User Agent
D. Authorization Manager
F. Host
H. Requesting Service
J. Requesting User Agent
K. Requesting User

Or even more svelte, without the user agents:
A. Authorizing User
D. Authorization Manager
F. Host
H. Requesting Service
K. Requesting User


How's that look for terminology?

-j

On 9/7/2009 9:53 AM, Christian Scholz wrote:
>
> Am 07.09.2009 um 18:48 schrieb Eve Maler:
>
>> I'd say that our primary use cases have the identity behind the
>> Requester *not* being the same as the identity (the User) behind the
>> AM and host. When I tell my dentist's office it's okay to see my
>> calendar, yes, they are "acting on my behalf" in the sense that they
>> provide dental services, but I'm treating them as a separate party
>> that *may* be worthy of receiving some of my precious personal-data
>> assets and am trying to establish that they will treat the assets with
>> care. If the other side is just "me again", it's quite a bit less
>> interesting to set up all the infrastructure for terms etc. (The
>> photoset->location scenario, which so far is conceptually closest to
>> OAuth among all our scenarios, is thus an "edge case".)
>
> But isn't the other side already defined in "Requester"? I mean does it
> matter which users are behind that? Isn't the TOS of the Requester what
> counts here?
>
>
> -- Christian
>
>
>>
>> This is where Iain's propeller/flower diagram may come in handy to
>> explain that we shouldn't have a solipsistic view of the personal-data
>> universe. :-)
>>
>> http://kantarainitiative.org/wordpress/2009/06/iain-henderson-the-personal-data-eco-system/
>>
>>
>> I do want to think about this more deeply in general, because, indeed,
>> the calendar wireframes show *me* logging in on the calendar-recipient
>> side in order to provision them with the resource URI. However, the
>> Access-Seeker (what do you think of that name for entity #5?) behind
>> the Requester isn't me -- it's the legal entity that owns/runs the
>> Requester.
>>
>> Eve
>>
>> On 7 Sep 2009, at 9:28 AM, Christian Scholz wrote:
>>
>>> HI!
>>>
>>>> In the last call, we had some fascinating discussion about
>>>> terminology that is dovetailing nicely with the (also fascinating)
>>>> discussion we had about entity #5 -- the natural or legal person
>>>> "behind" the requesting side.
>>>>
>>>> First, a summary of the terms we chose:
>>>>
>>>> User - Authz Manager (AM) - Host - Requester - (entity #5)
>>>>
>>>> Offline, I've been discussing with Christian some of the subtleties
>>>> of who knows what about whom, and how we can maybe get closer to
>>>> using OAuth directly. This resulted in our using a new kind of
>>>> convention that I suspect will be very helpful going forward. I hope
>>>> Christian will jump into this thread with his take!
>>>
>>> I think it also was kinda online ;-)
>>>
>>>> The convention is to "index" the entity with some unique local
>>>> identity that it knows about: entity(id). When I say "identity", I
>>>> don't mean that we are relying on any understanding of that identity
>>>> on the part of any other entity! It's entirely local.
>>>
>>> I tried to do some diagram but I am not sure if it captures your
>>> thoughts:
>>>
>>> http://www.flickr.com/photos/mrtopf/3897034944/
>>>
>>> Basically I think what we were discussing have been the people using it.
>>>
>>> E.g. lets take a normal OAuth redirect interaction started by a
>>> Consumer in order to retrieve an Access Token from the Service
>>> Provider (in "old" OAuth terms).
>>> This usually is triggered by the user who clicks e.g. "Connect with
>>> Twitter". This also means that the user is probably logged in at the
>>> Consumer so the Consumer can store the access token for the user
>>> along with all the other user related data. In order for the Service
>>> Provider (twitter in this case) to send a token it also needs to know
>>> which user asks for it. So the user also needs to be logged in at the
>>> Service Provider. Let's call this user Bob.
>>>
>>> Of course we usually assume that the user on both sides is the same.
>>> The question now is if this is relevant for the protocol. According
>>> to this scenario:
>>>
>>>> - AM and Host may have never met before, but each is
>>>> ProtectServe-enabled
>>>> - User Alice introduces Host(Alice) to AM(Alice) through an
>>>> OAuth-based approval interaction
>>>> - Thereafter, Consumer(Bob) attempts access to a resource controlled
>>>> by Host(Alice)
>>>> - Host(Alice) asks AM(Alice) for a ruling on whether to allow access
>>>> by Consumer(Bob)
>>>> - The terms offered by AM(Alice) are demonstrated to have been met
>>>> by Consumer(Bob)
>>>> - Thus, Alice and Bob now have a contract between them
>>>> - etc.
>>>
>>> it seems to be. But I would like to see this flow with a real world
>>> example where it impacts the protocol.
>>>
>>> I would think of the calendar example where a newspaper wants to know
>>> if some subscriber is on vacation so no newspaper is delivered. Here
>>> we have Eve being a calendar user and a subscriber to the newspaper.
>>> But in this case I would assume that Eve logs in to the newspaper
>>> (consumer) and the calendar (SP) via an AM and tells the SP which
>>> data is allowed to be given out to the newspaper service (only the
>>> dates she is not in town, no details). This would also be possible to
>>> define without any AM in the middle if the SP actually would ask some
>>> details about what to give out for this particular access token (AM
>>> makes it easier to manage though).
>>>
>>> But what I don't have here is a third user. One could say that some
>>> employee at the newspaper is that third user but maybe it's automated
>>> anyway and even if so it doesn't matter for the protocol. Some legal
>>> entity might of course now have some contract with Eve not to deliver
>>> the newspaper at certain times but this is still outside the protocol
>>> I think.
>>>
>>> (third user because 1 and 2 is both Eve).
>>>
>>>>
>>>> This helps us ask questions like: How do we protect AM(Alice) and
>>>> AM(Carol) from problematic interactions? How does Alice know it's
>>>> Bob ultimately doing the asking? In what sense do Alice and Bob
>>>> really have an enforceable contract? (Our early ProtectServe work
>>>> did confront and try to answer *some* of these questions and we
>>>> think we have useful answers, but our answers might very well be
>>>> wrong.)
>>>
>>> So in the case above Alice==Eve and the newspaper is Bob. We know it
>>> by the access token the newspaper service has now.
>>>
>>>> And notice that, without having a name for entity #5 as a general
>>>> category yet, we now have Bob as an instance of that category.
>>>> (Really, we've said that our instances of entity #5 should be
>>>> "services" and not "people", so we could talk about BobCo if we want).
>>>
>>> I think usually both users are the same and if they aren't I wonder
>>> if we need to know this. Some user might do something on behalf of
>>> another (e.g. I could do something on behalf of my company like using
>>> it's twitter account) but this is probably outside the scope.
>>>
>>> So what I basically want to say is that I am not sure we need more
>>> terms or syntax because we already have quite a bit. I would only
>>> introduce this if during the work on the protocol it's really needed.
>>>
>>> OTOH it might be that I have understood something completely wrong ;-)
>>>
>>> -- Christian
>>>
>>>
>>> --
>>> Christian Scholz Homepage: http://comlounge.net
>>> COM.lounge GmbH blog: http://mrtopf.de/blog
>>> Hanbrucher Str. 33 Skype: HerrTopf
>>> 52064 Aachen Video Blog: http://comlounge.tv
>>> Tel: +49 241 400 730 0 E-Mail cs at comlounge.net
>>> Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T
>>>
>>> neuer Podcast: Der OpenWeb-Podcast (http://openwebpodcast.de)
>>> new podcast: Data Without Borders (http://datawithoutborders.net)
>>
>>
>> Eve Maler
>> eve at xmlgrrl.com
>> http://www.xmlgrrl.com/blog
>>
>
> --
> Christian Scholz Homepage: http://comlounge.net
> COM.lounge GmbH blog: http://mrtopf.de/blog
> Hanbrucher Str. 33 Skype: HerrTopf
> 52064 Aachen Video Blog: http://comlounge.tv
> Tel: +49 241 400 730 0 E-Mail cs at comlounge.net
> Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T
>
> neuer Podcast: Der OpenWeb-Podcast (http://openwebpodcast.de)
> new podcast: Data Without Borders (http://datawithoutborders.net)
>
>
>
>
>
>
> _______________________________________________
> Wg-uma mailing list
> Wg-uma at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma_kantarainitiative.org
>
>

-- 
Joe Andrieu
joe at switchbook.com
+1 (805) 705-8651
http://www.switchbook.com



More information about the Wg-uma mailing list