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

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.