[DG-BSC] WEF Report
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
has a candidate list of technologies and techniques to fill in...
- Smart Contracts
- Legal Contracts
- IAM Systems
*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>
> 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
> 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.
> 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
> On Wed, Aug 17, 2016 at 4:14 PM, John Wunderlich <john at wunderlich.ca>
>> 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>
>> 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 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>
>>> 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
>> 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
> DG-BSC mailing list
> DG-BSC at kantarainitiative.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 470745 bytes
Desc: not available
More information about the DG-BSC