Standing agenda for 2019: Work on producing our second legal-business framework report by September, initially focusing the work on use cases that illustrate each of our mappings from business relationships (and changes in those relationships) to UMA technical artifacts.
...
- Business-Legal Framework and Use Cases (GDoc)
- Mapping Graphics (GSlides)
- Legal Role Definitions (GSlides)
- Definitions and Use Cases Spreadsheet (GSheet)
2020-01-28
Attending: Eve, Domenico, Colin, Tim, Lisa
This is the last time we'll be meeting at this hour where it's the "biz-legal call". We'll see what the results of the Doodle poll are in terms of a new hour. Please fill out that poll!
Tim likes that the Guardianship paper really wrestles with the temporal dynamics of guardianship. Tim had introduced the concept of "diachronic" issues in our work on the first Report, though it looks like the word itself didn't survive the editing process through to the final version. These aspects reflect (literal) life cycle changes that traditional IAM typically handles through workflow approvals and the like. Colin would have liked to see a reflection of existing work. Likely people are not fully understanding both UMA and OAuth, both of which handle delegation of authorization in some subtle ways. We need to make this really easy to understand with some demos.
The very first step in a Me2B relationship, delegating a guardian – or other RRA (resource rights administrator) – relationship, is not yet today interoperable in an OAuth or UMA world. Does profiling OAuth with a claim representing this semantic make sense?
We looked at the original NZ POC case study to see if it had any examples of guardianship or interesting delegation. The Aroha/Bailey use case is about "classic" delegation of access, though it includes mobile notifications of IoT data, which is nice. The ministry of education/picking up kids use case is about chaining delegation.
At Kantara we produce reports and specifications. We could analyze the use cases covered by the paper; our BLT work address guardianship along with various non-guardianship delegation use cases between data subjects and RRAs. UMA's architecture and Sovrin's architecture are pretty different. However, Identos has created an extension that seems to be potentially valuable in privacy-enhancing an UMA AS in an SSI-ish context, and Adrian and his cohorts have integrated uPort for providing RqP verifiable claims. We'd like to get a broader shared understanding in the group about these options.
2020-01-21
Attending: Eve, Andi, Domenico, Lisa, Nancy, Tim, Colin
Through her colleagues, Eve recently came upon the work of the Sovrin Guardianship group (which overlaps in some respects with our biz-legal work) and the DIDauthz work (which references OAuth and UMA). Nancy brings up the FAST work in healthcare, which is trying to accelerate solutions to common challenges. What is the best way for us to accelerate our own work and goals, and how we can center on the end-user perspective (the "User" in UMA)? Lisa notes the DIDUX working group, given this desired perspective.
Tim notes the rationale stated in the paper on p. 9 for the guardianship work: "In short, carefully constructed guardianship is essential to SSI. Without it, SSI solutions will either tend towards centralisation or exclude billions of people." This is somewhat a weird way to think, in Eve's opinion, because it's constructed around the goal of digital identity (an "input metric") as opposed to what people actually want out of digital services (an "output metric"). If we don't get out of this mindset, we may not get to the point of being creative enough to solve the next generation of problems. Tim notes that the UN and the World Bank are saying that legal identity is a human right. (Though "legal identity" is not the same thing as "(a) digital identity".) She takes the sentiment of wanting to solve the thorny problem of "offline and online" mixes of people, though. Lisa suggests that we pull Adrian into an analysis. Eve thinks Justin could shed light too.
Eve is going to pare down our meetings so that we only meet on Tuesdays. She'll send a note to the list just to be sure this doesn't cause any heartburn for our voting participants.
Homework for next time: Everyone please study the paper and the use cases, paying particular attention to the terminology and concepts, and seeing if we have comments or could use some of them. Eve will look into her team's ability to develop demos of the use cases in the paper (or equivalent), on an UMA/OAuth basis and potentially SSI. Others are welcome to do that too.
We are meeting next Tuesday. No meeting on Feb 4 as Eve is traveling.
2020-01-07
Attending: Eve, Tim, Lisa, Domenico
Could UMA be additive as a solution to the human rights efforts such as in the UN? Digital human rights is a driving motivation for Lisa. Rights and corresponding responsibilities need to be ensconced in technology where possible. An old writeup about UMA implications of Privacy by Design principles (for which the tiny URL is http://tinyurl.com/umapbd) is probably a bit out of date but helpful on this score. Me2B recently did a small ethnographic study, discovering some interesting – if perhaps nominally obvious – things about surveillance and awareness about it. There is a faction among healthcare IT people saying that informed consent is literally impossible. This is akin to the qualia problem: you can't inspect someone else's brain to know what they know. If this is the case, and even given that "consent is stupid", it's better to assert permissions as proposed in the LeVasseur/Maler paper. If people won't even read books now because their attention spans are shot in the modern era, then how can we expect them to read ToS? There's a Japanese word for the pile of books you have but haven't read, tsundoku, and now we have the digital version too.
To bring the news about what UMA can solve and how it can support "IRM" challenges, we want to publish the material we've put together in smaller bites, possibly in blog posts.
We talked a bit about the JLINC protocol, which can be found here.
2019-12-17
Attending: Eve, Cigdem, Domenico, Lisa, Colin
Note that we did rename (renumber) the states, so that the "little Johnny" use case is now State 2 because it's the next most common.
Domenico shared a great new non-tabular graphic that is helping us think about what we really mean by the first four states. (See the wiki version of these notes for the graphic.)
In the "Mapping graphics" deck, Eve had put some comments about needing to see the DS-as-RRA aspect as donning a role, and Cigdem raised this as well. The states we've been talking about are at a pretty operational level, meaning they allow us to specify details of implementation such as role changes and provisioning/deprovisioning requirements that could built into compound workflows. We're likely to have to go to the level of tackling the "multiple Data Subjects" use cases.
In healthcare, you could commonly have state transitions like 2-4-1, or 2-4-2-1 as little Johnny has his mother added to manage his EHR, then his father, then grows up and starts managing his own resources. We actually map cradle-to-grave scenarios somewhat like this in the "Legal role definitions" deck.
How does one map three-dimensional values in two-dimensional space? You split out one of the dimensions to two flat ones, or you have multiple tables. Ugh.
We observe that adding and removing RRAs is a provisioning/deprovisioning action, and adjusting whether the DS is one of the RRAs is a role change action, what if we think of this as two different "tables" (maybe tables in a technical viewpoint, but potentially not for the document)? They're orthogonal actions, which could be built up to form a "workflow" that triggers when you need to move from one state to another, like when Johnny e.g. hits a certain age, or succeeds in asking the court to be emancipated from his parents, or when a couple divorces, or when a temperature sensor hits a certain temperature, etc.
There can be harder edge cases for what to do around, say, historical bank account data vs. new data going forward in the case of multiple-down-to-single bank account data. What do banks do today? Do they close the joint account and open a new single-owner account for the newly divorced person?
Lisa shared a great "IRL mapping sketch" that is inspiring us to add a graphical version of the "typical use case" to the doc.
2019-12-10
Attending: Eve, Andi, Cigdem, Tim, Colin, Mark, Nancy
Lisa and Eve subsequently discussed the intro section and Eve did some more editing of it. This led her to bring up a few more legal party terminology and definition questions. It looks like we can remove the "Individual or Legal Person" phrases where they occur currently in the definitions of RRA and RqP. Let's do that. (Eve edited this live on the call, in both the canonical spreadsheet version and in the report.)
We discussed the question of Requesting Agent/Requesting Party. Tim made the excellent point that, until we hear that the outside world has a problem with the terms, we probably don't want to obsess any more about it. We could change it later if it turns out to present friction. We acknowledge that "agent" is a very different thing in the legal and technical worlds. Capitalized words are used in their legal party senses and we say that in the report, so legal experts and similar should be prepared to understand such terms in their legal senses.
We discussed whether to cram mentions of "agency contract" and "access contract" into the pentagram diagram (new nickname!). Should we do "progressive disclosure" in the document and have a version that has just the dashed pentagram, possibly with the agency and access contract wording added, and then a version with the delegation and license details added? If he is willing, let's ask Domenico to create a short series of diagrams.
AI: Eve/Domenico: Eve to ask Domenico to create several pentagrams (these are all additive):
- One with just the dashed pentagram lines and agency contract/access contract labels (as illustrated on the old "spaghetti" diagram on slide 7 here) – delegation/licensing relationship arrows removed
- One with all the delegation/licensing relationship arrows added back, as currently exist in the diagram
- One with a "spur on the left side with Data Subject-to-RRA relationship arrows added (as illustrated on the left side of slide 9 here)
- One with a "spur" on the right side with a Requesting Party-to-Requesting Agent arrow added (as illustrated on the right side of slide 9 here)
AI: Eve/Domenico: Eve to ask Domenico to create two table-oriented "state" diagrams (slides 3 and 4 here):
- One without arrows
- One to reflect the state changes with the arrows
2019-12-03
Attending: Eve, Domenico, Lisa, Nancy (regrets: Tim)
Lisa's and Eve's "Beyond Consent" article is now in a near-final version; Lisa kindly agreed (when asked by Eve) to distribute this version to the UMA WG.
Consensus: We looked at the Typical Use Case section of the doc and concluded that we do like having the "typical use case" for technical roles presented, followed by the formal definitions of said roles. Let's also plan to publish the spreadsheet as a companion Report because it can serve as the "source of truth" of definitions and relationships. We can prepare an Annex or Appendix or whatever we want to call it in this Report that consists of tables, along with a citation to the spreadsheet that has "live" data. We can say "In case of any discrepancy, the spreadsheet has the most accurate data" etc.
Assumption: We note here – but don't want to note in the Report, because it would complicate things for the readers – that EHR data typically gets selectively copied to a portal, and doesn't "live" there. If we elucidated all of our assumptions and caveats in the "typical use case", we'd never get anywhere. Nancy is clarifying for our group exactly how SMEs would split hairs on primary storage of health data. We agree that our audience will be motivated simply to understand the UMA paradigm at a relatively high level at this stage.
Lisa asks (paraphrased): When we say the resource owner "manages" resources at the RS and "controls" access at the AS, is she doing that at an app of some sort? Why are we saying Alice is interacting directly with services here and not apps? She does use apps, but we don't talk about them in protocol-related conversations because those interactions aren't "on the wire"; there are no UMA-dictated messages involved. However, those who deploy UMA-enabled systems do have to concern themselves with the implementation and deployment of such apps! Eve's recent webinar with Steve Giovannetti covered the four elements of integration and deployment needed:
- Deploy an AS. We have noted many times that policy engine functionality is something each AS can compete on because it lets ROs get more sophistication in policy-setting ability. However, often in healthcare use case conversations, the idea of policy interoperability comes up too.
- Integrate/create your client app (if you already have a client, you have to UMA-enable it) – is there room for creating "UMAlet" middleware? Gluu has talked about its open-source middleware in the past.
- Deploy your RS (if you already have RS apps, you need to UMA-enable them) – there are a couple of different approaches, gateway/proxy (could be in the cloud) and an SDK for UMA-enabling apps. The former seems preferred. Eve calls these "protectlets"
. - Encourage data partners to implement their own RS's – if you have a wide data ecosystem (i.e., multiple RS's in different domains), your partners will have to UMA-enable their hosts. Helping them do this is good business! See just above. Nancy notes that Patient Centric Solutions' new PatientShare offering does exactly this.
This whole list opens up the idea of publishing an auxiliary document called something like an UMA Deployment Guide and stimulating open source (once more) to encourage deployments.
Proposal: Lisa suggests that, since the Operators are extremely likely to be Legal Persons, we should acknowledge the obvious and enhance the formal definitions in the document somehow so that it won't trip up people who read them there. Maybe we can insert some bracketed text and/or italicize some? She will draft some candidate text and let's discuss it on the list. There are so many considerations around this question – rhetorical, UMA maturity, etc., that it's not even funny.
Domenico comments on the concept of a "data ecosystem". We've been talking about wide ecosystems for a while, but it seems there are different kinds of wide ecosystems. Lisa says: "UMA is an ecosystem builder." Nice! Eve has often called OAuth2 a protocol framework because it has so many choices that it's not just one protocol; unfortunately that has risked interoperability and security. XYZ is trying to enable protocol-building without all those sacrifices. UMA is meant to make it possible to build data – and data-sharing – ecosystems without sacrifices and compromises.
2019-11-05
Attending: Eve, Nancy, Tim (regrets: Cigdem, Andi)
...
- Agreement that turns a service provider into an RSO (wasn't included in business model report)
- Agreement that turns a service (or app) provider into a CO (wasn't included in business model report)
- Agreement that enables a Person to act on behalf of a Data Subject [which puts them into position to act as a Resource Owner -- otherwise RO=DS]
- Agreement(s) that delegates authorization for an ASO to grant access permissions on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement(s) that delegates authorization for an RSO to manage resources on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement that enables a Person to act on behalf of a Requesting Party [which puts them into position to act as a Requesting Party Agent -- otherwise RqPA=RqP]
- Agreement that delegates access seeking to a CO on behalf of a Requesting Party
- Agreement that delegates permission to know and persist personal data to an ASO on behalf of a Requesting Party
Jim H has started on a CmA version of the model.
...
Arrgh, so close! Tim and Eve will try and wrap up all the remaining comments in the doc by Monday and get the e-ballot out.
2018-01-12
Attending: Eve, Colin, Tim
...