...
- Fridays, 8-9am PT
- Screenshare and audio: http://join.me/findthomas
- UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
2017-07-21
Attending: Eve, Kathleen, Tim
We started looking at chart 6 (not sent in email). Tim would like to ensure that we get the pairwise (or more) relationships, legal devices, and artifacts locked down so that he can revise the definitions. The column mentioning "pairwise" should probably take that word out because some of the artifacts definitely represent more than two of the roles.
A license, versus a contract specifically, gives flexibility around number of parties and promises. It's about tracking permissions. Some permissions are given with some conditions. The license gets revoked if the conditions aren't kept. A license scales better than a contract as a legal mechanism. (Kathleen refers to the licensing model as essentially an authorization model.)
A DURSA (data use reciprocal service agreement), from healthcare, is an example of a surrounding contract that could be used to encompass the kind of license we're talking about. Many of the use cases we've collected – a nanny collecting kids from daycare, giving someone access to a connected car – show that there's a desire to ensure a contractual apportionment of liability across to a requesting party in addition to licensing.
If this were a contract, the RO Alice would be the offeror, the resource access permissions would be the consideration, and the RqP Bob would theoretically be the offeree – but where is the acceptance part? In the technical layer of UMA, Bob might not have acted positively at all to get access. His client software might have "pushed" claims about him without any action on his part, Alice's AS might issue a PCT to his client that represents claims previously collected and the client subsequently "pushes" that PCT back, but that happens silently. Does that constitute acceptance? Do we have to build that into our model clauses? Using a licensing model, RqP Bob doesn't have to accept, and any overarching contract layers could build that in only if they want to. Developing contractual-level tools is out of scope for us.
The term "access contract" came from UCITA law. Do we want to use it? It appears in the role definitions, but should we step back from it? Actually, this is between the RO and ASO. So it appears on the wrong line; it should be on the RS-ASO line, not RO-RSO. Or was it correct after all? Are the RSO and ASO both parties to the access contract? The RO becomes the licensor, and do the ASO and RSO both become the sub-licensors? It would be helpful, in the "Legal Relationship" column, to always state "so-and-so is the role for whom-downstream of what on behalf of whom-upstream". E.g., "RSO is sub-licensor on behalf of RO". Maybe we can even construct the columns so that each variable gets filled in, in order, to form a "sentence"?
The RO is at the "head" of the relationships. The RO owns the access rights. (In US healthcare, under federal law, a patient owns right of access.)
The ASO-CO artifact of OAuth client credentials is only related to that pairwise relationship (not to RqP BoB or to the PCT; this should be relegated to a separate row). It could be related to a contract, say, ToS. It's a potential place where conditions that are protective of Alice could go, e.g. to ensure that the client (later interacting with Bob, e.g. sharing Alice's data, storing Alice's data, etc.) acts in a way that is aligned with Alice's interests.
At the end of the day, the legal aspects have to match the UMA flows and artifacts exactly.
AI: Eve: Try to do an edited matrix in GSlides form for the group.
2017-07-07
Attending: Eve, Kathleen, John, Ann, Mark, Tim
...