[WG-UMA] Notes from UMA legal subgroup telecon 2015-10-09
eve at xmlgrrl.com
Fri Oct 9 11:11:55 CDT 2015
Fri Oct 9 8-9am PT
Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540#
Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me <http://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 <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 <https://docs.google.com/document/d/1IvuencOdrtShE6FCIu9v5eTO3Qjl4i1JnaDnCXC47uc/edit?usp=sharing>” 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 <http://new.commonaccord.org/index.php?action=list&file=GHx/KantaraInitiative/ROI/Simple/Demo/> 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 at gmail.com <mailto:xmlgrrl at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the WG-UMA