...
- 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 | Existing nonfunctional requirements | In scope? | (Candidate names of agreements formed out of our official clauses) | Technical artifact | Discussion | |||
|---|---|---|---|---|---|---|---|---|
| Resource Subject - Grantor (if they are different) | n/a | No | n/a | n/a | Do we need to name out-of-scope trust relationships, even if "lowercase" for discussion? | 2|||
| RSO - ASO | n/a | Yes | Protection API client agreement? | Client credentials | ||||
| 3 | Grantor - ASO | n/a | Yes? | Authorization services agreement? | 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? 4We agreed there are definitely reasons to have UMA-specific clauses, looking at our draft ones. | ||
| Grantor - RSO (dependent on #2, | RSO - ASO) | Yes | Resource protection agreement? | PAT (dependent on having client credentials) | 5 | 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? | Client credentials | We have not scrutinized the definition of Client Operator. Let's put a pin in that to be sure it's okay.6 | |||
| "RqP" - Client Operator | n/a | No | n/a | n/a | We need to work on the term for "RqP". Let's put a pin in that. | |||
| 7 | "RqP" - ASO(dependent on #5, CO | Client Operator - ASO) | Yes | Resource authorization agreement? | AAT (dependent on having client credentials) | |||
| 8 | Grantor - "RqP" (dependent on all of the above)Grantor - "RqP" | Resource Subject - Grantor, RSO - ASO, Grantor - ASO, Grantor - RSO, Client Operator - ASO, "RqP" - Client Operator, "RqP" - ASO, Grantor - "RqP" | ??? | Resource sharing agreement ?Resource access agreement ? | Claims subprotocol | 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? |
...