In the grand picture of decentralized identity, the leger plays a relatively boring role; it’s an important role however, and we’ll discuss why.
By Sam Curren
When exchanging verifiable credentials, there is information that needs to be known by all participants in the ecosystem or network; a distributed ledger, such as the Indicio Network, stores this information to facilitate verifiable interactions.
The following information — and only this information — is, typically, stored on the ledger:
DIDs for an Organization, Company, or Institution
A Decentralized Identifier (DID) is an identifier that is linked to public cryptographic keys and a service endpoint. These are used to verify credentials from a particular issuer; the endpoint allows you to communicate with that issuer.
Generally, public organization DIDs comprise Issuer DIDs, Verifier DIDs, and the DIDs of other well-known authorities.
Credential Schemas
A credential contains information and Schemas define the different fields containing that information. For example, if you look at a physical driver’s license, it will have sections for birth date, address, height, and weight. Each of these fields would be attributes within a Schema for a driver’s license verifiable credential.
TDLR: The Schema stores the definition for the attribute but not the specific values for the attribute.
Credential Definitions
These are specific to the use of the AnonCreds credential format with Hyperledger Indy. Credential Definitions link a cryptographic key to each of the attributes in a Credential Schema. This allows a holder of a credential to share information in privacy-preserving ways, such as through selective disclosure (only a single attribute is shared) or a predicate proof (an attribute value can be numerically assessed without the actual value being disclosed, such as >21 or <21 for purchasing items that have legal age requirements).
Revocation Registry Accumulators
This provides a way of signaling which credentials are valid by keeping track of which credentials have been revoked and which have not been revoked. It is called an accumulator because the information on non-revoked and revoked credentials is compiled into an aggregate value without revealing the underlying information. As a consequence, the accumulator does not directly reveal the revocation status of any individual credential. Instead, this aggregate value is used by the credential holder to prove that their credential has not been revoked. This calculation is called a “proof of non-revocation.”
Put simply, the revocation registry accumulator is a way of proving your credential is valid.
What’s not on the ledger
Personally Identifying Information (PII)
No PII or personal data of any kind is recorded on the ledger.
Credential Issuance
No information about the issuance of any individual credential is recorded on the ledger.
The Verifiable Credential
Verifiable credentials are not written to or stored on the ledger in any context.
One of the most powerful features of decentralized identity is that you can create an ecosystem of millions of people using millions of credentials with only three or four writes to the ledger: the credential type, the schema, the credential definition, the issuer DID, and the revocation registry
How do we ensure no personal identifying information ends up on the ledger?
Distributed ledger networks prescribe rules for who can write and what can be written (no PII!) to a ledger and these rules are enforceable through legal agreement. These governance rules typically require that writes to a ledger must be approved by a Transaction Endorser.
Seems complicated — why bother using a ledger?
The question “If you’re only going to write three-to-four things to a ledger, why have one at all?” comes up a lot. But these three-to-four things are critical to the way a decentralized ecosystem functions and as a consequence they need the following features provided by the ledger:
- Immutability: The data cannot be changed—by anyone. Having the Schema change underneath a credential would cause chaos.
- Tamper resistance: The structure of a distributed ledger makes it very difficult for a malicious actor to break in and change material. For example, if you wanted to change the private key associated with a DID you would have to break into the ledgers of a significant number of network nodes, whereas in a centralized system, you would only need to compromise one database.
- High availability: A ledger is distributed across many nodes with each containing a copy of the ledger. If one node goes down for any reason, there are plenty of others to receive data from.
- Geopolitical and infrastructure diversity: By hosting the ledger on servers located in multiple geographic areas and by diverse organizations, network resilience to technical problems is maximized—data is capable of being written and read even if multiple nodes succumb to problems.
It is technically possible to run a decentralized ecosystem without a ledger. It is possible to achieve immutability and tamper resistance by using some other technology. But as of now, the technology required to provide those features is extensive and will often come to resemble a ledger anyway. With a few exceptions, it turns out that an existing, purpose built ledger is actually the perfect tool to support decentralized identity ecosystems.
This is why Indicio uses Hyperledger Indy.
If you want to learn more about ledger technology and how it could help your organization our team of technical experts has years of experience implementing any type of use case you can think of, schedule some time to talk them here, or learn more about Proven, Indicio’s ready to use solution for setting up your own decentralized ecosystem.
