Page Comparison

• Review IIW and EIC discussions – progress around RSO-ASO as an "agent"
• Upcoming Digital Contracts conference with opportunity to gather requirements for CommonAccord IDE and feedback on our work
• Reality check on model clause process – definitions seem a lot easier, vs. clauses without a "live" agreement to work towards

Attending: ...

• 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 ("worse"?). 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.