Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Matching Identity Management Solutions to Self-Sovereign Identity Principles


Published on

We created an analysis of near 50 (blockchain based) digital identity management solutions, and matched these against Self Sovereign Identity (SSI) management principles, and additional requirements.

Published in: Science

Matching Identity Management Solutions to Self-Sovereign Identity Principles

  1. 1. Matching Identity Management Solutions to Self-Sovereign Identity Principles Tommy Koens and Stijn Meijer ING, Abstract. The Dutch Blockchain Coalition (BC3) aims to create the conditions for reliable and socially acceptable blockchain applications in The Netherlands. Its first action line is that of Digital Identities, and focuses on digital identity to, and on, blockchain technology. Further- more, BC3 envisions a Self-Sovereign Identity (SSI) solution for identity management. Currently, there are many identity management solutions that claim to be Self-Sovereign. However, it is unclear to what extent these identity management solutions match SSI requirements. We create a long list of nearly 50 identity management solutions, and compare these solutions to 3 knock-out SSI requirements. This gap anal- ysis results in a short list that consists of 9 solutions. We further test these 9 solutions based on the remaining SSI requirements, and include additional requirements set by BC3. We conclude that currently none of the identity management products match all SSI requirements. We recommend to BC3 is to choose the top 3 products from the short list, and determine which of their properties match best with the use case in which the product will be applied. Keywords: Self-Sovereign Identity, Identity Management, Blockchain 1 Introduction The current implementation of digital identity schemes contain a lot of redun- dancy, with many parties issuing and storing the same identity information. At the same time, users have to remember their password for each of these services. Moreover, users have little control over their personal data. A Self-Sovereign Identity (SSI) scheme, when properly designed, can help solve this fundamental problem. As a result, we are interested in how current (blockchain based) identity management solutions compare to requirements for SSI. In this document, we provide that insight by assessing existing identity management solutions based on certain requirements. We start with a long list of circa 50 solutions, which we consider the cur- rent most significant ones, and apply 3 knock-out requirements. The resulting short list is then tested against additional requirements. Finally, we provide a conclusion and recommendation that describe which current solution fits the self-sovereign goal best.
  2. 2. 2 2 Background Whilst not a requirement for identity management, many of the novel identity management solutions discussed here are blockchain related. Therefore, we will first describe what a blockchain is, why it could be useful in this context, and what its important characteristics and implications are. A blockchain is a kind of a distributed ledger, which is a record of trans- actions that is shared between all participants, without a centralized party. A certain number of transactions is stored in a block. This operation is typically performed by a miner, who validates the correctness of the transactions and solves a puzzle that is computationally intensive to solve, but whose solution is easy to verify. This puzzle is necessary to prevent attacks on the system by dishonest participants. Once the miner finds the solution, the block is propa- gated peer-to-peer through the network. As the block contains a reference to the previous block, we call this technology the blockchain. Once added, a block becomes immutable and its transactions cannot be changed or denied. In most blockchains, all transactions are fully transparent to anyone. The miner receives a general monetary reward plus the fees that the participants decide to pay for their transactions; a miner can choose which transactions to include in a block. Some blockchain implementations replace the puzzle with another consen- sus mechanism. Others restrict access to participants and/or miners, or make transactions confidential by using a private ledger instead of a public one. Recall that we are aiming for a Self-Sovereign Identity (SSI) solution. A blockchain stores data decentralized between all participants, hence removing the different silos for different data processors. This however comes with a pri- vacy and compliance risk. The public and immutable nature of a blockchain make it hard to store personally identifiable information (PII). Note that regulations like the GDPR demand that such data must be altered or deleted under cer- tain circumstances, which is perpendicular to the concept of a transparent and immutable ledger. Some solutions aim to solve this by using data encryption or by storing information on private ledgers or entirely off-ledger. Still, in general it will be necessary to disclose at least some information publicly in order to manage an identity and make it accessible. Smart contracts could be employed to govern access to identities. Blockchains both open new possibilities and introduce new challenges for identity management. We found that it is key to find the right combination of blockchain technology, ‘off-chain’ storage, and advanced cryptography. 3 Analysis Approach The approach of our analysis consists of two phases: first, we make a quick shifting of a long list (circa 50 products), resulting in a short list. Second, the short list is further tested based on additional criteria. The long list has been composed by products mentioned in the academic literature, manual Google search queries, and by recommendation of others. We believe that it captures the current most significant solutions.
  3. 3. 3 The quick shifting is aimed at quickly determining which products can al- ready be excluded from further analysis, because they possess properties that simply do not match SSI requirements and are easy measurable (e.g. is the prod- uct open source?). In Section 4.1 we define three knock-out criteria on which we base this shifting. We assess them by manually reading the information that is available about a product until we feel that we either got a good understanding of the product, or that the required information is not (yet) available. If we could not find the required information for a certain product, if its development has been abandoned, or if Self-Sovereign Identity (SSI) is not a core component, we consider the product to be not applicable. Products that are not applicable do not have to be scored on the separate requirements. Only the products that are applicable and pass all three knock-out criteria will make it to the short list. We document the results in a table, specifying the product name, infor- mation source(s), score for each knock-out criterion, and whether the product is knocked-out. We also supply a brief description and motivation for each product. The first analysis phase resulted in a short list of 9 products. These products are then tested against additional requirements as defined in section 6. Again we use manual search to assess each requirement; this time using the following verdicts: Yes, No, or nn. We use nn (‘not known’) where we could not find an answer for this requirement. 4 Requirements long list 4.1 Knock-out Criteria We introduce the following three knock-out criteria to perform a quick shifting of the long list. We consider these criteria deal breakers in our product selec- tion process. We base our criteria on three Self-Sovereign Identity principles by Christopher Allen [49]. 1. Principle: Control. This principle states that users must control their identities. Users should always be able to refer to, update, or hide their identities. In practice, the General Data Protection Regulation (GDPR) stipulates that data subjects can demand, under certain circumstances, rectification and erasure of personal data concerning him or her. The GDPR enters into force in all European Union member states as of May 2018. As a result, we consider it a knock-out criterion if a product does not allow the correction or erasure of any personal data that it contains. Note that we consider the authority (that is, the party that signs certain claims about a user) to be the data controller of that claim. When a product acts as an intermediary (between some authority and a relying party), it may rely on the authority to rectify data and then retrieve the changes automatically or upon demand by the user. 2. Principle: Transparency. This principle states that systems must be open, both in how they function and in how they are managed and updated.
  4. 4. 4 In practice, in order to ensure that anyone is able to verify the system, we demand that all necessary software is open source. A module may only be closed source if it could realistically be replaced by any vendor’s own im- plementation without further knowledge or permission. For example, closed source apps that connect to an open source identity management product are not taken into account. 3. Principle: Portability. This principle states that identities must not be held by a singular third-party entity, even if it’s a trusted entity that is expected to work in the best interest of the user. In practice, being dependent on a centralized service creates the risk of a vendor lock-in, and may restrict users in being in control of their own iden- tity. Here, we focus solely on the self-sovereign aspect: A user must not be dependent on any centralized party in choosing if, when and how identifiers are disclosed.Therefore, a product must have a decentralized or distributed architecture. Furthermore, we exclude any existing identity management solution provided by either a government or group of banks. An overview of European solutions can be found here [18]. Although these solutions are useful in exploring from an organizational, legal and technical perspective, none of these solutions match all three knock-out criteria. 5 Assessment long list Our survey starts with a basis of circa 50 identity management products that make up our long list. Although there are more (blockchain-based) identity prod- ucts out there [11], we believe that this list captures the current most significant solutions in introducing novel concepts. In this section we will assess the long list based on the three knock-out requirements. 5.1 Knock-out assessment We assess all products based on the three defined Self-Sovereign Identity Princi- ples: Control, Transparency, and Portability. The results are compiled in Table 1, and we provide a short motivation for each product. uPort uPort is a self-sovereign identity product that uses smart contracts on the Ethereum blockchain. However, it stores personal data off-chain on the user’s device. Most of the software is already open source; uPort’s Android and iOS applications will soon become open source too. Signed attestations can be ex- tracted, making them interoperable with other products. Knock-out: No Decentralized Identity Foundation (DIF) DIF uses an Universal Resolver to connect to service endpoints and to manage cryptographic keys. It can resolve
  5. 5. 5 Table 1. Knock-out assessment Solution Sources Control Transparency Portability K.O.? uPort [37], [59] Yes Yes Yes No DIF [45] Yes Yes Yes No Cambridge [27] No No No Yes Netki [39] Yes No No Yes Selfkey [35], [47], [48] Yes Yes Yes No HYPR [7] Yes No Yes Yes Guardtime’s BLT [12] N/a Yes Sovrin (Evernym) [52], [44] Yes Yes Yes No ShoCard [36] Yes No No Yes UniquID [36] Yes No Yes Yes FOCAFET [20] ? Yes Yes No Bitnation [8], [53] No Yes Yes Yes Civic [23], [5] No Yes No Yes ExistenceID [19] N/a Yes OIX - N/a Yes Cryptid [13], [14] Yes Yes Yes No 2WAY.IO - N/a Yes Atencoin [4] N/a Yes BlockAuth [10] Yes Yes Yes No Blockstack [2] N/a Yes BlockVerify [9] N/a Yes Credits - N/a Yes CredyCo - N/a Yes OpenID [40] [46] Yes Yes Yes No Information Card - N/a Yes NotarisID [3] Yes No No Yes IPv8 (Delft) [41] Yes Yes Yes No DIMS [6] Yes Yes Yes No IRMA [30], [32] Yes Yes Yes No MS Azure AD [61] Yes No No Yes Synonym for Blockstack Qiy / Digital me [43], [16], [22] Yes No Unknown Yes TrustTester [58] [28] Yes No No Yes SURFconext [15] No Yes No Yes Jumio [33] [34] No No No Yes Tradle [55] [29] [56] No Yes Yes Yes IDCUBED [26] N/a Yes Trulioo [57] Yes Yes No Yes MIRACL [1] N/a Yes [38] N/a Yes [60] N/a Yes Trunomi [42] Yes No No Yes Keybase [17] N/a Yes IdenTrust [54] No No Yes Yes : FOCAFET was added later and evaluated positively, but not considered further due to time constraints on the delivery of this report. : Cambridge Blockchain used our work to self-asses their product, see paragraph 5.1 Cambridge Blockchain
  6. 6. 6 any kind of decentralized identifier through a system of ‘drivers’. Drivers exist for e.g. Sovrin and uPort. The responsibility for storing the actual personal data is hence delegated to external parties. The software is open source. The universal resolver acts as a bridge between the various drivers, which are provided by other initiatives. This is a way of decentralization, although the resolver potentially remains a centralized service in this network. We however believe that such a resolver can be hosted by different parties. Knock-out: No Cambridge Blockchain LLC This blockchain-based identity service claims to achieve “no direct exchange of sensitive information” over the blockchain, by using an external data storage service for sensitive information. Only the proofs generated on this data are stored publicly. The software is not open source. The external data storage may become a centralized component in this ecosystem, also preventing users from having full control over their identities. Knock-out: Yes N.B. Because of our initial assessment of Cambridge Blockchain, we did not perform a further assessment on this identity management solution. However, Cambridge Blockchain used our assessment criteria and performed an analyses by themselves on their product. Taking its current status, as well as the road map of Cambridge Blockchain into consideration, we initially conclude from this self-assessment that Cambridge Blockchain may indeed tick many of the requirements, as stated in Table 2. The assessment by Cambridge Blockchain shows that our work can be reused for self-assessment. Furthermore, it also shows that development of identity man- agement solutions is an ongoing process. Note that our assessment is a snap-shot of the current status of identity management solutions. We recommend to take Cambridge Blockchain into account when a re-evaluation of identity manage- ment solutions is performed. Netki Netki aims at providing an address book for blockchain transactions, in order to meet the requirements in Know Your Customer (KYC) and Anti Money Laundering processes. No ‘personally identifiable data’ is stored on the blockchain. Only the partner API’s are open source. A Netki identity is not interoperable with other identity products. Knock-out: Yes Selfkey / KYC-chain The products KYC-Chain and Selfkey are related. At this stage, Selfkey offers the most technical information of the two. Personal data is stored on the user’s device. The software is open source. Selfkey sup- ports multiple issuers and relying parties, and if the public key of the attestor remains available, attestations could be transferred into other identity systems. Portability is further achieved by using uPort (attestations). Knock-out: No HYPR The technologies of biometric authentication and blockchain identity management find themselves combined in HYPR. The (biometric) data is stored
  7. 7. 7 on the user’s device. The software is not open source. The architecture is decen- tralized. Knock-out: Yes Guardtime’s BLT This solution presented by Guardtime offers an optimiza- tion for verifying the integrity of a file. It however is not related to identity management. We therefore consider this product not applicable. Knock-out: Yes Sovrin (Evernym) Users carry a private ledger, giving them control over their own attestations. The software is open source, although not everything is imple- mented yet. The regulations governing the Sovrin community and network are also transparent. The architecture supports multiple issuers, stewards (nodes), and relying parties. Knock-out: No ShoCard No personal data is stored on the blockchain by ShoCard; only a hash and signature of this data is submitted. The software is not open source. Verification is done by ShoCard’s service, which is a centralized element in this architecture that could lead to a vendor lock-in. Knock-out: Yes UniquID Each device manages his own private UniquID blockchain. The soft- ware is not open source. We could not find who manages the ‘main’ blockchain or infrastructure; an eye should be kept out to make sure this will not be a (private) blockchain managed by a singular third-party. Knock-out: Yes FOCAFET While in the final stages of completing this paper, FOCAFET was brought to our attention. The DENARS registry is the non-profit’s identity solution: Distributed Entity Naming and Attribute Registration Services. It intro- duces a virtual person, virtual organization, and virtual bar code for products. A standard for unique identifiers makes them portable. The software will be- come open source, but is not yet available at this moment. Given the very recent addition of FOCAFET to the identity management products list, we were not able to provide the proper analysis this product deserves. Therefore, we will not consider this solution further at this stage. However, its concepts are promising and we suggest to follow DENARS’ developments in the near future. Knock-out: No, but not considered further in this report. Bitnation Building a society and a jurisdiction based on blockchain technology are the ultimate goals of Bitnation and Pangea. Data is propagated through a mesh / gossip protocol. Attributes are stored (in plain) on a public ledger, with a reputation system built on top of it. The software is open source. Bitnation considers itself ‘blockchain agnostic’: interoperability is achieved among various blockchain networks. Knock-out: Yes
  8. 8. 8 Civic Attestations of the Civic product are stored on the blockchain, leaving the user with no control over them after issuance. Only the API for partner integration is open source. Verification is carried out by a centralized ‘SIP’ server, which is a centralized element in the Civic architecture. Knock-out: Yes ExistenceID The original ExistenceID project seems abandoned. The project is now moving towards providing a peer-to-peer network called ‘SafeNetwork’. It will become open source, but we believe that it cannot be considered a self- sovereign identity solution anymore. Therefore, we consider this product to be not applicable. Knock-out: Yes Open Identity Exchange (OIX) This foundation promotes the development of ‘open’ identities by means of various working groups. However, to the best of our knowledge, none of these groups has developed a concrete self-sovereign identity scheme. Therefore, we consider this entry to be not applicable. Knock- out: Yes Cryptid When using Cryptid, personal data is stored (encrypted by a user- supplied password) on a public blockchain. If we consider “the right not to be found again”, then this is acceptable (the user can ‘forget’ the password). The software is open source. By publishing the data on the blockchain, Cryptid has no control over the data after it is issued. Although Cryptid signs all entries with their private key, which might give the impression of a vendor lock-in, these signatures can efficiently be transferred to another signing authority. Knock-out: No 2WAY.IO We could not access the website of 2WAY.IO. As a result, we con- sider this product abandoned and therefore not applicable. Knock-out: Yes Atencoin This product has been renamed to ‘AML BitCoin’. It now focuses primarily on providing a more efficient bitcoin-like currency rather than provid- ing a (blockchain) self-sovereign identity management solution. Therefore, we consider this product not applicable. Knock-out: Yes BlockAuth When using BlockAuth, the user owns the authenticity verifications she obtains. BlockAuth will become open source, but a software implementation is not yet available. The architecture aims at providing a decentralized orga- nization, in which all users have a stake. The scheme is based on the OpenID Connect technology. Knock-out: No Blockstack Blockstack aims to re-decentralize the Internet by replacing con- ventional DNS servers and Certificate Authorities (CAs) by a blockchain. While
  9. 9. 9 this is an interesting concept and certainly comprises an ‘identity’ element, it does not focus on self-sovereign identity management. The blockchain identity that is offered by Blockstack is a means to an end for the rest of the product; we believe that its functionality is too scarce to provide a proper SSI solution for other use cases. We therefore consider this product not applicable. Knock-out: Yes BlockVerify The mission of BlockVerify is to make supply chains transparent, thus “improving anti-counterfeit measures”. However, it does not provide a self- sovereign identity solution for individuals. We therefore consider BlockVerify not applicable. Knock-out: Yes Credits We could not access Credits’ website and found a report that it was already offline multiple months ago. The social media presence of Credits has also come to a halt. As a result, we believe that this product has been abandoned and therefore is not applicable. Knock-out: Yes CredyCo The CredyCo project seems abandoned, as their website is offline. As a result, we consider this product not applicable. Knock-out: Yes OpenID Connect OpenID develops new standards for identity on the In- ternet. OpenID Connect is “an interoperable authentication protocol based on the OAuth 2.0 family of specifications”. Any website can send a request to the OpenID Provider, which authenticates the user and returns an ID token, an access token, or certain claims about the user. OpenID Connect functions as an intermediary and does not store personal data itself. The software is open source. OpenID Connect describes a federated identity scheme, which means that there is no singular third-party controlling the data. Moreover, attributes are expressed in the form of JSON data that is structured in the same way as popular alternatives, hence achieving portability between them. Signatures can be verified by retrieving public keys, using the JSON Web Key (JWK) standard, which should match with the issuer documented in the attribute. Knock-out: No Information Card The website of the Information Card Foundation is no longer available. We therefore assume that this product has been abandoned and consider it not applicable. Knock-out: Yes NotarisID The notary sector is well-known for providing trust. With the No- tarisID initiative, this trust is to be further extended into the digital domain. When someone wants to obtain a NotarisID, she has to visit the notary and get her identification documents checked. The notary then checks various gov- ernmental registers. Once everything is validated, the user receives a one-time token from the notary. Using a smartphone app, this token can be converted
  10. 10. 10 into a username/pincode combination. The user’s identity is stored in a secure online environment, called DataPlaza. Relying parties can query DataPlaza af- ter the user gives consent. The user can decide to ‘forget’ the pincode that gives access to DataPlaza, thus is having control over (the existence of) her identity. The software is however not open source. Moreover, DataPlaza forms a singular third-party in the architecture. Although users can choose any notary for setting up an account, we found no indication that multiple notaries can contribute to a user’s identity at the same time. Knock-out: Yes IPv8 (Delft) The TrustChain technology presents a novel idea for managing a distributed ledger. A self-sovereign identity solution is implemented by the IPv8 product, which can run on top of TrustChain (or other distributed ledgers). A user can either carry her attestations herself (by means of zero-knowledge proofs), or have it verified live at the relying party. New attributes can be created by providing data that is either public or proven (e.g. by means of another zero- knowledge proof). The software is open source and multiple authorities and issuers exist in the scheme’s architecture. Knock-out: No DIMS The Decentralized Identity Management System (DIMS) was originally a Proof of Concept (PoC) developed as a master’s thesis at Rabobank. The bank recently developed the solution further. Claims are stored as (salted) hashes in a smart contract on the Ethereum blockchain. The prototype is open source and the architecture is available and well described. Attestations are described in JSON-LD standard format, making them better portable with other identity systems. While claims cannot be removed from the blockchain, users can destroy the associated key material, making the information unusable. Knock-out: No IRMA The IRMA attributes are stored on the user’s device. The software is open source and documentation is available. IRMA supports multiple iden- tity providers and relying parties. The IRMA scheme relies on a (de-)centralized database that stores a part of the user’s private key and connects users to issuers & relying parties. This component, containing a ‘keyshare’ and an API server, can be forked and deployed by anyone, and it does not obtain information about the user. For each scheme, which contains attribute definitions, the scheme man- ager can decide whether or not to use the keyshare server. That server enhances security, but it also creates a dependency: the user can no longer use attributes if this server were to be removed. For this reason, the scheme manager should always disable the keyshare server in order to meet the SSI principle of Porta- bility. Note that the scheme manager can be defined in the configuration files of the IRMA app and the IRMA server. Knock-out: No Microsoft Azure Active Directory All identity information is stored by Microsoft, so in theory users could ask (or demand) Microsoft to rectify or delete their information. The API’s for relying parties and some other components are
  11. 11. 11 open source, but the main identity logic is not. All data remains in the hands of a singular third-party (Microsoft), hence risking a vendor lock-in. Knock-out: Yes is a synonym for Blockstack, which we cover elsewhere in this document. Qiy / Digital me Qiy offers a node that can store a user’s identity. The node can be hosted on any issuer’s website. The issuer controls this data; Qiy is just an intermediary. The software is not open source and we found no plans to change this. The Qiy scheme supports multiple issuers and relying parties, but it is not known whether an identity can be exported from a Qiy node. The issuers and service providers that use the Qiy Trust Framework and auxiliary services must obtain a license from the Qiy Foundation. Knock-out: Yes TrustTester Although TrustTester seems to provide strong privacy guarantees, the product relies on a patented algorithm and there is a lack of documentation, which leads us to believe the product currently is not open source. Furthermore, there is a recurring dependency by its users on validating parties (trusted orga- nizations), whom validate that a given statement by the user is correct. Here, a user is dependent on the validating party each time an attribute is provided. Knock-out: Yes SURFconext SURFconext is a service that allows a specific target audience to use a single UID and password for multiple independent cloud services. The SURFconext service consists of a gateway, that acts alike a central hub connect- ing service and identity providers. Although the service is open source, users are dependent on the party controlling the gateway. Furthermore, the service is focusing on connecting cloud services, not paricularly on managing identity of users. Knock-out: Yes Jumio Jumio is a company specialized in online identity verification. It offers a range of products, ID document verification (e.g. driving license), Identity verifi- cation (e.g. with biometric attributes, such as facial recognition), and document verification (e.g. to prove document authenticity). Though interesting, there is only high level documentation available and the focus lies on the three products, and its marketing. How exactly users are in control of their data is not available. Knock-out: Yes Tradle Tradle states that it combines a KYC process with blockchain technol- ogy. It is open source, and the blockchain is used to provide proof by a verifier (e.g. a bank) that it has verified the information provided by the customer.
  12. 12. 12 Although customers stay in control of their identities, each participating com- pany requires to have a tradle server. This, of course, suggests a vendor lock-in. Knock-out: Yes IDCUBED ID3 is a research and educational nonprofit, whose mission is “to develop a new social ecosystem of trusted, self-healing digital institutions”. As it does not offer a concrete self-sovereign identity solution, we consider IDCUBED not applicable. Knock-out: Yes Trulioo This company offers an interface and data sources to verify an indi- vidual’s or corporate identity. They do however only provide such verifications for a limited amount of individuals, and the scheme cannot be considered a self- sovereign one. We therefore consider Trulioo not applicable. Knock-out: Yes MIRACL Zero-knowledge proofs can be a way to solve certain problems within identity management. MIRACL offers these zero-knowledge proofs, but it does not offer a self-sovereign identity solution (i.e. one that uses them). We therefore consider MIRACL not applicable. Knock-out: Yes is a data sharing tool for a singular user between its de- vices; it is not related to a self-sovereign identity scheme. We consider not applicable. Knock-out: Yes was chosen by VISA as their biometric ID solution. Al- though interesting, this is not a self-sovereign solution in itself, and therefore not applicable for this research. Knock-out: Yes Trunomi Customers have to give consent to the user of their information; deletion of data is possible. Although Trunomi offers transparency to the user about how their data is processed, the software is not open source. All data is controlled by a singular private party, which results in the risk of a vendor lock-in. Knock-out: Yes Keybase This product offers a chat app, but it does not implement a self- sovereign identity scheme. We therefore consider Keybase not applicable. Knock- out: Yes IdenTrust The architecture still relies on different existent architectures; the user is not always in control. The software is not open source. The certificates are held by the users themselves. Knock-out: Yes
  13. 13. 13 5.2 The Short List Following our knock-out assessment, there remain a total of nine identity man- agement solutions that match the three defined Self-Sovereign Identity Princi- ples. These are: – Blockauth – Cryptid – DIMS – Sovrin (Evernym) – IPv8 (Delft) – IRMA – Selfkey / KYC-chain – OpenID – uPort 6 Requirements short list Having determined which identity management solutions fit the initial three requirement, we perform an in-depth assessment of the identity solutions on the short list. To do so, we create a new set of requirements, and match each solution to this new list of requirements. 6.1 Final round requirements Here we present our findings from matching the requirements to the short list identity management solutions, see Table 2. For any requirement of which the information could not be found, we added ‘nn’ (not known). 6.1.1 Self-Sovereign Identity Principles We discussed three Self-Sovereign Identity principles as requirement for the long list. Here we describe the remain- ing seven SSI principles and make them measurable. – Existence. Users must have an independent existence. A self-sovereign iden- tity simply makes public and accessible some limited aspects of the “I” that already exists [49]. Indeed, an identity management system must be able to provide a limited aspect of the “I”. Here, aspects of the “I” must be linked to the identity holder (i.e. user), and these aspects may not be transferable (even though some part of the identity, like gender, may account for approx- imately half of the population). To do so, there must be a strong, provable link between the aspect of the identity and the identity holder. – Access. Users must have access to their own data. A user must always be able to easily retrieve all the claims and other data within his identity. There must be no hidden data and no gatekeepers [49]. – Persistence. Identities must be long-lived. A user should be able to dispose of an identity if he wishes, and claims should be modified or removed as appropriate over time.
  14. 14. 14 – Interoperability. Identities should be as widely usable as possible. The goal of a 21st-century digital identity system is to make identity information widely available, crossing international boundaries to create global identities, without losing user control. – Consent. Users must agree to the use of their identity. Sharing of data must only occur with the consent of the user. Though other users such as an employer, a credit bureau, or a friend might present claims, the user must still offer consent for them to become valid. – Minimalization. Disclosure of claims must be minimized. When data is disclosed, that disclosure should involve the minimum amount of data nec- essary to accomplish the task at hand. For example, if only a minimum age is called for, then the exact age should not be disclosed, and if only an age is requested, then the more precise date of birth should not be disclosed. Additionally, if the age is called for again, there should be no link between both attribute verifications. – Protection. The rights of users must be protected. When there is a conflict between the needs of the identity network and the rights of individual users, then the network should err on the side of preserving the freedoms and rights of the individuals over the needs of the network. 6.1.2 Identity attribute life-cycle Attributes follow a life-cycle (including existence, validation, claim, revocation and deletion) which the identity manage- ment system must support. This life-cycle results in the following requirements: – Create. An identity holder must be able to have an attribute related to its identity to be created. – Attest. Attestation of the attribute must take place. Here, a trusted third party (TTP) validates that the attribute is correct. Additionally, the TTP enables that the identity holder can re-use this attestation, to prove the attribute is considered valid by the TTP. – Show. An identity holder must be able to show an attribute. – Prove. An identity holder must be able to prove that he or she holds an attribute, without showing the attribute itself. – Renew. An identity holder must be able to renew attributes. For example, an address change. – Delete. An identity holder must be able to delete attributes. – Revoke. A TTP must be able to revoke attributes. – Verify. A verifier must be able to verify the status of an attribute. 6.1.3 Implementation success criteria Furthermore, we match our short list of identity management solutions with a set of requirements that may have impact on the success of the identity management system. These are: – Biometric interface. The identity management system must be able to interface with an biometric identification system. Biometric identification is currently the only strong way to verify on-line the link between an attribute and the identity holder.
  15. 15. 15 – Proper documentation The identity management system must contain a proper technical and functional description. This allows for proper review of the system. Also, more mature systems, in general, have documentation against which the system can be audited. If there is no description available, or if the description is insufficient to draw proper conclusions from the docu- mentation, we state that the identity management product does not comply to our requirements. – Scalability The identity system must be able to scale to millions of users. – Maturity. The user base, connected organizations, live implementations all provide an indication of how well the community (identity management users) perceives the identity management system. 7 Assessment short list Table 2. Short list assessment based on additional criteria Product → BlockAuth CryptID DIMS Sovrin IPv8 IRMA SelfKey OpenID uPort Requirement ↓ Existence No Yes Yes Yes Yes Yes Yes Yes Yes Access Yes Yes Yes Yes Yes Yes Yes nn Yes Persistence nn No nn Yes nn Yes Yes nn Yes Interoper. No No Yes Yes Yes Yes Yes No Yes Consent nn Yes Yes No nn Yes Yes Yes Yes Minimal. No No Yes Yes Yes Yes Yes Yes Yes Protection nn nn nn nn nn nn nn nn nn Create Yes Yes Yes Yes Yes Yes Yes No Yes Attest Yes Yes Yes Yes Yes Yes Yes Yes Yes Show Yes Yes No nn nn Yes Yes No Yes Prove nn No Yes Yes Yes Yes nn No nn Renew nn nn nn nn nn No No No No Delete nn No No nn Yes Yes Yes No Yes Revoke nn nn No nn nn No No No No Verify Yes Yes Yes Yes Yes Yes Yes Yes Yes Biometric nn Yes Yes Yes Yes Yes Yes No Yes Documentation No nn Yes Yes No Yes No Yes Yes Scalability nn nn No Yes nn nn nn Yes Yes Maturity No No No Yes No Yes No Yes Yes #Yes 5 8 11 13 10 15 12 8 15 #No 5 6 5 1 2 2 4 8 2 #nn 9 5 3 5 7 2 3 3 2
  16. 16. 16 7.1 Blockauth Blockauth provides a decentralized framework that allows users to authenticate themselves to another on-line party. Its main idea is to let user attributes be verified by a verification partner (BlockAuth Identity Registrar). Existence The description of how a user authenticates with a third party is poorly described [10]. Given the current description, there is no strong link between the attribute provided and the attribute holder. Access Although not well documented, there is a statement of users being able to access their own data. Persistence We could not find whether there is a notion of a user identity, or how long-lived verifications are. Interoperability The focus of Blockauth is on-line authentication. This signif- icantly limits the interoperability, since off-line authentication is simply out of scope. Consent It is unclear how users may conduct consent on providing claims. Minimalization Disclosure of claims are indeed minimized, since the user is able to choose which claims to make. However, the information inside a claim is not minimized. Protection There is no mention of user rights protection. This is also deter- mined by how BlockAuth would be implemented and governed in practice, which we cannot assess now. Identity attribute life-cycle From the documentation it shows that users are able to create and show an identity. Relying parties can attest and verify an identity. However, much is lacking in the documentation, such as if a user is able to prove identity ownership. It is unclear how attributes can be modified or removed. Implementation success criteria nn,Yes,nn,No. . . There is a lack of infor- mation on scalability and linkage to biometric identification; documentation is scarcely available. Furthermore, there is no actual implementation available, and the last code update stems from 2014, making BlockAuth a project that hasn’t received attention for a long time.
  17. 17. 17 7.2 CryptID With CryptID, a user is able to send attributes to CryptID which are then up- loaded to the blockchain. Access to this data can be provided through three- factor authentication, something you know (password), something you have (unique identifier), and something you are (fingerprint). Destruction of any of these three would allow for removing access to credentials (right not to be found). Existence While users upload a form consisting of fixed attributes, this form makes available a subset of the user’s “I”. Access Users can access their information by downloading it from the blockchain and decrypting it with their password. Persistence The user’s identity information is stored on the blockchain indef- initely, thus achieving persistence, although no changes can be made. However, we believe that persistence is not achieved, as an identity has to be obsoleted once some of the information it contains changes. A new identity will then have to be uploaded to the blockchain. Interoperability Since data is stored on the blockchain, it is limited in use. For example, off-line identification is not possible. Consent Users have to give consent for the sharing of their data by giving the decryption password. Minimalization Since all data resides under a single (unique) key, minimalizing claim disclosure is currently not possible. Users can only disclose their entire CryptID identity, by sharing their password. Protection Unauthorized access to the data is hard to obtain, considering the three-way authentication. It is unknown how user rights are protected. This is also based on how the system is governed in practice, which we cannot assess at this stage. Identity attribute life-cycle Users can create and show their identity, which can then be verified. CryptID attests the identity by digitally signing it, and any other issuer could theoretically do the same. Data cannot be deleted from the blockchain. It is not known whether revocation of an identity is possible.
  18. 18. 18 Implementation success criteria CryptID has been an abandoned project for 9 months, with no user base and no field tests. CryptID is an identity man- agement system that involves biometric identification and uses crude storage identities on a blockchain. Its scalability will depend on the type of blockchain it chooses to use. There is a lack of documentation and user base, which leads us to consider CryptID as not sufficiently mature. 7.3 DIMS DIMS uses a decentralized exchange of claims, where claims are linked to tokens on a permissionless distributed ledger (Ethereum). Answers to questions will be stored as a (salted) hash within a smart contract on a blockchain. DIMS uses hierarchical deterministic wallets, such that each address is used one time only. Identity providers can attest a certain claim about someone by making state- ments about one’s public key, in a smart contract on the blockchain. Requests for claims by relying parties are performed off-chain. Existence DIMS expresses identities by means of attestations (‘claims’), which reveal limited aspects of the user’s “I”. Access The user can observe which claims are bound to her public key in the app. Persistence We were not able to properly assess this requirement. Interoperability The current version supports all kinds of statements, making DIMS interoperable towards many identity-related use cases. Consent A request for a claim is digitally signed by the relying party. The user can confirm the identity of the relying party via trusted registries, i.e. by the Chamber of Commerce. If everything is in order, consent can be given to exchange the relevant claims. The blockchain contains (salted) hashes. However, the user has limited control over the existence of the claims, as claims cannot be deleted. Fortunately, claims can only be matched against known values, thus in principle not leaking private information while on the blockchain – or at least as long as brute-force attacks prove unsuccessful. Minimalization Currently, claims are stored in hash format. Further minimal- ization could be achieved by incorporating zero-knowledge proofs, which provide more flexibility in which (subset of) information should be disclosed.
  19. 19. 19 Protection We think that the inability to delete claims does not favor the user’s interests in the long run. Apart from that, the degree of protection is based on how the system is implemented and governed in practice. We are unable to make such an assessment here. Identity attribute life-cycle DIMS supports the creation, attestation, prov- ing, and verification of claims. Attribute values cannot be shown, as they are (salted) hashes. Only prove that the identity owner possesses a certain identity is possible, since only claims can be verified by comparing the hashes. Although privacy friendly, this limits the system in adaptability for a larger audience, especially verifiers that demand (for personal / business / legal reasons) the dis- closure of an attribute, not only proving the fact that the claim is true. Users also cannot delete a claim, only by waiting until the claim stored in a smart contract expires. A claim can also not be revoked. We could not evaluate how/whether it could be renewed. Implementation success criteria In principle, biometric authentication could be added to the DIMS app, e.g. in the consent phase. The scheme is properly described in a master’s thesis. Each and every verification must go through a smart contract. This is very blockchain intensive. Given the current state of blockchain limitations, such as number of transactions for verifying claims, wide- scale usage of DIMS cannot be supported by the Ethereum system. Permissioned blockchains may provide useful here. However, the thesis dismisses the idea and considers permisionless blockchains as an ideal solution instead. 7.4 Sovrin (Evernym) As the Sovrin scheme is rather complex, we start with a general introduction. After that, we will dive deeper into the specific requirements, indicated by bold headers. In Sovrin, identities are provable by a sequence of identity transactions. It runs on a a public permissioned ledger: anyone can use the system, but per- mission is required to run a Sovrin node (a “steward”). This permission can be granted and revoked by the Sovrin Foundation. The community is regulated through the Sovrin Trust Framework. The original source code of Sovrin has been gifted to the Sovrin Foundation by Evernym Corporation. The consensus algorithm is called Plenum. A reputation scheme has been incorporated as well. As of May 2017, Plenum forms the basis for the Hyperledger Indy project [25]. Sovrin utilizes three places to store identity information [24]. Publicly avail- able information, such as a school’s address, is stored on the public Sovrin ledger. Others can attest the validity of this data, increasing its trustworthiness. Sensi- tive information is encrypted and stored on the user’s private ledger. The private ledger tracks time and order that things are written. Periodically, a hash of the private ledger can be written to the public ledger; this hash is called an “anchor”. The user can use her private ledger to create an audit proof that any particular
  20. 20. 20 interaction happened at a particular time without disclosing the details of the interaction. A user can have multiple private ledgers at the same time (i.e. on different devices), which can be synchronized with the help of an agency. This agency has to sign a legal contract with the Sovrin Foundation, settling allowed behavior. As the agency handles encrypted data, the privacy risks are limited. Agencies are interoperabile, such that users can switch agencies at any time. Finally, data can also be stored entirely off-ledger. Sovrin tracks cryptographic keys, identifiers, and claims. The cryptographic keypairs are public/private keypairs. A party’s identifier is different for each other party they interact with; they are ‘cryptonyms’. Claims can be attestations by the user herself (‘self-asserted’), or signed by others. Multiple of these claims can be combined into a disclosure, which is a zero-knowledge proof using the user’s master secret key. Disclosures are non-correlatable; a property that is best described by citing Sovrin [24]: “Suppose someone at the employer had a friend who worked in the local government. These two people couldn’t collude to use the proof Jane sent to the employer [containing her address and that she’s over 18] to discover additional information about Jane that the government holds. Neither the proof nor the identifier the employer holds for Jane correlate to any identifier that the government holds and thus can’t be used as a key to look Jane up in the government’s systems”. The Sovrin Provisional Trust Framework [51] describes how Sovrin users (‘identity owners’) can also be represented by their agents. Agents can share their address (DIDs) with other agents. Such DIDs can be generated for mul- tiple contexts, revealing a partial identity. Identity owners that are physically incapable of managing their IDs, can elect another person as a guardian to take care of their identity. A guardian can also manage the identity of a ‘thing’: a Sovrin entity that cannot be held legally accountable, such as an animal or an object (i.e. car / software program). Existence Sovrin allows individuals to record identity information about them- selves and to receive claims signed by others. This builds a personal identity that is a subset of one’s “I”. Access The user can make sure that information is deleted after a certain time or only used for a specific purpose by using consensus receipts. Attesta- tions signed by others are recorded by the user herself. This way, users can now know which informations others possess about them, as they set the rules for it themselves. Persistence A Sovrin identity is “portable, independent of all past and future relationships, that nobody can revoke (...) without the user’s permission” [21]. Therefore, it will persist for a long time. Interoperability The Sovrin identity scheme is a general-purpose scheme. The combination of being able to self-assert claims and to receive claims from others
  21. 21. 21 make it flexible and more widely usable. However, it is not possible to fork the Sovrin ledger [50], limiting future flexibility. Consent Consent can be controlled by means of consent receipts. As men- tioned before, the public ledger can be used to store public information, such as a school’s address. We foresee potential problems in the cases where the line between public and sensitive information is thin. For instance, we could agree that it is okay to store the addresses of companies on the public ledger. A Sovrin user Alice now wants to set up freelance activities. She registers a company called “Alice’s AgileCryptoCloud” on her home address with the chamber of commerce. Someone else now publishes her (company’s) address on the public ledger. As a result, her living address is forever publicly available on the Sovrin ledger. This is an example of a case in which others may add information to the Sovrin ledger that they think is public information, but that can be related to and against the interest of the data subject. Alice does not have control over the amount of sharing of her personal information that occurs. Minimalization Minimalization is achieved by using Sovrin’s disclosures, only disclosing the relevant claims in a zero-knowledge proof fashion. Protection Some aspects of Sovrin make it very privacy friendly, i.e. the non- correlatability of disclosures and the encrypted storage on private ledgers. How- ever, we believe that the danger is in non-public information ending up on the public Sovrin ledger. Note that this is not a problem with the Sovrin technology in itself, but rather a problem with how it can be (mis)used by its users given the current architecture. More general, we could not evaluate whether Sovrin functions in the best interest of the user, based on the available information. Note that this is also dependent on how the system is implemented in practice. Identity attribute life-cycle Identity credentials can either be created by the user herself (“self-asserted”) or attested by someone else. The user can gener- ate a ‘disclosure’ in order to (zero-knowledge) prove the possession of a certain credential. For credentials that were attested by others, the signatures can be verified. It is however not clear to us whether the (clear) values of attributes can be shown, whether attributes can be renewed or updated, whether the user can delete them, and whether the issuer can revoke attributes. Implementation success criteria While not currently implemented, in the- ory it should be possible to add a biometric layer to the Sovrin app. There also is plenty of documentation on Sovrin. The private ledgers will improve its scalabil- ity. The documentation and governance documents are mature, there is already a code base, and Stewards are currently being recruited. However, one currently cannot register as a user. The degree to which privacy is preserved is heavily
  22. 22. 22 dependent on how the public Sovrin ledger is going to be used in practice. The business model consists of ‘premium claims’, for which the user will have to pay [50]. 7.5 IPv8 In the IPv8 model, a user can create attestations by providing information that is either public or provable by means of a zero-knowledge proof. The obtained attestation can be used at relying parties by either supplying a zero-knowledge proof (which can be stored on the user’s device), or by having the relying party query the issuer directly. It is designed by the same group as TrustChain, a reputation-based distributed ledger that supports interactions that are signed by at least two parties, but compatible with various types of blockchains (IPv8 is ‘blockchain agnostic’). The protocol is currently under development. An example of the entire stack is: application layer, CHECO consensus algorithm, Trustchain Fabric, IPv8, and then a SSI solution. Existence IPv8 describes the user’s identity by means of attestations, which allows to prove properties of an identity. It provides a limited aspect of the “I”. Access The architecture of IPv8 supports two verification approaches: (1) an active approach in which the validity of an attribute is checked live at the attester – requiring communication with the attester at verification, and (2) a passive approach in which a zero-knowledge proof is created that eliminates the need to query the attester at verification. The latter method would satisfy the self- sovereign principle of ‘access’. Persistence We could not find how long attestations will remain valid, and whether there are facilities like an identity recovery scheme. Interoperability IPv8 is flexible and supports all kinds of identity information. It is useful for a wide range of use cases, and therefore considered interoperable. Consent We could not find whether the user has to give consent before personal data is shared. Minimalization The attribute-based architecture of IPv8 enables users to min- imalize their data sharing. Protection We could not evaluate whether IPv8 functions in the best interest of the user, as this is also dependent on how the system is implemented in practice and being governed.
  23. 23. 23 Identity attribute life-cycle Whilst it is not clear from the documentation, we believe (based on what the current documentation implies) that the cur- rent (proposed) version of IPv8 supports creation, attestation, proving, deletion (deleting the proof’s keys), and verification of attributes. As for the other re- quirements, we do not yet know whether this will be possible in IPv8. Implementation success criteria As the Android app of IPv8 is open source, it would be possible to create an interface for biometric authentication. IPv8 can run on multiple blockchain technologies (blockchain agnostic); it is likely that at least one of these techniques will make IPv8 sufficiently scalable. The current lack of documentation and ecosystem development leads us to believe that IPv8 is not mature yet. An Android application is already working; the first identity provider will become available early 2018. 7.6 IRMA IRMA is an identity scheme that focuses on user privacy. The scheme does not involve blockchain technology, but we believe that it would be interesting to extend IRMA with a distributed ledger to achieve efficient revocation. IRMA is operated by a non-profit organization, the Privacy by Design Foundation. Existence The user’s identity is modeled in the form of attributes, which de- scribe a limited aspect of the “I” by means of zero-knowledge proofs. Access The user controls all attributes herself, hence having full knowledge over which data exists concerning her. A logfile is available to track who accessed which attributes. Persistence An identity could last forever, but the attributes will expire after a certain time. Backups are made locally, but all data will be lost after a phone breakdown if such a back-up was not stored elsewhere beforehand. Moreover, even if the identity would survive a phone breakdown, its anonymity makes it impossible to re-retrieve attributes by means of the user’s identifier (“I, the issuer, already know that user x is allowed to possess attribute y”). This means that the user has to carry out the entire proof process at each issuer again after such an identity loss. Note that users are not labeled with a persistent identifier to the outside world, thus for others it will look like a new identity in every transaction. This means that persistence is currently not achieved. Interoperability IRMA supports various kinds of attributes. It therefore covers a broad range of use cases and can be considered interoperable. Consent The user has to give consent for each disclosure of attributes.
  24. 24. 24 Minimalization The IRMA scheme makes sure that only the required at- tributes are disclosed. This is further supported by providing the user with a log of the attributes requested by each relying party for each transaction, increas- ing social control on the relying party by IRMA’s users. A set of attributes is combined into a zero-knowledge proof. IRMA also supports signing based on a certain attribute, i.e. signing something as “a registered doctor”, anonymously [31]. Although the latter concept is out of scope for this research, IRMA min- imizes the personal data that is disclosed to a level where only the necessary attributes are disclosed. An exception is that IRMA stores usage data on a cen- tralized server, although details are amalgamated (i.e. IP address is discarded and converted into its geolocation’s city name). Protection IRMA is designed based on privacy-by-design. However, we were not able to assess if IRMA matches this SSI principle. Identity attribute life-cycle IRMA supports the creation, attestation, show- ing, proving, deletion, and verification of attributes. Renewing and revoking attributes is not (properly) possible in the current architecture. Implementation success criteria Biometric authentication could be added to the IRMA app, which is open source and already uses PINcode authentica- tion. There is plenty of documentation, both informal and in scientific papers. IRMA currently does not use blockchain technology, thus does not inherit ledger scalability & performance problems, although all requests between users and is- suers/relying parties go through a centralized server. We believe that the product is sufficiently mature. 7.7 SelfKey / KYC-Chain SelfKey, also known as KYC-Chain, stores identity information locally on the device. The Selfkey app contains a wallet and a public/private keypair. Users can add identity claims to their wallet and present them to some authority, who can attest identity claims. Possessing an attestation, the user can buy products in the SelfKey marketplace. SelfKey plans to use uPort, i.e. because of their account recovery scheme by means of a proxy contract. Users and/or relying parties have to pay with the cryptocurrency KEY for requesting attributes, receiving attestations, and for marketplace listings. SelfKey is a non-profit set up in Mauritius. The foundation was founded by a for profit company, KYC- Chain Ltd. Existence The user can present a certain set of attributes, leading to a subset of her total identity; her “I”.
  25. 25. 25 Access All attributes are owned by the user and stored on her mobile device. Backups can be made onto another device or a personal backup solution. Persistence Identity identifiers will last, but attributes may only be valid within a certain time frame. Interoperability Identity claims are stored in text fields (JSON-LD blobs) and can contain various kinds of claims, making SelfKey interoperable among use cases. Consent Users need to give explicit consent before attributes leave their phone. Minimalization The attribute-based architecture enables the user is to share only the attributes necessary. Protection We cannot assess whether SelfKey acts in the best interest of its users, as this is also dependent on how it is governed. Also note that users have to pay attestors. But once obtained, an attestation can be used freely (within its validity time frame). Identity attribute life-cycle The current version of the SelfKey ecosystem supports the creation, attestation, showing, deletion, and verification of at- tributes. The current implementation does not support proving the possession of an attribute without revealing its content, but the infrastructure does not block this feature from being added in the future. We appreciate the fact that SelfKey gives the user full control over its attributes, although this typically introduces a more sophisticated revocation scheme, which is not available in the current version. The only way to renew attributes is to delete the former and to receive a fresh attestation. Implementation success criteria Each user has to download the SelfKey app, in which their wallet (containing attributes) and cryptographic keypair are stored. Moreover, the wallet will host different apps ‘in the application layer’, such that any organization could add their own functionality. Possibly, biometrics could be added to unlock the keypair. Furthermore, SelfKey is already perform- ing research on using biometrics for Proof of Individuality (PoI). The (legal) structure of the SelfKey foundation is clearly described in its whitepaper [48], and so are descriptions of how the system works. A “trust framework” is going to contain specific protocol level information and information about KEY. It is not known when this crucial document will become available. Almost all software is still under development. The scalability of SelfKey will largely depend on the scalability of the underlying blockchain, which is Ethereum in this case. While SelfKey is planning to use uPort, we see an increased scalability risk for SelfKey as its KEY transactions will depend more on blockchain technology.
  26. 26. 26 7.8 OpenID The “ID token” in OpenID can be compared with Facebook’s “signed request” token in OAuth. However, the former supports multiple identity providers. The user is authenticated and can supply additional attributes (“UserInfo endpoint”). The protocol is interoperable. The “Granular Request” feature supports data minimization. Existence OpenID works with a notion of attributes, enabling the user to disclose a limited set of all attributes that make up her identity. Access Users could in theory obtain all attributes concerning them, but the storage of these attributes is decentralized across all data suppliers. It depends on the data supplier whether there are gatekeepers to the data and whether the user can access and is informed about all attributes. Persistence How long an identity lives depends on the data providers as well. Interoperability The focus of OpenID is on-line authentication. This signif- icantly limits the interoperability, since off-line authentication is simply out of scope. Consent The user approves the sharing of attributes beforehand. Minimalization The feature of “granular requests” helps in data minimaliza- tion. Protection The extent to which the right of the individual is taken into account depends on the decisions made by the data providers. Identity attribute life-cycle If we narrow our focus down to OpenID and do not consider the data suppliers driving it, the life-cycle is limited to the attestation and verification of attributes. OpenID itself does not handle the creation, showing, proving, renewing, deletion, and revoking of attributes. Implementation success criteria We do not see a concrete implementation surface for biometrics in the OpenID system. This would require either a central- ized authentication service, or all data suppliers implementing biometrics. The documentation and software is however (very) mature, and the decentralized architecture makes OpenID scalable.
  27. 27. 27 7.9 uPort uPort enables users to download attestations to their smartphone. A session to a ‘distributed app’ (dapp) must be set-up a-priori, which is typically done by scanning a QR code. The user can now send and receive attestations: attributes that are signed by a another party. uPort further supports calling smart contracts on the Ethereum blockchain. Existence The user’s identity is split in attestations, and the user has to ap- prove sharing them. This enables sharing a sub-identity. Access As the user controls all attestations herself, she has full access to her identity information. Persistence While a uPort identity persists forever and can survive a smart- phone breakdown (due to uPort’s mechanism of account recovery), attestations can expire or get lost in aforementioned breakdown. Interoperability Attestations can be downloaded as a Java Web Token (JWT) with the authority’s signature embedded in it. As long as the authority’s private key is known, attestations could be converted into other identity schemes. Consent The user gives consent before attestations are shared and before smart contract actions are performed. Minimalization uPort uses a unique identifier (the Ethereum address of a user’s proxy contract) in each transaction. This makes the user traceable within a single dapp (multi-show unlinkability not achieved), enables the issuer to see how attestations are used if it conspires with dapps, and hence enables profiling the user. However, we believe that uPort’s unique identifier is useful for account recovery. Protection The rights of the user are helped by giving the user full control over her identity, but the risk of profiling remains. Identity attribute life-cycle uPort supports creation of attributes, both at- tested by authorities and self-signed. These attributes can be shown to others, proven and verified. The user can delete attestations, but attestations cannot be revoked by the issuer (except for supplying an expiration time). In theory, attributes could be renewed as long as the issuer continues to exist, and both the issuer and the user remain the information necessary for the renewing – but this will not always be the case.
  28. 28. 28 Implementation success criteria The uPort apps already support the us- age of the fingerprint sensor on smartphones. Further usage of other biometrics should be feasible. Documentation is available in enough detail, although cur- rently not all documentation is up-to-date with the latest software implementa- tion. Whilst uPort uses the Ethereum blockchain, the ‘identity’ features function off-chain. The resolver that binds dapps and devices into sessions (when scan- ning a QR code) might become a bottleneck eventually. The software and its ecosystem are mature enough to perform serious pilots. 8 Conclusion As can be observed from Table 2 currently none of the SSI products match all requirements. However, the table also shows a countings (yes, no, and nn’s) difference between the products. These countings are an indication of how well the product matches the set of requirements. It must be noted that this indication is an observation in time. Over time, products evolve and the match counting may change. Also, the indication is based on an interpretation of high-level concepts. For example the SSI principles are generic guidelines. Given the time constraints of this analysis, we decided not to assign weights to the requirements. Depending on the use case, some requirements may be of more importance than others. This ties back to our initial observation, that this analysis is an indication of how well the products match the requirements. As for a final verdict, each product has its own unique properties. We there- fore recommend to match the top 3 products – Sovrin, uPort and IRMA – to a particular use case, in which the product will be used. 8.1 Further considerations Some further considerations are of importance to any self-sovereign identity so- lution. The following considerations are among them, but have not been included in this study due to time constraints: – The solution must fit PSD2 and eIDAS legislation: the solution shall be compatible with both the Revised Payment Services Directive (PSD2) and the electronic Identification, Authentication and Trust Services regu- lation (eIDAS), as described by [62]. For the former, the system must (1) provide or facilitate Strong Customer Authentication, and (2) only grant access to the Payment Service Provider (PSP) for Account Information Ser- vice Providers (AISP’s) and Payment Initiation Service Providers (PISP’s), based on informed and explicit consent by the subject, which can be revoked at any time. For the latter, the solution must (1) enable European Member States to verify a subject’s data, originating from another European Member State, on the system, and (2) provide the technological means to sign data using advanced or qualified digital signatures.
  29. 29. 29 – Hardware solution must be secure: the security of any (mobile) device used to store information related to the identity is potentially the weakest link in the system. Sets of requirements exist (i.e. within governments) that ensure a certain level of security of a device. A solution that uses mobile devices for the storage of private information, or for storing key material giving access to private information, must meet these requirements. – The device-to-owner link must be solid: often the user’s device stores at least some key material that unlocks her identity. The link between a user and a device has to be solid, such that others cannot impersonate the user or obtain unauthorized access to her identity by accessing her phone. Biometrics might be useful the establish this link. – Alignment to other sector choices: When moving towards large scale de- ployments, other sector’s choices for a (self-sovereign) identity management product should be aligned, to ensure interoperability between sectors. 9 Discussion & Acknowledgements Most of the 44 identity management solutions that we considered are relatively new, often leading innovation within their field. This might come at the cost of scarcity of (technical) documentation, which makes the products hard to match against the defined requirements. In some cases, it was possible to obtain addi- tional documentation or clarifications through our own network. Moreover, we could only compare the solutions that we know or heard of. As both authors are based in the Netherlands, this means that this work might be too Netherlands oriented, as we had more access to information regarding Dutch solutions. As a result, we may have been too generous for internationally lesser-known solutions, including IRMA, DIMS, and IPv8. As both authors are connected to Radboud University, the university that has brought forth IRMA, a conflict of interest for an unbiased evaluation may exist. However, the authors believe that they have carried out the analysis objectively to the best of their ability. Note that we did not offer solution developers the opportunity to provide feedback on our analysis due to time constraints. ING will correct factual er- rors at the time of first publication (2-2-2018). Closure date to report errors is 30-4-2018. Acknowledgements We would like to thank the participants of the Dutch Blockchain Coalition (BC3) who provided valuable input to this research. In particular, we would like to thank the reviewers of this document: Leonard Franken (Dutch Authority for the Financial Markets) and Andr´e de Kok (National Office for Identity Data). We also received useful documentation and clarifications from Johan Pouwelse and Quinten Stokkink (TU Delft), from Andrew Mooijman and Djuri Baars (Rabobank), and Alok Bhargava (Cambridge Blockchain LLC).
  30. 30. 30 REFERENCES References [1] About Miracl. url: [2] Muneeb Ali et al. Blockstack Technical Whitepaper. Tech. rep. 2017. url: [3] Lex van Almelo. “NotarisID veilig alternatief voor DigiD”. In: Notari- aat Magazine 10 (2014), pp. 8–11. url: notarisid-veilig-alternatief-voor-digid-digitale-dienstverlening- in-stroomversnelling. [4] AML BitCoin. url: [5] API Reference. url: [6] DS Baars. “Towards self-sovereign identity using blockchain technology”. MA thesis. University of Twente, 2016. [7] Biometric Blockchain Solutions — HYPR. url: biometric-bitcoin-blockchain/. [8] BITNATION PANGEA - Your Blockchain Jurisdiction. url: https:// [9] Block Verify. url: [10] (Github). url: https : / / github . com / TechEndeavors/ [11] Blockchain and Identity (Github). url: blockchain-identity. [12] Ahto Buldas, Risto Laanoja, and Ahto Truu. “Efficient Quantum-Immune Keyless Signatures with Identity.” In: IACR Cryptology ePrint Archive 2014 (2014), p. 321. [13] Cryptid. url: [14] CryptidID/Cryptid (Github). url: Cryptid. [15] Dienstbescrhijving SURFconext. url: content/assets/surf/nl/2015/dienstbeschrijving_surfconext. pdf. [16] Digital Me — more infrastructure. url: https : / / digital - me . nl / infrastructure/more-infrastructure/. [17] Docs Keybase. url: [18] eID & signing solutions. url: viewpage.action?pageId=10715243. [19] ExistenceID. url: [20] Focafet Foundation. url: [21] Getting Started with Sovrin, A Developer Guide from the Sovrin Foun- dation. url: [22] Governance Model ‘Qiy Scheme V1.1’. url: https://www.qiyfoundation. org/wp-content/themes/qiyfoundation_7/img/rulebook/Governance- Model-Qiy-Scheme-V1.1.pdf. [23] How It Works. url:
  31. 31. REFERENCES 31 [24] How Sovrin works. url: 2017/04/How-Sovrin-Works.pdf. [25] Hyperledger Welcomes Project Indy. url: archives/2017/05/hyperledger_welcomes_project_indy.shtml. [26] ID3. url: [27] Identity Compliance Solutions — Cambridge Blockchain. url: https:// [28] IDNext Trustester. url: laarakkers.pdf. [29] Interview with Simon Wilkinson from Tradle Europes No. 1 Blockchain Fintech. url: tradle-europes-no-1-blockchain-fintech/. [30] IRMA in detail. url: uitleg/. [31] IRMA issuance and disclosure protocol. url: https : / / credentials . [32] IRMA source code. url: [33] Jumio - Homepage. url: [34] Jumio - Wikipedia. url: [35] KYC-Chain - Enhanced KYC on Blockchain Technology. url: https:// [36] Learn How ShoCard & ShoBadge Work. url: it-works/. [37] Dr. Christian Lundkvist et al. UPORT: A PLATFORM FOR SELF-SOVEREIGN IDENTITY. Tech. rep. url: whitepaper_DRAFT20170221.pdf. [38] url: [39] Netki Verify Your World. url: [40] OpenID Connect FAQ and Q&As. url: faq/. [41] Pim Otte, Martijn de Vos, and Johan Pouwelse. “TrustChain: A Sybil- resistant scalable blockchain”. In: Future Generation Computer Systems (2017). [42] Our Platform - Trunomi. url: [43] Qiy Foundation — Technology. url: qiy-scheme/what-is-a-scheme/technology/. [44] Drummond Reed, Jason Law, and Daniel Hardman. The Technical Foun- dations of Sovrin. Tech. rep. 2016. url: content/uploads/2017/07/The-Technical-Foundations-of-Sovrin. pdf. [45] Markus Sabadello. A Universal Resolver for self-sovereign identifiers. url: for-self-sovereign-identifiers-48e6b4a5cc3c.
  32. 32. 32 REFERENCES [46] N. Sakimura et al. OpenID Connect Core 1.0 incorporating errata set 1. Tech. rep. 2014. url: connect- core-1_0.html. [47] SelfKey Self-Sovereign Identity Network. url: [48] SelfKey Whitepaper 4.6. Tech. rep. 2017. url: content/uploads/sites/19/2017/11/selfkey-whitepaper-en.pdf. [49] Self-Sovereign Identity Principles (Github). url: ChristopherA/self-sovereign-identity/blob/master/self-sovereign- [50] Sovrin FAQ. url: [51] Sovrin Provisional Trust Framework. url: content/uploads/2017/07/Sovrin-Provisional-Trust-Framework- 2017-06-28.pdf. [52] Technology - Sovrin. url: [53] Susanne Tarkowski Tempelhof et al. Pangea Jurisdiction and Pangea Ar- bitration Token (PAT) - The Internet of Sovereignty. Tech. rep. 2017. url: BITNATION%20Pangea%20Whitepaper%202017.pdf. [54] The IdenTrust Rule Set: Providing Secure Identities While Protecting Pri- vacy. url: WhitePaper.pdf. [55] Tradle presentation. url: content/uploads/2016/12/11.20-Tradle.pdf. [56] tradle/bots. url: tradle-server-and-the-clients. [57] Trulioo developers. url: [58] TrustTester: Secure validation of personal data. url: https://www.tno. nl/en/focus-areas/industry/networked-information/information- creation-from-data-to-information/trusttester-secure-validation- of-personal-data/. [59] uPort source code. url: [60] Visa Selects Daon to Provide Biometric Authentication Services for ‘Visa ID Intelligence’ Platform. url: https : / / www . daon . com / newsroom / press-releases/486-visa-selects-daon-to-provide-biometric- authentication-services-for-visa-id-intelligence-platform. [61] What is Azure Active Directory? url: en-us/azure/active-directory/active-directory-whatis. [62] Marvin van Wingerde. “Blockchain-enabled self-sovereign identity”. MA thesis. Tilburg University, School of Economics and Management, 2017.