[DG-BSC] WEF Report

James Hazard james.g.hazard at gmail.com
Mon Aug 22 05:40:50 CDT 2016


Hi Koen,

Thanks.  The operative line in that slide may be:

           "Structure:  Ricardian Contract (legal prose, parameters,
code)".

I prefer the order "i) params ii) prose iii) code" because the parameters
drive the other two, but you can indeed think of the legal prose as framing
for parameters which drive code.

"Ricardian Contracts" references Ian Griggs's work.  Some background is
here http://financialcryptography.com/mt/archives/001556.html.  Ian
discusses the fit with CommonAccord towards the end of that piece.

Jim




On Sun, Aug 21, 2016 at 6:51 PM, Koen Vingerhoets <
koen.vingerhoets at telenet.be> wrote:

> While I support your view on Record, I think you’re making quite a
> shortcut on the smart contracts.
>
> “A collection of code snippets” sounds to limited.
>
> http://static1.squarespace.com/static/55f73743e4b051cfcc0b02cf/t/
> 5784f5dbebbd1aba2d3e400e/1468331499513/R3+Smart+
> Contract+Templates+Summit+_FINAL.pdf
>
> Check out slide 14.
>
>
>
> Best regards,
>
> KOen
>
>
>
> *Van:* James Hazard [mailto:james.g.hazard at gmail.com]
> *Verzonden:* zondag 21 augustus 2016 17:16
> *Aan:* Koen Vingerhoets <koen.vingerhoets at telenet.be>
> *CC:* Luk Vervenne <luk.vervenne at synergetics.be>;
> dg-bsc at kantarainitiative.org
> *Onderwerp:* Re: [DG-BSC] WEF Report
>
>
>
> On separate channels - notably twitter - there has been a bit more
> discussion of record -> smart contract -> blockchain.
>
>
>
> A CommonAccord-ish perspective on defining the boundaries and points of
> interchangeability in the stack of transacting could be:
>
>
>
> i) "records" are the goal.  E.g., records of agreements, consents, queries
> and responses.
>
> ii) each record can be named by its hash.  (e.g. using IPFS hashing).
>
> iii) a record has a context.  The record's context can be referenced in
> the record by the hash of the context.
>
> iv) the context will often be the preceding step in the transacting.  A
> transaction event flow will consist of a chain of records, each of which
> reference a preceding one by hash.
>
> v) the context can also include (and add):
>
>   a) other "data", e.g., identities of persons and things.
>
>   b) "prose" - e.g., legal documents such as the text of agreements,
> consents, policies.
>
>   c)  "code" - functions that the host system must do or may do (or
> schedule), when it receives the record.  References to "code" could also
> include a required operating environment.
>
>  vi) a record can override any element of its context (prototype
> inheritance).
>
> vii) a query is a record that asks for a response.
>
>
>
> The records, including prose and code, must be independent of the
> platform.  "Smart contract" means a collection of code snippets.
>  "Blockchain" is a database.
>
>
>
>
>
>
>
> On Thu, Aug 18, 2016 at 6:30 PM, Koen Vingerhoets <
> koen.vingerhoets at telenet.be> wrote:
>
> Hi Luk,
>
>
>
> How would vendors be able to mix that? (I don’t understand your remark).
>
> There is no need to disclose an identity, we’re simply building one. If 3
> banks and a telco accept and validate your “proof of address” and “approve”
> the hash of that document on the ledger, it’s up to you to use it for a 4
> th bank. But if you do, your KYC should go faster (de lege ferenda – at
> the moment it’ll merely indicate you already used the document).
>
> As we’re doing KYC anyway, returning the result to the user just seems to
> be the best thing to do.
>
>
>
> Keeping identity secured is interesting from a personal point of view, for
> the collective it’s way more interesting to know who is where.
>
> But that seems to be an entirely different discussion.
>
>
>
> Best regards,
>
> Koen
>
>
>
>
>
> *Van:* Luk Vervenne [mailto:luk.vervenne at synergetics.be]
> *Verzonden:* vrijdag 19 augustus 2016 0:20
> *Aan:* Koen Vingerhoets <koen.vingerhoets at telenet.be>
> *CC:* James Hazard <james.g.hazard at gmail.com>; Luk Vervenne <
> luk.vervenne at synergetics.be>; dg-bsc at kantarainitiative.org
> *Onderwerp:* Re: [DG-BSC] WEF Report
>
>
>
> Hmm, that would allow vendors to mix identification, authenticaiton and
> authorization.
>
> I would be favour to cleanly separate those three elements.
>
> In fact I would like individuals be known - after identification - through
> "pairwise persistent pseudonyms”. By default.
>
> Identity disclosure is a prerogative of the user.
>
>
>
> So it can’t be google/facebook either.
>
> Federated networks of IdM providers (Martins suggestion) is focused but
> also limited in what it does.
>
>
>
> Luk
>
>
>
> On 19 Aug 2016, at 00:00, Koen Vingerhoets <koen.vingerhoets at telenet.be>
> wrote:
>
>
>
> Hi,
>
>
>
> I’m working on a blockchain use case where banks use the KYC procedure to
> construct an identity fort heir customer.
>
> Based on (re)validation of hashes of re(used) documents, banks can confirm
> an identity.
>
> By extending to telco (and other utilities), the “digital identity” gains
> extra value.
>
> Basically a onename.com with banks/large corporates validating instead of
> github, twitter, facebook.
>
>
>
> Banks are no hosts – what benefit would that bring in the short or medium
> term?
>
> They’re investing a lot to ensure they can still add value in a peer 2
> peer (or human 2 human) world.
>
>
>
> Best regards,
>
> KOen
>
>
>
>
>
> *Van:* dg-bsc-bounces at kantarainitiative.org [mailto:dg-bsc-bounces@
> kantarainitiative.org <dg-bsc-bounces at kantarainitiative.org>] *Namens *James
> Hazard
> *Verzonden:* donderdag 18 augustus 2016 15:48
> *Aan:* Luk Vervenne <luk.vervenne at synergetics.be>
> *CC:* dg-bsc at kantarainitiative.org
> *Onderwerp:* Re: [DG-BSC] WEF Report
>
>
>
> Thanks Luk.   I would think that real P2P would not have central
> governance (not even central "mining").  It would be polycentric.  Anyone
> or any group could fork their own and cooperate or interoperate as they
> found convenient.
>
>
>
> Of course there are very strong reasons to interoperate, and standards are
> important (e.g., our discussion on a Kantara thread).  Regarding
> decentralized law (document templates) we think that participants will want
> local, national, industry and global standards processes, under distinct,
> "local", even competing managements.  Hence a "Center for Decentralized
> Law."
>
>
>
>
>
>
>
> On Thu, Aug 18, 2016 at 9:05 AM, Luk Vervenne <luk.vervenne at synergetics.be>
> wrote:
>
> OK James.
>
> But there is a difference between who’s is running the federated IdM, and
> who is governing it.
>
> A data center, Telco’s or even a bank might actually do it, but an
> independent  "separation of concern” governance should manage it.
>
>
>
> If we* really* want to make the individual a genuine stakeholder… it
> starts there and then.
>
> By *ethically industrialising personal data management* (which is more
> than IdM, we need to end this *fight for personal data,* by setting up a *new
> digital utility* as the very basis from which individuals can become
> genuine stakeholders.
>
> To name one ...Local Gov. should take up its (partial) responsibility.
>
>
>
> Luk
>
>
>
> On 18 Aug 2016, at 14:46, James Hazard <james.g.hazard at gmail.com> wrote:
>
>
>
> This is an interesting discussion.
>
>
>
> I have no dog in this fight, and am not trying to take sides.  I notice,
> however, that telcos are i) more digital, ii) in more direct contact with
> the customer via mobile phones iii) more agile iv) bigger (in subscriber
> bases).
>
>
>
> In addition to the advantages of banks mentioned in the report, banks are
> more numerous and many are more local than telcos.  They might pose less of
> monopoly threat and perhaps less monoculture threat.
>
>
>
> In this view, telcos are natural conduits for a P2P solution and banks are
> natural hosts.  This of course does not make banks the exclusive hosts, not
> even for a single individual.  In a P2P solution, individuals can
> host-their-own or host with an alternative supplier, and there is a very
> low barrier to switching.
>
>
>
>
>
>
>
>
>
> On Thu, Aug 18, 2016 at 8:14 AM, Luk Vervenne <luk.vervenne at synergetics.be>
> wrote:
>
> Adding to Martin’s, here’s another one :
>
>
>
> Even in an digital world, most of the economic value of an individual is
> spend ...local.
>
> So federated IdM - and in fact the Digital Utility supporting Personal
> Data Ecosystems - need to be locally based in a Europe of Regions.
>
>
>
> Luk
>
>
>
>
>
> On 18 Aug 2016, at 14:04, Martin Kuppinger <mk at kuppingercole.com> wrote:
>
>
>
> Hi,
>
>
>
> yes, unfortunately they neither act that way nor are they as trusted for
> that role as most believe.
>
> We did research even a couple of years ago on that and it has been
> verified repeatedly that Telcos including mobile operators are in a better
> position. They are trusted. And they have far bigger ecosystems than most
> banks have. Furthermore, I believe that many people still want to keep
> identity and their own financials somewhat separate. Otherwise, PayPal
> might be the best home for identity management: Global, large scale,…
>
> At least we finally might see an evolution towards an ecosystem of trusted
> identity providers with sufficient interoperability, particularly for the
> interactions and transactions that really need trust. Most governments
> failed in providing such infrastructure. Others, including many startups,
> tried to fill that gap – and commonly failed. Now, others (and I bet more
> on telcos than the finance industry), based on new technical options, might
> succeed.
>
>
>
> Regards,
>
> Martin
>
>
>
> *Von:* dg-bsc-bounces at kantarainitiative.org [mailto:dg-bsc-bounces@
> kantarainitiative.org <dg-bsc-bounces at kantarainitiative.org>] *Im Auftrag
> von *James Hazard
> *Gesendet:* Donnerstag, 18. August 2016 13:58
> *An:* John Wunderlich <john at wunderlich.ca>
> *Cc:* dg-bsc at kantarainitiative.org
> *Betreff:* Re: [DG-BSC] WEF Report
>
>
>
> This report of the World Economic Forum, done by Deloitte, has a
> consistent thesis - that banks (financial institutions) are the natural
> home for identity management.  It makes the point in great depth.
>
>
>
> http://www3.weforum.org/docs/WEF_A_Blueprint_for_Digital_Identity.pdf
>
>
>
> On Wed, Aug 17, 2016 at 5: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
>
>
>
> 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
> <image001.jpg>
>
> 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
>
>
>
>
>
> --
>
> @commonaccord
>
> _______________________________________________
> DG-BSC mailing list
> DG-BSC at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/dg-bsc
>
>
>
>
>
>
>
> --
>
> @commonaccord
>
>
>
>
>
>
>
> --
>
> @commonaccord
>
>
>
>
>
>
>
> --
>
> @commonaccord
>



-- 
@commonaccord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20160822/36d9eefd/attachment-0001.html>


More information about the DG-BSC mailing list