UMA telecon 2014-08-28

Date and Time

All-hands meeting Thu Aug 28 9-10am PT (time chart)
- Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines), room code 178-2540#
- Screen sharing: http://join.me/findthomas

Agenda

Roll call
Minutes approval
- Candidate motion: Approve minutes of UMA telecon 2014-07-31 and read into today's minutes all intervening ad hoc meeting notes.
Calendar review and interop planning
- Next week: APAC-friendly meeting time Wed/Thu (see below for details) and KI workshop in Utrecht
- MIT-KIT conference Sep 18-19 with OpenID Connect Day on RESTful Services in Healthcare (Sep 19)
- IIW Oct 28-30: UMA implementors' meeting Wed Oct 29 afternoon
Public review ends on Sep 6: next steps
IoT comparative case studies and technologies
- "Reefer" (Marcelo), healthcare (Domenico), IETF ACE, AllSeen...
Open issues: see latest email discussions
- Issues 88 and 99: decide disposition today if possible
AOB

Minutes

Roll call

Quorum was reached.

Minutes approval

Candidate motion: Approve minutes of UMA telecon 2014-07-31 and read into today's minutes all intervening ad hoc meeting notes.

MOTION: Moved by Keith: Approve minutes of UMA telecon 2014-07-31 and read into today's minutes all intervening ad hoc meeting notes. APPROVED by unanimous consent.

Calendar review and interop planning

Next week: APAC-friendly meeting time Wed/Thu (see below for details) and KI workshop in Utrecht

Maciej can make the Wed meeting, and Maciej, Mark, and Domenico are all going to be at the workshop. Mark and his colleague will present the UX perspective. It would be great to publish their work as a case study after. We should try and get a report out from the workshop about the consent receipt work as well.

MIT-KIT conference Sep 18-19 with OpenID Connect Day on RESTful Services in Healthcare (Sep 19)

Of those on the call, Eve, Zhanna, likely Sal, and Adrian will be there.

IIW Oct 28-30: UMA implementors' meeting Wed Oct 29 afternoon

This is planned.

Public review ends on Sep 6: next steps

Original plan:

Do V0.9 public review of the three technical specs.
Get LC to vote on proceeding these to All-Member Ballot as KI Draft Recommendations.
Get KI membership to do All-Member Ballot as KI Recommendations.
Burn down all the GitHub issues identified as "pre-V1.0 prep".
Do it all again for V1.0.

Alternative option:

Do V0.9 public review of the three technical specs.
Proceed directly to burning down all the GitHub issues identified as "pre-V1.0 prep" without doing steps 2 and 3 above.
Do V1.0 public review of the three technical specs.
Get LC to vote on proceeding V1.0 specs to All-Member Ballot as KI Draft Recommendations.
Get KI membership to do All-Member Ballot of V1.0 specs as KI Recommendations.

The advantage of doing the original plan is that anyone who wants there to be an official KI-"blessed" version sooner will have one. The advantage of doing the alternative option is that we can avoid lots more process. We think both are totally legitimate exercises of the Operating Procedures. Keith notes: As long as the alternative option is "legal", the KI blessing earlier is not absolutely essential.

Until we get more information in, let's lean towards the alternative option as our revised plan.

AI: Eve: Publicize remaining Public Review period with Joni and others.

IoT comparative case studies and technologies

"Reefer" (Marcelo), healthcare (Domenico), IETF ACE, AllSeen...

Domenico has prepared an early draft of a healthcare-focused IoT use case for the KI workshop. There is additional complexity and subtlety needed around object (device) ownership, resource ownership, etc. Does it make sense to say that the doctor literally owns their RFID-enabled white coat? Then they would have to onboard their white coat to the hospital they're in that day, the electronic stethoscope they're using right now, etc. The stethoscope would need short-lived provisioning of the association.

(See George's Internet-of-Things presentation from CIS. He talks about use cases for this kind of dynamic association there, referring to the dynamic client registration software statement as a potential solution component.)

Adrian notes that today's real-world problem is how to associate the stethoscope with a particular patient when the test results go into the health record. Does this use case make the assumption that patient identification is implied by the surrounding context already? George asks: If the patient has a way to introduce themselves to the stethoscope – not a provisioning mechanism from the perspective of "right to use" but from the perspective of discovering where to send the data for that short period of time – could that dynamic creation of a relationship suffice?

Do all the people in question have their own authorization servers? That is indeed the assumption. If both patient Alice and Dr. Bob have their own AS, then Adrian thinks this can hang together. Automated delegation is the goal.

There's a protocol needed here that's outside of UMA that does the "personal discovery service" piece. That may be largely what a lot of IoT protocol work has done already!

Eve points to the IETF ACE "actors" work here. It would be cool if Domenico's case study could map to the ACE actors, and then we could perhaps contribute a case study I-D to the ACE group for consideration that maps the ACE actors to UMA actors.

There's also the work being done at AllSeen on "security enhancements" that include authorization, where UMA may possibly be relevant.

Open issues: see latest email discussions

Issues 88 and 99: decide disposition today if possible

Deferred!

Attendees

As of 27 Aug 2014, quorum is 8 of 15.

Eve
Pete
Domenico
Mark
Keith
Maciej
Jin
Sal

Non-voting participants:

Adrian
George
Zhanna
Ann

Next Meetings

APAC-friendly focus meeting Wed Sep 3 4-5pm PT/ Thu Aug 7 8-9am JPN / Thu Sep 4 9-10am AUS (time chart)
Focus meeting Thu Sep 11 9-10am PT (time chart)
No meeting Thu Sep 18 9-10am PT (time chart) - Eve, Mike regrets
All-hands meeting Thu Sep 25 9-10am PT (time chart)

Browser not supported