[Wg-uma] Terminology and identity (!) progress
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
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
On 7 Sep 2009, at 9:28 AM, Christian Scholz wrote:
>> 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
> Basically I think what we were discussing have been the people using
> 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-
>> - 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
> 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
> 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
> 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:
> 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,
> neuer Podcast: Der OpenWeb-Podcast (http://openwebpodcast.de)
> new podcast: Data Without Borders (http://datawithoutborders.net)
eve at xmlgrrl.com
More information about the Wg-uma