[DG-BSC] Ann Vroom Followup toBSC telecon Thursday August 25 2016

James Hazard james.g.hazard at gmail.com
Fri Aug 26 07:47:18 CDT 2016

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

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 at 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 at 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 at 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 at 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 at gmail.com]
>>> *Sent:* Thursday, August 25, 2016 4:13 PM
>>> *To:* M AV <av_m at hotmail.com>
>>> *Cc:* Eve Maler <eve.maler at forgerock.com>; dg-bsc at 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 at 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 at kantarainitiative.org
>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc
>>> --
>>> @commonaccord
>> --
>> @commonaccord
>> _______________________________________________
>> DG-BSC mailing list
>> DG-BSC at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/dg-bsc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20160826/d497cd28/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 57216 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20160826/d497cd28/attachment-0001.jpg>

More information about the DG-BSC mailing list