[DG-BSC] WEF Report

Eve Maler eve.maler at forgerock.com
Wed Aug 17 17:21:20 CDT 2016


Very briefly, I agree with Jim's analysis. In the three-bullet
definition/analysis I shared out, the "more valuable/less valuable"
analysis contains within it the seeds of a lot of those other technologies
and techniques. Maybe if we write their definitions/analyses in the same
fashion, they'll have a sort of interlocking nature. And then the use cases
can point in to them in a natural fashion.

Our report outline
<http://kantarainitiative.org/confluence/display/BSC/Report+from+the+Blockchain+and+Smart+Contracts+Discussion+Group>
has a candidate list of technologies and techniques to fill in...

   - Blockchain
   - Smart Contracts
   - IPFS
   - CommonAccord
   - Legal Contracts
   - IAM Systems
   - UMA





*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 Wed, Aug 17, 2016 at 2:02 PM, James Hazard <james.g.hazard at gmail.com>
wrote:

> A couple of thoughts:
>
> These "blockchain" analyses tend to minimize the role of related
> technologies, such as identity management and access control, and of
> knock-on effects resulting from, for instance, harmonization of the record
> format, of the functions and of the legal text.  If we recontextualize
> "blockchain," it is busting down the proprietary door to banking and
> finance software, and all the other technologies can follow.  "Financial
> technology" becomes simply "technology," technology that is open source.
>
> Borrowing from the Barclays' smart templates vocabulary and Thomas's use
> case, the layers seem to be:
>
> 1. Records, which can be:
>   1.1. parameters (transaction particulars and paradigms)
>   1.2. prose (framing - legal, descriptive and other human-readable text)
>   1.3. code (functions - "smart contracts" - text that computers like to
> read)
> 2. synchronization of records
> 3. execution of code
> 4. management of collections of records (notably access control)
> 5. validation of the veracity of collections of records.
>
>
> "Blockchains," in the technical sense provide advantages primarily in
> layer 5, but "blockchains" in the movement sense highlight the advantages
> of using common approaches to the other layers.  Blockchains in the
> technical sense are suboptimal (or even unusable) in some of the other
> layers, notably in management of records.  It is hard to see how
> blockchains can be reconciled with, for instance, the privacy requirements
> of the GDPR.
>
> http://kantarainitiative.org/confluence/display/BSC/
> Privacy-Preserving+Data+Sharing
>
> Banking is a particularly important use case, that we might wish to
> consider.  The EU Payment Services Directive mandates banking APIs.  Banks
> are, I am told, extremely concerned about data security and fraud, as well
> as worried about the competitive effects.
>
> To demonstrate a vision of "open sourced" financial services in a format
> that is compatible with blockchains but not dependent on them, I improved
> on a "bank chain" demo I did in France.  This demo is very dense - (not the
> first time that that can be said of my work) - but it shows a flow of
> drafting, signature and validation of a payment instrument (check), and has
> stubs for specifying consequences that need to be implemented in code (a
> kind of loose-text SCDL - smart contract definition language).
>
> This is neither legal nor coding advice, and is certainly wrong in all
> particulars, but it may help convey the general idea - that open source
> (blockchain in context) can permit the financial sector and its customers
> (most of us) to be treated as a decentralized file system, nodes in a
> "graph."
>
>
> http://www.commonaccord.org/index.php?action=doc&file=bqc/
> fr/bnpp/a5we/Account/Check/00001/06-Accept.md
>
>
>
> On Wed, Aug 17, 2016 at 4:14 PM, John Wunderlich <john at wunderlich.ca>
> wrote:
>
>> If I were to pick at that nit, I would suggest "mistrust somewhere in the
>> chain of transactions"
>>
>> Thanks, John
>> 4giv spellin errurz from mobile devize
>>
>> _____________________________
>> From: j stollman <stollman.j at gmail.com>
>> Sent: Wednesday, August 17, 2016 12:30 PM
>> Subject: Re: [DG-BSC] WEF Report
>> To: John Wunderlich <john at wunderlich.ca>
>> Cc: Thomas Hardjono <hardjono at mit.edu>, <dg-bsc at kantarainitiative.org>
>>
>>
>> John,
>>
>> This list provides some valuable insight.
>>
>> The only thing I would change is the Item 3:  Minimal Trust.  My
>> correction is nitpicky, but I would change "mistrust *between* entities:
>> to "mistrust *among* entities."  Often the two parties transacting trust
>> each other.  The trust breakdown is further up or down the transaction
>> chain.  "Among" captures this more accurately than "between."
>>
>> Jeff
>>
>>
>> ---------------------------------
>> Jeff Stollman
>> stollman.j at gmail.com
>> +1 202.683.8699
>> <stollman.j at gmail.com>
>>
>> Truth never triumphs — its opponents just die out.
>> Science advances one funeral at a time.
>>                                     Max Planck
>>
>> On Wed, Aug 17, 2016 at 6:27 AM, John Wunderlich <john at wunderlich.ca>
>> wrote:
>>
>>> Here's the page that leapt out at me - characteristics of high potential
>>> use cases
>>> [image: Image]
>>> John Wunderlich,
>>>
>>> Sent frum a mobile device,
>>> Pleez 4give speling erurz
>>>
>>> "...a world of near-total surveillance and endless record-keeping is
>>> likely to be one with less liberty, less experimentation, and certainly far
>>> less joy..." A. Michael Froomkin
>>>
>>>
>>>
>>>
>>> On Wed, Aug 17, 2016 at 5:13 AM -0400, "Thomas Hardjono" <
>>> hardjono at mit.edu> wrote:
>>>
>>> This might help us in some of our use cases:http://www3.weforum.org/docs/WEF_The_future_of_financial_infrastructure.pdf/thomas/_______________________________________________DG-BSC mailing listDG-BSC at kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-bsc
>>>>
>>>>
>>>
>>> This email and any files transmitted with it are confidential and
>>> intended solely for the use of the individual or entity to whom they are
>>> addressed. If you have received this email in error please notify the
>>> system manager. This message contains confidential information and is
>>> intended only for the individual named. If you are not the named addressee
>>> you should not disseminate, distribute or copy this e-mail. Please notify
>>> the sender immediately by e-mail if you have received this e-mail by
>>> mistake and delete this e-mail from your system. If you are not the
>>> intended recipient you are notified that disclosing, copying, distributing
>>> or taking any action in reliance on the contents of this information is
>>> strictly prohibited.
>>>
>>> _______________________________________________
>>> DG-BSC mailing list
>>> DG-BSC at kantarainitiative.org
>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc
>>>
>>>
>>
>>
>>
>>
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this email in error please notify the
>> system manager. This message contains confidential information and is
>> intended only for the individual named. If you are not the named addressee
>> you should not disseminate, distribute or copy this e-mail. Please notify
>> the sender immediately by e-mail if you have received this e-mail by
>> mistake and delete this e-mail from your system. If you are not the
>> intended recipient you are notified that disclosing, copying, distributing
>> or taking any action in reliance on the contents of this information is
>> strictly prohibited.
>>
>> _______________________________________________
>> 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/20160817/b90f95d1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Image.png
Type: image/jpeg
Size: 470745 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20160817/b90f95d1/attachment-0001.jpe>


More information about the DG-BSC mailing list