RO = Data Subject
RS = Controller, Processor AND Subprocessor (AKA Exporter/Importer)
AS = NOBODY yet, which is why the Data Subject’s rights are all third party beneficiary rights. But an AS would authorize sharing with RS’s offering model clauses or modifications thereto. Which is why UMA can now extend EU privacy to people around the world (a lot of bridges, if that was what Scott meant when I was passed out).
D’Accord?
Jon Neiditz
Kilpatrick Townsend & Stockton LLP
Suite 2800 | 1100 Peachtree Street NE | Atlanta, GA 30309-4528
office 404 815 6004 | cell 678-427-7809 | fax 770 234 6341
jneiditz@kilpatricktownsend.com | My Profile | vCard
From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of James Hazard
Sent: Saturday, October 10, 2015 6:07 AM
To: Eve Maler
Cc: wg-uma@kantarainitiative.org UMA
Subject: Re: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-09
The Demo (EU-US Model Clauses) now makes reference to ~standardized~ security regimes. That might be a place to specify best practices.
(Click on "Document", look for the orange and magenta text near the end in Appendix 1)
On Sat, Oct 10, 2015 at 7:01 AM, James Hazard <jh@hazardj.com> wrote:
Eve,
That seems right. The Model Clauses have the virtue of being a big bridge, as Scott discussed. Bridging the Atlantic.
Here is a demo for a fictive French sub of a US company, transferring to headquarters. I remain a non-expert in the field, so the completions are whatever came to mind.
Jim
On Fri, Oct 9, 2015 at 9:51 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Thanks for this, Jim!
The Model Clauses seem very useful because:
- They assume data transfer to countries without an (I assume WP29) “Adequate” level of protection (so it’s a “worst case”)
- They define terms around parties that “touch” data about subjects, in a six-degrees-of-separation way
- They help the data subject handle/enforce liability in case of changes in business relationships among the "data touchers” over time
- They have some relevance to all of our meta-use cases because (I think) we could map them to RO-RqP, RO-AS, and RS-AS relationships
I’m assuming RO = data subject. Is that fair? Note that when an UMA “protected resource” could be broader than or different from EU-defined personal data, but there will be many important cases where an UMA protected resource is, or includes, personal data. Examples, counterexamples, and weird examples:
- RO = an individual, and PR = an identity attribute (obvious personal data)
- RO = an individual, and PR = an uploaded photo of a pastoral scene taken by the RO (maybe the photo’s digital metadata reveals personal data or maybe it doesn’t; the subject of the photo is not the RO and has no faces in it)
- RO = an organization rather than a human, and PR = corporate IP (no personal data, though it’s valuable and sensitive)
- RO = an individual or organization, and PR = an API endpoint for using an RO-developed algorithm for which the RO wants to charge RqPs a fee (no personal data, though it’s valuable and possibly sensitive if it’s, say, patented or a trade secret)
Eve
On 9 Oct 2015, at 7:28 PM, James Hazard <jh@hazardj.com> wrote:
As we map out a source-based approach to the text of personal information transfers EU->US, I presume that the Model Clauses are important. Here I've begun the process of automating one of the sets.
They are not yet automated, so won't render into a form (I'll get to that as _v0.md, then when it seems solid, freeze it as _v01.md). Please let me know if (i) this seems relevant, (ii) the URL seems ok (mirrors the source), (iii) other.
On Fri, Oct 9, 2015 at 6:11 PM, Eve Maler <eve@xmlgrrl.com> wrote:
· Fri Oct 9 8-9am PT
· Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines), room code 178-2540#
· Screen sharing: http://join.me/findthomas - NOTE: IGNORE the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line)
· UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
- How have we done on our next steps?
- Everyone please contribute “mile-wide, inch-deep examples on contract terms examples across all three meta-use cases — at least one of each kind (IT’S NOT TOO LATE! :-) )
- Jim H walks through his Common Accord structure and examples to help us capture our examples and understand all of his
Attending: Eve, Andrew Hughes, Steve, Adrian, Mark, Tim, Jim, Jon, Dazza, Ann, Scott, Mary Hodder
Jim and Adrian have sent out a putative “Simplest Possible UMA Contract” document that structures a healthcare Release of Information form along the lines of an “imagined UMA” that does things that UMA today doesn’t do (as Adrian cautions, don’t get caught up in the technicalities). It uses the CommonAccord framework/data model for a mapping to the Restatement of Agency work that Adrian and Eve had attempted previously.
Which meta-use case(s), if any, does this text address? It seems like it’s about RS-AS; we talked about it last time. There’s been some discussion about herd immunity, where some parties engage in selfish behavior, and if enough of them do, then other free riders can benefit such that the aggregate risk reduction ends up having selfless aspects (Scott’s “stopping at red lights” example). There can be a “tragedy of the commons” problem if there’s over-engagement in the behavior that doesn’t confer herd immunity. So the desirable behavior that weighs on the side of risk reduction has got to be valuable in and of itself often enough. The incentives have to be high enough. Put another way, as seen as is being sought with certification programs, UMA adoption should be able to drive "network effects”.
The idea is that similarity of bankruptcy clause, notice clause, etc. is what gives the aggregate value. It’s “legal interoperability”. Jim’s work lets us slice and dice contracts.
We drilled down on the RO-RS portion of the text, which leads to the CommonAccord framework portions that modularly lead to constructed contracts. E.g., RO Alice has this first name and this last name, and live in Dallas. Dallas, of course, is in a particular jurisdiction. Different jurisdictions have wildly different implications.
The way the framework works, the “Source" is hosted on GitHub, and Jim’s site pulls it in. It can be “Edit”ed right there. The “Document” view dereferences the pointers in the source. Jim got into doing this through the “smart contracts” path in a blockchain context, though this is not technically an instance of that.
Knowing that the latest Safe Harbor news has upset the current ecosystem, it appears there may be an appetite to restate the requirements in a new way. Suddenly some parties may not be well served by the way legal text is handled in the current system.
With consent receipts in the picture, does it make sense to have a CommonAccord way to capture agreements and receipts? This may indeed be productive. Effectively, GitHub can be the audit log. And then, of course, the logs have to be mutually available to the parties, nonrepudiable, and tamper-proof. Blockchain technology could come into play here. An escrow agent role can make sense (again, blockchain is relevant here).
There’s a larger ecosystem of contracts management and vendor management in which (e.g.) hospitals already have to operate, so whether UMA is used or not, a system like this one could be relevant if it lowers cost and friction. But then if UMA uses it, it becomes more attractive.
Thinking of blockchain as a ledger, the ledger is not the actual money. A ledger has a separate value that can be measured and acquired.
What sorts of deliverables should we consider producing? Some options…
- Previously produced: Auditable junctures in the protocol (the UMA “state changes” to which we attached some clauses in Binding Obs)
- Previously produced: An indivisible set of “axiomatic” clauses we thought deployers of UMA should adopt (the Binding Obs clauses - dependent on #1)
- Future option: Specific auditable junctures that should have consent receipts attached to them (build on #1?)
- Future option: CommonAccord-expressed consent receipts
- Future option: Recommendations about how to literally store and manage these consent receipts in CommonAccord (build on #4?)
- Future option: Recommendations about specific language that meets our meta-use cases and business models
The EU has model clauses. Could we build on those? The “boring approach” is to get agreement on the things that matter the least. It won’t solve our problems, but it starts to build a solution and gets some success.
AI: Jim, Eve (and invite Jon and Dazza and Steve): Whip up some model clause thinking for the subgroup next week. Eve to send an invite for a midweek ad hoc to do preparatory work.
AI: Adrian, Eve: Document the delta between the UMA-that-is and the UMA-that-is-posited by this new doc.
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
Confidentiality Notice:
This communication constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. Section 2510, and its disclosure is strictly limited to the recipient intended by the sender of this message. This transmission, and any attachments, may contain confidential attorney-client privileged information and attorney work product. If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Please contact us immediately by return e-mail or at 404 815 6500, and destroy the original transmission and its attachments without reading or saving in any manner.
***DISCLAIMER*** Per Treasury Department Circular 230: Any U.S. federal tax advice contained in this communication (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.
