UMA telecon 2009-08-20 (quorate)

Owned by Former user (Deleted)
Last updated: Aug 20, 2009Version comment

UMA telecon 2009-08-20 (quorate)

Date and Time

This is a Quorate meeting.

  • Day: Thursday, 20 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. Akram, Hasan
  2. Andrieu, Joe
  3. Bryan, Paul
  4. Machulak, Maciej
  5. Maler, Eve
  6. Nagelberg, Alan

Regrets

  • J. Trent Adams
  • Christian Scholz
  • Mike Hanson
  • Bill Smith
  • Iain Henderson

Agenda

Minutes

Roll call

6 of 27 present; quorum not reached.

Announce results of leadership team balloting

As previously announced in email, Eve Maler was confirmed as Chair, Paul Bryan as Vice-Chair and Technical Spec Editor, and Hasan Akram as Use Cases Editor. Thanks to all for their participation in this ballot.

Approve minutes of prior telecons

Deferred due to lack of quorum.

Consider setting up a special time to review ProtectServe details

AI: Eve: Create a doodle poll to establish a time for a ProtectServe overview.

IIW F2F meeting idea

Eve has pursued inquiries with the IIW organizers, and they may have a room to offer us. Let's try and request an afternoon-long meeting on the Monday. We could also plan to host an IIW session sharing the results of our work to date. (Do we need a "walk-through IPR agreement" in the form of a sign outside the door?)

AI: Eve: Check on IPR considerations around public(ish) F2F meetings.

Review methods of working on our documents

Hasan has sent email proposing a way of contributing to the scenario document: we can use hashtags to alert him of our ideas in email, or contribute content directly. Note that his email may have reversed the senses of our choice of scenario (high-level) and use case (lower-level) terminology.

The goal is to identify the key differences between scenarios/use cases, so that we don't add a lot of duplication.

  • Scenarios are high-level, ideally real-world, and express the needs of the actors without reference to technology (unless interoperability with something is a hard requirement/constraint).
  • Use cases add a precise accounting of the actors and the overall interaction goal. They might have pre-conditions and post-conditions.
  • Issues capture a technical problem we're going to need to decide.
  • Requirements (which we don't actually have any of, yet) capture a unique technical need we've agreed to solve.

Eventually our technical specs will need to turn into IETF Internet-Drafts. So possibly we should write the spec using xml2rfc. Alternatively, we could edit the document in Confluence, which allows for more natural collaboration and gives us some content management (e.g. tracking changes) by default. Maybe there's a way to export to xml2rfc or raw HTML from Confluence.

AI: Paul: Research technical spec formats and their pros and cons.

Review and consider acceptance of scenarios and use cases

We discussed two scenarios but haven't decided on a disposition of them yet.

Sharing a Calendar with Vendors (Pending)

Eve reviewed this scenario and its use case in detail. Some aspects that make this scenario special/unique (are these on the way to becoming requirements?):

  • The SP is simply where the user has chosen to host the calendar data; nothing is said about how it got in there. (It might have gotten there by means of a permissioned feed from elsewhere!)
  • The SP and the AM are conceptually separate; the user might choose different providers for these services.
  • This is about simple data-sharing in one direction. Think of it as a read-only operation, or an HTTP GET.

Granting Service Access to a Photo Set (Pending)

We began to discuss this. Some aspects that make this scenario special/unique:

  • This is about potentially two-way service access. Think of it as a read-write operation, or an HTTP GET/POST/PUT/DELETE.
  • Currently it involves multiple resources hosted at a single SP.
  • It is not only inspired by OAuth's authorized interactions, but it relies on integrating with OAuth specifically.

We discussed the possibility of not "muddying up" this scenario by having the multiple resources aspect in it. Should we pick another example, maybe something more realistic taken from today's OAuth world? The real-world example of chained location services that all read and write to each other is cool, but also scary. (smile)

AI: Eve: Revise the photo set scenario to be more realistic.

We definitely need to add a scenario, probably focused VRM or VPI situations, that takes into account distributed SPs for pieces of data coming from multiple sources. We don't have an owner for this yet, though Iain and Eve may be contenders; they will be discussing this offline.

(Following is an example of the hashtag in use...)

#scenario: Authorizing access to a set of multiple resources hosted on distributed SPs.

Alan (question) noted that there's a big problem in identity systems of having the same data in multiple places, since they may go out of sync or go stale. [Eve notes later: We're trying to mitigate this by making point-of-use data retrieval more consistently reliable than using data on hand.]

Next Meeting: UMA telecon 2009-08-27 (focus)

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