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

Christian Scholz cs at comlounge.net
Mon Sep 7 09:53:56 PDT 2009


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)








More information about the Wg-uma mailing list