...
- Fridays, 8-9am PT
- Screenshare and audio: http://join.me/findthomas
- UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
2017-05-05
- Reviewing draft deliverable #3
Attending: Eve, JimH, Tim, Adrian, JohnW
Peer-to-peer models and/vs. trust framework models, and potential impact on our eventual toolkits:
We had concluded last week that more "onesie-twosie" (peer-to-peer) contracts could be appropriate in many more circumstances than "trust frameworks". It takes a lot to push ecosystems over into a fairly expensive and static agreement-making process (as seen in identity trust frameworks vs. regular contracts), and as the BSC analysis showed, that often doesn't favor individuals anyway. A finer-grained process that reduces friction and achieves the goals of our subgroup would be helpful.
Jim points out that there can be a leveling aspect of one-to-many. In both 1:1 and 1:n cases, the key is creating efficiencies in the direction you want. This may speak to the kinds of tools that we'll want to develop next based on the legal framework that we develop first. John suggests that maybe we want to create "Binding Transactional Rules" as a kind of tool, analogously to Binding Corporate Rules that are intended to be static and 1:1 between enterprises. Nice! If they can be win-win, both friendly to business and friendly to the business's users, and also more dynamic, they could be successful.
Jim notes that the IACCM tries to move towards supply chain and infrastructure relationships. A master services agreement is a key framework artifact, with layers of parameters on top of that.
If we can add individuals to such relationships, and even allow for "one-night stand" relationships 
(that is, say, a single purchase or payment or access or whatever), then a way of standardizing terms that the individual insists on could feed into a contracting workflow such as this CommonAccord example. This is one UMA Legal toolkit use case: model clauses, at least for purposes of granting access to digital resources. Would reducing friction (cost) to using such tools be enough, in the absence of business-model incentives, to encourage a resource server to give a resource owner meaningful control?
Other use cases would be for others to develop their own legal toolkits, as HL7 is doing – described in the BSC report. (An UMA "technical" use case could be delegating access to such contracts.) A hash of a signed contract could be recorded on a blockchain.
The licensing model, completing deliverable #2, and "the three tokens":
How can licenses be converted into tokens? We have some urgency around figuring this out, given the regulatory situation – not just GDPR but PSD2 as well, and even the HL7/FHIR and perhaps DIACC/TFEC/PCTF work going on.
Would this be like a "reverse EULA"? Adrian's work with Patient Privacy Rights has revolved entirely around the license concept. The patient shouldn't ever have to see the CommonAccord details we've been looking at. If you look at Creative Commons, everything is given a name/nickname, which helps. And the User Submitted Terms work tries to do convenient bundling as well.
John describes "the tyranny of the default". There is great power in default settings. We can reduce friction/cost in "doing the right thing". Jim provides another MSA example where some default choices have been made.
We do have a call next week. Let's plan on reviewing a final (barring final amendments being suggestions) deliverable #2 on May 12. That call will have a hard stop so that the full WG can start meeting right afterwards.
2017-04-28
- Reviewing draft deliverable #3
- "Resource Regulator" role
...