By Dr Paul Ashley, co-CEO and CTO, Anonyome Labs
This article was originally published in Michael Bazzell’s Unredacted magazine, September 2022. To learn more, view the latest issue.
My first article, in the June 2022 issue of Unredacted, introduced some initial concepts around decentralized identity – the new technology that’s giving users greater control over their personal data and identity. Here, I’ll expand on those initial concepts and focus on decentralized identity blockchains—the trust foundation for decentralized identity-based applications and an essential part of the decentralized identity story.
Blockchain = verifiable data registry
The technical term for the decentralized identity component that provides the trust foundation for the whole system is a verifiable data registry (VDR). Similar in its application to centralized public key infrastructure (PKI), the VDR allows users and services to verify their authenticity by proving they hold the private key corresponding to the public key written to the VDR. It is often called a decentralized PKI.
Most people don’t use the term VDR, but rather the more widely known terms distributed ledger or blockchain, to describe how the component is implemented in the system. In reality, there are over 100 distinct VDRs available, built using well-known technologies such as Hyperledger Indy, Ethereum, Bitcoin, Interplanetary File System (IPFS), Hyperledger Fabric, Cosmos, and so on.
Hyperledger Indy
The most successful VDR is Hyperledger Indy. Created within the Linux Foundation, Indy is a public ledger designed specifically and only for privacy-preserving decentralized identity (also called self-sovereign identity). The Hyperledger Indy ledger is for credential issuers to publish data necessary for issuing verifiable credentials, and for holders to construct presentations based on those verifiable credentials.
Anonyome Labs supports and maintains validator nodes for both the Sovrin and Indicio Hyperledger Indy networks. Let’s look at Hyperledger Indy’s characteristics:
| Public ledger | Anyone can read the data on the ledger. |
| Permissioned network | This statement has two different aspects: 1) The Hyperledger Indy network comprises a set of validators that have been approved (permissioned) to run the network. For example, the Sovrin Foundation approves validators to run on its three networks (Dev, Staging, and MainNet). 2) The ability/permission to write data to the Hyperledger network, which allows for writing decentralized identifiers (DIDs), schemas, credential definitions and other decentralized identity-related items. To write to the ledger, an organization must have endorser permissions (which includes paying the appropriate fee to become an endorser). |
| Consensus algorithm | Just like Bitcoin, validator nodes must come to agreement (consensus) before anything is written to the Hyperledger Indy network. Indy uses the Redundant Byzantine Fault Tolerance (RBFT) consensus algorithm. Indy networks typically have 24 validator nodes. |
| Governance | Hyperledger Indy uses an offline and centralized governance model. In practice, that means people work together to create the network’s governance policy, write policy documents and have validators and Endorsers sign the agreements. These governance activities happen in the physical world. |
| Economic model | Application developers pay the organizing company or foundation (e.g. Sovrin) for permission to write to the network. |
Cosmos
Anonyome Labs runs a Cosmos validator node on the cheqd network. For comparison with Hyperledger Indy, here are some characteristics of a Cosmos-based VDR network:
| Public ledger | Anyone can read the data on the ledger. |
| Permissionless network | This statement has two different aspects: 1) Any organization can join the network as a validator.2) Any organization can write to the network. |
| Consensus algorithm | Cosmos uses Tendermint Byzantine Consensus Algorithm (BCA) to establish a consensus between validator nodes. |
| Governance | Cosmos uses an online and decentralized governance model. In practice, that means that any validator can submit a governance proposal to the network, which validators will vote on and either approve, decline, abstain, or veto. All this happens online. |
| Economic model | Cosmos has a very well-defined crypto-economic model: Validators earn tokens through commissions to help run the network.Writers to the network spend tokens. Cosmos also has an economic model for verifiable credentials. |
DID methods
DID methods define how to interact with decentralized identity networks. Since Hyperledger Indy networks are so popular, I’ll focus on the Indy DID method.
Written as did:Indy this DID method describes how to interact with a Hyperledger Indy network, including creating decentralized identifiers and issuing, verifying, and revoking verifiable credentials. It is proposed that in the future there could be hundreds of separately run Hyperledger Indy networks. The purpose of the did:indy method is to facilitate full interoperability between each of these networks.
The Indy DID method defines methods for writing the following data:
Decentralized identifier (DID)
A DID is the fundamental identifier of a decentralized identity in the network. It may be the identifier for a user, a verifiable credential issuer, a service, an IoT device, etc. The DID structure is similar to a web URL.
The DID has four components, which are concatenated:
- DID: The hardcoded string did: indicating that the identifier is a DID
- DID Indy method: The hardcoded string indy: indicating that the identifier uses the Indy DID method specification
- DID Indy namespace: A string that identifies the name of the primary Indy ledger, followed by a colon. The namespace string may optionally have a secondary ledger name prefixed by another colon following the primary name.
- Namespace identifier: An identifier unique to the given DID Indy namespace.
The components are assembled as follows:
did:indy:<namespace>:<namespace identifier>
Some examples of did:indy DID method identifiers are:
- A DID written to the Sovrin MainNet ledger:
- did:indy:sovrin:7Tqg6BwSSWapxgUDm9KKgg
- A DID written to the Sovrin StagingNet ledger:
- did:indy:sovrin:staging:6cgbu8ZPoWTnR5Rv5JcSMB
- A DID on the IDUnion Test ledger:
- did:indy:idunion:test:2MZYuPv2Km7Q1eD4GCsSb6
DID documents (DIDDocs)
DIDDocs contains two primary data elements:
- Cryptographic material the DID owner can use to prove control over the associated DID (i.e., public keys and digital signatures)
- Routing endpoints for locations where one may be able to contact or exchange data with the DID owner.
DID resolution is the process of obtaining a DID document for a given DID.
Verifiable credential schema
A schema object is a template defining a set of attributes (names). A schema is bound to verifiable credential definitions in a Hyperledger Indy network. The bound schema restricts which claims an issuer can include in the credential. Schemas have a name and version, and an issuer or authoritative organization (e.g. government authorities defining license schemas) normally writes them to the ledger. Any client can read schemas from a Hyperledger Indy node.
Verifiable credential definition
A credential definition contains data required for both credential issuance and credential validation. Any Hyperledger Indy client can read it. A credential definition references a schema and the issuer’s DID. The issuer’s public key is included within the credential definition in order to enable validation of the credentials, which are signed by the issuer’s private key. When credentials are issued using the issuer’s credential definition, the attributes (names) of the schema must be used.
Revocation registry definition
A revocation registry definition contains information required for verifiers to determine whether the issuer has revoked a (revokable) verifiable credential. Revocation registry definitions are required for revokable verifiable credentials and are written to the ledger during creation of the credential definition. Any client can read them from a Hyperledger Indy node.[1]
Revocation registry entry
A revocation registry entry marks the current status of one or more revokable verifiable credentials (i.e., “revoked” or “not revoked”) in the ledger in a privacy-preserving manner. The owner of a revocation registry definition writes a revocation registry entry whenever they wish to make a batch (possibly only one) of revocations public and detectable.
Any Hyperledger Indy client can read any revocation registry entry.
[1] The registry definition isn’t ever updated after creation. It binds immutably the revocation detection mechanism (currently the Tails File) to the credential definition. There is an m to 1 relationship between revocation registry definitions and credential definitions. This is because a new revocation registry definition is created whenever the Tails File number of entries is exhausted and a new one needs to be created; the new one will still point back to the original credential definition. The revocation registry entry is updated when credentials are revoked.
