...
- Fridays, 8-9am PT
- Voice: Skype: +99051000000481 / US +1-805-309-2350 / international lines / web interface, code 178-2540#
- Screen sharing: http://join.me/findthomas – NOTE: do not use the join.me dial-in line
- UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
2016-11-18
- Eve to give update on Karsten Kinast convo
Attending: Eve, John W, Kathleen
Eve had a chance to deep-dive on some of our current topics with Karsten. In the rights-based EU conception, law/regulatory interpretation/contract can capture the sheer reality of little Johnny's natural rights to privacy over data about him; he has an aura that can't be detached. His relationship with his mother Alice is internal, and UMA's relationship is with him, not Alice. This is "the view of the world from the human rights/legal end". On the other hand, "the view of the world from the technical end", where the technical end in our case is UMA, would connect UMA to Alice because she is the one actually wielding the technology as a resource owner. So the bridge we're building connects those two worlds at the point of identifying the resource owner, data subject, and grantor roles. Does that work? For this reason, it's perhaps best to use the literal GDPR (and other data protection law) wording, vs. being cute and using "resource subject".
This is making us want to revise the charter to a) ensure that our work helps UMA be used for good and not evil generally, and also b) ensure it's used on behalf of data subjects, not just for resource owners in that role. How about replacing ", particularly where the resource owner is an individual" with "in a manner consistent with protecting privacy rights" (and get rid of the word "themselves")?
They also talked about sharing access with the intent of making the grantee a(nother) data controller vs. making them a data processor. Making someone a DP (say, because you're asking them to do something "on your behalf" for consideration – e.g. outsourcing payroll processing) means accountability remains with the grantor (Alice), while making someone another DC means you've just given them access for whatever reason, and they're just another accessor. Control becomes additive. So Eve's working theory became: Would it be possible to develop tools that distinguish between Alice's ability to grant access for the purpose of processing vs. for other purposes, as a broad means of managing the DS's/ risk? Would our time be best spent in this group working on these tools first vs. other tools? Could grantors/resource owners clearly understand such distinctions? This is where the DS would be accountable but the DP would need to take on responsibilities (think "RACI") to balance the risk. Our tools – e.g., data sharing agreements – could include standard text for that.
The last subject they discussed was the types of use cases that would need to be developed. Eve has started a fresh Legal Use Cases page, here. It's just a shell so far. Following are the use case axes identified so far.
- Granting access to DC vs. DP
- Disclosing data vs. granting other kinds of access (e.g., letting a client of a grantee add data back through the API, or let it use an algorithm by paying for access, or accessing a photo...)
- Whether the DS and the grantor are both in the EU (leave this complexity aside for now??)
- Every vertical and horizontal use case will probably need its own special-sauce text! But we should at least start gathering examples and identifying what are hopefully "design patterns"
John is concerned that XACML went down a similar path, with resulting complexity. Let's seek ways to boil the smallest of ponds.
2016-11-04
- Review draft UMA Legal mission statement (and Jim comments), wordsmith, and decide
- Review current use cases and plan for building up new ones
...