...
- Fridays, 8-9am PT
- Voice: Skype: +99051000000481 / US +1-805-309-2350 / international lines / web interface, code 178-2540#
- Screen sharing: http://join.me/findthomas – NOTE: do not use the join.me dial-in line
- UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
2016-10-21
- Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts
- Working through use cases per party in the transaction
Attending: Eve, John W, Ann
What is the scope of our work (in this subgroup)? The technical layer may or may not change, while the contractual and regulatory layers above may change surrounding it. Our effort to gather use cases is an attempt to literally scope our work for now. Think of this as a "V1" effort of the "UMA legal subgroup" (which perhaps needs a new name because "legal" is too specific?). The use cases are driven by business and influenced by the regulatory environment, and could be implemented with UMA and other technologies – e.g., consent receipts, user-submitted terms, JLINC's stuff, etc.
Eve's theory: We wanted to do draft model text by 1Q2016. 
But the need for some visible progress by 4Q2016 is getting acute. Evidence: The use case of "delegation of access rights" (think "power of attorney", or positive acceptance of access on behalf of the resource owner, or "I am accepting that you gave me rights to drive this connected car", or "this is a payment API and Alice gives Bob the right to spend money out of her account") keeps coming up. UMA the technical solution says nothing about the API semantics, but the contractual and maybe the regulatory layer (think Open Banking API and PSD2) may say a lot about this.
Also, there are some complementary technologies such as Token Exchange, which has an "act_as" semantic, which may have a role at the technical layer. Once upon a time, we had innovated the "Binding Obligations" approach, which enabled a mapping of the non-technical layers to the technical layer where there was a state change so that it's possible to capture that change as part of the chain of evidence (hey, with blockchain/DLT involved??). Sometimes there is no technical state change at the UMA level, but sometimes there is, e.g., a token expires or gets issued or something. And we can start to be more and more clever about that.
Keep in mind that "getting access" could mean getting a value of data, or getting access to a stream of data (e.g. Websocket), or getting access so as to insert or delete data. In the world that used to be, only control of "disclosure" mattered. But now, with UMA anyway, API publishers (RS's) are authoritative for what grain of access is possible, and ROs can control what scopes are handed out.
What are the constraints on Bob's behavior once he gets access as a "first-party" RqP?
- Bob is a completely free agent to use the access as he sees fit.
- Bob is legally or contractually constrained in how he uses the access.
- Bob is technically constrained in how he uses the access.
Eve attempts to make the case that there are fine gradations (referencing her as-yet unpublished permission model taxonomy!) among "ways he uses the access", e.g. onward sharing with third-party grantees such as Charlie, and using it for marketing purposes vs. essential business purposes. She owes the group/the world her taxonomy writeup already.
Look at last week's notes for the description of how UMA and a combination of other technologies could address the onward sharing proposition.
The "delegation of access rights" use case seems to be such a popular one that maybe we should highlight it in our interim publications.
What are the realistic options for Bob's use or disclosure of Alice's data he's been exposed to (in this specific case, vs. onward sharing)? "Information wants to be free", generally. To the extent that data is volatile, it loses value over time. To the extent that data is nonvolatile and valuable, helping Alice not to overshare will help, and leveraging wider ecosystems where the business model favors Alice's interests. Beyond that, only nontechnical methods of enforcement will need to be exploited to keep the Bobs in line.
2016-10-14
- Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts
- Working through use cases per party in the transaction – see last week's notes for the pattern
...
- If there is a narrow ecosystem where all users are using the same AS, it's very easy to manage this, because the (singular) AS can keep track, and then you (the RS that publishes APIs) could theoretically invent something like a "no re-sharing" scope on your APIs and then let people set this when they share. (Think of Google Apps's similar "Advanced" feature.) Such a scope, if that's the right place to put it, maybe could be a standard "best practice" scope in various APIs.
- In a medium or wide ecosystem, where everyone uses (say) a different AS, John points out that Alice could at least monitor sharing through a ledger mechanism (he can send the diagram to the group), but you'd need something like encryption or DRM technology above UMA to actually control the re-sharing. John mentions J-LINC JLINC and Sal mentions COALA.
AI: Eve: If feasible, approach Scott D about the possibility of more focused work to complete our use cases and terminology and analysis around DS/DP/DC.
...