...
- Accountability (data controller) vs. responsibility (data processor) in relation to the data subject (this topic came up at our UMA Legal IIW session)
- Terminology: the next generation – can we tackle Grantee subtleties next?
- What is the right structure for UMA Legal work and review? (this topic came up at our UMA Legal IIW session)
Attending: Eve, John W, Adrian, Jon N, Mary, Dazza, Ann
RACI charts map the responsible/accountable/consulted/informed split. We discussed at IIW22 how the accountable body, the data controller, would typically outsource to a third party, the data processor, some work. It's optional to outsource. Would could it possibly mean if Alice really runs her own AS (she's the ASO) and her own RS (she's the RSO)? Could the AS be viewed as a DP in any sense? We recognize that conceiving of the DS as a DC is really novel. The IIW microservices conversation is relevant to this because micro-level service conversations that go cross-domain don't yet have a "legal model" of personal data flow.
Each RS seems naturally to be a DC. Okay, but what about the case where you have APIs that allow clients to put data back in to the service? E.g., if the API presents a POST-based call that lets a multitude of clients send various kinds of PII-bearing data to the service for safekeeping? A cloud file system is a great example; there are lots of third-party GDrive clients. Maybe there's some split of DC and DP roles among resource servers and clients for any one API, determinable by their contractual trust relationships. We didn't even list RSO - Client Operator as one of our trust relationships below, because so it's clearly out of our scope.
An important note: Alice's interactions (in whatever technical or legal role) with the AS and RS are actually out of band; there are no UMA messaging arrows there. There's only "contractual" (or role?) and "regulatory" reality.
John W is suggesting that we have two diagrams of UC1 (etc.), the current one and a new one that carries an analysis of how the DS, DC, and DP roles might map onto our roles.
Jim and Thomas have an opportunity, if they wish, to bring it up at the GLTL MIT event they're attending next week. The exercise would be to map the flows of information represented in the use cases to the delegation of authority and responsibility represented by the model of authority and responsibility in the GDPR.
Is the AS even anything in this system? Maybe nothing; it's novel. Jon N believes it doesn't add anything and could make things work. UMA brings something new, and the problem is of consent. The AS, in GDPR terms, must stand in for the DS, and the critical problem is that it may be difficult to make the case for this important role given the regulatory regime that never imagined this role. The AS needs to be the DS's "agent"! How can we achieve this? Let's seriously consider outreach on this score as part of our remit.
Watch out for missing meetings in our schedule.
2016-04-15
- Grantee and Resource definitions; how to handle role stacking (Grantor can be Resource Subject, RSO can be ASO, etc.) – handle in a generic way? (see this thread)
- (Based on input from Scott D.) RSO - ASO model clauses (original proposal):
- How to parameterize to enable different legal models for handling the granting of "access"?
- How to identify/parameterize to enable exceptions to normal access/non-access? (see decision tree)
- How to handle notification requirements?
Attending: Eve, Ann, Adrian, Jim, Kathleen, Mark
Adrian's idea for an IIW session: UMA and GDPR.
Do our model clauses actually want to be broad enough to serve the use cases for things like the enterprise as a resource owner/Grantor? So far, we do have a definition of Grantor etc. that admits a Legal Person (e.g. an enterprise or government agency or whatever).
HL7's definition of grantor: "An individual who agrees to confer certain rights or authority to a grantee." A grantee is: An individual who accepts certain rights or authority from a grantor." The various ISO and EU standards discuss collection, access, use, and disclosure. Unfortunately, they didn't think of the case where API access is about other HTTP verbs than GET 
, where the client might be putting data for which it's authoritative back into the server, or whatever; in these cases, collection, use, and disclosure could sort of be reversed. This is why "access" so often carries the burden for the other three.
Jim believes: "A goal might be to create text handles for each of the foreseeable circumstances. So, a complete vocabulary seems better to me." So shall we define the full set, then? We would theoretically know when to use which phrase (potential vs. real) in each clause. After all, the "potential Grantee" doesn't have consent, right? Why conflate?
What about carefully staying away from applying a specific legal theory to underlie the agreement (e.g. license)? We've already put out of scope the different agreement life cycle templates; Jim has done a ton of work on this in CommonAccord. (Kathleen is interested to learn about this so she can apply them in status definitions in the HL7 contract work!) Essentially, we think staying away from picking normative legal contexts, including workflows, is still out of scope, so wherever this might "intrude" on our clause text, we'll need to figure out how to parameterize the text.
Next time without fail: Let's focus on the #RSctrl clauses needed (which may be part of the RSO - ASO trust relationship and also part of the RSO - Grantor (Potential Grantor?) relationship). See the Jan 15 notes for four use cases, and also realize that we have to take into account a fifth use case of "requested access outside of normal UMA mechanisms".
We discussed the GA4GH work on "ADA-M"; they're developing what look like model clauses for the sharing of genome data.
...