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

Joe Andrieu joe at switchbook.com
Mon Sep 7 15:24:25 PDT 2009

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 

 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.


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

More information about the Wg-uma mailing list