...
- Our budget request was accepted! Let's work out a timeline
- Work on RSO - ASO model clauses more – can we get to "beta" quality today?
- How are invitations to our April 15 meeting going?
Attending: Eve, Andrew, Ann, Adrian, Mark, Kathleen
Budget request accepted
The Kantara board has asked us for a cash flow timeline. Eve's estimate was that we could develop our requirements by early Q3, say no later than July, and identify a contractor by early-mid Q3, and ideally conclude the project by the end of Q3 (Sep). This gives us a forcing function to have a credible set of beta model text to work with by Q2. We seem to be able to accept this, even though there are some question marks.
AI: Eve: Reach out to our community of "legal eagle" participants to wake up active participation once again.
Realistic first beta review timelines
Is it realistic to invite anyone to our Apr 15 call? Are we ready with text? There are two parts to this: Can external parties attend, and do we have enough text/materials?
Adrian proposes that Kathleen is on the critical path here. Kathleen just wants to run a FHIR pilot based on our clauses! And doesn't see Andrew's use case as incompatible. What's most practical? Kathleen suggests that getting to the point of real clauses is really the most practical. The FHIR connectathon is in May. She would like to "XMLize" the clauses for that target. What actual language is being executed here (since XML is just the "punctuation", if you will), if FHIR has a place in the code for a Grantor etc.? It sounds like they are using UMA authorization servers to consume standardized policy expressions in XML (if not necessarily XACML) format, and this would map to the Grantor's wishes for sharing. This could come down to a particular set of trust relationships, and the question of whether it splits into "active" policies vs. things like consent receipts.
Our Grantor - RqP (Grantee?) trust relationship already mentions consent receipts, and we've already discussed how CRs need to be part of a workflow that shows the Grantor what it is they're consenting to (or proactively sharing/delegating or whatever, i.e. setting a policy/sharing preference), so we could already be in the ballpark here. FHIR is using its audit logging framework for this workflow.
Adrian had made a generic "NPE Release of Information Form 1" sample form a few months ago, and Kathleen observes that with a few additions this could be something like what FHIR needs. Adrian is intending this to be used by the RS/RSO for setting up phase 1 (that is perhaps a rathole for our purposes for today's agenda).
Eve shared a slide deck that runs through various design patterns for splitting the technical resource subject and legal Grantee roles. This deck now has some explanation on the first slide about how the technical UMA flow can stay the same, while the trust relationships and legal/contractual backing might vary significantly.
2016-04-01
- 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.
...