Government Sovrin SSI

Dispelling 7 Myths of Self-Sovereign Identity (SSI)

Misinformation is everywhere. In this post we fact check 7 myths of SSI, including scalability, privacy, compliance and governance.

Let me start by saying that the image selected for this post is not me having a bad hair day! To confirm it is the mythical creature, or character, Medusa….

The identity debate is heating up, and we are fast approaching real world applications being delivered that look to address many of the needs behind digital identity. However, like all debates, there are lots of myths and miss-information created, typically to dispel one model over another.

I personally really hate this, I have spent several years of my life committed to understanding digital identity models more, working towards the adoption of fundamental pillars, such as security, privacy and trust. This is why ID Crypt Global became a Steward of the Sovrin foundation, to be part of that governance framework and to ensure we all do the right things as a community. Sadly, misinformation spreads and before you know it, policy makers are basing decisions on information that is factually incorrect.

So here are 7 pieces of misinformation / myths that often get levied against SSI.


Many claim that SSI cannot scale to meet the demands of millions and millions of users. They also believe that because SSI utilises DLT blockchain technology, that again it hinders the scalability of the solution, and that it becomes energy intensive to use such an infrastructure.

So here are the facts. SSI has the data self-sovereign to the identity owner. This means the data lives with the identity owner securely on a device or agent that runs in the cloud.  When verification takes place, the data on the identity owners device is shared peer-to-peer, no centralised infrastructure and no use of any blockchain. The data has been signed by the issuer, whose public signing key lives on the blockchain. Now, if the key hasn’t been cached by the verifier (and many can and will do that – because it is the verifier that states which credentials are valid, and therefore will be able to cache specific signing keys) the key is retrieved from the blockchain, this is a read operation only, so it’s very efficient. In terms of performance, a read operation is never a challenge for a blockchain implementation, and in terms of energy intensive, its no heavier than any other read operation.

As data is shared point-to-point, and because public keys can be cached by a verifier, there is no centralised infrastructure or access to the DLT required at this point. Even if the verifier must retrieve a public signing key, it’s a lightweight and highly performant operation.

Fact check…The entire SSI model is far more capable in terms of scale than any other approach.


Various protocols, standards, different infrastructures do cause friction across all industries, a great example being the financial services industry with trying to move money between various payment systems. The SSI community has been working exceptionally hard in this area to ensure that SSI models are interoperable with each other.

Recent work carried out by a partner of ours, Animo Solutions, has shown just how interoperable SSI can be, ensuring SSI models can be ledger agnostic. By this the community means, SSI implementations can run using various different identity infrastructure underneath, for example Sovrin or Cheqd, but the solution still works, supporting credentials based around both ledgers.

But it’s not just about ledgers, its about the different types of identity credentials that can be supported. Some like W3C standard based credentials, however, they lack specific privacy capabilities, which means that many SSI solutions utilise AnonCreds, which supports concepts such as Zero Knowledge Proofs (will talk about that capability shortly).  But as solutions are becoming ledger agnostic, so are they becoming agnostic to which credentials are used – though clearly solutions specify which is preferred based on privacy capabilities.

So as a fact check, SSI solutions and technology is becoming highly interoperable with other SSI implementations.


Privacy is at the heart of SSI, so this being seen as an issue for SSI is somewhat confusing to me. SSI is the only model that has privacy at the very centre of it. So, what do people fear is an issue with privacy?

Many believe that personal identifiable and private data is stored on the blockchain that is used to deliver an SSI solution. This is fundamentally untrue. There is zero personal identifiable data ever stored on the blockchain. Because many believe data is resident on the blockchain, privacy is then raised as a concern. Who can see that data on the blockchain? The blockchain is immutable, so how do I maintain the right to be forgotten? Both questions are void as data doesn’t reside on the blockchain.

In an SSI solution, data is sovereign to the identity owner and is shared peer-to-peer. The identity owner confirms what data they are happy to share, and they control when they share it. In addition, SSI fundamentally believes in Zero Knowledge Proofs (ZKPs) which allows confirmation to be shared about the identity owner WITHOUT the need to share the underlying data. A quick example, confirming I am over the age of 21. There is no need to share my date of birth to do this, rather a ZKP cryptographically confirms that I have an identity credential (that is trusted by the verifier) that confirms I am over the age of 21.  There is no other model that supports privacy as much as SSI.

Let’s talk the right to be forgotten. Well data is shared peer-to-peer and limited data at that. If you wish to be forgotten, then it is the company you shared the data with that needs to “forget you”. This is far simpler in an SSI model, as for many use cases they don’t hold identifiable data about you. If they do, then this is no different to how they hold data about you today, and the company is legally bound to provide that right to be forgotten.

So as a fact check, SSI solutions support the privacy of the identity owner much more than any other model and solution available.


Many do not understand where liability lives in a decentralized platform, and because liability in DLT solutions used for financial services can get, shall we say complex, there is an immediate assumption that the same is true for identity. The answer is simply no.

Let’s look at the moving parts with SSI. The verifier is liable at all times for operating their business, and lets say confirming that I as a customer am over the age of 21. They therefore trust specific issuers of SSI based identity credentials. This is no different to them trusting a typical platform provider for credit ratings etc. With ID Crypt Global, they actually have more control and understanding because we provide those that feel they need it, oversight to how identities are created and issued by ID Crypt Global. As a company, ID Crypt Global is liable for keeping data it stores safe regarding identities it has issued to. That data is limited to only the identity information ever issued – and since this is small, ID Crypt Global as an issuer isn’t some central store / honeypot of data, it has very limited data, the rest is, guess what, self-sovereign to the identity owner.

Fact checks. The liability model is no different to that which is in place today for any service provided or sold.


DLT conjures up this view that there is a zero-trust model and zero governance. The reality is very different, Governance is in place at an infrastructure level, and Sovrin has a very mature governance model in place. But let’s be clear, the governance model is about access to the underlying blockchain and who can write to it. Governance structures after that are the same as they are today.

How an issuer runs its company? Same governance requirements as it ever had, and there are things like ISO accreditations to help companies prove their governance. How a verifier runs its company? Well, that’s again unchanged. If the company is regulated, its still regulated in the same way.

So, fact check again? Governance is at the infrastructure level, but in terms of identity solutions and how they are implemented and used, it all falls under the very same governance capability that verifiers and issuers must abide by in any case.

Regulatory Compliance

Everyone loves to throw in regulatory compliance into any solution, often before thinking in-depth of what do they mean?

Regulatory compliance is based on making sure you do the right things, and more importantly aren’t doing the wrong things. The fact that SSI uses a blockchain has no bearing on regulatory compliance, why? Because no personalised data is resident on the blockchain.

As a regulated bank, for example in the UK, an SSI identity that is presented as proof of identity has the same regulatory requirements applied to it as if the identity holder presented their passport in the bank branch. The regulated bank must be accountable for ensuring and doing everything it can that the identity is accurate. An SSI proof therefore is subject to the same level of scrutiny by the bank as the physical passport or any other implementation they chose for enforcing good KYC practices.

I personally would argue that for a regulated institution, some SSI implementations ease the compliance burden on the bank. It does so because some issuers are able to verify an identity better than those processes typically implemented by a bank, and in addition, the nature of an SSI credential is far more secure once issued, held and presented than any form of physical identification. Couple this capability with the need to only store that which you must and issues like GDPR are also made easier.

Fact check. Regulatory compliance is easier with SSI than without.


So, myth number 7 of 7. Trust. Can you trust an issued SSI credential or not? To answer this you need to be aware of two elements of trust, the first being security around the presentation of the SSI credential and the second, how was the SSI credential issued.

First off. Trusting a presented credential. Well, this is easy to answer, trust is in mathematics and cryptography. Presented proofs are cryptographically secured and cryptographically verifiable, so you can apply science and maths to your trust model. A credential that is presented is not about trust, its about knowing, which is much better.

The second point, trusting the issuer, well this is the crucial aspect. At ID Crypt Global we provide oversight to any verifier that wishes to verify credentials we issue. This isn’t about building trust, rather its about showing them exactly what we do and how we do it. The verifier can then select if they trust our credentials or not – and so far everyone we have spoken to does. So that’s a great testament to the work we have put in to date.

However, what about when things scale up? In a world where we hope many SSI issuers are providing specific credentials and details within those credentials, how do we know who to trust at scale. Well oversight still works, however for verifiers this becomes too much hard work – having oversight of several organisations will be tough, let alone hundreds. This is where government has a role to play, ensuring that issuers are audited, verified and awarded with a status so that verifiers know they can trust credentials issued by that issuer. Finally, fact check number 7. Can I trust an SSI credential? Yes, you can. Can I trust the issuer? Yes, you can if you do your research. I wouldn’t recommend you trust blindly, why would you? You wouldn’t do that with any other supplier, so why here.

Leave a Reply