Identity: What's It All About?

[cryptowanderer]

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.

uPort

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!

Vinay Gupta

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.

Beyond Ethereum

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.

[ricardo3]

Status wants to support Identities for a better user experience with Status and other Ethereum Dapps.
So before I go fully into code, I want to share my vision of what is being implemented.

Keys

Self-sovereign Identity Keys (ERC725) is an access list for Ethereum addresses with four defined purposes: Management, Action, Claim Signing, Encryption.

• Management Purpose is allowed to alter setup of Identity, such as key management and claim management, and any other configuration regarding identity behavior.
• Action Purpose is solely to allow a key make calls to other contracts.
• Claim Signer Purpose is solely to allow other key set a pending claim to signer.
• Encryption keys purpose is not fully developed, but probably would be to extend off-chain capabilities - as Identities cannot sign messages, but their keys might be able to, and thus being useful for future applications.

This is still up to improvement and suggestions.

Claims

Self-sovereign Identity Claims (ERC735) are an emerging need for many new dapps that allow only users with specific certifications.

Certification

The idea of Identities Claims is that DApps can check user property (claim topics) without needing to disclosure its pseudo-anonymity (identity address).

Topics

For example: age, nationality. Both usually needed for ICOs and casinos that might want to compile with some classic government or, in near future, DAO regulations.
As many of this properties would be wide required by many apps, instead of each dapp checking a user property, the app trust a certifier that does somehow that checking.

Certifiers

For example, certifier could be a centralized government or a DAO that requiring photo of ID and your address written by hand sent to random judges in the world.

Account Abstraction as a Smart Contract

User Account (Identity) now is a contract, this means we can programmatically change its behavior to our imagination limits. This is helpful for providing a better user experience to our users, like multiple transactions, recovery process, gas relay.
This tooling is not exclusive to Identity, any contract (as MultiSigWallet) can implement derivatives of this to enhance user experience.

Recovery Process

Allows user to start a recovery process from a predefined contract address, which can be a centralized authority (not recommended) or a secret multisig with your friends addresses (friends recovery).

Friends Recovery

I’ve been extensively calling this friends recovery (secret multisig). The reason is to bold to its technical view - and I think we might need a better name for this.
The Secret Multisig contract allows you to setup:

• a secret salted hash of threshold (secretHashedThreshold;
• array of secret salted hash of address (secretHashedAddresses) ;
• hash of secret salt (hashedSecret).

To make a call from the Secret Multisig you need the secret addresses to make a call to approve(bytes32 _secretCall) passing a hash of secret salted _data (secretCall) parameters _tlist of allowed, _threshold revealed , data.
If the address is an externally owned address, the recoverer could add this signatures by deploying them in approvePreSigned(bytes32 _secretCall, uint8[] _v, bytes32[] _r, bytes32[] _s) , or the addresses, specially contracts, can call the function allow.
Anyone can call the above functions, because the contract dont know who can allow and cannot, this will be verified at revealing execution.
When the threshold is met, the recoverer can reveal the secret salt and the list of addresses that allowed by calling:

function execute(
/* Revealing Current "secrets" */
    bytes32 _revealedSecretSalt, /* secret salt revealed */
    address _callDest, /* address being called, _to of secretCall */
    bytes _callData, /* data being called, _data of secretCall */
    address[] _friendList, /* revealed list of multisig needed for the call */
    uint256 _threshold, /* threshold revealed */ 
/* Setting up next recovery */
    bytes32 _newSecretSaltHash, /* substitute secret salt */
    bytes32[] _newSecretHashedAddress /* substitute new list of "friends"
    bytes32 _newSecretThreshold /* new amount of signatures needed */
) external

Gas Relay

Allow user to provide Ethereum signed messages from keys to gas relayers that would deploy the signed messages in transactions calls to the identity in reward of a proportional gasPrice in a token held by Identity, in terms defined by Identity.

Multiple Send

Allow user to make consecutive calls in the same transaction - this is perfect for moving different tokens at same call and fixes the ERC20 approve and call problem, because Identity can make both calls happen consecutively at same transaction, avoiding race conditions and being more user friendly.

Proxy Contract Factory

Allow user to use a safe immutable version of Identity previously deployed as code, and using evm opcode delegatecall in a cheaper contract to deploy.

Limited Upgradability

Allow user to replace the version of code its using at delegatecall.
Because of ability of upgradability remove “recovery process”, this should be only done by Recovery address or upon a time delay to allow rightful owner to avoid takeover from a compromised key.

[ricardo3]

Status Identity Support

Status would use Identity to enhance user experience in Status Network and other DApps.
For Status having an Identity is an optional that upgrades from a simple key account to a contract account that provide additional methods.

Status Wallet would support making transactions for the Identity (by user held keys) in any dapp (even if they are unaware of Identity), could be displaying certain badges (claims), Account Tab would managing identities (editing keys, claims), could support user-to-user claims.

Abstract Identity and Claims

ERC725 is just one of many options of contract account interfaces Status might want to supports, maybe some users want to start using Gnosis/Consensys Multisig Wallet, or Gav Wood/Foundation Multisig, that have different features.
ERC735 is just one of many badges/certifications interface Status Wallet might want to support, maybe some users want to start using the Claim Registry contract and a simple key.
The Claim Registry obviously is a singleton instance that would be used by the Identity objects of this other type of claim system.
Therefore, making Status be able to support any type of Identity implementation, as needed.

ERC725 & ERC735 initial support

Status should start supporting only ERC725 and ERC735, but the architecture of its implementation should think about future porting multiple types of interfaces for multisig and claims.
One way of doing this is by Application implementing its own abstract class of Multisig and Wallet and having a more specific concrete classes for ERC725 and ERC735, initially used by default (as is the only supported).
If later we see demand for other types of Multisig and Claim interfaces, we can extend the client and add a selector or auto detect based on contract code analysis.

HD wallet key derivation for Identity keys

Status use HD wallets and we can derive a key for each dapp.
Currently including a key requires a transaction, however there might be some way of including a key off-chain and adding it on-chain by a signed message only when/if needed.
Users should be able to use Identity only if they want, a option to “disable/logout” and use directly the keys to interact should be an option.

After including any dapp name, as using Identity, would be nice to rotate the hash with status wallet + device number & identity as salt. Device Name -> Number can be saved encrypted by root hd wallet key in off-chain storage (swarm/ipfs/server) together with user global configs.

ERC725 Management Keys

We might have multiple managers, and Status could be added through a key created/imported in wallet.
We could use the status wallet & identity salted key “root” for MANAGEMENT_KEY, however if HD wallet is imported in other wallet than Status, it would need to request an Status Wallet to add that other wallet - or, this other wallet could be aware of status derivation key.

DApp ERC725 Keys for transactions

If needed for doing a transaction by Identity, this new key should be added to Identity as ACTION_KEY or user should be able to select a default/shared action key, then the call should be called through execute method - or if Dapp don’t requires an Identity, to use an key that contains ETH with an direct call.

DApps ERC725 Keys for off-chain

If needed for signing or reading messages, maybe it would be added as ENCRYPTION_KEY, but as Identity stores authorization to a hash of the Keys (not the keys itself), you need to pass your non hashed key to the network/interested nodes or to a server.
In this sense, if an user want to proof its Identity to a determined other user in Status Chat it could do so by providing a signed message coming from a key listed (hashed) in Identity as ENCRYPTION_KEY.
This can be useful, but I am not sure how, in some off-chain technologies like plasma, zero knowledgbe proofs or state channels, where the contracts can check for a Key in an identity refers with proof provided.

Keys for non ERC725

The class implementing the other standards should be able to derive the key as they need, being able to also specialize the keys for dapps, for off-chain and for management, but by default using all the a generic derivation method that assumes that one key per device for all dapps and management of identity itself.

Gas Relay Wallet Interface

When using Identity, and Identity is Gas Relay enabled, user would be able to sign a message instead of a transaction to make a call, and select what token to use in gas price. This would make the call cost funds held by Identity, making keys not needed to hold any funds.

Friends Recovery Wallet Interface

After creating a new Key in Status, user could request the recovery of an Identity. The Secret would be a hash of a bio-metric data, and as bio-metric sensor returns many different results, UI will hash against recovery secret hash, where when found it would be able to select user friends to sign the recovery approval.
Friends would receive a notification in Status, and would have to check with user to see if request is valid, and then authorize by pressing a button.

[yessin]

From the Wallet to Digital Identity

A summary of the challenge from a purpose perspective could be as follows.

Digital identity can be defined as the digital representation of a person in the Web 3.0 context. Or put differently, when Ethereum has become the World Computer, it should recognize you as the spaceship computer HAL recognizes Dave in 2001: A Space Odyssey and says: “Hello Dave!”.

The crypto wallet is an artifact which people use to do crypto transactions. I love the Status wallet for that, as it is becoming the latest and greatest of its kind. It would be pretty cool if Ethereum will recognize me, know my wealth and allow me to do whatever I can afford on the blockchain without having to fiddle with any wallet! I hope Status will upgrade to that functionality soon.

Now, you’re probably thinking that you wouldn’t trust HAL and thus also not trust Ethereum with your wealth. Too late! You probably have your stake on Ethereum already. No worries, a more real issue to think about currently, is that Ethereum is public, and you don’t want your identity to be revealed to everybody all the time.

That’s where the “unified self-sovereign identity” mentioned by @ricardo3 above comes into play. It is the solution where you can be in control of your identity data and only provide it when it is needed to validate yourself without the need to rely on a central repository of identity data. Truly decentralized stuff!

Confused? Alex Van de Sande’s presentation on the Universal Login sheds light on the work being done in relation to the identity challenge.

[ricardo3]

So Status have a use case to Claims, where we could have for example, public adult channels with encrypted content (like a private group), where users could join and get the decryption key from other online user if they have a certain type of claim in user Identity.

@ricardo3

Some channels might also require Identity Claims to accept user messaging on them