Different Approaches to Ethereum Identity Standards
Identity as a concept affects all of us. Yet, depending on who you ask, there are many different ideas of what Identity is as a technology.
For governments, Identity is a mechanism for taxing citizens and providing them benefits. In the case of large companies, they need to provide access control to their offices and systems for managing their employees and customers. For web 2.0 companies, Identity exists in the form of Facebook Connect, Google Login, or your good old email address.
For fintech companies Identity is all about KYC. Ethereum dApps might just want to know your Ethereum address. For NGOs it’s about providing Identities to refugees and others without valid forms of identification.
And finally, we have Identity Standards activists who are extremely adamant that users take control of their own identity so that none of these other entities have ownership over it.
As a result of trying to unify all of these different world views, proposed Identity Standards often have difficulties talking in terms that actually make sense to the people they will impact. You hear terms like Claims, Attestations, Credentials, Certificates, Directories, Registries, Identifiers, etc. all purporting to reflect a specific understanding of some Identity aspect.
There have been many different attempts at creating open Identity standards:
- The ITU’s attempt at the horrific x500 family of standards of which x509 is thankfully the only remaining (yet rapidly dying) trace
- OpenID was the first attempt at an open web-based standard allowing users to take control of their own identity. It is mostly used for enterprise login systems today.
- At uPort, we are part of the Decentralized Identity Foundation, where we are trying to learn from previous attempts and create a simple, unifying standard capable of supporting many different blockchain and non-blockchain technologies.
Core Identity Concepts
Almost all Identity Standards support a few basic concepts:
- An identity has some sort of unique identifier
- Parties (sometimes including the identity themselves) can make claims about an identity. Claims are basically attributes, such as a name, address, email, etc. The reason the identity world calls these ‘claims’ is that they are not necessarily treated as facts unless you trust who makes the claim.
- There is some way of asking a user for their identity.
- There is some way of looking up claims about an identity.
ERC 725: a Proposed Ethereum Identity Standard
Most recently, Fabian Vogelsteller proposed a standard ERC 725 for managing Identity for users on Ethereum. It consists of the following parts:
- An Identity is identified by the address of an Ethereum Smart Contract implementing ERC 725
- An integrated key management scheme
- A proxy contract interface, for interacting on the Ethereum blockchain using the Identity
- A claims registry for the given identity allowing any key pair-based account to make claims publicly on the blockchain about the identity
- A way of looking up claims in that registry (actually defined in ERC 735)
- Proposal to build up a standard Ethereum taxonomy of claim types
The ERC 725 simply specifies an interface, just like the ERC 20 Token standard did before it. Thus people can implement them as they wish. This design decision has a bunch of implications on security and upgradeability, which we will discuss in this article.
One important concept and a major difference to note about uPort is that each Identity manages all the above in a single, monolithic smart contract instance owned by the Identity holder.
Other Initiatives
uPort: an open Identity platform built on Ethereum
uPort consists of a combination of Ethereum Smart Contracts, some which are shared and some specifically owned by the Identity owner, including:
- An Identity is identified by an MNID encoded Ethereum address. MNID includes the Ethereum network ID and a checksum, making it safer to use in a world where users regularly transition between Mainnet, multiple test networks, and private chains
- A very simple optional proxy contract designed to live permanently with key recovery and management delegated to an upgradable Identity Manager contract
- One or more shared registry contracts for storing public claims on chain (we’ve recently proposed ERC-780)
- A decentralized PKI (Public Key Infrastructure) system allowing identities to share and verify signed data privately off the blockchain, but verified via the above registry contracts
- A JWT-based messaging standard built on top of the above PKI system
- Standard methods and flows for requesting private data
- Standard formats for signing private off chain claims about uPort identities
- Implementation of the proposed DID (Decentralized IDentifier) standard from the W3C Credentials Community Group and the Decentralized Identity Foundation.
- Views claim types as opaque, such that any new or existing claims taxonomy can be used, eg. W3C Verifiable Claims
uPort has individual smart contracts for individuals, but is not a monolithic standard. It consists of a combination of smart contracts owned by the user and shared contracts for efficiency and safety’s sake.
Decentralized Identity Foundation
The Decentralized Identity Foundation (DIF) was created by uPort, Microsoft, Blockstack, Sovrin, and others to establish a very simple, common framework for making claims about identities using different kinds of decentralized technologies.
With the rise of blockchain technology, there has been exponential growth in the different number of blockchains in existence, with Ethereum and Bitcoin establishing the most traction thus far. Additionally, there are also several non-blockchain, decentralized platforms, such as IPFS and SWARM.
Since DIF was created to support interoperability between completely different types of implementations, it only has to concern itself with a very narrow layer.
Any identity is represented by it’s DID (Decentralized IDentifier) consisting of did:[method]:[method specific identifier]
eg did:uport:2nQtiQG6Cgm1GYTBaaKAgr76uY7iSexUkqX
Each DID has a DID document which contains its public keys, any public claims made by the Identity, and optional endpoints that can be used for interacting with the Identity.
A resolver is implemented to lookup the DID document for a given DID using the specific methods underlying that technology. For uPort, for example, this looks up an IPFS hash in the claims registry, which is used to look up the document on IPFS.
W3C Verifiable Claims
Where the DIF is working on a high-level definition of what a Decentralized Identity is and how to interact with it, the W3C has been working on standards for different kinds of claims about an Identity.
Any Ethereum address should be able to be an Identity
As a whole these standards are fairly similar to the on-chain aspects of what we have in uPort. One main difference however is that with uPort any Ethereum address is basically a uPort identity.
With uPort, there is no need to implement a special interface, since regular key pair-based accounts are just as valid as smart contract-based uPort Identities.
This is particularly important as deploying smart contracts involves serious costs. The costs may be fine in the beginning, but if we also want these standards to work for IOT, where there could potentially be millions of devices needing to make and receive claims about themselves, it is not realistic that each device starts by deploying a contract to the blockchain.
An interesting part of ERC 725 is that only smart contracts can be identities, yet only key pair-based accounts are able to make claims.
With uPort, both account types can sign and receive claims.
Upgradability
Our proxy contract and upgradable key management contracts are just one specific implementation; a proxy contract is essentially a multi sig wallet contract and it is critical that the basic logic can be upgraded.
There are already other ERC standards for handling key management in multi sig contracts that should be built on instead of trying to reinvent the wheel.
There is an incredible amount of innovation happening within the world of wallet contracts, which is why we believe that the exact interface and implementation of it should not be defined as part of an identity standard.
In reality, as part of the identity flow, there is really no reason for any third parties to ever concern themselves with how you manage the keys for your identity contract.
A claim system needs to be resilient to breakage in signature schemes that is likely to happen with the introduction of quantum computers. To accomplish this it needs to support the addition of new signature schemes.
While ERC 725 does support different kinds of siguature schemes, the burden of verification of these signatures is given to the consumer of the claim.
If the consumer is a smart contract, it needs to implement all the current schemes, but it can obviously not implement any future schemes. This means that when a new signature scheme is introduced it will not be supported by a majority of smart contracts that want to verify claims.
In our proposed ERC 780, this problem is solved by simply using the regular Ethereum account abstraction, which can support any kind of signatures.
Safety in the Commons
Claims created by someone are meant to be trusted. This also means that the basic infrastructure used to store, view, and verify these claims need to be trusted.
As a user, you want to be able to trust that the key management of your identity contract works, but for others, they are primarily concerned with whether they can trust that the claims listed in your identity contract are correct, regardless of if they represent good or bad information about you.
Due to the potentially untrusted source code of ERC 725 implementations, it requires the complexity of actual signatures included in the on-chain claims.
The uPort approach as represented by ERC 780 instead uses shared common contracts that are easily reviewable and understood. These contracts are not controlled by anyone and can thus be thought of as a form of common good, as anyone can deploy their own with newer features. We are now on our third version of this registry and welcome others to innovate in this area as well.
Public vs Private information
Once you work in the blockchain space it is very easy to fall into the trap that all information should be public. Public information is important and has its place, but it is not suitable for everything.
We believe that Ethereum will be one of the most important technologies and touch all aspects of our lives. However that does not mean that I feel that all information about me should be available to anyone able to write a Web3 Javascript dApp.
This is not just shared by us at uPort. The number one fear people/implementors/regulators have about blockchain identity is if private information has to be stored on the public blockchain.
Currently, the only information uPort requires to be stored publicly in the registry is a public key that can be used to verify signed data.
Most of the claims created about uPort Identities occur completely off the blockchain. The signatures are verified through our registry of course, but the claims themselves don’t need to ever hit the blockchain.
Gas costs
At uPort we are designing an identity platform that could potentially have billions of Identities (people, organizations, trees, shipping containers, devices, etc.).
To do this we need to think about minimizing the amount of transactions needed to create, manage, and interact with your Identity.
We are constantly thinking of how to improve this as well as improving the gas economy of our contracts.
We realize it’s early for ERC 725, but as currently written, it is very inefficient. Most operations require two transactions to be completed: one for proposing it and one for approving it.
Adding a claim is a transaction, approving it a second. In the uPort approach, no transactions are needed in most cases as most claims are private.
Monolithic vs Layered
The internet was built on a series of relatively simple standards that do just one thing. By layering these on top of each other, everything from Ethereum to Google to Tinder is possible, and works on different devices and network types.
We think it’s extremely important to follow the same approach when building standards on top of Ethereum. This allows us to focus on each problem area with one or multiple ways of solving it. It’s not a take it all or leave it all approach. It also makes it easier to build hybrid applications that use Ethereum where it’s needed and not where it isn’t.
uPort takes this approach and we are always ready to insert, swap, or remove layers as needed.
The following Diagram shows the layers used for basic Identity use in uPort and ERC 725:
The key takeaway here is that ERC 725 has almost everything incorporated into a single Monolithic Standard/Contract.
With uPort, almost any layer can be updated and innovated on separately. Each section from the bottom up to any arbitrary layer is useful on its own, without needing the rest.
For example if you only need on-chain claims, all you need are the layers from ERC-780 and down. You could create your own off-chain applications using uPort by building on top of the uPort Compliant JWT’s without interacting with the higher level identity constructs in the top two layers.
Identity and its multitude of use cases is complex and not something you can just solve in a single document. We believe it makes most sense to create different layered standards, and where it makes sense, work with people outside of the Ethereum world as well.
Join us in building and defining the next generation of identity standards
ERC-725 is ultimately too narrow, and unfortunately, developers will likely quickly reach its limits. uPort has been designed from the beginning as an intentionally open platform. We even encourage others to build competing identity wallets on top of the uPort protocols.
Our proposed on-chain claims registry, ERC 780 can be found here, and we need more eyes on it. Our current version, the uport-registry is also completely open for review. We will migrate to ERC-780 once it’s finalized.
We are constantly working on improving our Proxy and Access Control contracts in our uport-identity repo. Anyone can use these and we happily review and accept PRs if they make sense.
Finally, the entire uport-protocol specs are also available on github. Remember identity is mostly off-chain in the real world. We are also constantly updating these. We are in particular interested in new use cases you might think of.
So please take a look at our work thus far as well as our proposal for ERC-780, and let us know what you think. We look forward to working with the community on pushing forward the next generation of identity standards.
