UMA telecon 2009-08-27 (focus)

Owned by Former user (Deleted)
Last updated: Aug 27, 2009Version comment
4 min read

UMA telecon 2009-08-27 (focus)

Date and Time

  • Day: Thursday, 27 Aug 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

  1. Adams, Trent
  2. Akram, Hasan
  3. Andrieu, Joe
  4. Bryan, Paul
  5. Catalano, Domenico
  6. Fletcher, George
  7. Hanson, Michael
  8. Henderson, Iain
  9. Machulak, Maciej
  10. Maler, Eve
  11. Nagelberg, Alan

Regrets

  • Diego Lopez

Agenda

Minutes

AI: Eve: Investigate donations of properly working telecon bridges for the future.

Roll call

Quorum not reached. Let's undo our focus/quorate decision, and just have meetings. We can batch-up our meeting minutes into monthly electronic ballots, to make sure that group participants who are not joining the calls have a chance to review and approve the work done to date.

Approve minutes of prior telecons

AI: Eve: Send out an electronic ballot for the August meeting minutes.

Action item review

2009-08-20-2: Check on IPR considerations around public(ish) F2F meetings: Still pending a final decision from Kantara staff on how to handle this.

2009-08-20-4: Eve: Revise the photo set scenario to be more realistic: Now closed.

Briefly discuss options for collaborating on implementations

Eve describes our group has having a goal of facilitating implementations, but not hosting them here. If someone wants to start a "sister group" in Kantara (or elsewhere) that chooses a suitable IPR option (very likely the "Apache option" in the Kantara case), that's a possibility.

Iain notes that his company Mydex is interested in doing an implementation and possibly contributing some work that's been done to date. Currently they've built on ID-WSF and information cards.

Paul plans to establish a "reference implementation" type of project that tests out and demonstrates the protocol we're developing, with the hope that it could eventually be suitable as a code base for productized efforts. He's reluctant to make it part of this group or too closely associated with this group, since all implementations should be equal in this group's eyes.

Christian may be able to work on an implementation related to the distributed social networking use cases.

Maciej expresses an interest in coding, with a preference for working in Java – possibly working with Paul.

Michael suggests that validator code is what should be placed in the public domain first and foremost.

When we've got enough real efforts started, we'll keep track of them on a wiki page.

Review and consider acceptance of scenarios and use cases

Sharing a Calendar with Vendors (Pending)

What does it mean to "accept" a scenario or use case? It means that we have decided to include it in the problem space we're trying to solve. Obviously, for a scenario this is a vague standard, but for use cases it's a bit more specific, and for requirements (which might be derived from our "distinctive aspects"), it could be quite precise and ideally machine-testable.

We don't have quorum on the call (and may not generally get quorum on the calls), so let's do as much as we can by "perfect consensus" on the calls, and then do electronic ballots to confirm our decisions.

No one objected to provisionally ACCEPTING this scenario.

AI: Eve: Set up electronic ballot for Calendar scenario.

AI: Hasan: Derive and document proposed requirements from the Calendar scenario.

Controlling Two-Way Sharing of Location Information

Eve proposed this scenario in email.

The read-write aspect doesn't seem to have huge protocol implications, but it may have huge conceptual implications, in that two one-way write authorizations look like a single big two-way authorization, but they're actually not.

The issue of somehow controlling the level of location information is a big one for privacy.

Does it have protocol implications to imagine that the SP can "teach" the AM what policy options it offers (or even other details of its API)? Paul believes that, in step 0, the AM and SP do have an opportunity to exchange such information.

Eve suddenly realizes that this scenario has a huge, but so far unstated, distinctive aspect: It demonstrates a degenerate case of the UMA assumption about "person-to-service" sharing, in that the service is representing the exact same person. This is because OAuth today is literally about granting service-to-service access where the same exact person is "behind" both services.

We think it's worth continuing to refine this scenario and trying to get it accepted eventually. We're not there yet. Joe points out that the scenario sets up a sort of "federation" that allows any node to update my location, but doesn't have grand designs about having the services literally collaborate to figure out or correct my location.

We do want to capture scenarios around "person-to-service" authorization where the service represents other people, along the lines of "portable contacts" or similar – but most such scenarios might be deferred rather than accepted for V1.

Paul would like us to generate more scenarios, so that we can pick among a bunch of compelling ones.

AI: Christian: Revise distributed social networks scenario.

AI: Hasan: Revise the wiki document to incorporate all scenario revisions proposed by people in email.

AI: Everyone: Submit new scenarios by next Tuesday so we have time to read them before next week's meeting.

AI: Eve and Hasan: Investigate the possibility of breaking up the scenarios into multiple wiki pages.

Next Meeting: UMA telecon 2009-09-03

  • Day: Thursday, 3 Sep 2009
  • Time: 9-10am PDT | 12noon-1pm EDT | 16:00-17:00 UTC (time chart)
  • Dial-In: Stay tuned! We may switch our number