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

Christian Scholz cs at comlounge.net
Mon Sep 7 11:51:20 PDT 2009

Eve Maler schrieb:
> 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.

Sure, this might be the case at some point but I'd like to keep 
terminology out of the specification we do not need for the first 
version. I also think that maybe such terms might be better put into an 
additional spec which extends the base spec as this is mostly policy 
based terminology anyway. The more terms we add the more complicated to 
understand it will become.

Another question: If there is only one legal entity behind the Requester 
and not multiple, do we need a term for that or can we group them 
together under one term? I think we need User because it in fact is 
important which User is owning a resource so that no User B is accessing 
a resource of User A. For everything else I'd like to see some examples 
first which make it necessary to have further terms.

-- Christian

>     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