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.

Thanks,

Eve