https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note... 2017-09-29 Attending: Eve, Tim, John, Bjorn, Mark Agenda: - What work remains for us to have a complete legal framework? - Getting ready to develop one key set of tools: model clauses / standard contractual clauses (discussed here: http://ec.europa.eu/justice/data-protection/international-transfers/transfer... ) - Could we actually get ours preapproved? - Note controller-to-controller transfer vs. controller-to-processor transfer options, something we’ve discussed in the past Jim pointed out his "Accordified" GDPR text efforts: - DE/FR/NL/EN. (Spanish and Greek also available): http://www.commonaccord.org/index.php?action=list&file=Dx/Acme/09-EU-US-DataTransfer/ - E.g., English language version under hypothetical of a UK sub of a US company transfering data to US parent: http://www.commonaccord.org/index.php?action=xEdit&file=Dx/Acme/09-EU-US-DataTransfer/Acme_UK/0.md - Source: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32010D0087 What's the difference between BCRs (binding corporate rules) and model clauses/SCCs? A set of BCRs is a kind of contract that might have SCCs in it. BCRs are developed in an ~18-month process, and have to be approved in all the various jurisdictions where they apply. BCRs have a lot of upfront cost/time, but save the organization cost/time later. SCCs can also be preapproved, but then each contract overall doesn't have preapproval, so you haven't saved as much cost/time upfront. Is it viable for us as a WG or dot-org to seek preapproval of SCCs we write? Maybe we should ask the Art. 29 Working Party about this. This could be valuable for giving UMA/Kantara visibility at that level. *AI:* Eve: Discuss the proposition of generic preapproval of standardized SCCs with Colin and Andrew. ISO/IEC 29100 <https://www.iso.org/standard/45123.html> is the key privacy framework that defines the terms PII subject, PII controller, PII processor (etc.). (We are using Data Subject etc. in our UMA Definitions Annotated deliverable.) In Consent Receipt, they use PII Subject etc. and recommend parameterizing the language accordingly. We can literally parameterize the language in our SCCs to the extent that we capture our language in CommonAccord. GDPR seems like the most obvious target for our completion of the framework, since it's got the right world attention, deadline, etc. Key questions (which we've asked before): - Can the Data Subject truly serve as their own Data Controller in a permission granting interaction? (Karsten Kinast has said yes before, at least philosophically.) Mark calls this a Master Controller Access Framework. - If yes, does it make sense for our use cases for end-to-end licensing relationships <https://docs.google.com/a/meshfire.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS7wSfzDjU/edit?usp=sharing> to split out to make the requesting party (and client operator?) become either a) another Data Controller, or b) a Data Processor? Also see the new slide diagram <http://Merging RO-RSO, RO-ASO, and RO-RSO-ASO relationship train tracks> "Merging RO-RSO, RO-ASO, and RO-RSO-ASO relationship train tracks". This shows how our legal framework would work in terms of contract and licensing clause text dependencies. *AI:* Eve: Ask Domenico to take a look at the new diagram. A key theme of our work is to ensconce the twin to GDPR's (never-talked-about, Article 7) "right to withdraw consent at any time" – the right to consent, or not, at any time (vs. simply opting in or not!). The recitals of GDPR are infused with a data subject's rights but oftentimes regulators can't know what's possible in tech until they've seen it with their own eyes. UMA + consent receipts are powerful in this respect. *AI:* Tim: Think about revamping his magnum opus for Eve to "GDoc-ify". *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl