Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

 

Introduction

tbs - brief history of group formation and launch - audience for this report (primary: Kantara leadership; secondary: others)

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.

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 to contain programmable content

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

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?

 

  • No labels