...
- Review document deliverables
- UMA Legal Primer
- UMA Legal Use Cases
Attending: Eve, Kathleen, Ann, John W, Adrian, Scott, Paul, Mark
We started reviewing the primer. If we can't make it all fit into 2-3 pages as we first hoped, let's try and use a "progressive disclosure" approach, so that the first part boils down the rest of the paper in a very short space.
NOTE: All but Eve (and John): Eve will "take the pen" over the weekend in the doc. If you want to do stuff in the doc till the next meeting, please do so in Suggest mode!
Adrian introduced the notion of the AS as the only safe way to handle bots (such as Siri) that are the alternative to the explosion of apps on mobile devices (see the de-app-ification trend). So the "agent" theme as exemplified by a personal AS could be an exploratory theme in the doc.
How deep to go on privacy compliance? Scott suggests that UMA makes the underlying systems reliable and predictable, which provides a basis for trust and enables observability of regular actions. The systems are tuned to local expectations. Things are "done to spec". Adrian observes that UMA could be said to be a "core component of privacy engineering". Scott also reframes as "operational privacy". Don't forget about Privacy by Design – here is the (old by now?) paper on Privacy by Design implications of UMA.
Why could an XXX love it?
CPO:
- Standards make for cheaper solutions for compliance. Average US privacy budget (PSR '15): $300K.
- Emerging ecology of user control standards gives an alternative to contracts of adhesion.
Data subject:
- There's power in having more "consent tech" solutions available and deployed on your behalf to choose from.
2016-06-03
- NOTE: No subgroup telecon next week
- Privacy@Scale report
- Status of outlining/editing of newly planned document deliverables
- UMA Legal Primer
- UMA Legal Use Cases
Attending: Eve, Paul, John W, Mary, Ann, Kathleen, Adrian, Mark
Privacy@Scale and other event reports: John and Eve both attended on Monday of this week; it was the 2nd annual, and their first. Facebook hosts it. It was in DC this year. John was very vocal. You can find two of the three report deliverables commissioned by Facebook from Ctrl-Shift at this site.
The third report is coming soon. Eve spoke at FB’s behest on the roundtable process that fed into those reports, and mentioned UMA and Consent Receipts.
John points out Omri Ben-Shahar’s research (he wrote a book called More Than You Wanted to Know: The Failure of Mandated Disclosure) purporting to show that privacy notices are pointless (he was doing a “point-counterpoint” talk with Lori Cranor). Mark contrasts this (?) with the Project IF work on “data licenses”, where it seems to matter.
On Tue-Wed of this week, Adrian attended the NIST Named Data Networking meeting. This work has significant privacy implications. Relative to UMA, there was a mention of longitudinal health records. But he doesn’t expect movement on this soon.
PPR has its annual Health Privacy Summit. Remember: It’s free and streamed. Contact Adrian to get an invite!
New UMA Legal document deliverables: John did a draft outline of an “UMA Legal Primer”. Eve has her slide deck as a start for something like an “UMA Legal Use Cases” document. What should the real names of these documents mean? “Legal” comes after something like “Business”, “Strategic”, “Real-Life”, etc.
The use cases are ideally tackled in a fashion that doesn’t introduce UMA terminology, at least at first. They can introduce UMA terminology as a mapping exercise in a second chapter or something, or even point to the other document.
What real-life digital resources should we use for examples in the use cases? Health data is a very real example, but how much should we use this? There’s a sense that we should either spread the examples around, or be cautious/aware about using health examples because of its specialty characteristics.
We could introduce RACI mappings once we come out of the “UMA technical” term explanations into the “data *” mappings. Kathleen notes that when we have a 1yo (actually a minor who is legally incompetent but old enough to be aware) Johnny, he is legally incompetent to consent and thus may give assent vs. consent; this maps to “Resource Subject that is not at a Responsible level” or something. IOW, RACI is an imperfect system to map to (as we concluded previously). However, the point is that RACI maps well to “data *”. (John writes this part. :-D )
Further, mapping UMA-technical roles to data-* roles leaves a hole: the AS. It’s not a data-anything. This is the innovation of UMA.
The contract roles and relationships is the third plane. We should treat it on its own.
The goal of the UMA Model Clauses section would be melding the three dimensions all together. We should take a lightweight approach, point to a couple of illustrative clause samples, and in essence serve as clause documentation. We might need a subsection somewhere in this doc (not as a separate dimension/plane) for the UMA-legal definitions, to support the clause explanations.
Eve (John?) will import this into a GDoc for collaborative editing.
...