Versions Compared

Key

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

...

 

Table of Contents

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

Status
subtletrue
colourRed
titleObsolete

Note: This wiki version of the Report has been obsoleted by the live Google Docs version. Information confirmed to appear there has been removed from this version.

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

...

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. 

...

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

Blockchain

...

Blockchain Types

...

...

Other axes

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

Smart contracts:

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

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 allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves.  The idea is that clients should refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.  Uses hash chaining to prove the order of events and the existence of transactions.

Benefits: Provides consequences for poor operational security at certificate authorities by increasing the chance of detecting improperly issued certificates.

Weaknesses: Requires widespread buy in before incentives work, privacy tradeoffs with publicly attesting to every certificate issued.

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...

Consent Receipts

...owner: John W?...

User-Submitted Terms

...owner: John W or designee?...

(see Nov 1 notes for a "starter pack" of content)

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

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

...