Status has been working on our own identity implementations. Ricardo will post about the technical work being done, and I have put together a summary of the latest thinking here to introduce people to the subject and encourage broad discussion.
On a personal note, the project of building a permissions system on top of a permissionless, pseudonymous and shared computational substrate has always been, imo, a conceptually awkward one. Our work sidesteps this a bit by focussing mainly on easy key recoverability, ENS integration and other great UI components that just make using decentralised tech easier in general, rather than trying to specify how it ought to be used.
Identity is contextual, fluid, and - most importantly - emergent. It arises out of the ways in which we interact in a given space with a given set of products, people or services. This notion has strong support from both psychology and neuroscience, which tend to treat the brain and its competing centers of interests, impulses and capabilities as something far more like a parliament than a monarchy, more like an impromptu play or communal narrative than a single author blithely italicizing experience from above.
My favourite people on this topic are those like Carl Jung or David Eagleman.
Building identity qua identity (i.e. an identity system that exists in and of itself, expressly for the purpose of identifying people) will likely never take off in my opinion, or - if it does - it will not be nearly as beneficial as people working on the issue now seem to think. This is perhaps a controversial view, but blame the cypherpunk in me, who prefers privacy and deniability to authorisation.
I think this is why there are seemingly endless discussions about the “right” way to implement a sensible and flexible enough framework for identity.
ERC 725 and 735
In Ethereum, there are four key pieces of the puzzle worth discussing: ERC 725, 735, uPort and Vinay Gupta.
725 is a set of standard functions to build a unique identity for humans, groups, objects and machines. This identity can hold keys to sign actions (transactions, documents, logins, access, etc), and claims, which are attested from third parties (issuers) and self attested (which is where 735 comes in), as well as a proxy function to act directly on the blockchain.
735 is a standard set of functions that describe how to handle the claims mentioned above. It’s important to note for now that it could be extended to accept claims from a claims registry, which is what we’ll talk about when we get to uPort.
Basically, identity in this regime comes down to management of keys and claims. Claims are really where the implementational disagreements arise in the community. Keys are just hard for anyone to keep safe, but because you can hold lots of them in HD tries and other groovy structures, you can do all sorts of interesting things related to the different and fluid parts of your identity, like seamless logins (ERC1078) or signed messages with refunds (ERC1077 and our own gas relayer work).
Phew, sounds complicated, but basically this specification was chosen to allow more flexibility and experimentation around identity. By having each person’s identity in a separate contract it allows for cross identity compatibility, but at the same time extra and altered functionality for new use cases.
The uPort team has a slightly different take on the matter after a year and a bit of investigation and research, which I think is worth paying attention to. They have two competing standards, 780 and 1056. Their response might best be summarised with this:
"With our standards, there is no need to implement a special interface, since regular key pair-based accounts are just as valid as smart contract-based Identities.
This is particularly important as deploying smart contracts involves costs which, if we also want these standards to work for IOT, are not realistic. Each device cannot start 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 our work, both account types can sign and receive claims."
Basically, 725 (and 735) want to deploy a unique contract for each address interested in issuing or signing claims to do with identity. This is flexible, allows for potentially interesting future use cases that haven’t really been thought of, and have a fair deal of community support. It also is arguably “more decentralized” - imagine the identity registry gets hacked or killed like a Parity wallet one day… What then?
uPort want to deploy an on chain registry contract (780), and then use a really “lightweight” standard (1056) in which the focus is primarily on a “limited use of blockchain resources” and making sure that any address can operate as an identity for free and can be created offline (recalling some work with refugees as an instance in which people would not be able to deploy their own identity contracts).
To be honest, I lean conceptually more toward some of the uPort arguments (especially given that there need not be one registry - so that adds resilience - and because identity is free and can be done offline, which I think are both critical for real world adoption). However, I am not certain of their standards, and it seems the community is more keen to use 725 and 735 than to implement uPort’s stuff (just anecdotally). Comments like this highlight the use of events as limited and a bit worrying, and show up that they weren’t exactly correct in their assessments of their own work.
uPort has paid seemingly close attention to the host of other work on identity which has been done over the last few decades, are fully compliant with the W3C DID spec. This is debatably a good thing.
I think it is worth entertaining quite seriously the standards uPort has put forward, even though we have only implemented 725 and 735. Ricardo will give more reasons why in his technical post. Luckily for all of us, there is a wiki page with pros and cons to the different approaches, so go there!
The final piece of the puzzle in what has become another long post is Vinay Gupta. He says that there are massive ontological differences in most people’s conceptions of identities. This makes it hard to build appropriate and useful technologies. Basically, the best we can hope to build is trust models that interoperate.
The problem, especially when it comes to identity, is that though there are very reliable averages in biology, identity is really an “irregular mess of edge cases” and that:
“If you build a system that kind of sort of works for the average case, it will be completely harassed by the things that nobody ever thought of when they built it, and then it will become an enormous maze of exceptions.”
That same exact pattern is behind almost every single government, bank, law and piece of software I have ever interacted with. #BreakThePattern
So, “identity” - much like the term “Intellectual Property” that RFS so raged against - is just a magnet word for bad thinking in the end.
“Everybody thinks, ‘Identity is that special me-thing, we just need to find a way of naming that,’ but in practice, it’s almost impossible to get a reliable expression of this identity concept in a way that allows other people to recognise it, never mind the machines, and this mismatch between how we feel our own identity and the problem of dealing with identity as a bulk property of enormous numbers of people means that our intuition about identity is almost always completely backwards.”
Hmm, awkward, where does that leave us? Well, we should probably look at a different question, which is not the insoluble identity problem but the consequences of identity. A working identity system should just let us get things done, unsurprisingly.
Gupta goes on to describe a system that lets us make good decisions often enough that the weight of the good decisions outweighs the weight of the bad decisions, using insurance in an interesting and novel fashion. I’ll leave the details to you.
You can, using the right insurance scheme, get to essentially zero knowledge proofs of identity without any of the really complicated maths and cryptography. This is also not the only idea for zero-knowledge authorisation schemes that don’t rely on fancy numbers; API keys seem to be a good candidate for this kind of approach too.
I like his approach conceptually - it doesn’t fall into the same traps as some (if not all) of the people thinking about technical standards and ERCs. It’s fairly simple, intuitive, and has some really neat consequences, but there are still some fairly obvious holes.
It’s also worth mentioning that there is obviously a long history to trying to do identity right which is worth delving into and that there are many people outside of Ethereum working on this same problem. The most interesting other blockchain project is like Sovrin, where the focus is on multi-source identities:
“Multi-source identity emphasizes relationships instead of identifiers. Identifiers still exist, but they’re not the primary focus. In Sovrin, each relationship is represented by a pairwise, pseudonymous identifier exchange2. These identifiers are linked to public-private keypairs so that each relationship can be validated by either party and supports private, confidential communications between the parties to the relationship.”
. . .
And that’s it for now. Tell me why I’m wrong, and where I was inaccurate!
We are continuing work on 725 and 735, about which Ricardo will post shortly. Feel free to join in our contracts repo and make sure to check out the different branches there to see all the awesome work that is happening across the board.
I shall end this now ridiculously long summary with a cute animal picture, because Jacques’ work on Vyper has me thus inspired.