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.

1. Matching Identity Management Solutions to
Self-Sovereign Identity Principles
Tommy Koens and Stijn Meijer
ING
tommy.koens@ing.com, stijn.meijer@ing.com
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 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
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
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
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
onename.io 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
Meeco.me [38] N/a Yes
Daon.com [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
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
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
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
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
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
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
onename.io Onename.io 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
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
Meeco.me Meeco.me 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 Meeco.me
not applicable. Knock-out: Yes
Daon.com Daon.com 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
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
– 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
– 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
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
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
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
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
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
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
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
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
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
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
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
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
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
– 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 REFERENCES
References
[1] About Miracl. url: https://www.miracl.com/about-miracl.
[2] Muneeb Ali et al. Blockstack Technical Whitepaper. Tech. rep. 2017. url:
https://blockstack.org/whitepaper.pdf.
[3] Lex van Almelo. “NotarisID veilig alternatief voor DigiD”. In: Notari-
aat Magazine 10 (2014), pp. 8–11. url: https://www.knb.nl/stream/
notarisid-veilig-alternatief-voor-digid-digitale-dienstverlening-
in-stroomversnelling.
[4] AML BitCoin. url: https://amlbitcoin.com/.
[5] API Reference. url: https://docs.civic.com/.
[6] DS Baars. “Towards self-sovereign identity using blockchain technology”.
MA thesis. University of Twente, 2016.
[7] Biometric Blockchain Solutions — HYPR. url: https://www.hypr.com/
biometric-bitcoin-blockchain/.
[8] BITNATION PANGEA - Your Blockchain Jurisdiction. url: https://
tse.bitnation.co/.
[9] Block Verify. url: http://www.blockverify.io/.
[10] BlockAuth.com/Whitepaper.md (Github). url: https : / / github . com /
TechEndeavors/BlockAuth.com/blob/master/Whitepaper.md.
[11] Blockchain and Identity (Github). url: https://github.com/peacekeeper/
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: http://cryptid.xyz/.
[14] CryptidID/Cryptid (Github). url: https://github.com/CryptidID/
Cryptid.
[15] Dienstbescrhijving SURFconext. url: https://www.surf.nl/binaries/
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: https://keybase.io/docs.
[18] eID & signing solutions. url: https://support.signicat.com/pages/
viewpage.action?pageId=10715243.
[19] ExistenceID. url: http://www.existenceid.com/.
[20] Focafet Foundation. url: https://focafet.org/.
[21] Getting Started with Sovrin, A Developer Guide from the Sovrin Foun-
dation. url: https://github.com/evernym/sovrin/blob/master/
getting-started.md.
[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: https://www.civic.com/products/how-it-works.

31. REFERENCES 31
[24] How Sovrin works. url: https://sovrin.org/wp-content/uploads/
2017/04/How-Sovrin-Works.pdf.
[25] Hyperledger Welcomes Project Indy. url: http://www.windley.com/
archives/2017/05/hyperledger_welcomes_project_indy.shtml.
[26] ID3. url: https://idcubed.org/.
[27] Identity Compliance Solutions — Cambridge Blockchain. url: https://
www.cambridge-blockchain.com/.
[28] IDNext Trustester. url: https://www.eema.org/wp-content/uploads/
laarakkers.pdf.
[29] Interview with Simon Wilkinson from Tradle Europes No. 1 Blockchain
Fintech. url: https://hollandfintech.com/interview-simon-wilkinson-
tradle-europes-no-1-blockchain-fintech/.
[30] IRMA in detail. url: https://privacybydesign.foundation/irma-
uitleg/.
[31] IRMA issuance and disclosure protocol. url: https : / / credentials .
github.io/protocols/irma-protocol/#attribute-based-signatures.
[32] IRMA source code. url: https://github.com/credentials/.
[33] Jumio - Homepage. url: https://www.jumio.com/.
[34] Jumio - Wikipedia. url: https://en.wikipedia.org/wiki/Jumio.
[35] KYC-Chain - Enhanced KYC on Blockchain Technology. url: https://
kyc-chain.com/.
[36] Learn How ShoCard & ShoBadge Work. url: https://shocard.com/how-
it-works/.
[37] Dr. Christian Lundkvist et al. UPORT: A PLATFORM FOR SELF-SOVEREIGN
IDENTITY. Tech. rep. url: https://whitepaper.uport.me/uPort_
whitepaper_DRAFT20170221.pdf.
[38] Meeco.me. url: https://meeco.me/how-it-works.html.
[39] Netki Verify Your World. url: https://www.netki.com/.
[40] OpenID Connect FAQ and Q&As. url: http://openid.net/connect/
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: http://www.trunomi.com/our-platform/.
[43] Qiy Foundation — Technology. url: https://www.qiyfoundation.org/
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: https://www.evernym.com/wp-
content/uploads/2017/07/The-Technical-Foundations-of-Sovrin.
pdf.
[45] Markus Sabadello. A Universal Resolver for self-sovereign identifiers. url:
https://medium.com/decentralized-identity/a-universal-resolver-
for-self-sovereign-identifiers-48e6b4a5cc3c.

32. 32 REFERENCES
[46] N. Sakimura et al. OpenID Connect Core 1.0 incorporating errata set 1.
Tech. rep. 2014. url: http://openid.net/specs/openid- connect-
core-1_0.html.
[47] SelfKey Self-Sovereign Identity Network. url: https://selfkey.org/.
[48] SelfKey Whitepaper 4.6. Tech. rep. 2017. url: https://selfkey.org/wp-
content/uploads/sites/19/2017/11/selfkey-whitepaper-en.pdf.
[49] Self-Sovereign Identity Principles (Github). url: https://github.com/
ChristopherA/self-sovereign-identity/blob/master/self-sovereign-
identity-principles.md.
[50] Sovrin FAQ. url: https://sovrin.org/about/faq/.
[51] Sovrin Provisional Trust Framework. url: https://sovrin.org/wp-
content/uploads/2017/07/Sovrin-Provisional-Trust-Framework-
2017-06-28.pdf.
[52] Technology - Sovrin. url: https://sovrin.org/technology/.
[53] Susanne Tarkowski Tempelhof et al. Pangea Jurisdiction and Pangea Ar-
bitration Token (PAT) - The Internet of Sovereignty. Tech. rep. 2017.
url: https://github.com/Bit-Nation/Pangea-Docs/raw/master/
BITNATION%20Pangea%20Whitepaper%202017.pdf.
[54] The IdenTrust Rule Set: Providing Secure Identities While Protecting Pri-
vacy. url: https://www.identrust.com/pdf/IdenTrust_Privacy_
WhitePaper.pdf.
[55] Tradle presentation. url: http://www.fintechconnectlive.com/wp-
content/uploads/2016/12/11.20-Tradle.pdf.
[56] tradle/bots. url: https://github.com/tradle/bots#your-bot-the-
tradle-server-and-the-clients.
[57] Trulioo developers. url: https://api.globaldatacompany.com/docs.
[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: https://github.com/uport-project/.
[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: https://docs.microsoft.com/
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.