[WG-UMA] Lexicon discussions

George Fletcher george.fletcher at corp.aol.com
Tue Feb 2 12:02:36 EST 2010


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.

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?

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?

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?

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

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20100202/b9fc7b0b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UMA Actors.jpg
Type: image/jpeg
Size: 75248 bytes
Desc: not available
Url : http://kantarainitiative.org/pipermail/wg-uma/attachments/20100202/b9fc7b0b/attachment-0001.jpg 


More information about the WG-UMA mailing list