[WG-UMA] Lexicon discussions

Eve Maler eve at xmlgrrl.com
Sun Jan 10 12:34:37 EST 2010


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



More information about the WG-UMA mailing list