Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Status
subtletrue
colourRed
titleObsolete

Note: This wiki version of the Report is being has been obsoleted by a the live Google Docs version. The DG is still pulling content Information confirmed to appear there has been removed from this version over to the other one.

 

toc

Introduction

The Blockchain and Smart Contracts Discussion Group was launched in July 2016. This report from the group offers recommendations and observations to Kantara Initiative covering the following scope:

  • Solving use cases for empowering traditionally disempowered parties (such as individuals)
  • taking part in transactions (such as entering into contracts and information-sharing agreements)
  • with parties that traditionally hold greater power (such as companies and large countries)
  • in the context of decentralization technologies and techniques (such as blockchain and smart contracts)
  • and their mixture with identity (both in the course of conducting business/legal transactions and to solve digital identity use cases).

Beyond Kantara, the group anticipates that anyone else who is interested in these topics may find this report useful.

A recurring theme in digital identity communities ("user-centric") as well as in blockchain communities ("removing intermediaries") is the question of balancing control between individuals and others – to enable disempowered entities to rise to the level of a "peer" with others in some fashion. A legal term for the way the imbalance may assert itself in a transaction is a "contract of adhesion" (a standard-form, take-it-or-leave-it contract). Key aspects of this imbalance are:

  • Granularity: The less-empowered party must accept a totality of trust and liability, rather than a smaller apportionment.
  • Dynamism: The less-empowered party must accept the contract all at once in time and can't change the parameters now or in future.
  • Market choice: The less-empowered party must accept an offer due to limits on available alternatives.
  • Transparency: The less-empowered party must accept that the other party is acting as promised.

...add more commentary about the imbalance? ...public and private blockchains have different dynamics – there's a different economic incentive – can't 100% rebalance, we suspect... ...add OpenBazaar-based short discussion (see Oct 4 notes)...

While it's important to evaluate technology for its ability to effect change, it's not the end of the story. Technology operates in a business and legal context; hence the popular notion of a "BLT sandwich". We have seen a rise of technologies that address the process of negotiating and executing legal contracts, along with smart contracts that aim to automate agreements while providing required legal context (such as the jurisdiction and the parties).

...to come... listing our technologies and techniques for analysis... ...listing our use cases and case studies for analysis in light of the previous... 

...preview recommendations...

then END INTRO.

 

Frame the tensions as themes:

  • centralization/decentralization (can the "drug" of centralization be overcome with cooperative techniques? even beyond this drug, what about the business-model drug of making someone create identities all over?)
  • trust/distrust
  • power/disempowerment (enfranchising individuals)
  • static/dynamic (need for acceleration in digital transformation, IoT, trust, imposition of contract of adhesion through static-ness, trust frameworks becoming dynamic, being discoverable)
  • traditional/new (early adoption, hype cycles, fear of change)
  • governance/technology/policy (and what is available to support what)
  • contracts/machines (identities and parties)

Summary of Recommendations and Observations

tbs - reference use cases, technologies, and issues by number from sections below as appropriate

Summary of Liaison Activity

tbs - both internal and external - IRM, IDoT, UMA, CIS, other

Purpose

(new crystallization of the purpose, derived from a BSC DG blog post directed to the Kantara LC) The BSC Discussion Group is offering these recommendations and observations to Kantara Initiative regarding solving use cases for empowering traditionally disempowered parties (such as individuals) to "contract and transact", e.g. with parties that traditionally hold greater power (such as companies and large countries), given the new landscape of "decentralization and distributed" technologies and techniques (such as blockchain and smart contracts) and their mixture with identity.

(from July 26 discussion) 

We should ensure that we satisfy the needs of an external audience that shares our purpose too. We could, in part, do this by including a review (John: "environmental scan") of other activities attempting to address some of these issues. The world seems to just be entering the trough of disillusionment. We want to achieve empowerment and the "P2P-ness" in a functional sense, even if not in a strictly technical sense. It's a good idea to reference the Kantara vision/mission wording. Jeff suggests: Maybe we shouldn't say "P2P" at all in our goal, because it implies a (technical) technique too strongly. We could illustrate the power imbalance instead by talking about "contracts of adhesion" or simply talk about addressing the power imbalance directly (brute force method!).

Eve essays a goal: Solve the use cases, with whatever technologies. This may mean not always using a pure blockchain model if that has certain vulnerabilities, or requires a TTP in the mix, or whatever. We could discuss how blockchain has started to be over-applied to solve problems it perhaps wasn't meant for (the root of the trough-of-disillusionment phenomenon!).

From the chat: Technology cannot solve problems that require management and governance
. But technology can provide tools to manage and govern.

Technologies and Techniques Potentially Applicable to Solving Use Cases in Scope

tbs - describe each briefly

tbs - how and where to do cross-tech analysis, e.g. CmA/legal contracts/smart contracts?

Blockchain

Following are the key elements of blockchain technology and their value. Other technologies can be blockchain-like if they have some of these elements, but are not considered true blockchains.

  • A tamper-evident “ledger” (linear, append-only) data structure

    • Valuable for recording events that definitely happened

    • Less valuable for recording any information that is uncertain or required to be deleted (such as personal information for which a “right to be forgotten/right to erasure” has been established)

  • Autonomous, distributed, and possibly even decentralized (no node has higher privileges) storage nodes

    • Valuable for architectures where trust in a central authority is difficult or undesirable to establish (although trusted third parties do play a role in some blockchain deployments anyway; see third bullet below)

    • Less valuable for recording sensitive information because of the increased attack surface (every node has a copy of everything) and resulting increased privacy considerations

    • Less valuable for recording voluminous information because every node has a copy of everything

  • Mathematically based (algorithmic) consensus for contents of new ledger entries

    • Valuable for incentivizing cooperative behaviors among node participants about entry contents (“proof of work” as used in Bitcoin is the most famous)

    • Less valuable if other parts of the “BLT sandwich” (business-legal-technical) are not well controlled for through IAM, trust frameworks, etc. -- e.g., multiple node participants can collude to game the system -- but then decentralization goals can be compromised thereby

The sum of the elements is intended to be valuable for establishing dynamic trust across a wide ecosystem of participants that would otherwise not be able to establish trust, exactly along the lines of the use cases this group seeks to solve. 

Blockchain technology is a platform, not a ready-made application. There are “public blockchains” on which applications can be built; two of the most well-known are Bitcoin and Ethereum. (N.B.: A recent (Jul-Aug 2016) hack and fork have left the Ethereum blockchain split into two, Ethereum and Ethereum Classic, showing the extreme volatility of this space. See also the Blockchain Graveyard detailing the many startups that have already died due to hacks.) These can be thought of as being something like “public cloud services” for blockchain.  There are also open-source implementations of blockchain that can be deployed internally within an organization; depending on how they’re deployed, they can be thought of us being something like “private cloud” blockchains. There are also many blockchain-related tools, SDKs, and app platforms that ride on top of these base layers, much like other development platforms.

Blockchain

TypesSpecial-purpose blockchains such as Bitcoin

  • General-purpose blockchains that can contain anything
  • General-purpose "smart contract" blockchains designed for nodes that contain programmable content
  • Other axes

    • Permissionless/permissioned...
    • etc. (which graphical form(s) of analysis? diagram? matrix? etc.)

    Smart contracts:

    ...owner: Thomas... (see Nov 1 notes for a "starter pack" of content)

  • "True" contract
  • Pile of code (smile)

    ...elephant in the room: performance?...

    IPFS

    ...owner: Thomas...

    Certificate Transparency

    ...owner: Scott S...

    Definition: Certificate Transparency is an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that permits monitoring of certificate authority (CA) activity and detection of mis-issuance of certificates.  The idea is that clients should refuse to honor certificates that do not appear in a log, providing incentive for CAs to add all issued certificates to the logs.  Merkel hash chaining is used to prove the order of events and the existence of transactions.

    The current approach to PKI is vulnerable to the threat of mis-issuance, which allows malicious actors to impersonate valid web sites and perform Man In The Middle (MITM) attacks.  The PKI trust model requires all parties to rely on the proper issuance of certificates by CAs, but does not provide a mechanism for monitoring compliance or enforcing remedial actions when noncompliance is discovered.  If CAs operate with insufficient security, malicious actors can obtain fraudulent certificates through social engineering, insider attack or external hacking.

    Certificate Transparency (CT) addresses these flaws by providing the capability to detect, prevent, and enable remediation of certificate mis-issuance.  Monitoring of logs provides detection of mis-issuance.  Logging deters CAs from poor security.  If monitoring detects potential mis-issuance then certificate revocation can remediate the problem.  The protocol is implemented and under active development. The base protocol is specified in IETF RFC 6962, with additional gossip protocols being developed as IETF Internet Draft draft-linus-trans-gossip-ct. As of this draft there are ten log operators (the tenth was added yesterday), and Google Chrome has implemented enforcement for some certificates.

    Ethical Diamond Trade

    Ethical sourcing of minerals is a challenge in a world in which many natural resources are located in countries without strong civil society and worker's protections.  In the diamond trade, this issue is addressed through the Kimberley Process Certification Scheme (KPCS), a process established by the United Nations in 2003 to prevent "conflict diamonds" from entering the wholesale market in rough diamonds.  The process involves countries that import or export rough diamonds issuing paper based certificates attesting that the diamonds are not conflict diamonds, defined as "rough diamonds used by rebel movements or their allies to finance conflict aimed at undermining legitimate governments".  In 2015, over 53000 certificates were created for over $42B in trade value - an average of $8M per certificate. 

    Problems with current approach: 

    • Kimberley Process Certificates have a known forgery problem. As paper based certificates without modern anti-counterfeit technology, they are vulnerable to fraudulent issuance.  There is no verification process for confirming the authenticity, and every country has their own format for certificates.  The KP enforcement pagelists several countries of caution whose certificates should not be blindly trusted.
    • Due to the definition of "conflict diamond", the arrangement protects the rights of governments to control the diamond trade, rather than protecting the working conditions of legitimately mined diamonds.  The world bank report on conditions in the extractive industries shows numerous reports of fully authorized mining operations with appalling working conditions.  Beyond the scope of the KPCS, there are efforts, funded by Apple and by the German civil society group GIZ, to promote the registration of small scale miners for their protection and to support documentation of supply chain all the way to the source (source: 2014 Diamond Development Initiative Annual Report).  The Maendeleo Diamond Standards are an effort towards the certification of KPCS approved mining locations to ensure that they are free from government-led violence and abuses, and do not undertake mining operations or related activities in any protected or conservation areas are eligible for certification. 

    Ways for blockchain to improve current approach:

    • import/export transactions recorded on a public ledger allowing the attestation to be done in a verifiable and accessible manner
    • issue blockchain based credentials to support identity registration of small scale miners, record chain of custody of diamonds from source to export

     

    CommonAccord

    ...owner: Jim...

    CommonAccord is an initiative to create global codes of legal transacting by codifying and automating legal documents, including contracts, permits, organizational documents, and consents. We anticipate that there will be codes for each jurisdiction, in each language. For international dealings and coordination, there will be at least one "global" code.

    Protocol-Specific Contract Provisions

     

    HL7 (with FHIR) security/privacy/trust/provenance codes, GTRI, GA4GH model text, UMA model text...

    ...owner for LH7 piece: Kathleen...

    ...owner for UMA model text piece: Eve...

    Legal Contracts

    ...owner: Scott D?...

    Sub-type: trust frameworks

    • Identity federation
    • Access federation

    Digital Identity [and Access?]

    ...owner: Andrew...

    ...ultimately this has to include access management too, because this comes into permissioning use cases...

    ...treat "blockchain identity" as wholly separate from "identity and access management" applied over "blockchain" technology, and also separate from the general notion of the identities of the "parties" involved in contracts...

    UMA

    ...owner: Eve...

    User-Submitted Terms & Consent Receipts

    ...owner: John W.

    Use Cases

    tbs - present each of the analyzed and approve use cases here, presumably each in a subsection (or transcluded?), drawn from this page

    tbs - where to identify and analyze issues uncovered through the use cases?

    Case Study: MedRec

    (Kathleen takes writing this one up as an assignment. She'll float some text to the list first.)

    Authors

    ...list all contributing authors here...