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

James Hazard james.g.hazard at gmail.com
Sat Aug 27 19:31:20 CDT 2016


Thanks Thorsten,

I suggest thinking separately about the two technologies - smart contracts
and blockchains.

"Smart contracts" as a concept predates blockchains and for
interoperability smart contracts must be independent of any specific
database.  Smart contracts are (I think) very broadly useful and will have
a powerful impact because they open source both code and legal.

Jim


On Sat, Aug 27, 2016 at 4:09 PM, Thorsten H. Niebuhr [WedaCon GmbH] <
tniebuhr at wedacon.net> wrote:

> Hi All,
>
> Still trying to catch up all the great stuff you all did in the past
> weeks, and sorry for not taking part of it due to my vacation!
>
> This comment from Jeff is the one which finally make me step in again:
>
> Question: What is it, which can not be achieved because we do not have a
> blockchain (yet) ? In my eyes, the only thing which limits 'the digital
> world' is the current lack of (universal) trust.
>
> Assuming we would have such a trustworthy (from all possible angles)
> instance right now: Which usecase can NOT be realized with current
> technology?
>
>
> thx,
>
>
> Thorsten
>
>
>
> On 26.08.2016 19:32, j stollman wrote:
>
> All,
> It's been said that when you are keeping you head and everyone around you
> is losing theirs, maybe you don't understand the situation.
> So I'll allow that, perhaps, I am guilty of missing something important
> here.
>
> I see this consent as an excellent demonstration of an UMA application,
> but I fail to understand the benefits of using blockchain.  Any database
> could track the consents.  And an SQL database could perform queries much
> faster and cheaper.  The only justification I can imagine for using
> blockchain would be if you could not find a trustworthy owner for the
> database.  In this instance, using a public blockchain would remove the
> fear that the database owner might be unscrupulous and try to modify the
> data to some advantage.  Other than that, I don't know why it would be
> beneficial to engage a blockchain network to perform this simple record
> keeping.
>
> So what am I missing?
>
> Thank you.
>
> Jeff
>
>
> ---------------------------------
> Jeff Stollman
> stollman.j at gmail.com
> +1 202.683.8699
>
>
> Truth never triumphs — its opponents just die out.
> Science advances one funeral at a time.
>                                     Max Planck
>
> On Fri, Aug 26, 2016 at 12:50 PM, M AV <av_m at hotmail.com> wrote:
>
>> Critiques coming in are great, thx – super advantage of cartoon-simple
>> illustrations is that is spoofs out places where there’s fundamental lack
>> of clarity or consensus on the basics of the proposed flow – deep details
>> are eventually necessary, but at the brain-storming use case level a
>> beehive of details can be more obfuscating than illuminative (excuse my
>> mixed metaphors – obviously I’m a “visual” thinker …  so I always kind of
>> push back for a “draw it” explanation and trimming the proffered flow idea
>> down to it’s bare essentials .. J
>>
>>
>>
>> All that said – I think the concept of Alice co-owning the consent with
>> the researcher(s) is one of the radical ideas here that could be
>> facilitated in a new way by the new BC technology – i.e., the idea that
>> Alice’s consent is an “asset” that she shares with the co-parties to the
>> consent contract and which she therefore thereafter participates actively
>> in vis-à-vis the addition of new co-parties, i.e., researchers using the
>> asset – e.g. Alice’s data –
>>
>>
>>
>> My knowledge of research consents is not current enough (former JHMI
>> administrator and then health care biz lawyer, but semi-retired now) to
>> know whether a downstream researcher could piggy-back on to an existing
>> consent asset (contract agreement), but I guess as long as we blue-sky
>> use-case-ing we can assume anything arguendo J
>>
>>
>>
>> Best to all, ann v.
>>
>>
>>
>> *From:* James Hazard [mailto:james.g.hazard at gmail.com]
>> *Sent:* Friday, August 26, 2016 12:11 PM
>> *To:* John Moehrke <johnmoehrke at gmail.com>
>> *Cc:* M AV <av_m at hotmail.com>; dg-bsc at kantarainitiative.org
>>
>> *Subject:* Re: [DG-BSC] Ann Vroom Followup toBSC telecon Thursday August
>> 25 2016
>>
>>
>>
>> Hi,
>>
>>
>>
>> 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
>> role).
>>
>>
>>
>> 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 B.
>>
>> http://www.commonaccord.org/index.php?action=doc&file=GH/Kan
>> taraInitiative/DG-BSC/Consent/Use2/01-Data.md
>>
>>
>>
>> Maybe John can correct or round this out.
>>
>>
>>
>> Jim
>>
>>
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> @commonaccord
>>
>> _______________________________________________
>> DG-BSC mailing list
>> DG-BSC at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/dg-bsc
>>
>>
>
>
> _______________________________________________
> DG-BSC mailing listDG-BSC at kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-bsc
>
>
>
> _______________________________________________
> DG-BSC mailing list
> DG-BSC at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/dg-bsc
>
>


-- 
@commonaccord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20160827/211983f9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 26119 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20160827/211983f9/attachment-0001.jpe>


More information about the DG-BSC mailing list