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

Eve Maler eve at xmlgrrl.com
Mon Sep 7 11:19:39 PDT 2009


Yes, but: since a "Requester" is a protocol endpoint/API and can't, in  
a sense, meet or agree to terms except on behalf of some legally  
recognized entity, our notion of "enforceable agreements" gets tangled  
up IRL...  Maybe correlating an agreement with a Requester handle will  
end up being sufficient for V1. But I suspect that the larger problem,  
including an eventual general-purpose peer-to-peer data-sharing  
platform (anyone as the Access Offerer and anyone as the Access  
Seeker), will need a generalized solution.

	Eve

On 7 Sep 2009, at 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)
>
>
>
>
>


Eve Maler
eve at xmlgrrl.com
http://www.xmlgrrl.com/blog




More information about the Wg-uma mailing list