UMA telecon 2012-11-29

Owned by Former user (Deleted)
Last updated: Nov 29, 2012
5 min read

UMA telecon 2012-11-29

Date and Time

  • All-hands meeting on Thursday, 29 Nov 2012, at 9am PT (time chart) - technical/interop
    • Skype: +99051000000481
    • US: +1-805-309-2350 (other international dial-in lines available) | Room Code: 178-2540

Agenda

Minutes

Roll call

Quorum was not reached.

Review of meeting schedule and topics for December

We hope the SMART team will have its proposal for registration of discovery metadata ready for next week, and we'll plan to do a podcast next week.

Eve will check with the "legal all-stars" about the possibility of focusing on legal topics on December 13.

We'll do an all-hands meeting on Dec 20, and won't meet Dec 27 because of the holidays.

There's an UMA/AXN ad hoc meeting on Dec 7 which a number of us are attending.

Eve and Thomas will do an ad hoc collaborative spec editing meeting sometime next week.

Healthcare case study discussion

The "Direct" system uses the email system. A sender picks up the domain name of the recipient's email, use this to source the recipient's public key, encrypt the email content with it, and send to the email address. We're not sure what standardization they've done or leveraged around the metadata where that public key is located (such as RFC 4871, Domain Keys). E.g., it doesn't seem to use Webfinger or similar. Adrian is currently at a meeting (the "Direct Trust" meeting, run by the White House, which about 30 people are attending, mostly representing HIE systems) where they're working on helping patients to participate as first-class citizens.

It might be useful to point out the inherent limitations of the Direct system as part of the problem scenario. It does have some strengths around being "patient-centric" in that it can work with self-signed certificates; the patient would just have to figure out how to post the cert through their ISP or through Microsoft HealthVault. However, all of the institutions using it are struggling with how to create an overlay on this very low level that meets their business purposes. In light of UMA and patient authorization of data transfer, it's most interesting to consider the challenge of getting data out of the institutions (data-holders/hosts). What is the relationship between the Direct identifier and notification systems, and the ability to discover one's account at an AM? As long as the patient can get a login (local or federated) at the institution and then link it to their AM, UMA has a solution for this that is OAuth-based, similar to but enhanced compared to the OAuth BlueButton work that Adrian is already involved in.

Adrian is also meeting with the Coalition for Patient Privacy this week (a group in which Latanya Sweeney is involved)! From this point of view, the issues around the coercive aspects of health data sharing – sharing outside the patient's control, such as for public health reasons or for tracking narcotics prescriptions – come to the fore. Is UMA a good way to enable patient auditing of data sharing by hosts that they have connected to their AMs? This is an area that Synergetics has been exploring with TAS3 and similar, which is a more web-service-based system of event notification. Eve's guess is that the patient requires a login to the host in order to be able to audit that sharing accurately, since if there's no identifier link, the linkage of data to person may be heuristic and may compromise privacy if the link has been forged incorrectly.

The HIEs see the problem according to the three issues listed in the writeup: "From the HIE perspective, they need technology, policy and process to manage at least three data flows: (1) the matching of patient ID across independent EHRs; (2) the ability to locate the EHRs that have data for a particular patient; and (3) the list of patient authorizations that control transfer of information from one EHR to another." The HIEs have no in-person relationship with the patient or anyone else, and in many cases they're not the actual data-holders (hosts). Adrian sees issue #1 as the most pressing for UMA purposes: how would HIEs forge a business relationship with an AM? Could a patient use the same Direct email address for all the data holders and the HIE, so that they can all be relying parties on the asymmetric-key-based identification therein or could themselves register a local account on this basis? The patient could actually be pseudonymous, but they can be "strongly correlated" across all these apps by virtue of their public key.

Eve notes that anonymity is awfully hard to achieve in an ecosystem that relies on correlating identifiers and dealing in biometric-infused PII! George points out that if the patient chooses to use a different email address for pseudonymity, the patient will have re-introduced issue #1. And in any case, if multiple email addresses use the same key, that's effectively a correlatable ID anyway. What the groups are trying to avoid is the massive coercive matching algorithms used on back-end systems, since these are opaque to the patient. The patient could theoretically have something to help them manage the multiple email addresses, but that's an additional UX challenge, and the HIEs will have the same correlation requirement. These privacy requirements are a "bubble under the wallpaper" problem: it doesn't go away even if the transparency to the patient is increased, it just gets moved around.

We note that the AXN NSTIC project isn't related to healthcare, but shares many of the same goals.

AI: Eve: Suggest updates to the case study based on our new understanding.

Dynamic client registration spec review

We walked through the rev 02 spec and discussed the "OAuth access token" paradigm (if not literally OAuth) now used for accessing the registration endpoint. It's possible to have the endpoint completely open, for totally dynamic un-constrained registration; we're likely to need this more for requester app registration. And the mobile native app challenge can be solved through later presentation by the client app of a certificate that uniquely identifies it.

Should UMA point to this and profile it? It could require a signed JWT, for example, and do some domain name matching in the "completely open" circumstance. We agree we should at least point to this spec in the next UMA core spec edits.

AI: Eve: Report back to the OAuth group on the dyn client reg discussion in the UMA group.

AI: Thomas: Edit the UMA core spec to point to the new dyn client reg spec.

Issue 71

We've reached rough consensus: Let's remove the media type names from the spec!

AI: Thomas: Edit the UMA core spec to remove all the media type names and to document that we currently have no need for IANA interactions.

Attendees

As of 27 Nov 2012, quorum is 6 of 10.

  1. Catalano, Domenico
  2. Fletcher, George
  3. Hardjono, Thomas
  4. Machulak, Maciej
  5. Maler, Eve

Non-voting participants:

  • Adrian Gropper

Regrets:

  • Sal D'Agostino
  • Kevin Cox
  • Dave Coxe
  • Keith Hazelton

Next Meetings

  • Focus meeting on Thursday, 6 Dec 2012, at 9am PT (time chart) – technical, interop, podcast 
  • Focus meeting on Thursday, 13 Dec 2012, at 9am PT (time chart) – legal (subject to change), educational 
  • All-hands meeting on Thursday, 20 Dec 2012, at 9am PT (time chart) – all topics 
  • NO MEETINGS for the rest of 2012 – happy new year/end-of-the-world!

Â