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

Eve Maler eve at xmlgrrl.com
Mon Sep 7 09:48:41 PDT 2009


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".)

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




More information about the Wg-uma mailing list