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

Eve Maler eve.maler at forgerock.com
Tue Aug 30 10:54:44 CDT 2016


Just caught up to this whole thread after returning from vacation. Love the
"cartoon" approach, the CommonAccord rendering, and of course John M's
reflection of subject-matter experts' long work in the field.

Again we see the "blockchain vs. smart contract" split, and an analysis
showing some doubt that the new bag of technologies strictly helps or is
needed to solve the problem that the use case sets out.

Can the new info/artifacts/links/analysis be added to the use case, the
last along the lines of what I've been suggesting (a sort of SWOT for each
technology/technique) if you think it would work?


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
*ForgeRock Summits and UnSummits* are coming to
<http://summits.forgerock.com/> *London and Paris!*

On Sun, Aug 28, 2016 at 5:32 AM, James Hazard <james.g.hazard at gmail.com>
wrote:

> 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/healthca
>>> re-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
>
> _______________________________________________
> 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/20160830/49db80f5/attachment-0001.html>


More information about the DG-BSC mailing list