UMA telecon 2013-09-26

UMA telecon 2013-09-26

Date and Time

Agenda

Minutes

Roll call

Quorum was reached.

Consideration of revised charter proposal (track-changesclean)

MOTION: Keith moved, and Andrew seconded, a motion to accept the proposed charter revision as amended on 2013-09-26. APPROVED by acclamation.

Eve has alerted the LC to consider approving the revised charter.

Demo video status (rough-cut)

Keith is interested to do the audio for the "real" video!

AI: Eve: Reach out to Dazza and Keith to set up a "real" PCloud video recording session.

How easy is it to change the sample app "skins" and wording? It should be pretty easy for wording changes. Andrew suggests showing a sidebar when each application's tab is up, highlighting the UMA entity. Can we "add that in post"? Let's hope! Maybe we can shorten the script precisely around the huge long explanation of the different entities, if we can use this shorthand to help people understand "naturally". Could we leverage the spiral itself, shrinking it down once the demo begins kind of like a sign language interpreter and highlighting different interactions as they occur? Eve could create a series of slide images to do this. Admittedly, it's hard to keep track without this sort of help.

It would be best to have the UMAWG Twitter handle and the tinyurl available more constantly on the screen, and of course be sure to have a companion slide deck available to download, advertised on the first image. That companion deck could have the acknowledgments on the first page; then it's okay to have a credit roll or similar at the end of the video with those acknowledgments.

A takeaway slide at the end should reiterate the benefits, learnings, and takeaways – it's simple! That helps "seat" the knowledge in people's brains. "Tell 'em what you told them."

What if we were to take a "Pop-Up Video" approach to privacy and PbD, doing a version that's identical to the PCloud one but has pop-ups?

Privacy/PbD API discussion and next steps (proposed text)

Andrew notes that Ann Cavoukian's office publishes reports on technologies. If this text could be the beginnings of a coauthored report from her office, it would get wider readership. Ann's office usually also sends people to the Privacy & Security Conference in Victoria, BC February 5-7. It would be very cool indeed if UMA could get a sort of "PbD APIs" branding.

AI: Eve and Andrew: Loop in Neil on a discussion about reaching out to Ann C about UMA+PbD futures and the upcoming User Forum event.

Domenico makes a case that for "5. End-to-End Security - Full Lifecycle Protection", UMA could enable this. Eve's thinking: It could enable it through the maintenance of a historical audit log of access policies, requests, approvals, and revocation during a resource's lifecycle, which supports the user being able to assess the state of their personal data confidentiality and even supports the user being able to impose downstream data usage controls by extracting "chain of confidentiality" promises from requesting parties. Other back-end systems would still be needed for defense in depth of the resources at rest..." etc.

Jin supports seeing the PbD efforts here! This is critical for healthcare solutions. The next HIMSS conference is in March, and a lot of solution vendors will be presenting their solutions there (the CfP is closed for this). So perhaps we can have a solid story for that timeframe. Jin will also be attending IIW. Part of the solution, besides data liquidity, is data segmentation for privacy. The DS4P work can benefit from seeing the PbD material.

AS=C use case discussion (previous notes)

There seem to be three issues that potentially impact our deliverables:

  1. Resource set registration as an avenue for the RS to convey some representation of the resource (set) in question for AS dashboard purposes
  2. Binding obligations that prevent the AS from being a bad actor in issuing itself client "UMA artifacts" such as credentials, AAT, RPT, and authorization data
  3. Optimization opportunities around the AS communicating with itself-as-C without having to go out to the wire, but resulting in conforming "UMA artifacts" that the RS can treat totally normally

Does the current spec say that messages do or don't have to go out on the wire? It says they do. Everything is HTTP-based APIs. In addition to AS=C, the other use case we've been considering is RS=AS, where resource set registration could be done in a totally proprietary way. The questions could be: Is the result auditable? and: Does it have to produce UMA artifacts that other entities may be required to interact with?

Lukasz notes that adding the resource type to RSR is a good idea, though not really leveraged yet in their AS. Would a third-party extension to the JSON format of a resource set description help Mark D? We can ask him. It's an interesting escape hatch, but doesn't do exactly what he asked, which was access to the real value of specific personal data.

Let's continue to muse on these options.

Field any interop planning questions

None. Eve has suggested that interop participants target end of 2013 with their implementations so that we can begin virtual interop testing, even if a F2F interop isn't scheduled until later in 2014Q1 or whenever.

Quick action item review if time

Deferred.

Attendees

As of 26 September 2013 (pre-meeting), quorum is 6 of 11.

  1. Eve
  2. Andrew
  3. Jin
  4. Lukasz
  5. Domenico
  6. Thomas
  7. Keith

Regrets:

  • Mark Dobrinic

Next Meetings

  • Focus meeting on Thursday, October 3, at 9am PT (time chart)
  • Focus meeting on Thursday, October 10, at 9am PT (time chart) - Eve regrets, Thomas is chair pro tem
  • Focus meeting on Thursday, October 17, at 9am PT (time chart) - Eve regrets, Thomas is chair pro tem (IDESG is happening Oct 15/16)
  • Focus meeting on Thursday, October 24, at 9am PT (time chart) - note that UK goes off summer time on Oct 27
  • All-hands meeting on Thursday, October 31, at 9am PT (time chart) - note that US goes off summer time on Nov 3
  • Interop event at MIT on Oct 31-Nov 1 (date and location may change)