...
- 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.
2016-05-27
- Review Digital Contracts event
- DG
- CommonAccord directions
- Legal POC appetite
- ...
- IDE directions
- Model definitions: next steps
Attending: Eve, John W, Adrian, Ann, Jon N (Andrew regrets)
Adrian is on the FHIR group, along with Kathleen. The conversation at that table around "policies on the wire" is very live there. The motivation to source policies from multiple places in the FHIR conversation seems to be internal to a single domain.
Given our capturing of notes last week, we'd like to write a short document for a nontechnical, legally inclined, even regulatorily inclined audience. John has stuck his hand up to outline such a doc, and he and Eve can review the results together at Privacy@Scale (run by FB) next Tuesday. (Microsoft is running a similar event the next day, NIST is running a Named Data Networking event on May 31-Jun 1, and there's a Health Privacy Summit at Georgetown Law June 7-8, and it will be streamed.)
Looking at it from a business/strategic point of view, the benefits are privacy-preserving because no authorization/permission policy transmission is needed, and the AS is not a data controller, and individual/patient/consumer/citizen-centric because the AS exists to enable that party's wishes (their "agent" in some fashion). Looking at it from a legal point of view, we are working on a system of model text to protect the interests of all the parties engaging with each other.
(As we said last week, if an institution running that domain wants to federate policies in some fashion a la the methods that XACML makes available, they're free to, behind the "UMA façade" of the standardized APIs of AS. If it turns out to be valuable to develop a companion technical paper that answers questions that technical people have about the architecture that supports our contentions, we could write that afterwards.)
It seems like we really need a proper use case document now too, identifying why and how the parties might be equivalent or not equivalent (note that in UC4, "offlice Alice/gov agency", the Grantor happens to be the ASO, but in UC1-3, it's not). We need more use cases showing how the Grantor could equal the Grantee, the Grantee could not equal the human end user that is acting on behalf of the Grantee (like Dr. Bob working for the hospital that wants access), etc. Once we have a full, non-repeating set of use cases, we'll know we're close to being done with the model term definitions. 
Eve's interested to coauthor; John W's tentatively interested to coauthor; Jon N's interested to review.
There's a new Kantara Blockchain and Smart Contracts Discussion Group – feel free to join!
Note that the actual original EU Model Clauses are under threat. But we seem to be happy with the lowercase phrase for our work, still.
We should have a CHEDDAR rundown on a future call.
...