...
- Review current set of model definitions
- Choose first trust relationship to work on for model clauses
- Identify any model definition areas that need work given our choice
- Decide/confirm our plan for first round of external review
Attending: Eve, Paul, Kathleen, Adrian, Jon N, Ann, Jim
We reviewed our model text with model definitions, with recent changes.
What's the deal with the "D word" – delegation? If we qualify "delegation of what", then we can observe that there are several types, and we can map them to different trust relationships we have identified:
- Resource Subject - Grantor (not in scope): This enables a "resource owner" to find someone else to actively manage resource access for them at an AS.
- Grantor - ASO: This enables an always-on AS to be available to execute the wishes (policy conditions) of the Grantor.
- RqP - Client Operator (not in scope; also not previously discussed as a model definition...)
- Grantor - RqP
Discussion about Grantor - RqP: Adrian doesn't think this is an appropriate use of the word "delegation". Eve believes "that train has sailed". 
See, e.g., the NZ POC.
Regarding Adrian likes the distinction of "If you have a privacy policy, then there's an Operator involved; if you don't have a privacy policy, then you own it/wrote it." (It's personal to you and there's a 1:1 relationship between you and the software/service.)
We have a new party with responsibilities now in scope! It's the Client Operator.
Also, we're likely going to have to change references in the bodies of various model clauses from the Grantor to the Resource Subject, since the duty will be owed to the Resource Subject instead in a lot of cases.
Which trust relationship should we dig into first? For reasons of our #RSctrl/#ROctrl use case tension, and because it's the most "upstream" (no dependencies) trust relationship, let's start from RSO - ASO (see the clauses that start ASO... here and the clause that starts with RSO here – however, these are old and almost certainly don't reflect our latest discussion).
There's a use case that could help us interestingly when we get to working on Resource Subject- and Grantor-involved model clauses, but will need to take into account some out-of-band machinations because it engages precisely the Resource Subject - Grantor relationship: a "digital death" use case. Alice (as her own Grantor) shares some digital data resources with Bob. She wants to arrange for her lawyer to become her Grantor when she dies, so that Bob can continue to get access to those resources. In practice, because of what are known (really) as "time-to-live" strategies around credentials, tokens, and permissions inside tokens, the access that Bob enjoys to those resources is certain to get cut off at some point after Alice dies. Using a combination of business, legal, and (non-UMA – including digital contract) technical approaches, Alice's lawyer can replace Alice as the owner of those resources and ensure through the AS that Bob's access can continue or be restarted.
AI: Jim and Eve: Extract the two-party reworkings of the old model clauses for at least RSO - ASO and prepare for group review next week.
AI: Everyone: Think about and approach candidate external reviewers by next week.
2016-03-18
- External review and reviewers of our work at the Q1 mark
- Action items for the model definition editors regarding last week's consensus definitions
- In-scope and out-of-scope trust relationships and their names (see this thread and below)
- Disentangling meanings of "delegation" – do we need a group norm about terminology?
- How do we square the "Requesting Party"/Grantee/Potential Grantee circle?
Attending: Eve, Kathleen, John W, Sal, Ann (regrets from Adrian, Mark)
AI: Eve, Jim: Revise our CmA model definitions with new consensus definitions.
Eve's premise was that anything with an UMA technical artifact really has to be in scope, and a direct relationship with any service operator with an UMA-specific purpose for existing (namely the AS operator) seems plausible to be in scope.
Would it be useful to write an explanatory document for reviewers about these relationships?
Should we be naming the agreements at all? There will be multiple actual agreements, for example, at different phases, or for whatever reason. And (channeling Jim) there are literally different agreement/contract workflow phases such as offer, acceptance, etc., and different sides of the equation might be offering or whatever. And given that English is only our first target language and not our only one, perhaps it should be a principle of ours that we should name as few things as we can get away with, so as not to have "language skew". Since our ultimate deliverables are at the size of "clauses", we need not care (for purposes of discussing trust relationships) about the larger combinatorial things into which they're mixed. Jim has put together quite a few assembled agreements, contracts, offers, etc., and we might do the same with our clauses as exemplars, but in the main we expect they'll be non-normative. So we've saved the candidate names, but kept them non-normative.
We have established to our satisfaction that there is complete separation between the legal and technical work of UMA by demonstrating that a technically conforming deployment of UMA services could be out of compliance with the data protection laws of some jurisdiction. Our "Russian example" is apt here: A Russian Grantor cannot legally allow a non-Russian "Requesting Party" access to their own data.
The clauses need to set up the correct preconditions for a deployment of UMA that encourages a "race to the top" in a greater alignment of incentives among the parties and in behavior that is compliant to relevant nonfunctional requirements (such as regulations).
John notes: "Makes me think that we need something like: Authorizing Server Operator - Regulating Body: Allowed-To-Release"
| Trust relationship | Dependencies on existing nonfunctional requirements | In scope for model text work? | (Candidate names of agreements formed out of our official clauses) | Technical artifact | Dependencies on existing technical artifacts | Discussion |
|---|---|---|---|---|---|---|
| Resource Subject - Grantor (if they are different) | n/a | No | n/a | n/a | n/a | |
| RSO - ASO | n/a | Yes | Protection API client agreement | OAuth client credentials for RS | n/a | |
| Grantor - ASO | n/a | Yes | Authorization services agreement | n/a | n/a | This has no technical artifact in UMA, and therefore no exact or obvious moment of appearing "on stage" for our work. Does this have an impact on whether it is in scope based on the rationale above? We agreed there are definitely reasons to have UMA-specific clauses, looking at our draft ones. |
| Grantor - RSO | RSO - ASO | Yes | Resource protection agreement | PAT | OAuth client credentials for RS | It's awkward to have a two-party agreement resting on a PAT. There are plenty of agreements where there are multiple Persons in one of the roles, but we're not so sure about true three-role agreements. |
| Client Operator - ASO | n/a | Yes | Authorization API client agreement | OAuth client credentials for Client | n/a | We have not scrutinized the definition of Client Operator. Let's put a pin in that to be sure it's okay. |
| "RqP" - Client Operator | n/a | No | n/a | n/a | n/a | We need to work on the term for "RqP". Let's put a pin in that. |
| "RqP" - ASO | Client Operator - ASO | Yes | Resource authorization agreement | AAT | OAuth client credentials for Client | The same discussion about n-party agreements above applies here. |
| Grantor - "RqP" | Resource Subject - Grantor, RSO - ASO, Grantor - ASO, Grantor - RSO, Client Operator - ASO, "RqP" - Client Operator, "RqP" - ASO, Grantor - "RqP" | Yes? | Resource sharing agreement Resource access agreement | Trust elevation mechanism and specifically claims subprotocol | OAuth client credentials for RS, PAT, OAuth client credentials for Client, AAT | Could be in the form of a consent receipt, sent to a notification endpoint. Is this trust relationship too "dependent" to be in scope, or does the calculus work? More discussion is needed. |
...