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

Joe Andrieu joe at switchbook.com
Fri Sep 4 15:28:14 PDT 2009


Eve,

Fascination discussions around the "natural" person on the other end of 
the request is now in the terminology. It introduces a parallel we've 
ignored that at the front end.  For the sake of discussion, what if we 
add it? [With apologies in advance for the damage done to the number 
system in hopes of maintaining backward compatibility...]

1. User
1.5 User Agent
2. Authorization Manager
3. Host
4. Request Agent
5. Requester

However we could argue that #4 is not necessarily interactively under 
the requester's control but that instead that the Requester used their 
own user agent at a service to request the data, i.e., the other person 
used a browser to access the request agent website.

So, introducing a "natural person" at both ends is symmetric, but 
doesn't quite fit (because where is the user agent for that natural person?)

How about
1. User
1.5 User Agent
2. Authorization Manager
3. Host
4. Requesting Service
4.5 Requesting User Agent
5. Requesting Entity

I think we want to be especially clear about this distinction, 
including, at a minimum, hand-wavy definitions (by reference might be 
fine) of how the User Agents authenticate on behalf of their respective 
entitities.

1. User
1.5 User Agent
1.75 User Authentication Service
2. Authorization Manager
3. Host
4. Requesting Service
4.25 Requesting Authentication Service
4.5 Requesting User Agent
5 Requesting Entity


And most of the time, we skip the "user agent & authentication components"
1. User
2. Authorization Manager
3. Host
4. Requesting Service
5. Requesting Entity

However, skipping the authorization elements presumes that the AM and 
the RS are trusted to actually perform that role appropriately. While I 
was relatively comfortable with that assumption for the AM--after all, 
_of course_ I have some sort of account and login there--I am less 
sanguine about skipping that requirement for the RS. Because how do I 
know that my real friend Sally is the same Sally that is presented as 
the RE by the RS?

Hopefully, this makes sense. The additional layers are complicated, but 
I think this is the essential question behind adding person #5: namely 
who am I really giving access to this data? Whether or not UMA solves 
these issues, our terminology should allow us to meaningfully talk about it.

And, if I really want to be pedantic, here's the layering when the 
Requesting Entity has delegated authority to another, for example when 
IBM delegates to Bob Smith for a accessing my personal datastore during 
a customer service interaction.

1. User
1.5 User Agent
1.75 User Authentication Service
2. Authorization Manager
3. Host
4. Requesting Service
4.25 Requesting Authentication Service
4.5 Requesting User Agent
5 Requesting Entity
6 Delegation Authentication Service
7. Delegated User Agent
8. Delegated User

Or, with examples
1. User (Joe)
1.5 User Agent (Firefox)
1.75 User Authentication Service (1id.net)
2. Authorization Manager (ProtectServe-based service in the cloud)
3. Host (Personal Datastore)
4. Requesting Service (IBM's CRM system)
4.25 Requesting Authentication Service (IBM's outgoing IDP)
4.5 Requesting User Agent (via proxy? or more likely the same as the 
delegated user agent)
5 Requesting Entity (IBM)
6 Delegation Authentication Service (IBM's internal IDP)
7. Delegated User Agent (Chrome)
8. Delegated User (Bob)

Ugh!

Because, of course, IBM can be the legal entity requesting the data, but 
IBM, in this case, acts through a "natural" person.

-j

p.s.
Apologies for missing the meeting. I should be able to make the next one.

On 9/4/2009 8:46 AM, Eve Maler 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!
>
> 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.
>
> For example, I can explain the existing ProtectServe sketch by observing
> that:
>
> - 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.
>
> 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.)
>
> 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 have some really old ProtectServe-related diagrams that reflected all
> of this -- I could revise to show the new terms, if anyone is
> interested... Let me know.)
>
> Eve
>
> Eve Maler
> eve at xmlgrrl.com
> http://www.xmlgrrl.com/blog
>
> _______________________________________________
> Wg-uma mailing list
> Wg-uma at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma_kantarainitiative.org
>
>

-- 
Joe Andrieu
joe at switchbook.com
+1 (805) 705-8651
http://www.switchbook.com



More information about the Wg-uma mailing list