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

James Hazard james.g.hazard at gmail.com
Fri Aug 26 11:10:38 CDT 2016


John and I discussed this a bit off channel (some issue re the mailing
list), and I suggested that all use cases need to be accommodated.  The one
that Ann posed makes sense in many contexts (for instance, I think it is
like the use case for the GA4GH's ADAM consents - but giving Alice a direct

So I did a start on John's use case - of Alice offering the same materials
- and present a base for negotiation of the conditions of the use, which
can then take place as an exchange of records between Alice and Researcher

Maybe John can correct or round this out.


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/691b6075/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/691b6075/attachment-0001.jpg>

More information about the DG-BSC mailing list