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

Iain Henderson iain.henderson at mydex.org
Mon Sep 7 15:28:58 PDT 2009

yes, very helpful for me thanks.

On 7 Sep 2009, at 23:24, Joe Andrieu wrote:

> This is looking better.
> I'll summize rather than do point by point (please give me feedback  
> about whether or not this helps get through the thread).
> 1. I agree that "user agent" is normally implied, but it is  
> important terminology, well accepted by IETF and others.
> 2. Also, I think the authentication services are well address by  
> other standards, as long as our terminology allows for them, and we  
> can still paint the rigorous detailed map of the different parts of  
> the puzzle.
> 3. The reason I distinguish that the AM, Host, and Requesting  
> Service are automated was to avoid another round of User Agents.  A  
> website that commits to a sales contract isn't acting as a user  
> agent. But if that same website brought in a live customer support  
> rep, we would need to account for /that/ human differently than if  
> it were just the service. I think this distinction is vital. There  
> are different levels of authorization: (1) what the service can  
> automatically do with the data all by itself based on my belief that  
> it is under the control of its presumed owner, e.g., execute a  
> credit card payment, and (2) what (a) particular user(s) of that  
> service can do, e.g., edit my photograph.
> For a brief moment, I liked "party" and wanted to unify the legal &  
> message flow language, that didn't quite work for me.
> > Authorizing User
> > Authorization Manager (some days I still like "Agent" here...)
> > Host
> > Requesting Service
> > Requesting Party
> Unfortunately, this implies that a "corporation" can be an RP, which  
> I think fails the test that the authorization is to the specific  
> actor. That is, to one of two types of entities:
> 1. An automated service, whose legal responsibility lies with its  
> lawful controllers (not necessarily owners in the case of hosted  
> servers)
> 2. A person, who may or may not be acting on behalf of a different  
> legal entity.
> From an auditing perspective, we don't want a human being to log in  
> as a "corporation" without that corporate entity validating that the  
> human is an appropriate representative (via authentication).
> Auditers will want to record that "John Smith" (or user #234526),  
> authenticated by IBM Systems IDP (at URI XYZ) accessed such and such  
> resource on the Host SwitchBook on June 23, 2009, as per  
> Authorization granted by User #26544 on May 15, 2009 to IBM Systems  
> via AM MyDex.
> Even if a corporation is taking legal responsibility, we need to be  
> able to assure that the whoever is accessing the host is, in fact,  
> authorized to do so.  That means it is either an authorized service  
> (using some machine-based credential) or an authorized individual  
> (perhaps delegated authority by said corporation).
> I'm not sure where this leaves us, but it does seem that we need to  
> be able to resolve assertions about IBM's access to data, whether by  
> a human agent or an automated one.  That implies either an IBM- 
> authenticated individual or by an IBM-authenticated machine.  And  
> unless I'm missing something, there is no way that a corporation can  
> act in any other way. Contracts online presume the machine hosting  
> the contract is a credentialled representative. Offline contracts  
> need an authorized representative to sign the dotted line.
> -j
> On 9/7/2009 12:59 PM, Eve Maler wrote:
>> 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
> -- 
> Joe Andrieu
> joe at switchbook.com
> +1 (805) 705-8651
> http://www.switchbook.com
> _______________________________________________
> Wg-uma mailing list
> Wg-uma at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma_kantarainitiative.org

Iain Henderson
iain.henderson at mydex.org

This email and any attachment contains information which is private  
and confidential and is intended for the addressee only. If you are  
not an addressee, you are not authorised to read, copy or use the e- 
mail or any attachment. If you have received this e-mail in error,  
please notify the sender by return e-mail and then destroy it.

More information about the Wg-uma mailing list