...
...
...
UMA telecon 2013-11-07
Date and Time
- Focus meeting Thu Nov 7 8:30-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
...
- Reminder about the meeting schedule in the rest of 2013
- Field interop feature test issues
- AS=C use case discussion (most recent previous notes) – any conclusions yet?
- Healthcare IT record location service use case discussion (if Adrian joins and we have time)
- Final half-hour: Oshani Seneviratne will present on "Provenance" research in the last half-hour
- AOB
Minutes
Meeting schedule
tbs
Interop test issues
tbs
AS=C discussion
tbs
Oshani presentation
tbs
Attendees
- tbspresentation (see details below)
- AOB
Minutes
Mark's use case: student data sharing (and connections to healthcare use cases)
Mark D's mockup doc is here. His use case writeup is here.
One challenge in mapping Mark's use case to UMA is that the UMA materials are very technical and don't illustrate clearly enough the essential concept of how UMA can support data usage controls and purposes, for privacy management. So, e.g., they have worked very hard in their mockup UX to make clear to the RO the requesting party's identity, what purpose the data will be put to (signing up for secondary school), and for how long the RqP will need that access. This is for the RO to "craft policy", at a stage similar to the OAuth user authorization stage. So this is about "policy UX", not about RqP claims-gathering.
The AS=C part of the story comes in when it's time for the parent of the student to help control the sharing of very sensitive school information, which may include health information etc. Adrian notes that there are US state and federal regulations around health data that require the person who throttles access to see what actual data is under consideration for sharing. The AS is essentially the patient's "agent", so if it's the AS that screws up, the hospital etc. as RS's are less liable. Mark's intention is for the AS/agent/dashboard not to persistently store such data, but for it to really reside on the RS. This matches the healthcare "record locator service" use case – what's stored is only the location of the data, not the data itself.
Mark has presented the UMA solution layer to the people who are working to determine the technical architecture for this use case for the next 5-10 years. Privacy by Design is a very important concept at this juncture.
Dan is a PbD ambassador now (and Eve has been invited), and Dan and Drummond are working with Ann Cavoukian's office to write a white paper on privacy and big data, and the challenge of getting authorization to access data you now need for doing further analytics.
Adrian points to the new IDESG healthcare use case. A record location service is typically a state agency, and it's an aggregator. An UMA AS might also be an aggregator. And an IdP (e.g., an OpenID Connect one) might be an aggregator too. So there are three entities that might be in this role. Today, under "participation agreements", the data moves to the aggregator, and there's no privacy-preserving way (think PbD or FIPPs) for the RO to have transparency around what's being shared. Adrian is promoting the notion at IDESG and HHS that we could link the participation agreement that allows the RS to share the data with the aggregator. SSO could be part of this: If you don't have an IdP, the RS needs to act as the IdP so that the agreement that allows the data flow can have a clause added that the AS will accept the record location service. SSO gets the ball rolling, and it doesn't require a new business relationship to be added in disruptive fashion. The ecosystem implications here are that the RS is already a patient portal – so, QED, the patient has a login and some ToS they already know about there.
AI: Adrian and Eve: Identify a time to work through the IDESG healthcare RLS use case and "UMA-fy" it. Invite the rest of the WG to the meeting time. Dan, Mark, and Domenico are definitely interested to join in.
Oshani presentation: Discussion on Decentralized Provenance Management for UMA
Abstract: Increasingly there are many privacy breaches on the web that result due to unforeseen data disclosures. It has been suggested by Weitzner et al, among many others, that supplementing access control with information transparency and accountability is one way to mitigate privacy breaches. I will describe a framework that makes transparency a first class citizen on the web, enabling a user to see who, what, why, when and where her sensitive information has been used. This framework is powered by 'decentralized provenance', where an open global trusted network of peer servers participate to keep track of provenance information related to sensitive data usages and disclosures. These records are tamper-evident and provide non-repudiable evidence of actions by various entities on the data. A reference implementation of this framework on electronic healthcare records is available at http://www.transparent-health.us.
The UMA protocol can be extended with this framework, where at each points of control for authorizing who can get access to identity attributes, content, and services can be recorded, and made available to the user after the fact. This framework can also make provisions for 'break glass' scenarios where even unauthorized parties may obtain legitimate accesses to personal data, but leave a trail behind so that the user knows that her privacy has not been breached (for e.g. an emergency room doctor accessing sensitive health data of an unconscious patient). This work is presumed to operate under a legal trust framework, and can be used to prove compliance of actions against policies defined using UMA.
Bio: Oshani Seneviratne is a PhD Candidate at MIT advised by Tim Berners-Lee. Her primary research interest is on transparency, accountability and privacy on the Web. She is also currently actively involved in research projects on disaster management, linked data visualizations, and the MIT app inventor. She has previously taught courses on mobile application development in Kenya, Sri Lanka, and the Philippines through the MIT Accelerating Information Technology Innovation program.
Presentation is available here. Eve points to the early HL7 standardization commentary around Accounting of Disclosures that she found online. Adrian and Oshani will be discussing these matters shortly. Adrian cautions against acceding to expensive, complex solutions that often come out of the HL7 standardization milieu. We don't want auditing to be "FOIA-style" onerous. Adrian approves of the approach Josh and BB+-Pull exemplify.
Is the Provenance Tracking Network is completely secure in terms of forward secrecy, or is it a point of failure? Nodes are created in a secure way in that the app server signs the record with a private key. The data owner delegates responsibility. To prove you own the resource, you have to provide the key. Eve wonders if UMA is recursively applicable to protecting PTN entities! Proving you're the owner of a record is the most important part of this new ecosystem. Thomas comments that forward key hash-chaining would be needed to answer Adrian's question fully.
Thomas is contemplating writing up a doc with Oshani for UMA WG and potentially IETF consideration. This could tie into Binding Obligations.
Eve suspects that the PTN notion also ties in closely to the ability to profile policymaking, claims-gathering, and auditing capabilities along with UMA as a base.
Attendees
- Domenico
- Eve (a prospective PbD ambassador
)
- Adrian
- Mark
- Maciej
- Keith
- Dan (a PbD ambassador!)
- Thomas
- Oshani (guest)
Next Meetings
- No meeting Thu Nov 14
- All-hands meeting Thu Nov 21 8:30-10am PT (time chart) - we'll discuss resource/scope management and SAML/UMA attribute release with Roland and he will show a demo of this implementation
- No meeting Thu Nov 28 (US Thanksgiving holiday)
- No meeting Thu Dec 5
- Focus meeting Thu Dec 12 8:30-10am PT (time chart)
- All-hands meeting Thu Dec 19 8:30-10am PT (time chart)
- No meeting Thu Dec 26 (holidays)
- Focus meeting Thu Jan 2 8:30-10am PT (time chart)
...