Page Comparison

• 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.