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

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


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

More information about the Wg-uma mailing list