Fabian Vogelsteller and Oliver Terbu

As chapter 1 explains, blockchain technology is the mother of SSI, pure and simple. The twin pillars of blockchain are Bitcoin and Ethereum, and while both communities have been active in SSI, Ethereum has been a particular hotbed due to the power and flexibility of smart contracts. Leading the charge has been Fabian Vogelsteller, who joined the Ethereum Foundation in July 2015 and has built some of its core applications, including the Ethereum Wallet and the Mist browser. His collaborator in this special appendix describing the evolution and standardization of SSI in the Ethereum ecosystem is Oliver Terbu, identity architect with ConsenSys/uPort since 2018 and an active member of the W3C Credentials Community Group, the W3C Verifiable Claims Working Group, the Decentralized Identity Foundation, the Ethereum Enterprise Alliance, the OpenID Foundation, and others too numerous to mention.

Blockchains are consensus networks; they allow participants to view and modify the state of a distributed ledger using clear rules that are agreed upon by the network. There are many blockchains, and each has both its own rules and its own purpose: the Ethereum blockchain was built to create a distributed computing network.

Ethereum enables its distributed computing through smart contracts, which are simple programs that run in virtual machines: the Ethereum Virtual Machine (EVM) or Ethereum Flavored WebAssembly (eWASM). These smart contracts can be used to take specific actions, such as voting, or to transfer Ether, the native cryptocurrency of the Ethereum blockchain. They cost small transaction fees to run, paid with a unit called gas, which calculates fees in Ether.

Smart contracts can be quite complex: each one has different rules. They might be owned by individuals, by groups of people, or by no one at all. Most importantly, smart contracts can talk to each other, allowing one transaction to trigger a whole chain of actions on the network. This enables a variety of complex business logic, from simple wallets to proxy accounts and, yes, full-fledged identity systems.

But there isn’t just one way to do something on Ethereum. Because it’s a programmable blockchain, anyone can build anything using its Turing-complete smart contracts. The result is a rich and diverse ecosystem. In fact, the problem isn’t finding exciting new things to do on the Ethereum blockchain but instead figuring out how to do them in organized and well-defined ways so that different systems can interoperate. That’s where the ERCs (Ethereum Requests for Comment) come into play: each one defines a way to do something on the Ethereum network.

Two ERCs are of particular note for identity on the Ethereum blockchain: ERC 725 v2, the “Proxy Account,” and ERC 1056, “Lightweight Identity.” They help to ensure that self-sovereign identities on the Ethereum blockchain are interoperable, manageable, and verifiable.

Identity on the blockchain

Blockchains tend to offer specific advantages for identity systems, and Ethereum is no exception. Because blockchains are public databases that are accessible and verifiable by everyone, their identity data is public, too. Because self-sovereign identities on the blockchain are ultimately accounts that are manipulated by private keys, identities can be controlled by persons, companies, or objects; they can be traditional identities, simple profiles, blockchain access points, or avatars. Of course, the Ethereum blockchain moves beyond these traditional advantages because of its programmability. This means that Ethereum identities aren’t just passive data but more complex computer programs.

There are also challenges to hosting identities on the blockchain. First, because blockchains are anonymous, there are issues when other systems need to recognize accounts, understand their relationships, or check attestations and claims.

Second, because blockchain data is visible to everyone, careful decisions have to be made about which personal data is stored on the blockchain (“on-chain”) and which is instead stored elsewhere and linked to from the blockchain (“off-chain”). Each of these methodologies is supported by ERCs, which resolve some of the problems inherent in these schemes. They can each address the challenges of blockchain identity and do so in ways that are complementary, not exclusive.

Third, the keys for an identity need to be managed carefully. They need to be backed up, and provisions must be made to avoid losing identities when keys are lost. Although methods such as multi-signatures and key-recovery schemes such as Shamir’s Secret Sharing exist to solve some key-management problems, nuance is required on Ethereum to support updating or replacing the permissions system associated with a smart contract without changing the identity itself, a topic that requires some additional discussion.

The keys to identity

Today, Ethereum decentralized applications (DApps) are all built around private keys, which are used to communicate with the smart contracts and move assets like Ether. This is both dangerous and limiting. On the one hand, if the private key is lost, then all access to the contract and assets is lost. This can be devastating because it means that the identity is effectively lost: there are no second chances in blockchain. In addition, it effectively restricts the number of people who can access the identity, which is not to the benefit of public identities such as avatars, personas, and company accounts, and also poses risks for key recovery. Any good blockchain identity system thus needs a complex identity-management scheme that goes beyond the simple use of private keys.

First, identity-management systems must solve the problem of updating permissions without changing the identity. One option is to create separate key-management and identity smart contracts. This way, the key management can be upgraded and evolve over time without needing to change the on-chain identifying address. This allows attached on-chain information such as claims, reputations, and other identifying information to stay unchanged even if the whole permission system is replaced. Another possibility is to integrate ownership change directly into the smart contract while ensuring that the account’s identifying address does not change.

Second, identity-management systems should support robust features such as these:

• Multiple access methods—Could include signatures, multi-signatures, or even key-management smart contracts

• Different key types—Could exclusively support managing the contract, taking actions, or signing claims

• Social recovery schemes—Could allow private keys to be recovered by combining information from a variety of associations

Any of these key-management methodologies can apply to either on-chain or off-chain identity solutions, though each may approach the problem in a different way.

On-chain identity solutions

In an on-chain identity scheme, personal information is referenced from the blockchain identity: this could be public profile information or organizational data that is completely published on-chain, or it could be verifiable claims that don’t reveal concrete personal identifying information. An on-chain identity scheme requires a smart contract that supports a key-value store so that both keys (such as “some claim” or “nickname”) and values (such as “Person identified by ...” or “Superman”) can be recorded—either self-issued or signed by the issuing party. This information can then be retrieved and verified automatically by other smart contracts, supporting interactions with ICOs or other gateway systems.

However, there’s a notable drawback to this method: information stored on-chain is public and immutable. Although it may or may not be linked to a human, company, or other entity, it will live forever on the blockchain: even the actions associated with an identity will live forever!

Although immutable information of this sort can be beneficial for a number of public entities, maintaining personal data in such a public and immutable way can be much more problematic: most personal information is private and never needs to be seen by the public. Thus, careful decisions must be made when deciding which identities to host on-chain in this way.

ERC 725 v2: “Proxy Account”

ERC 725 v2: “Proxy Account” supports both identity-enabling key-value stores and a separate key-management methodology by creating a public blockchain profile that is a verifiable, manageable proxy account. Because of the standardization of the ERC, it can be integrated into user interfaces and easily verified by other smart contracts.

Figure D.1 Identity management using ERC 725 v2

The proxy account describes a simple smart contract that has an owner and a key-value store. In this methodology, the owner is the controller of the identity, and the key-value store encodes the attached information. The address of the smart contract then functions as the identifier for the digital identity.

The owner

Although ERC 725 v2 supports the typical DApp methodology of an owner being a simple private key, it also allows another smart contract to be an owner, and that contract could itself have specific rules for how it’s controlled. This supports more complex key-management schemes such as multi-signatures and, more precisely, permissioned keys. Specific keys could even be restricted to only allow interactions with other specific smart contracts on a user-basis—or if the identity is an organization, on a staff-basis.

The controlling smart contract can also support submissions of transactions by third parties, provided that they contain a valid signature from one of the owner keys. This allows gas costs to be paid for by the application developer or by a third-party transaction relay service, without them having any control of the contract—which resolves a traditional problem where interacting on a blockchain otherwise requires all parties to have access to the blockchain’s native cryptocurrency.

Because the owner of an ERC 725 v2 identity can be delegated, the owner of the smart contract can change. This permits the controlling smart contract to update and improve over time without changing the address of the smart contract, and therefore the identity’s public identifier.

The key-value store

The key-value store of ERC 725 v2 allows arbitrary values to be set for 32-byte keys. This simple mechanics permits all sorts of information to be attached to the identity smart contract and proves that the information is permissioned, as only the owner can attach this information.

When this attached information is on-chain, it allows other smart contracts—such as ICOs, insurances, and decentralized exchanges—to automatically verify whether an account is allowed to take a certain action. The key-value store can also link to claim registries, reputation systems, zero-knowledge proofs, other smart contracts, or different types of on-chain identities. This all can occur without revealing anything about the person owning this account.

Although much of ERC 725 v2 is focused on on-chain solutions, its key-value store can additionally link to off-chain data through decentralized identifiers (DIDs) or Merkle root hashes. The flexibility of the ERC 725 v2 key-value store allows identities to record and link to a variety of information, creating an adaptable and thus future-proof identity system.

The public on-chain identity

The heart of the ERC 725 v2 digital identity is an Ethereum address owned by the smart contracts. Traditionally, these addresses were pure public keys, which are hard to manage and hard to verify; ERC 725 v2 is meant to create manageability and verifiability, laying the foundation for public on-chain identities.

These public identities may be quite different from the personal identities and their personally identifying information (PII), which are the heart of many self-sovereign identity systems. Instead, they’re more likely to be public personas, digital avatars, and online influencers; corporations and institutions may also find this sort of public identity useful: they can use public on-chain identities to make their actions transparent, allowing for easy verification and supporting claims issuance. Because on-chain identities of this sort can list relevant information in a provable way, they can replace or supplement today’s governmental registries for companies, professional profiles for workers, and information websites for public personas like stars or politicians.

Finally, on-chain public identities may be useful for some private individuals, such as traders and investors: they support automated on-chain interactions that require trusted and verified accounts—a use case that is currently hard to accommodate but that is now made transparent and safe.

These personal public identities can ultimately be as public or pseudonymous as a user requires. Although an on-chain identity could be linked to personally identifiable information, it might only be identified by specific claims: an on-chain identity for a professional driver could include claims that they have a driver’s license and that they haven’t had an accident or received a ticket in five years, but not include an actual name.

Personal semi-public identities may have even more uses in the future when blockchain pruning could introduce the right to be forgotten. But even absent that, there are clear needs for them in the modern day.

Off-chain identity solutions

In an off-chain identity scheme, identity information is kept in data storage such as hubs that are separate from the blockchain. The data can be linked from the blockchain by methods such as DIDs but is accessible only when specifically requested. This keeps off-chain data private and shareable on a peer-to-peer basis. It also supports strong controls over who can access the data and precise granularity for what data is shared.

Despite the clear privacy advantages of off-chain identity solutions, there are challenges here as well. First, interactions with a blockchain are more complicated; since accounts are just sets of links, they’re essentially anonymous: owners, delegates, and accounts can be verified by smart contracts, but more intensive processes such as Know Your Customer (KYC) can’t provide verification without breaking anonymity.

Second, off-chain identities can end up being less private than intended. If off-chain data is attached to transactions, then they ultimately end up linked to an on-chain account. This creates some of the same publicity dilemmas as on-chain identity solutions.

Third, transactions can bloat in size because of the need to sign data in transactions. And fourth, key management is once again complicated. Off-chain data is likely to be linked to specific keys rather than smart contracts; this means that losing a private key can still mean losing access to data, which can be devastating if it is a signed claim or attestation.

ERC 1056: “Lightweight Identity”

Much as with ERC 725 v2, ERC 1056, “Lightweight Identity,” supports both on-chain and off-chain identity storage, but its lightweight registry is particularly useful for efficiently managing off-chain identity data by using the Ethereum network to increase the trustworthiness of that information. While identity data is managed off-chain, the ERC 1056 smart contract provides an on-chain anchor.

Although ERC 1056 is not specifically limited to public Ethereum networks and can be used with private and permissioned networks as well, it focuses on addressing common challenges of public Blockchains such as cost-efficiency, scalability, and, of course, key management. ERC 1056’s primary use case is helping developers to onboard new users and to provide verifiable identity data.

The lightweight registry

ERC 1056’s lightweight registry serves three major functions. First, it records the owner of an identity. Second, it records delegates that can act on the owner’s behalf for a specified time. Third, it implements a decentralized public-key infrastructure (DPKI) with the ability to add keys and public attributes to the identity, creating a hub service endpoint

These elements enable the registry to secure off-chain identity data exchange, assuming that the identity data is associated with an identifier managed by the registry: another smart contract can authenticate and verify this off-chain data exchange by obtaining the cryptographic information linked to the data through the registry. In W3C verifiable credentials terminology, the holder includes an identifier contained in the registry in the data exchange and signs the presentation with the corresponding public key; a verifier then extracts the identifier and uses the registry to get the verification key of the holder to verify the signature of the presentation.

When keys or attributes are changed, these changes are not written to the ERC 1056 smart contract itself. Instead, Ethereum events are emitted and written to the Ethereum event log. Technically, they are included in transaction receipts, which are verified by Ethereum as the transaction receipt hashes are stored in blocks. The lightweight registry links these events with each other to allow a fast lookup of all relevant changes for an owner. This approach dramatically decreases the gas costs for identity management operations (IMOs). Any of these transactions can also be initiated by third parties as meta transactions. Although the owner still signs the operation, it can be submitted by the third party, who will pay the gas costs of the IMO. Figure D.2 illustrates how involved parties use ERC 1056 to manage or verify identity data.

Note that no personal data needs to be stored on Ethereum using ERC 1056. The DPKI can simply be used to link to hubs where the data is recorded. This may provide better compliance for regulations such as GDPR; there are still ongoing discussions on the topic, but if off-chain identity data is deleted, the on-chain information may no longer be considered personal data.

Figure D.2 Identity management using ERC 1056

Owner and delegates

ERC 1056 allows any Ethereum account to become the owner of an identity by the simple act of controlling its private keys: the owner of the identity is the same as the owner of the corresponding account. Because Ethereum accounts can be created off-chain, there’s no need for an Ethereum transaction; there’s also no need to deploy a new smart contract at this time, as a single ERC 1056 smart contract can track the owners of all identities for an application or a set of applications. These advantages largely eliminate gas costs at identity creation, which is crucial for use cases that need to create billions of identities, such as in the field of the Internet of Things.

Recording an owner on-chain is only required if the owner has changed. If the registry contains no entry about a particular identity, it is assumed that the owner has never changed and the public authentication and verification keys can be derived entirely off-chain by presenting the address of the Ethereum account.

It’s still possible to use a proxy contract, such as a multi-signature contract, to become the owner of an ERC 1056 identity: the owner of the identity simply sets a new Ethereum account as the new owner in the smart contract, possibly using a meta transaction. This approach supports guardianships, enterprise-grade key management, social recovery, or more complex ownership relationships.

ERC 1056 identities can also have multiple delegates, which are Ethereum accounts that can act on behalf of the identity owner for a limited time, or until the owner revokes the delegate. This is useful when an identity owner wants to assign a representative or share the ownership of off-chain data with certain parties. For example, if the off-chain data is a credential used to unlock a smart lock, then the owner could add their partner as a delegate so that they can both access the protected goods.

Other ERCs

• ERC 725 v2 and ERC 1056 are the two most complete identity systems currently being standardized on Ethereum, but the diversity of the ecosystem ensures that there will be more. In fact, several proposals of smaller scope can already be found among the ERCs.

• ERC 734, “Key Manager” and ERC 735, “Claim Holder” work in combination with ERC 725 v2, providing more details on the key management and claims elements.

• ERC 780, “Ethereum Claims Registry,” was in turn written by the author of ERC 1056 and provides standards for both self-issued claims and peer-to-peer claims.

• ERC 1812, “Ethereum Verifiable Claims,” puts claims off-chain instead of on-chain, in part due to the pressure of new regulations such as the GDPR.

By the time you read this, there may be some fascinating new ERCs, approaching self-sovereign identity on the Ethereum blockchain in a new way.

Conclusion

ERC 725 and ERC 1056 are two different approaches to self-sovereign identity that function differently. ERC 725 focuses on making an Ethereum account into a public on-chain identity, which can have any amount of information attached. It is meant to live mainly on the blockchain and interact with other blockchain entities. ERC 1056, in contrast, keeps all of its identity information off-chain. The on-chain smart contract serves largely as a public key registry for that identity. And there will be more, because there’s always another way to do things on Ethereum.