Identity Agents & HUBS: Messaging API’s & the “Layer Model” & Functional Architecture for S.S.I. Blockchain – working session

From IIW
Jump to: navigation, search

Identity Agents & HUBS: Messaging API’s & the “Layer Model” & Functional Architecture for S.S.I. Blockchain – working session

Tuesday 1H

Convener: Nathan George

Notes-taker(s): Ed Eykholt

Tags for the session - technology discussed/ideas considered: blockchain, self-sovereign ID, architecture

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Better title: Functional Architecture and considerations for Identity on Blockchains

Nathan George / Evernym/Sovrin

  • Ledger Identity Models
    • What is a blockchain?
    • Proof of existence. We all agree
    • Proof of "before". "After".
    • "Trustless" system -- can use the crypto math to verify. Collectively we all agree.
    • Byzantine Fault Tolerant consensus
    • Often blockchains will have:
      • Smart contract layer
      • Consensus layer
      • Ordering layer
      • Distributed Smart Contract architecture allows for more validity.
      • Two basic models for blockchains UTXO (Bitcoin) and Smart Contract/State (Ethereum)
    • What do we want to do for Identity on blockchains?
    • An entity is represented by a cryptographic key. (Key management)
    • Identifier, Keys, Attributes (bind to keys and/or identifiers
  • Why is a blockchain needed?
    • It's not, but it’s a way that everyone can equally trust the root of trust.
  • Is identity on the blockchain enabling the bad guys?
    • It could if verifiers must disclose those events. (making correlation easier).
    • SSI opposes implicit tyranny, but doesn't stop it.
  • Risks of on-chain identity data is Correlation.
    • "Keys constitute a unit of correlation". If you want something not correlated, you need to use another key.
      • Anti-correlation is wicked hard: must Avoid ANY majority and Avoid ANY minority.
      • Sovrin calls these parties Trust Anchors, building out a web of trust.
      • Correlation is contagious!
    • Usability. E.g., to get around correlation? How much is enough, and how much is too-much?
    • Don't put too much on the ledger, since it can't be undone.
  • Patterns of interactions
    • Most occurs off-chain (see below)
    • Initiated by Issuer
      • When there are credentials issued there are B.L.T. (Business, Legal, and Technology) guarantees.
    • Initiated by Holder
      • The unit of interoperability is what the holder decides to tell someone else, not the issuer.
      • Most selective disclosure should be based on ZKPs.
      • Identity Agent
        • An Identity Agent (software that control keys and can sign on behalf of the entity) is needed. … delegate responsibility to a key and later revoke it. In case an Identity Agent goes rouge.
      • Key Management
        • Other keys can be used for private, off-ledger interaction. For details, see DKMS topic/session.
          • See also Identity Mixer, U-Prove, Indy's Anoncreds.
          • Blinded Commitment / Petterson Commitment
  • On-Ledger Data (public ledger)
    • OK
      • Bootstrap consensus of ledger, establishing web of trust
      • Addresses of blockchain nodes
    • Not OK
      • Identifiers
      • Attributes (which bind to keys and/or identifiers)
      • PII, Biometrics
    • Concerns
      • What is "secure" now might be secure now, but it must stay secure on human timescales.
      • See magic penny video by Sam Smith. Not all the pennies are in one safe.
      • One can have a mountain of data, but they must not come along with the keys.
      • Equifax and others know more about us than we can remember.
  • Off-Ledger Interactions
    • Exchange of Verifiable Information
    • Agent Messaging Protocol (for off-chain …)
    • One of challenges in designing an ecosystem is to enable Verifiers to pay Issuers.

Tu1H.1.png

Tu1H.2.png