UMA telecon 2009-09-03

Date and Time

Day: Thursday, 3 Sep 2009
Time: 9-10am PDT | 12noon-1pm EDT | 16:00-17:00 UTC (time chart)
Dial-In: +1-218-862-7200
Code: 987-632 (do not press #)

Attendees

Adams, Trent
Akram, Hasan
Catalano, Domenico
Fletcher, George
Hanson, Michael
Machulak, Maciej
Maler, Eve
Scholz, Christian
Smith, Bill
Stollman, Jeff

Guest: Brett McDowell

Regrets

Paul Bryan
Iain Henderson
Diego Lopez

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 #)