[WG-UMA] Lexicon discussions

Eve Maler eve at xmlgrrl.com
Thu Feb 4 10:49:46 EST 2010


George-- Great stuff!  A few thoughts from me below, before we dig into this on the call today...  By the way, Paul and I met with Tom Smedinghoff, who's heavily involved with the American Bar Association Federated Identity Management Legal Task Force and who contributes to the Kantara ID Assurance group, to check some of our assumptions and draft terminology around the requester universe. I'll share a bit of that below, and more on the call.

On 2 Feb 2010, at 9:02 AM, George Fletcher wrote:

> First a quick clarification. I would have thought that for #5, it would be "A web user on whose behalf a #2 is acting in seeking access to a protected resource".  Note #2 instead of #3.

Good question.  Perhaps it depends on whether we mean "seeking" in a legal or technical sense, but in that case, the terminology section already has a technical bias (as it should, being a technical spec) so it should probably be #2.

In talking with Tom, I hit on the idea that we might want to produce a separate document -- perhaps a non-normative paper, or maybe even a "normative non-technical doc" of some kind? -- that provides a parallel legal view of things, including deeper legal terminology. So perhaps this is where a "shadow definition" that says #3 instead of #2 might come in.

> 
> Second, I don't see any actors for the protected resource side of things? For instance, what number is Alice, or Alice's calendar service. And if Alice delegated her "authorization management" rights to her mom "Betty", where does that fall in?

Yeah, it became clear in our convo with Tom that we need just as much sophistication -- whatever level that is -- to describe the authorizing side as the requesting side. So we could account for, at a minimum:

- an authorizing user (Alice)
- an authorizing entity to which the AU has delegated some powers (CopMonkey LLC)
- an authorizing application (the CopMonkey app)
- an authorizing endpoint (copmonkey.com/whatever)

...and in the custodian case, maybe that first one splits off into:

- an authorizing entity (little Carol's mom, or big Alice's employer)
- a user of a host's services (little Carol or big Alice)

Once we conceive of a role of a host-user role that Alice can don, along with the authorizing user role, then we can split it up more naturally, and also talk with more precision about Alice's interactions with the host in doing the initial host-AM introduction.

> 
> Is Alice's calendar service a #2 because it is a web app that can speak UMA protocols and talk to the AM and clients?
> 
> Is the organization that deploys Alice's calendar service #3?
> 
> Is Alice #5 in respect to her calendar service? What about in her role with AM?

Hmm, I just realized I listed the "authorizing" side in the reverse order to the "requesting" side, because I keep picturing it as an access bridge that's approached in the middle by the two sides. But accounting for that, and assuming we can flesh out the host-related roles, this sounds right.

> 
> If we're talking about user-generated content as the resource being accessed/protected. Who is the "legal" owner of that content and how does that relate to #3?

According to our convo with Tom, the agreements a user may have with a chosen host, requester, or AM, are second-order compared to the primary one being forged in the UMA process.  If I understand correctly (I hope he'll correct me if I'm wrong!), and if we use the example of Alice authorizing Bob to subscribe to her calendar, it only makes sense for that primary agreement to be forged by the ultimate authorizer and requesting user: Alice and Bob. If we use the example of Alice authorizing some company (a requesting entity that happens to be a legal person) to get her info for some purpose, then it's an Alice-company agreement.

> 
> Finally, is Bob a #3 when proving himself to Alice's AM so that he can be a #5 when accessing the service?

I think he's still a #5 the whole time. ??

> 
> Sorry, for all the questions. I threw a diagram together for your Google use case. Don't know if helps any. I labeled the actors according to your description. It seems like we still have a number of actor's unlabeled. 

The questions are great, and the diagram description looks on the right track to me. Maybe we need to make a series of these diagrams, one that "ends in" Bob, one that "ends in" a legal person, and another one that has a requesting entity representative in it, and one that splits the authorizing user and user of a host...then try to label all the roles.

	Eve

> 
> Thanks,
> George
> 
> On 1/10/10 12:34 PM, Eve Maler wrote:
>> 
>> Thanks to Nat for this thought!  I think we'd better try and reserve a bit of time in next week's call for this, though I'd rather hash out as much of it in email ahead of time as possible.  (So, anyone who cares about terms and concepts, please read and comment further. :-)
>> 
>> What if I try and propose some definitions here, sans names for them, and see if we're in agreement on the concepts first?  I'm working from the entire set of existing definitions in our current spec to come up with these:
>> 
>> http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol#UMA1.0CoreProtocol-Terminology
>> 
>> #1: An HTTP client (per [HTTP]) capable of interacting with hosts and AMs to request, and receive access to, protected resources.
>> 
>> #2: A web application that manifests a #1.
>> 
>> #3: A legal person (for example, an organization or natural person) that has deployed a #2 in order to seek access to a protected resource.
>> 
>> #4: A web user acting as a representative of a #3, capable of assisting an AM's process of determining the suitability of that #3 for access.
>> 
>> #5: A web user on whose behalf a #3 is acting in seeking access to a protected resources.
>> 
>> These are sort of bloodless without real terms, and I think the spec would benefit if it had a few examples (not in the Terminology section but nearby) of the sort Joe has provided.
>> 
>> Nevertheless, this exercise has helped me quite a lot.  It enables me to say, for example, that a very clever person may have deployed their *own* application on the web for seeking access to others' data, and in that #3 role they're not, strictly speaking, a "web user" but just an entity capable of entering into contracts.  If that same person is in a position to click "I agree" or type some self-asserted claims into a field or something, they're acting as a #4.  And if that person later does something with their successfully acquired data/service access, they're in the #5 role.
>> 
>> Another example: If Google Calendar is asking for "subscribe" (GET) access to Alice's calendar resource on behalf of Bob, Google's protocol endpoint for seeking access is #1, Google's calendar application is #2, Google the company is #3, Bob is #5, and there is no #4 (if the granting of access is handled entirely untouched by human hands on the requesting side)...
>> 
>> Thoughts?
>> 
>>         Eve
>> 
>> On 29 Dec 2009, at 6:41 PM, Nat Sakimura wrote:
>> 
>> > It might be worthwhile to introduce the notion of signatory.
>> > We use that in Contract Exchange.
>> > e.g., requesting entity's representative would then be the signatory of
>> > the requesting entity.
>> >
>> > FYI, in CX, we have these actors:
>> >
>> > 1. Proposer (requestor)
>> > 2. Signatory of the Proposer
>> > 3. Acceptor
>> > 4. Signatory of the Acceptor
>> >
>> > Best,
>> >
>> > =nat
>> >
>> > (2009/12/29 5:11), Eve Maler wrote:
>> >> Thanks, Joe!  Very helpful, and it gets at something I've been having trouble with lately.
>> >>
>> >> To date I've been using "requester" for Joe's #1 sense ("requesting [HTTP] client"), but I've sometimes slipped into using it for the #2 sense (e.g., when I feel it necessary to say "requester app" -- you'll find that phrase in a few places in scenarios).  I've tried to use "requesting party" in what turns out to be a fairly ill-defined mix of his #2, #3, and #5 senses, with "requesting user" as a substitute when there is actually a #5 in the picture (sometimes there really isn't, as, e.g., when you sell your demographic data to a survey company for its own use).  This is why I asked Domenico to show a few different options for who is "behind" the requester (in the HTTP client sense): the same person as the authorizing user vs. a different person vs. a company or other organization.
>> >>
>> >> Now I understand why this isn't quite right.  I was beginning to realize that if the authorizing user (through their AM) is negotiating access terms with ***somebody***, it's not strictly accurate to say that the three choices listed above are options for that somebody.  Rather, the contract is always with #3, the requesting entity, where there may have to be a clause naming any specific requesting user (#5) on whose behalf the access is wanted, if there is one.
>> >>
>> >> The notion of the requesting entity's representative (#4) is especially useful for considering usability issues around having an employee consent in real time to the terms, if that's what the requesting entity expects.  (However, we've pretty much stayed out of imagining any protocol implications here, so far.)
>> >>
>> >> We can optimize names once we get agreement around the concepts, methinks.
>> >>
>> >> Thoughts?  (Note that this message is cross-posted; if you have not signed a GPA for a group, you won't be able to post to that group!)
>> >>
>> >>      Eve
>> >>
>> >> On 28 Dec 2009, at 10:37 AM, Joe Andrieu wrote:
>> >>
>> >>
>> >>> Howdy.
>> >>>
>> >>> In today's Information Sharing work group call, we spent the better part
>> >>> of the hour synchronizing a shared lexicon between UMA&  Infosharing.
>> >>>
>> >>> http://kantarainitiative.org/confluence/display/infosharing/Lexicon
>> >>>
>> >>> (full notes can be found here:
>> >>> http://kantarainitiative.org/confluence/display/infosharing/Weekly+Meeting+2009+12+28+Notes+Pending
>> >>> )
>> >>>
>> >>> We aren't quite done and that document is definitely a work in progress.
>> >>>
>> >>> However, one thing that did come up was a desire for some clarity around
>> >>> the "Requester" term currently used by UMA.  Its use has become more
>> >>> focused in the UMA conversation--unfortunately I have missed the last
>> >>> several meetings--and I had a different connotation for it than current
>> >>> UMA usage:
>> >>>
>> >>> requester: An HTTP client (per [HTTP]) capable of interacting with hosts
>> >>> and AMs to request, and receive access to, protected resources.
>> >>>
>> >>> Eve also mentioned that "Requesting Party" is sometimes used to refer to
>> >>> the requester. I pointed out the challenges with that being acronymized
>> >>> to RP (which also stands for Relying Party). Eve also mentioned that the
>> >>> use in the definition has been narrowed down to the client (as in HTTP
>> >>> client) and specifically does not refer to the service, entity, or
>> >>> individual directing that client.
>> >>>
>> >>> In the information sharing conversation, our focus is almost entirely at
>> >>> the entity and individual level, so we need terminology that can refer
>> >>> to the correct layer in the stack.
>> >>>
>> >>> For example, in a scenario where FedexOffice is printing a soccer team's
>> >>> calendar on demand for a soccer mom, we have the following layers
>> >>> involved in the requestor side:
>> >>>
>> >>> 1. requesting client (the http client)
>> >>> 2. requesting service (the application running on the FedExOffice servers)
>> >>> 3. requesting entity (FedExOffice, the legal entity taking possession of
>> >>> the data)
>> >>> 4. requesting entity's representative (FedExOffice employee who is
>> >>> handling the print job)
>> >>> 5. requesting user (the soccer Mom whose child is on the team)
>> >>>
>> >>> Or
>> >>>
>> >>> 1. requesting client
>> >>> 2. requesting service
>> >>> 3. requesting entity
>> >>> 4. requesting entity's representative
>> >>> 5. requesting user
>> >>>
>> >>> Or
>> >>>
>> >>> 1. client
>> >>> 2. service
>> >>> 3. requesting entity
>> >>> 4. requesting entity's representative
>> >>> 5. requesting user
>> >>>
>> >>> I don't like #4 as a term (I made it up while writing this email), and
>> >>> I'd like to simplify this much further.  However, my main point is that
>> >>> I would like to start a conversation to synchronize terminology for
>> >>> referring to the participants at a higher level in the stack, while
>> >>> keeping the simplicity in the protocol level work UMA is doing.
>> >>>
>> >>> Input and feedback would be much appreciated.
>> >>>
>> >>> Cheers,
>> >>>
>> >>> -j
>> >>>
>> >>> --
>> >>> 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
>> >>>
>> >>
>> >> 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
>> >>
>> >
>> >
>> > --
>> > Nat Sakimura (n-sakimura at nri.co.jp)
>> > Nomura Research Institute, Ltd.
>> > Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
>> >
>> > _______________________________________________
>> > WG-UMA mailing list
>> > WG-UMA at kantarainitiative.org
>> > http://kantarainitiative.org/mailman/listinfo/wg-uma
>> 
>> 
>> 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
>> 
> 
> -- 
> Chief Architect                   AIM:  gffletch
> Identity Services                 Work: george.fletcher at corp.aol.com
> Aol Inc.                          Home: gffletch at aol.com
> Mobile: +1-703-462-3494           
> Office: +1-703-265-2544           Blog: http://practicalid.blogspot.com
> <UMA Actors.jpg>


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20100204/5709de7f/attachment-0001.html 


More information about the WG-UMA mailing list