[DG-BSC] WEF Report

James Hazard james.g.hazard at gmail.com
Sun Aug 21 10:15:35 CDT 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20160821/7ef76b90/attachment-0001.html>


More information about the DG-BSC mailing list