...
- Work on RSO - ASO model clauses
- Decide external review strategy
Attending: Eve, Andrew, Adrian, Kathleen, Thomas, Jim
We discussed the candidate model clauses for RSO - ASO.
What is a resource set description vs. a scope description vs. a resource vs. a scope etc.? Should we be really specific, the way a technical spec – or legal document – would expect, and define every little term? A resource set description being registered is a set of metadata about an actual digital data resource of Alice's that is being put under the AS's protection (in other words, the data itself is not uploaded), and the scope description(s) that are part of that metadata are descriptors of the potential extents of access that are possible to be performed over that resource – not actual entitlements that some requesting party has "won". One metaphor is that a resource set is a "noun" and a scope is a "verb" (among some set of verbs) that is possible as an action on that noun. Another metaphor is that the scopes are the definition of the contract, or interface, for that resource. In effect, the scopes define the "API" for the resource. Note that since RS gets to choose how to split up its design of resources and scopes, and the design line between them is moveable.
subj - verb - object (crude representation of an authorization policy)
RO - RSO - RSO (who's authoritative for each piece)
ASO (authoritative for executing the whole thing)
Adrian's concept of "I split, you choose" means that the RSO gets to be authoritative for that digital data resources and the APIs presented for exposing them. UMA has innovated around enabling the RS outsourcing the function of letting the RO be authoritative for associating the "verb and object" part of a policy with the desired subject, and then letting the AS execute the RO's wishes. This is through a combination of resource set registration and then the rest of the UMA flow.
Do we have a chicken/egg problem in terms of the relationships? What if there are two independent relationship streams leading up to the three-way PAT relationship?
- Trust relationship 1: Grantor - RSO (no technical artifact)
- Trust relationship 2: Grantor - ASO (no technical artifact)
- Trust relationship 3: RSO - ASO (technical artifact is OAuth client credentials for the RS)
- Trust relationship 4, dependent on the previous three: Grantor - RSO - ASO (technical artifact is a PAT, carrying user consent)
(The numbers where there are no preconditions are arbitrary – they're just for easy reference.) There may be cases where the conditions are variable. Eve was concerned about our two-party "atomic" approach previously because a PAT inherently has three entities involved, and it naturally maps to three parties; likewise, an AAT. Her suspicion is that some of our duties may have to "go there" in mentioning three parties, and that this isn't a variable thing: the clauses will have to do that.
Adrian asks: Is it valuable for trust relationships 3 and 4 to have different model clauses? In other words, would the RSO and ASO ever want to contract with each other separate from the context of any specific individual? Eve made the case that some sort of blanket protection against liability, in both directions, makes sense regardless of the particular resource owner. Kathleen mentions market forces as pressuring ASOs and RSOs variously on this point. Also, regarding #ROctrl, that's going to have to be fought out in trust relationship #1, not trust relationship #3; the ASO is more likely going to want to say "Listen, I'm going to put stuff in the token, and if you do something else, I wash my hands of you."
Regarding external review, Andrew would like to point some DIACC members to our model definitions.
AI: Everyone: Reach out to external reviewers and offer to hold a live review session on Apr 15 and see who can attend. Eve to send a reminder of what this is all about in email.
Let's also plan a live review at IIW, by which time we'll have more model text.
2016-03-25
- Work on RSO - ASO model clauses
- 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.
...