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

Eve Maler eve at xmlgrrl.com
Mon Sep 7 12:59:49 PDT 2009


I'm going to respond to both Christian's latest and Joe's latest here.

I do think we're being forced into a term for "entity #5" (oh, how  
that old numbering scheme seems mocked and belittled by Joe's latest  
effort! :-).  It should account for whatever kind of entity can be a  
party to a contract, so Christian's question of "multiple" is probably  
moot unless someone comes up with a scenario that involves a single  
act of authorization to multiple entities that aren't already bound  
together in a corporation or government agency or something like  
that.  (For the moment, I'm going to hand-wave about the truly  
"social" scenarios brought up by George Fletcher, where you want to  
authorize a whole ACL's-worth of people to get some data of yours;  
hopefully we can externalize that complexity to a PoCo service or  
similar.)

Accounting for user agents (in the IETF sense) should be a second- 
order concern, I'm guessing; human beings must interact with networked  
protocols through user agents, so if we were to see "User" appear in a  
protocol diagram it probably stands for "User interacting by means of  
a UA".  But it's good to realize that the substitution is being made,  
and be more explicit wherever clarity demands it.

More comments below.

On 7 Sep 2009, at 11:38 AM, Joe Andrieu wrote:

> The identity of the Requesting Service is relevant, but if they are  
> not the endpoint of the authorization, then things get complicated.
>
> With OAUTH, the presumption is that there is live interaction with  
> the controlling human (of both resources) at the time of  
> provisioning. In the simplest case, that translates into http  
> redirects to log in to service B while authorizing access to service  
> B for service A.  In this case, I am both the Requesting User and  
> the Authorizing User.
>
> However, that is actually a special case of authorizing another user  
> on service B.
>
> I am most definitely /not/ providing blanket authorization for  
> Service A to do whatever it wants with my content.
>
> To be more concrete, if Service A is Ping.fm and Service B is  
> Twitter. When I use OAUTH to provision my Ping account with access  
> to Twitter, I'm not giving Ping unlimited access to my twitter  
> account for use by any of their users. I'm giving them the right to  
> post as directed by the /user logged in at Ping at the time OAUTH is  
> invoked/.
>
> The presumption in the usage pattern is that /I/ am that user.
>
> I think with UMA we are, in part, wrestling with the question "what  
> if that user is /not/ me?"

This is an extremely cogent way of putting it!

Christian, note that this doesn't invalidate your "multi- 
authorizations for one person" scenario, but you may want to decide  
whether you are exploring a true edge case, or a scenario that can/ 
should be broadened to include "others besides me".

> I don't want to dive into the details of solving that... because  
> that's the work ahead of us, but I think the terminology we are  
> settling into needs to work for this case.
>
> This is especially true if the legal entity of the Requesting  
> Service wants to pass liability on to the Requesting User (as, I  
> believe, most will want to do).
>
> Hence, a distinction between the "Requesting Service" and a  
> "Requesting User" make sense to me. Also, I think the "user agent"  
> and "authentication service" are reasonable terms for acknowledging  
> the interaction between users and their services.
>
> I think however, I just added the distinction between the  
> Authorizing User and the Requesting User.

Yep.  And I was starting to grope towards Access Controller and Access  
Seeker in my other recent posts...  Given that we're trying to start  
with a human on the near end and a non-human on the far end, I'm a  
little worried about "User" appearing in both, but maybe it will fly.   
More on that below.

> So, here's a new stack (using letters), intentionally ignoring the  
> Authentication Services.
>
> A. Authorizing User
> B. Authorizing User Agent
> C. AU Authentication Service
> D. Authorization Manager
> E. AM Authentication Service
> F. Host
> G. RS Authentication Service
> H. Requesting Service
> I. RU Authentication Service
> J. Requesting User Agent
> K. Requesting User
>
> The presumption in this remains that the AM, Host, and Requesting  
> Service are all automated systems (they are their own agents with  
> intermediary user agents and hence act on their own credentialed  
> authority).

I'm not quite sure I understand this explanation.  I would say the AM,  
Host, and Requesting Service are "agents" of somebody, and they have  
been instructed how to behave by that somebody.  The first two always  
share the same somebody in our conception, and the last one might have  
the same or a different somebody.

> Or without all the Authentication Services:
> A. Authorizing User
> B. Authorizing User Agent
> D. Authorization Manager
> F. Host
> H. Requesting Service
> J. Requesting User Agent
> K. Requesting User

Much preferred, since my hope is can successfully late-bind identities  
(and their authentication) so that we can avoid caring about whether a  
particular identifier ever "crosses agent lines".  There's an  
"authentication model" document I wrote a long time back for  
ProtectServe that would probably find use for mentioning the authn  
services, though...

>
> Or even more svelte, without the user agents:
> A. Authorizing User
> D. Authorization Manager
> F. Host
> H. Requesting Service
> K. Requesting User
>
>
> How's that look for terminology?
>
> -j

I like it a lot!  I do have that hesitation about "User", and could  
see us doing the following, as appropriate:

Legal view (when discussing how terms are offered and met/accepted):

Authorizing Party
Authorization Manager (some days I still like "Agent" here...)
Host
Requesting Service
Requesting Party

Message flow view (when discussing protocol, UX, security  
considerations, etc.):

Authorizing User, or User for short -- and mention User Agent as  
required
Authorization Manager
Host
Requesting Service
Requesting Person (plus User Agent) or Requesting Organization (?),  
depending on the scenario

	Eve

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



More information about the Wg-uma mailing list