I'm happy to do another flow. I believe all flows can be accommodated, and the system must be extensible to accommodate all flows (or you never get harmony). This one reflects what I understand to be a common flow in some kinds of research. The researcher collects the information and makes known to other researchers. It is, I understand, common to give ResearcherA general authority to respond to requests by other Researchers (within the scope). The flow demo-ed gives Alice a direct role. This kind of flow is common (and should be much more common) in other settings, such as NDAs or use of credentials. Should I do a second flow? On Fri, Aug 26, 2016 at 8:33 AM, John Moehrke <johnmoehrke@gmail.com> wrote:

I don't think this flow is realistic. he second researcher (B) would not likely be added to the existing consent, but rather build a new consent.

An alternative flow :

1. Alice publishing her 'preferences' first, likely advertising specific health attributes to help researchers select. (blockchain publication, likely using Pseudonym) 2. The researcher discovering Alice, and determines preferences meet the research terms. (possibly using smart-contracts) 3. The researcher approaches Alice with the offer. (blockchain messaging) 4. Note at this point, as JohnW diagram shows, there is usually some form of 'negotiation'. This might be simply Alice making selections (web form), or might be an interactive session using technology (Oauth/UMA), human interaction, or smart-contracts. This negotiation phase is to optimize the terms of the consent (possibly through smart-contract). 5. The terms of the interaction are fixed (likely published on blockchain) - possibly in smart-contract) 6. The researcher accesses the data (with authorization from blockchain evidence, or other such as UMA)

In this flow, what you have diagrammed as a new researcher (B) is really a new opportunity -- starting at step 2. This would certainly be a new consent.

I realize I might be bias, as this is the scenario that I diagrammed on my blog in May. But I still think it holds up, and would love to see it developed under kantara https://healthcaresecprivacy.blogspot.com/2016/05/healthcare- blockchain-big-data.html

John

John Moehrke Principal Engineering Architect: Standards - Interoperability, Privacy, and Security CyberPrivacy – Enabling authorized communications while respecting Privacy M +1 920-564-2067 JohnMoehrke@gmail.com https://www.linkedin.com/in/johnmoehrke https://healthcaresecprivacy.blogspot.com "Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Thu, Aug 25, 2016 at 6:27 PM, James Hazard <james.g.hazard@gmail.com> wrote:

...

Hi,

Here is a first, rough sketch. There are five steps in the transaction. It is structured to anticipate additional requests and grants. 05-AliceGrants, is the last link in the chain and gives an overview of the steps. You could click on it, then on "Document". Note that a few nuances have been captured, such as the request being more limited in scope than the full data.

The general principle is that each step in a transaction that needs to be persisted is documented as a record. The record states particulars and references its context, including the prior step.

In a production system, each record can be stored under a friendly name, like this, or under a hash. Records can be stored in a file system versioned with git, like this, or in a database such as IPFS or a blockchain, as needed.

http://www.commonaccord.org/index.php?action=list&file=GH/Ka ntaraInitiative/DG-BSC/Consent/Use1/

On Thu, Aug 25, 2016 at 4:14 PM, M AV <av_m@hotmail.com> wrote:

...

It’s one .jpeg you should be able to cut and paste from the email …

*From:* James Hazard [mailto:james.g.hazard@gmail.com] *Sent:* Thursday, August 25, 2016 4:13 PM *To:* M AV <av_m@hotmail.com> *Cc:* Eve Maler <eve.maler@forgerock.com>; dg-bsc@kantarainitiative.org *Subject:* Re: [DG-BSC] Ann Vroom Followup toBSC telecon Thursday August 25 2016

Excellent! I'll do a minimal sketch of this flow.

On Thu, Aug 25, 2016 at 4:02 PM, M AV <av_m@hotmail.com> wrote:

Hi – in reference to this afternoon’s conf call, here’s my super-simplified version of the flow I described:

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

--

@commonaccord

-- @commonaccord

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

-- @commonaccord