-
Notifications
You must be signed in to change notification settings - Fork 6
Identity
As we engage in commerce and social activities we often choose to do that with a consistent name. It used to be that only merchants needed a trusted name, but in peer-to-peer shared economy apps, like Airbnb, and Uber users need to acquire a good reputation too. Proving that you act under a certain name faithfully is much harder in decentralized apps than it is in a common Web or mobile app. This is the problem we are solving here. We are not re-inventing any cryptography here, instead we are using a systematic approach to identity developed by PGP in the last 20 years and are making it easier and stronger by putting all data in shared global database, the blockchain. In addition we use chains of objects and merkle trees to enhance cryptographic guarantees offered by PGP.
##Abstract Tradle extends the blockchain to store versions of objects. Identity is just a type of object. Collection of identities on-chain is like a decentralized PGP keyserver.
- Extensibility. Most identity validation rules belong to the apps and thus allow degrees of anonymity, from the aliases to full KYC-compliance. Some validation rules can be performed on-chain, in case of Ethereum, which makes writing smaller clients easier.
- Invisibility. Identity is an integral part of many apps. We intend this framework to melt into an app instead of standing as a separate app. That said, decentralized apps move the responsibility for managing keys to the client. We aim to strongly support this by forcing an app to use isolated key storage and controlled key access.
Thanks to Mark and Ellen @ Tradle, Joe Lubin, Rick Dudley, Christian Lundkvist, Simon de la Rouviere and many others, including participants of the Cryptoeconomicon workshop on Identity. Special thanks to Ray Valdes from Gartner Group.
- Q. We have a pseudo identity on a blockchain in a form of a bitcoin address. Why do we need anything else?
- A. Suppose I send you an order and I want to encrypt it, I need to find your public key, where will I get it?
- Q. Ah, but public key is part of the spend sig in bitcoin transaction. You do not need anything else, like fancy identities.
- A. Short answer - identity continuity will not be possible. Long answer - indeed this way a public key can be used in a minimalistic identity implementation. But consider that with this design you will be forced to re-use your private-public key pair for all your transactions to have a stable identity. If you switch to another key pair, how will I know it is still you?
- Q. Why do we need so much complexity as in PGP: separate keys for signing and encryption, subkeys, expiration, revocation. Man, this is too much for me.
- A. Hey, we too want to keep it simple, you know. But people were burnt really badly in the past and created a system to prevent this from happening. Check out this answer on rationale separate keys and subkey.
Apps might like to associate an alias and perhaps even a real name with the identity. Some applications might like to associate social network profiles, domain ownership (like is done in Google Analytics), and perhaps a driver license (like in Airbnb). We need a storage for these attributes and a way to associate them with the pub key of this identity. As in our design identity is just a regular object, the above needs are easily met with adding more properties to the identity object.
You might want to connect your blockchain identity to the identity in some social network, email or a phone number. Any connection from the on-chain identity to another identity needs verification. It can be done the way onename.io is doing it, by posting your onename on your social profile or the way keybase.io is doing it. Onename proves that they verified it. It works like an endorsement - onename is saying: trust me I verified it. Keybase does one better, it allows third-party to verify this for themselves, by adding your signature to your status update.
Our improvement to onename follows the keybase approach:
- create a text like onename.io does it, but also sign it with a private key of an on-chain identity. The result is like this.
- post a status update with this text (which includes a signature) on your social account
- this creates proves that you control both the on-chain identity and a specified social identity.
To accomplish the same proof for an email address you would need a URL to an email message (like the Twitter URL above). But mail servers do not have a way to make an email message accessible with a public URL. So email address verification can not provide a third party audit, like with keybase.io, only an endorsement, like with the onename.io.
Some links to verifications can be made automatically, while others are statements made by other people and organizations. Those are statements confirming that they have verified specific aspects of your identity, like a driver license or a birth certificate (which are also stored on chain). This can be done with or without revealing the document itself. If you trust the person or the organization making a statement, or if you trust several such organizations making similar statements, then you can trust the Identity.
Once you have verified someone's identity, based on their links to social accounts, or by calling people or meeting them in person, you save that decision by signing their Identity object and store as an entry in your address book. This way, when you need to lookup the friend's or a partner's address, it is easy and recognizable instantly.
This is how a simple Attestation will look like:
{
identity: hash /* pointer to the identity you verified */
signature: sig /* sig of the hash above with my key */
}
Yet the cool part is that if you publish this signing fact on-chain, a collective wisdom emerges, that is you can check who else verified this identity. Apparently Keybase is doing that already, they call it tracking. Maintaining the address book is natural for users and will help bootstrap the long anticipated Web of Trust.
Continuity of identity (stable identity) allows orders, invoices, reviews and any other transactions created by the apps refer to the identity, much like links on the web.
When we built supply chain management systems in the past we had to deal with a lot of identity issues for authentication, access control, for locating a proper company to send orders/invoices/shipments to (and for mapping to existing identity standard in EDI world), for mapping between people and organizations:
- we needed to record actions of the individuals that represented some organizations. Sometimes one individual was a contact for a couple of organizations.
- people got married and changed names
- same person would move to work for another company
- we had to have a list of organizations that everyone recognized. Quite often names people used were short names or abbreviations of organizations that were unique only in a limited context.
- some organizations were more like places, e.g. sea ports and had multiple companies associated with them
- often a company would change a name
- other times it would get purchased
- sometimes a company would be referred by the name of its parent company, and vice verse a parent would be referred by the name of its local subsidiary
Therefore the identity system must be very flexible and allow evolution of identities
##Design here is a preliminary identity design we are working on right now
- we provide no uniqueness of names, unlike the domain registrars, social networks, namecoin, onename.io, etc. There is no uniqueness of names in real life either. Instead the identity is just a hash of a [json] object that contains a public key. Identity object can not be modified directly, but a new version of it can be created, pointing to a previous version. The owner of the identity object can optionally connect it with the real life credentials, e.g. the social account, internet domain, email, etc. by proving the proof of ownership of that account the way onename.io does it, the way Google Analytics does it, etc. This allows a spectrum of identities from fully anonymous to fully disclosed and verified. This also allows a person to have multiple identities, for work, for social, for gaming, for interest-specific forums. To simulate OAUTH2, a new site-specific identity can be created and signed with person’s other identity.
- a collection of identity objects on the blockchain are equivalent to a key management server.
- one pub keys is not enough. We need a hierarchy of keys, like in PGP. We will use HD wallets for that. Master key is either kept offline or generated from a pass phrase (BIP39). Master key is used only to issue next level keys:
- signing key
- encryption key
- attestation, or web-of-trust key
- revocation certificate for the master key
- we also need to use sub-keys, like in PGP, so that the sub-key can be revoked if compromised or expired, while keeping the master key safely offline. This is quite easy to achieve with the HD wallet's hierarchical keys.
Think of the identity hash as a bitcoin address, it is indeed public. So to assert anything with this identity you need to sign the object you are creating or changing with the identity’s private key. Specifically it is a private key that corresponds to a public key that you published in your identity’s object (json). The signature is not placed on the bitcoin transaction, as OP_RETURN has only 40 bytes. The signature is added to a [json] object that is modified with this identity.
There is a whole other issue of identity theft that needs to be addressed. Just a short note here as this is a big subject: If the private key to identity object is stolen, the true owner of the identity needs to have a way to change the key. One approach to that would be to use the private key of the bitcoin transaction that created the first version of the identity object. Another way could be to prove the ownership of other public keys on the identity object, like the one used for encryption (PGP key management suggests a separate key for each purpose, signing, encryption, etc.). Other non-automatic ways could include a trusted third-party, social proof, etc.
- As Identity is just an object that have many versions, each client needs a way to verify that the chain of modifications for the Identity object is valid. Validity algorithm is app-specific, but several apps may choose to use the same algo. The most basic such algo useful in consumer apps (but may not be useful in games and business apps) is to enforce the rule that all the versions of an Identity object are signed with the proper keys and even when the keys have changed, the chain was not broken.
- Other objects signed with the particular Identity need to be validated in the context of keys changing on that Identity. That is if my signing key changed in May, objects signed by me in April are considered valid as signed by old key, but objects signed in May must be signed with a new key.
The difficulty is to develop light (also called SPV) clients for these validations. The main idea is to perform validation without downloading the whole blockchain, as this is not feasible on mobiles and places significant and growing storage and bandwidth requirements even on the servers. The approach we will take will draw ideas from bitcoin "UTXO commitments". The essence of UTXO commitments idea is to validate the download of only unspent transactions without downloading the whole chain. In the context of Identity it means - download only the latest Identity objects, not all their previous versions.
SPV in Ethereum is easier to achieve, as validation can be done by a contract for each object modification transaction. Thus the blockchain will only contain valid transactions and SPV client only needs to achieve high confidence that the transaction was recorded on the valid block. But when validation of transactions is done on the edge nodes, SPV client needs to validate the whole object's version chain till the genesis of this object. A design suggestion recently made by Poramin Insom in an Identity workshop lead by Tradle at cryptoeconomicon conference can make it possible. Specifically, Poramin suggested the identity object in DHT to include a backlink to a previous bitcoin tx, not only a back link to a previous object hash (we considered in the past to add a link to a current bitcoin tx. But it is not possible, as tx is calculated after object's hash is added to the bitcoin transaction. Thus adding tx to the object will change its hash and will change the tx - ad infinitum). This optimization actually works not only for Identity objects but for any objects and we will implement it immediately.
- Q. Why not use the Namecoin?
- A. We love what namecoin guys are doing, but it does not seem we need namecoin since we have a way to store objects using 1) bitcoin blockchain + DHT + bittorrent 2) Ethereum. Since the identities are just objects, we do not need another chain to keep them. We do not really need another level of complexity, which comes from running a full namecoin node (and then maintain it, upgrades, etc.), having to setup a namecoin wallet, buy and manage namecoins, etc.
- bitcoin wiki describes SIN, secure identification number
- Timo Hanke created a patch to bitcoind that adds certificates functionality.
- US Government's initiative on identity
- ID3 and Open Mustard Seed
- https://keybase.io
- https://onename.io
- Identity per Web Payments group
- Ethereum Identity exploration
- OASIS's XDI aims for a distributed social web
###Software
###Front end