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

James Hazard james.g.hazard at gmail.com
Sun Aug 28 07:32:35 CDT 2016


Thanks Patrick,

I support working in the direction you suggest - assurance regimes for
cross-border DLTs and BCs.

I merely emphasize that smart contracts and blockchains are discrete
subjects.  Bitcoin is a blockchain but does not support smart contracts.
Corda, which is not a blockchain, has demonstrated smart contracts.

Smart contracts, in effect, are open source transaction automation combined
with legal templates (standards).  They need to work cross-platform.  For
privacy, efficiency and data security, the platforms will include
conventional databases, git, Interledger, etc.

I think we are on the same page or perhaps two mergeable forks of a page.

Jim





On Sun, Aug 28, 2016 at 7:34 AM, Patrick Curry <patrick.curry at bbfa.info>
wrote:

> Hi All,
>
> In the various EU industry & gov discussions, there has been some debate
> about the nature of block chains vs databases.  There’s a shrinking few
> folks claiming that BCs are just databases and that’s all there is to it.
> But the consensus differs.
>
>
>    - The three primary features of a distributed ledger enabled by a BC
>    are:
>       - It is peer-peer and updated by a consensual voting mechanism and
>       with a set of strong cryptographic functions.  There is no centralised
>       master database under control of a single organisation, which is the
>       practical norm today.
>       - The distributed ledger technology (DLT) enables everyone to get
>       to see the same information at the same time.
>       - It is tamperproof.
>    - It is true that there are ways to attack a BC in theory but its
>    peer-peer nature requires much coordinated action and collusion to attack a
>    distributed mechanism.  There are ways to mitigate both threats and
>    vulnerabilities.
>    - In some circumstances, part of the BC could be replaced by other
>    mechanisms, to enable much greater efficiency and higher levels of
>    assurance.  Hence ongoing to work to start piloting a first BC where the
>    Proof of Work is replaced by PKI federation.
>    - The complexity of today’s supply chains and business interactions
>    means that BCs will need to federate in a number of cases, and the
>    expectation is that a company in a major supply chains will need to
>    interact with several BCs for different purposes.  However, the trust
>    mechanisms and trusted attributes that underpin these BCs will need to be
>    the same to minimise risk and cost, and also to avoid information and
>    process fracture.
>
>
> Of courses, there are many situations where a database is just fine and
> there is not need for a BC.  However, where there is a cross-organisational
> requirement for an electronic distributed ledger that is distributed, fast,
> at scale, tamperproof, supports transparency, signing, authentication,
> access control and smart contracts, then a BC is the logical choice.
> Hence the interest for supply chains, payments, asset tracking and major
> registers of authoritative data.
>
> BCs depend on access control, particularly for high assurance, and hence
> demand for PKI federation is rising.  Colin Wallis and I will be
> participating in the Estonian gov supported Future of Identity meeting 1-3
> Sep, which is looking at exploiting eResidency for several international
> uses, including supporting block chains.  The Estonian gov has had a
> blockchain supporting part of their X-Roads shared services for several
> years, provided by Guardtime.
>
> My intention is for KI to become involved in the assurance regimes for
> major cross-border DLTs and BCs.  Individual BC policy frameworks will be
> decided by the BC and constrained by the particularly BC technology being
> used.  KI could provide the collaborative assurance profiles and much more.
>    Colin is aware of this.  I hope it will be possible for this DG-BSC to
> engage on some of these emerging realities.
>
> regards,
>
> Patrick
>
> Patrick Curry
> Director
>
> British Business Federation Authority - BBFA Ltd
> M: +44 786 024 9074
> T:   +44 1980 620606
> patrick.curry at bbfa.info
> www.bbfa.info – a not-for-profit, self-regulating body
>
>
>
> On 27 Aug 2016, at 21:09, 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:
>>
>> <Mail Attachment.jpeg>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20160828/8da1de8e/attachment-0001.html>


More information about the DG-BSC mailing list