What Goes on the Ledger?
Self-Sovrin Identity is the solution for a fundamental problem of the internet: it was not designed with an identity layer. As a result, each website owner and service provider must gather the same information, and we are continually required to provide more information than necessary for using online services. This practice has left our personal information scattered across the web, in data-silos that make an attractive target for hackers. HyperLedger Indy \ Sovrin is part of an effort to replace those data-silos with a decentralized internet-wide identity layer. Here, we’ll discuss exactly which data ends up on the Indy ledger, as it was designed to be used. First, let’s review what type of ledger that is.
Based on feedback at Ernesto.Net, people tend to think of blockchains as being either public and permissionless, or private and permissioned. Bitcoin and Ethereum, for example, are public — permissionless networks. Anyone can read and\or transact on those blockchains, while validators are chosen randomly in a competition to solve a cryptographic hash. Hyperledger Fabric or R3’s Corda, on the other hand, are private — permissioned chains. Each participant in those networks requires specific permissions to read, write or transact, depending on their role. Hyperledger’s Indy is distinguished in that it is public and permissioned.
HyperLedger Indy is designed so that anyone can read the contents of the chain and transact upon it, but only Stewards participate in validation. An Internet-wide identity system must be public, or else how could it be used? But why permissioned? Phil Windley wrote on the subject in 2016, explaining that permissionless networks must protect against Sybil attack, and require incentive systems to make attempts at cheating costly. As a result of those incentive systems, even honest use of those networks is more costly. Additionally, when something goes wrong in a permissionless ledger, code maintainers must choose how to resolve the matter without clear governing principles.
Permissioned ledgers, such as Sovrin, have no issues of Sybil attacks because validators are known, and pre-vetted parties. Sovrin also has a clear governance framework, so that if there are any problems with the ledger, there is an unambiguous process for resolving them.
While I don’t believe it’s necessarily a competition and that both kinds of ledgers will co-exist to meet different needs, I believe that permissioned ledgers have an edge in establishing trust with claim issuers and relying parties alike. A governance process allows a clear case to be made about trust and process. — The Legitimacy of Permissioned Ledgers
What Goes on the Ledger
Since HyperLedger Indy supports a public ledger, no private-personal information is written on it. With respect to GDPR, PII and other privacy issues, this is a critical advantage. Instead, the distributed ledger is used to maintain the information required for identity owners to transact with each other and organizations within the network.
The HyperLedger Indy ledger was designed to store DIDs, their associated public keys, and communication endpoints. DIDs are a specification for decentralized identifiers, under development by the Credentials Community Group of the W3C. There are both public and private DIDs. Public DIDs are added directly to the ledger. For example, a public institution may record a DID to the ledger so that anyone can verify their public key and any information associated with it. A private, or “pairwise pseudonymous” DID is both stored and shared off-ledger.
Each DID resolves to an associated DID document, a JSON-LD file containing metadata such as service endpoints, identity information, and cryptographic keys. In the case of a public DID, this document might also include name, address, website, and other information useful to the public.
A new pairwise DID is created for every private relationship, stored off-ledger and encrypted. No information related to a pairwise DID is stored on the Sovrin ledger.
In addition to public DIDs, the ledger contains schema defining the various elements of a credential. For instance, every passport credential will be composed of the same types of data including name, date of birth and passport number. Schema definitions support the standardization of data types out of which credentials are made. This way every issuer of passport credentials can use the same name and format for each type of data stored, enabling interoperability.
Schemas are the basic building blocks of credential definitions. Each credential issuers uses schemas to create credential definitions, suited to their specific needs. These definitions may be composed of attribute types from various schemas, and are not bound to a particular schema or its data types. Credential definitions also contain attribute specific public verification keys, bound to the private key of the issuer. In addition to allowing for the re-use of existing schemas for storing data, this enables verifiers to look up a credential definition on the ledger and verify its keys, proving the integrity of the identity owner’s credentials.
Finally, the HyperLedger Indy Ledger stores revocation registries, allowing the issuers of credentials to revoke issued credentials in a way that doesn’t reveal personally identifiable information regarding who’s credentials were revoked.
A revocation registry is written to the ledger by the issuer for each type of credential it issues. This registry references the credential definition and contains a single (long) number called a cryptographic accumulator. This number can be checked instantly by anyone needing to verify a credential, to ensure that it hasn’t been revoked. The value of the accumulator changes when a credential is either added or removed from the list. From the number itself, it is impossible to know whether a particular credential is included in the list.
The credential holder can use the cryptographic accumulator to create a zero-knowledge-proof that their credential is currently valid. Then the relying party checks that proof of non-revocation against the cryptographic accumulator, to instantly know whether the credential is still valid or not. When issuers need to revoke a credential, they merely remove its hash from the list of credentials that make up the accumulator and post the new number to the ledger. At that point, while still retaining the credential itself, they can no longer create a proof of its validity.
The HyperLedger Indy ledger is used to store only public information and no private data of any kind. Organizations use it to create public identifiers that can be used to prove the off-ledger interactions they have with identity owners. Private data is exchanged ‘peer-to-peer,’ and the public ledger is used to verify the integrity of those exchanges.
Note: this is true for HyperLedger Indy as deployed in the Sovrin network’s “privacy by design” architecture. Organizations outside of the Sovrin network might choose a different design philosophy. However, Indy was designed to be used as discussed here and is taught in this way also by the Linux Foundation.
What goes on the ledger?
* Public DIDs and associated DID documents with verification keys and endpoints.
* Schemas and credential definitions.
* Revocation registries.
* Agent authorization policies.
What does -not- go on the ledger?
x Private DIDs.
x Private credentials.
x Consent receipts or records of credential exchange transactions.