[Wg-uma] Draft minutes of UMA telecon 2009-09-03

Bill Smith Bill.Smith at Sun.COM
Fri Sep 4 08:03:29 PDT 2009


Eve,

One minor correction, I was in attendance - late but there for about  
45 minutes.

Bill

On Sep 4, 2009, at 7:43 AM, Eve Maler wrote:

> The draft minutes are here:
>
> http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2009-09-03
>
> Please especially note the "NEXT MEETING" info and dial-in details,  
> since we'll be experimenting with an offset (and every so slightly  
> lengthened) meeting time.  Also, I'm pleased to say that the action  
> items are getting spread around quite a bit more :-), so please keep  
> an eye on any AIs you accepted.  The action item summary is here:
>
> http://kantarainitiative.org/confluence/display/uma/Meetings+and+Minutes
>
> The minutes are also pasted below, for your convenience.
>
> 	Eve
>
> Attendees
> Adams, Trent
> Akram, Hasan
> Catalano, Domenico
> Fletcher, George
> Hanson, Michael
> Machulak, Maciej
> Maler, Eve
> Scholz, Christian
> Stollman, Jeff
> Guest: Brett McDowell
> Regrets
> Paul Bryan
> Iain Henderson
> Agenda
> Roll call
> Status of the August minutes ballots, and what "non-voting"  
> participation means
> Action item review
> 2009-08-27-1	 Eve	 Open	 Investigate donations of properly working  
> telecon bridges for the future.
> 2009-08-27-3	 Eve	 Open	 Set up electronic ballot for Calendar  
> scenario.
> 2009-08-27-4	 Hasan	 Open	 Derive and document proposed requirements  
> from the Calendar scenario.
> 2009-08-27-5	 Christian	 Open	 Revise distributed social networks  
> scenario.
> 2009-08-27-6	 Hasan	 Open	 Revise the wiki document to incorporate  
> all scenario revisions proposed by people in email.
> 2009-08-27-7	 Everyone	 Open	 Submit new scenarios by next Tuesday  
> so we have time to read them before next week's meeting.
> Drill down on prototype/validator coding budget request
> Terminology: can we identify a winning set?
> Discuss use cases
> Revised
> New
> AOB
> Minutes
> NOTE: Christian experimented with streaming the call at http://bit.ly/wgumalive 
>  and also recording it, but on the advice of Brett (Kantara  
> executive director) when he joined the call, we aborted the  
> recording due to an earlier decision made by the Kantara Initiative  
> leadership to avoid recordings because of potential chilling effects  
> on IP contributions from some participants.
>
> Roll call
> Quorum was not reached.
>
> NOTE: Some people who want to join are being stymied by the  
> inability to join the calls. Since we have not received offers of  
> better telecon bridges, we will continue to use the current system  
> but will offset our telecon's starting time to avoid what we believe  
> is top-of-the-hour congestion. [Added after the fact: Since we tend  
> to run a bit long anyway, Eve has now blocked off 100 minutes  
> instead of 60 for our calls.]
>
> New member Jeff Stollman introduced himself. He's an independent  
> consultant and he's involved in a couple of other Kantara groups.
>
> Status of the August minutes ballots, and what "non-voting"  
> participation means
> Eve is recording the informal balloting results on the Meetings and  
> Minutes page.
>
> There is a perceived "bug" in the Kantara procedures (or in Robert's  
> Rules?), in that people who weren't in attendance at a meeting are  
> hard-pressed to vote on whether the minutes reflect reality. In  
> advance of the Leadership Council discussing the issue in Las Vegas,  
> we will assume that these four ballots are validly constructed, and  
> we will assume for them that "positive" abstentions from voting  
> (people writing in to say they abstain) will count towards the total  
> we need to have a successful ballot. [Added after the fact: Eve  
> confirmed our interpretation.]
>
> Action item review
> 2009-08-27-1	 Eve	 Open	 Investigate donations of properly working  
> telecon bridges for the future.
>
> We haven't gotten any donations yet. Eve will opportunistically look  
> for alternatives.
> 2009-08-27-3	 Eve	 Open	 Set up electronic ballot for Calendar  
> scenario.
>
> This is pending until Eve can declare some people "non-voting".
> 2009-08-27-4	 Hasan	 Open	 Derive and document proposed requirements  
> from the Calendar scenario.
>
> This is still open. Hasan has been working on deriving the  
> requirements, and will put them in the wiki soon.
> 2009-08-27-5	 Christian	 Open	 Revise distributed social networks  
> scenario.
>
> This is still open. Could he substitute his "mass authorization"  
> scenario (which Eve saw in private communications) for this one?  
> Yes, it appears so, and H=he'll try to write up the mass  
> authorization one for next week. The discovery service aspect (of  
> both of them) is not distinctive, as it turns out.
> 2009-08-27-6	 Hasan	 Open	 Revise the wiki document to incorporate  
> all scenario revisions proposed by people in email.
>
> Christian will work on his scenario as a separate document. We'll  
> consider this single action item closed, but will review status of  
> this nature every week.
> 2009-08-27-7	 Everyone	 Open	 Submit new scenarios by next Tuesday  
> so we have time to read them before next week's meeting.
>
> This will become our standing rule, and we'll consider this single  
> action item closed.
> Drill down on prototype/validator coding budget request
> Michael notes that whether a validator is hosted or not would impact  
> any funding estimate. Brett suggests that if we have hosting  
> requirements, we should include these parameters in our request,  
> since Kantara's servers could possibly run a hosted validator  
> depending on traffic needs. He also recommends that we guess at the  
> level and type of effort we might need overall, even in the face of  
> insufficient data, rather than let this window of opportunity close.
>
> Paul has, in private communications, guessed that an initial  
> implementation (of an AM, or other piece as well?) might take a  
> couple of weeks. Michael thinks a validator might overall be more  
> work than any one implementation of a single "entity", since it has  
> to cover all the endpoints, and also it needs to stress  
> implementations thoroughly. We need to find out and catalogue what  
> endpoints people are interested in implementing.
>
> There are various methods for funding implementation work. We could  
> hire someone, or we could offer a bounty that helps cover costs for  
> a community volunteer, or we could offer matching funds along with  
> some other party.
>
> Let's say that a validator takes 200% of the "two weeks" estimate we  
> have; that's four weeks. We might want to think of accomplishing  
> things in phases, so a phase 1 could focus on implementation towards  
> adoption, and a later phase could focus on testing.
>
> AI: Eve, Paul, Michael: Open: Finish the budget request for UMA.
>
> Terminology: can we identify a winning set?
> We discussed the "entity numbers" to ensure that we agree on our  
> understanding of the different entity positions. It appears we're  
> clear on:
>
> Entity #1: User (the thing – in our V1 scope, a natural person –  
> that hosts some data/content)
> Entity #2: the thing that does authorization on the user's behalf
> Entity #3: the thing that the user has chosen to host some  
> particular data/content
> Entity #4: the thing to which the user may wish to grant some access  
> to entity #3's data/content
> Jeff asked why we couldn't use existing terminology. Eve gave this  
> rationale: The ProtectServe sketch did reuse OAuth terminology, but  
> it turned out to be more confusing than helpful: first,  
> ProtectServe's AM and SP play, respectively, OAuth SP and Consumer  
> roles; second, the OAuth terminology seems to be changing to bring  
> it closer to low-level HTTP authentication (server/client), leaving  
> UMA as a obviously higher-level application above OAuth in the  
> "stack". Further, there are many choices of terminology among  
> existing systems – e.g., ProtectServe's Consumer could be called a  
> client, a web service client, a relying party, and even a service  
> provider! – so it's hard to pick exactly one that matches.
>
> No one liked "PDP" (policy decision point) for entity #2.
>
> We discussed the potential need for an "entity #5", which is a  
> corresponding (natural or legal) person that uses entity #4 to  
> accept data/content access on their behalf. Even if the 4<->5  
> interaction is out of our scope, we may find it handy to have a term  
> for them.
>
> George thinks we may need to get more specific about the identities  
> of specific #5 entities somehow. Michael notes that there's the  
> concept of "user agent" on the web, and entities #2 and #4 are in a  
> sense serving as different kinds of agents of various parties. Eve  
> asks if the word "agent", as good as it is, is already used up by  
> "user agent"?
>
> We discussed the need for entity #4 (which allows many "users" of  
> its service offering) to reflect the fact that it's asking for  
> access to hosted data on behalf of some particular user/company/ 
> whatever (#5). We don't want to bind UMA to identifier systems, but  
> we do need to ensure that whatever correlation handle entity #4 is  
> assigned isn't reusable by different customers of theirs, and so  
> that entity #1 knows who they made a contract with. In a lot of  
> ways, the relationship between #1 and #2 is mirrored by the  
> relationship between #4 and #5.
>
> AI: Michael: Open: Create a scenario, or a use case off the Calendar  
> scenario, that explores the need for entity #4 to approach the other  
> entities in the context of some unique entity #5.
>
> Can we force some decision-making on what to call the entities? Why,  
> yes we can:
>
> Entity #1: User (along with User Agent as necessary): Yes
> Entity #2: Authorization Manager (AM): Yes
> Entity #3: Host: Yes
> Entity #4: Requester: Yes (somewhat tentatively)
> Entity #5: we'll see what we can come up with later...
> AOB: interest in XRD work?
> Brett asks if we have an interest in liaison with the XRD work. We  
> do, although it may or may not be directly related, and we have some  
> membership overlap. Potential touchpoints might include, for example  
> (forgive the heavy acronym usage below):
>
> Defining a REL so that XRD can point to a user's AM
> Syncing up with the ID-WSF Evo group regarding similarities in the  
> way we mediate our AM/Host introductions and the way they mediate  
> their RESTful DS/WSP introductions
> Next Meeting: UMA telecon 2009-09-10
> Day: Thursday, 10 Sep 2009
> Time: 9:10-10:30am PDT | 12:10-1:30pm EDT | 16:10-17:30 UTC (time  
> chart)
> Dial-In: +1-218-862-7200 or +1-712-432-3100 (if one doesn't work,  
> try the other)
> Code: 987-632 (do not press #)
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma_kantarainitiative.org/attachments/20090904/ff077017/attachment-0001.html>


More information about the Wg-uma mailing list