UPORT A PLAT FOR SELF-SOVEREIGN IDENTITY DRAFT VERSION 2017-02-21 Dr. Christian Lundkvist, Rouven Heck, Joel Torstensson, Zac Mitton, Michael Sena INTRODUCTION History There are many problems with the current state of identity systems. Digital identity is fragmented and siloed between various service providers, prohibiting a holistic view, and delivering poor user experience necessitating repetitive registrations and logins with usernames and passwords. This results in insecure systems where people use the same password for many of their sites. The centralized servers of identity providers like Google and Facebook are honeypots of data, so they’re economically valuable for hackers to attempt to crack. The upcoming reliance on billions of internet-of-things devices makes it untenable to have all those devices controlled by a centralized identity provider, since a breach of this provider would prove catastrophic to not only digital but also physical infrastructure. Public/private key cryptography and decentralized technologies like blockchains offer a promising solution to the problems mentioned above. These technologies push ownership of identity away from centralized services to the edges - to individuals - so that the identities themselves are in control. This is commonly referred to as​ self-sovereign identity​ . This approach decentralizes data and computation and pushes them to the edges, where it is less economically valuable to hackers because it would require a lot of effort to hack many individual identities one-by-one. However, introducing new technologies to end-users is difficult. Public-key cryptographic tools like ​PGP have been around for 25 years, but their use in digital identity systems have seen little use due to their unintuitive and complex user experience, and the fact that usernames and passwords work well enough for most people. Blockchain technologies are interesting in that they ​require​ the use of cryptographic keys to sign messages for each interaction of the blockchain. Thus the rise of cryptocurrencies like Bitcoin and general blockchain architectures like Ethereum have sparked new interest in making public key cryptography usable to regular consumers and users in order for them to interact with these systems. Interactions with blockchain based systems necessitate usable public-key cryptography, and up to this point the key management solutions commonly called “wallets” have been difficult to use for non-technical users. Interestingly the blockchain can itself help make public-key cryptography more usable and secure by acting as a decentralized public key infrastructure PKI. The blockchain can be viewed as a decentralized certificate authority that can maintain the mapping of identities to public keys. Smart contracts can furthermore add sophisticated logic that helps with key revocation and recovery, lessening the key management burden for the end user. Introduction to Uport Uport is a secure, easy-to-use system for self-sovereign identity, built on Ethereum. The uPort technology consists of three main components smart contracts, developer libraries, and a mobile app. The mobile app holds the user’s keys. Ethereum smart contracts the core of the identity and contain logic that lets the user recover their identity if their mobile device is lost. Finally the developer libraries are how third party app developers would integrate support for uPort into their apps. uPort identities can take many s individuals, devices, entities, or institutions. Uport identities are self-sovereign, meaning they are fully owned and controlled by the creator, and dont rely on centralized third-parties for creation or validation. A core function of a uPort identity is that it can digitally sign and verify a claim, action, or transaction - which covers a wide range of use cases. An identity can be cryptographically linked to off-chain data stores. Each identity is capable of storing the hash of an attributed data blob, whether on ​IPFS​, Azure, AWS, Dropbox, etc., which is where all data associated with that identity is securely stored. Identities are capable of updating this file themselves, such as adding a profile photo or a friend, or they can also grant others temporary permission to read or write specific files. Since they can interact with blockchains, uPort identities can also control digital bearer assets such as cryptocurrencies or other tokenized assets. Proposed Use Cases A self-sovereign identity system will have many use cases, here a few of them are presented uPort allows end-users to own and control their personal identity, reputation, data, and digital assets; securely and selectively disclose their data to counterparties; access digital services without using passwords; digitally sign claims, transactions, and documents; control and send value on a blockchain; interact with decentralized applications and smart contracts; and encrypt messages and data. uPort allows enterprises to establish a corporate identity; easily onboard new customers and employees; establish an improved and transitive Know-Your-Customer process; build secure access-controlled environments with less friction for employees; reduce liability by not holding sensitive customer ination; increase compliance; maintain a network of vendors; establish role-specific, actor-agnostic identities i.e. CTO with specific permissions. TECHNICAL OVERVIEW Ethereum and Smart Contracts Ethereum is a blockchain architecture with an associated state database, capable of storing programs and their state. These programs are commonly referred to as ​Smart Contracts. ​ A smart contract can be deployed by any Ethereum user and it has a function-based interface. Once deployed the smart contract can be referenced by its ​address​ , which is a cryptographic identifier. A user can call a smart contract function by sending a transaction with this address as the destination, and with the data payload of the transaction containing the function signature and parameters. Calling a function causes the miners of the network to cute the program in a trust-minimized way and update its state. A smart contract can hold and send the native value token Ether, and can furthermore call functions of other smart contracts. For further reading on Ethereum and Smart contracts, see the ​Ethereum white paper​. uPort Technical Overview At the core of a uPort identity is the uPort identifier, a 20-byte hexadecimal string that acts as a globally unique, persistent identifier. This identifier is defined as the address of an Ethereum smart contract known as a Proxy contract. The Proxy contract can relay transactions and it is through this mechanism that the identity interacts with other smart contracts on the Ethereum blockchain. When the user wants to interact with a particular application smart contract, they send a transaction through the Proxy contract, via a Controller contract, which contains the main access control logic. The Proxy contract then forwards this transaction to the application smart contract. This architecture allows the application to view the Proxy contract address as the interacting entity. The Proxy contract thus introduces a layer of indirection between the user’s private key - stored on their mobile device - and the application smart contract. The purpose of having a Proxy contract as the core identifier is that it allows the user to replace their private key while maintaining a persistent identifier. If the user’s uPort identifier instead was the public key corresponding to their private key, they would lose control over their identifier if they were to lose the device where the private key is held. In the case of device loss, the Controller contract maintains a list of recovery delegates that can help the uPort user recover their identity. These delegates can be individuals, such as chosen friends and family members, or institutions, like banks and credit unions. A quorum of delegates is required to let the user recover their identity and connect it to a new device. We can also use uPort for non-blockchain identity-related use cases. This is achieved by cryptographically binding an external data structure to the uPort identifier using a Registry contract. The Registry contract contains a mapping from a uPort identifier to an IPFS hash. IPFS is a decentralized system for storing, linking and transporting data. The hash guarantees the integrity of the data structure, and the cryptographic binding to the identifier is defined by smart contract access control only the uPort proxy is authorized to update the Registry contract. The data structure corresponding to the IPFS hash can contain profile ination like Name, Profile picture, etc. It can also contain data such as public keys in order to support a decentralized public key infrastructure. The data structure used is a collection of JSON schemas. Each JSON schema can be digitally signed with a private key to create a JSON Web Token. This token can then be used as an off-chain attestation. An attestation is a very general structure. It can be used as proof that a certain identity makes a claim about another identity. It can also be a self-signed certificate stating that a public key belongs to a specific identity. Furthermore, an attestation can be used to provide a two-way link to a service like Twitter, allowing the user to leverage their existing social network. Technical Components In this section we present in more detail the main components of the uPort system. Smart Contract Components ● The ​Proxy Contract​ is a minimal contract, used to forward transactions and its address is the core identifier of a uPort identity. ● The ​Controller Contract​ maintains access control over the Proxy contract, and allows for additional functionalities. ● The ​Recovery Quorum Contract​ facilitates identity recovery in case of key loss. ● The ​Registry Contract​ maintains cryptographic bindings between a uPort identifier and the off-chain data attributes associated with it. Data Components ● Attestations or Credentials​ are signed data records containing profile attributes and/or verifiable claims, stored off-chain. Developer Components ● A ​Developer library​ allows for simple integration of uPort into decentralized applications or existing digital services. Mobile Components ● A ​Mobile application​ stores the identity’s private key, which is used to control the identity and sign attestations, in the smartphone’s secure enclave. Server Components ● Chasqui - messaging server ● Sensui - gas fueling server ● Infura RPC ● Infura IPFS SMART CONTRACT COMPONENTS Proxy Contract A large part of the uPort system rests on the concepts that in the Ethereum EVM, a contract address and the hash of a public key can both be the origin of a message sent to a smart contract, and that the target smart contract sees no difference between these two cases. This makes it possible to forward almost any interaction with Ethereum through a ​Proxy Contract​ which lies between the initial signed transaction and its intended target. One of the primary benefits of such a scheme is the ability to add features like key recovery or spending limits, which are not possible using a simple private/public key pair. Another benefit is that the proxy address can stay the same as keys are recovered or updated, thus allowing a user to maintain an immutable identifier capable of acquiring a reputation over time as third parties attest to its authenticity and actions. The proxy is standardized, with two main features. The owner of the Proxy Contract can 1. Forward an Ethereum transaction to an external address 2. Swap out the owner for a different one The proxy contract Solidity code is very simple, and is presented here for reference contract Owned { address public owner; modifier onlyOwner{ if isOwnermsg.sender _ } modifier ifOwneraddress sender { ifisOwnersender _ } function Owned{ owner msg.sender; } function isOwneraddress addr public returnsbool { return addr owner; } function transferaddress _owner onlyOwner { owner _owner; } } contract Proxy is Owned { event Forwarded address indd destination,uint value,bytes data; function forwardaddress destination, uint value, bytes data onlyOwner { if destination.call.valuevaluedata {throw;} Forwardeddestination, value, data; } } Controller Contract As the uPort software matures, we want users to be able to update their smart contract logic without changing their core uPort identifier, which is tied to reputation, assets and history. With that objective in mind, the Proxy Contract was designed to be extremely simple. Another contract, the ​Controller Contract​ , was designed to act as the al owner of the Proxy Contract. The Controller Contract maintains core access control features that allow the user to authenticate themselves using their private key to the Proxy Contract, and have it act on their behalf. As better controllers are eventually developed, users will be able to replace their controller with a new one without affecting the services linked to their identity. The first version of the ​Controller Contract​ is RecoverableController.sol. This contract has two main addresses associated to it the ​user address​ and the ​recovery address​ . The user address corresponds to the private device key of the user and is the standard way of interacting with the contract. The recovery address is used to help the user recover control if they lose their key. We use a separate contract to represent the recovery address; see the Recovery Quorum section below. Specifically the following interactions are defined 1. The user address can forward transactions to the Proxy Contract 2. The user address can relinquish control of the Proxy Contract to a new Controller Contract timelocked 3. The user address can replace itself with a new user address timelocked 4. The recovery address can replace the user address with a new address. Interactions 2 and 3 are “timelocked”, meaning they take a certain amount of time to go into effect after they are requested. This extra security measure gives the user additional time to recover their account using the recovery address in the event they have had their key stolen, and is under attack by a malicious entity. Recovery Quorum Contract In the above description of RecoverableController.sol the recovery address has the ability to swap out the main user address of the Controller. We currently give this access to a contract called RecoveryQuorum.sol. This is a multisig contract that is controlled by the user’s friends or other trusted entities, known as ​recovery delegates​ . The recovery delegates can specify a new user address for the Controller Contract. This feature gives the uPort user a means of recovering their identity in th