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 context of requiring identification for transaction purposes and to solve broader 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 as well as in blockchain communities is the question of balancing the control between individuals and other entities – to enable disempowered entities to rise to the level of a "peer" 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). Two 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 a the contract all at once in time and can't change the parameters now or in future.

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

...

tbs - describe each briefly

...

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.

The Continuum of Blockchain Types

• Special-purpose blockchains such as Bitcoin
• General-purpose blockchains that can contain anything
• General-purpose "smart contract" blockchains designed for nodes that contain programmable content
  • For more information: Contracts and Transactions (with Ethereum)

Case Study: MedRec

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

IPFS

tbs

CommonAccord

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.

Legal Contracts

tbs

IAM Systems

tbs

UMA

tbs

...