On 2 Sep 2015, at 8:27 AM, Mark Lizar <mark@smartspecies.com> wrote:
On 29 Aug 2015, at 12:44, James Hazard <james.g.hazard@gmail.com> wrote:

Just now reviewing the discussion at https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles-and-Obligations. It repeatedly surprised me with it's broad and persuasive analytical position of the issues.

Two thoughts:

1. We could work on a taxonomy of legal issues and provisions. The taxonomy could include ideas such as signature, authorization, revocation, ownership, disputes, etc. We already have a lot to work with from the discussion, and can also work backwards from precedent documents. A small way to start would be an outline for ToU or system rules. We could focus on US health records, while keeping an eye on expanding it to non-US, non-health, non-English, etc. Statutory and other "primary" materials could be linked to. We could also link to lists of model and precedent documents. (Something similar was done by some UMKC students in connection with municipal data sharing agreements, sponteneously or at Dazza's suggestion.)

In the Consent & Information sharing Work Group we have been working on a common consent record format. This provides an easy way to start for scenaros that involve explicit consent and personal information. Which I think covers all of UMA? (if we assume that term User in UMA is = to a person) (is this correct Eve?)

The “user” in User-Managed Access was originally intended to be Alice, our resource owner. We “solved for” the hard use cases where an individual was a resource owner, and then subsequently realized that nothing was stopping the resource owner from being an organization or other non-person entity. Thus, the RO role is not technically constrained. (The requesting party role is similarly unconstrained.) This matters for things like how each of them might, say, authenticate to a system, or whether it’s possible to redirect the RqP to the authorization server or not (it only works if they’re a human end-user). Of course, many laws treat them differently as well, so it’s good to take the distinction into account and be specific.

2. It might be simplifying and empowering to generalize the notion of "events" - to treat all events that might need to be legally proved as being effectuated by records in a common format. For swimlanes, each step (lap in the pool?) should generate a text record that renders into a document and is shared among the directly concerned parties. The record would render a document/webpage such as ToU or the NYPH patient consent, or as little as a mere selection or "yes" in the context of a form. The format of the records would be such that they can be added to a log. Each party would have (or have the right to) a log of the interaction.

Laps in the pool, nice… Effectively, this is what we tried to do prior to developing the Binding Obligations spec. I’ve gone nuts trying to find one of the old diagrams and failed, but we basically analyzed every single pairwise relationship and every single interaction between them, then tried to identify which interactions really “meant” something and would be worth capturing a mutual log out of because somebody’s responsibilities had changed. Issue 63, Audit logs to support legal enforceability, is about this as well.

I’ve been thinking of consent receipts as a special case of transaction receipts marking such occasions — sort of audit log entries that are optimized to help human beings know/prove what happened or what they did, by having machine-readable elements. Seems we’re reaching convergence on this, roughly?

The key in the CIS work is the requirement for a purpose specification:

Purpose Specification - [discussed deeply in this Article 29 WP Opinion Paper ] "The purpose of the collection must be clearly and specifically identified: it must be detailed enough to determine what kind of processing is and is not included within the specified purpose, and to allow that compliance with the law can be assessed and data protection safeguards applied.
Purpose specification lies at the core of the legal framework established for the protection of personal data. In order to determine whether data processing complies with the law, and to establish what data protection safeguards should be applied, it is a necessary precondition to identify the specific purpose(s) for which the collection of personal data is required. Purpose specification thus sets limits on the purposes for which controllers may use the personal data collected, and also helps establish the necessary data protection safeguards.
Purpose specification requires an internal assessment carried out by the data controller and is a necessary condition for accountability. It is a key first step that a controller should follow to ensure compliance with applicable data protection law. The controller must identify what the purposes are, and must also document, and be able to demonstrate, that it has carried out this internal assessment.”

This is the native trust framework in consent and notice and I think legally where access controls can be onboarded by the individual.

In the past, Dazza and I and others have batted around some ideas about where we could put purpose limitations in an UMA flow. One model is to embed metadata in scope descriptions (which becomes a kind of API-wrap). Another is to require the requesting party to provide a claim confirming your request for them to adhere to some purpose limitation, or to select values for some required claim type that indicate their willingness to adhere to the purposes corresponding to those values. There are no doubt others.

I have not worked much on logs. In blockchain implementations, the records and logs are (from the perspective of CommonAccord) an application-side implementation issue. The log is necessarily shared on the blockchain and the challenge is to avoid over-circulation of the information (e.g., using sidechains). In non-blockchain, a log could be kept by having each record added to a log as a single JSON-formatted line of text, with some metadata such as a GUID, time and author. The JSON aspect ties in with a discussion on a GitHub issue that I did with Dazza on design of a more modular and generalizable implementation of CommonAccord rendering.

To date, we’ve stayed away from normative specifications of technical log requirements because each industry seems to have unique requirements. E.g., HL7 has its own. But we’ve gotten close a couple of times!