Please see below for the meeting notes.
====
Many thanks to Dazza for his ministrations last week! What a team. We are unstoppable.
We only had Jon, Adrian, and myself as “legal subgroup regulars” on today’s WG call, so the following is an agenda but also a lot of context-setting...
An important topic came up that relates directly to our work here: the “wormhole” between the UMA Core spec and our ultimate deliverables, connecting “technical" to “legal”. There were two key wording changes:
#1: From this: "If the client's request at the protected resource has a valid RPT associated with sufficient authorization data as determined through RPT status checking (see Section 3.6), then assuming the resource server chooses to respond to the client, it MUST give access to the desired resource.” to this: "The client's presentation of a valid RPT associated with sufficient authorization data as determined through RPT status checking (see Section 3.6) indicates that the resource owner's policies have been met. The resource server MAY apply additional authorization controls when determining how to respond."
#2: From this: "The resource server MUST NOT give access where the token's status is not associated with sufficient authorization data for the attempted scope of access.” to this: "The resource server must not give access in the case of an invalid RPT or an RPT associated with insufficient authorization. To ensure the integrity of the ecosystem in which the resource server, authorization server, and resource owner are participating, it is STRONGLY RECOMMENDED for the parties to establish agreements about access rules in this case on a legal or contractual level. See Profiles and Trust Establishment for more information."
These both relate, essentially, to the RS’s natural reluctance to do what the AS/RO tell it to do. UMA’s entire purpose is to enable outsourcing of protection of resources. But UMA can’t actually make the RS do the protocol’s bidding if the RS has interests that aren’t well aligned with the others’. Don’t forget this, in the intro section:
Practical control of access among loosely coupled parties requires more than just messaging protocols. This specification defines only the "technical contract" between UMA-conforming entities. Work is ongoing to define recommendations for developing agreements about the rights and responsibilities of parties operating and using these entities on a contractual or legal level (see, for example, [UMA-obligations]). Parties operating entities that claim to be UMA-conforming should provide documentation of any rights and obligations between and among them, especially as they pertain to the concepts and clauses discussed in this companion specification."
It’s valuable to read the above in combination with Adrian’s new
analysis of the Restatement of Agency, which also includes notes from the both of us on deltas between UMA’s technical layer and what’s desired. Tomorrow, let’s tackle the items identified last week as our next steps, colored by the above:
- It was confirmed that the group should continue working through the HIPAA use cases
- As part of this, confirm/correct the non-experts’ analysis of the Restatement of Agency
- ...and review the “technical UMA healthcare safe harbor propositions”
- …on the assumption that these activities will be broadly valuable/applicable (based on the WG call’s discussion)
- It was evident participants want to further discuss the Apple Healthkit/Researchkit and so it will be included as a variation of the initial health information scenarios.
- Dazza will work with Adrian (and anyone else so inclided) to refactor the use case table scenarios into more detailed cross-functional process diagrams (aka swim lane diagrams) including agency law overlay (and possibly a first guess as to where contracts are formed, already exist or could be monkeyed with). When ready, a link to the diagrams in the wiki will be emailed to the list for everybody to hammer at or at least view them.
====
Attending: Eve, Adrian, Dazza, Mark, Jeff
Next steps: What’s the right thing to do — validate the non-legal experts’ understanding as expressed in the blue text in the “UMA as Restatement of Agency” doc? Dazza suggests doing the “restatement of agency” exercise on the simpler OAuth mode, and then build up to UMA. Since UMA is different from OAuth, start with UMA? Unless OAuth is going away, it’s best to start with it. And UMA, of course, has “OAuth inside”! The protection API token and authorization API token are both formed from OAuth.
Part of the ambiguity in agency law is that you have a Principal that is a person, and then you have a Third Party that doesn’t yet have a relationship with that Principal. So we have to live with the discomfort of identifying the AS/RS in OAuth as a Third Party even from step 1. Is agency law even the right body of law? It’s not perfect, but it's the best one for now, on the way to contract law!
AI: Eve: Develop "negative use cases” for the “Attempt at UMA flow with mappings (incomplete)” portion of the new document.
Adrian serves as an expert witness on exactly such matters as provider responsibility in the event of a breach. There is real economic value at stake.
AI: Dazza: Look into having one of his students write up a "legally refined" version of some of our outputs.
AI: Eve: Put OAuth mapping into GitHub wiki.
Next steps:
- Adrian and Eve walk through attempted UMA mapping to Agency
- Adrian and Eve walk through import of “ROI form goals”/"business goals" to our work
- Are we ready to think about deliverable types yet?
- Role of Purpose Specification to our work?
- Essential to or separable from our work?
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar:
xmlgrrl@gmail.com