In this article we will try to breakdown the concepts and terminology behind SSI, as well as the reasoning for its increasing traction particularly in Europe. Traditionally speaking human beings are identified through reference, claims made by ourselves are generally regarded as useless if there is no one to “back them up”, so to speak. As an example a statement by an individual that he is a citizen of country X is meaningless if he does not possess a passport i.e. a claim, issued to him by a trusted third party, in this case a government.
To combat this problem governments and later businesses started issuing attestations about certain claims. Sometimes these claims are directly tied to an individual, in which case the documents stating those claims carry a photograph of the said individual or a serial number, often referred to as a tax or personal number. Other claims simply state that they belong to the holder, in which case whoever possesses the claim is also its owner or can state that the claim refers to them. As the time passed new concepts were introduced, such as a legal person, the idea that an incorporeal construct or agreement can also have an identity. In the following text we will use the term entity to denominate both terms.
With the advent of Internet, a need arose to identify entities online and while legal persons can have their information be made public, natural persons wish to maintain their privacy which is also guaranteed by law. The traditional model taken from the physical world was transcribed into the digital and the end result is a fractured landscape in which every entity offering any services online keeps its own database of users, performs identity verification and uses proprietary ways of storing the user data. To combat this, federated identity networks were created to foster data sharing and interoperability but due to strict privacy laws these federated systems very rarely extend across borders.
The situation around online identity is even worse in the private space of the Internet where companies such as Google, Facebook, Twitter, LinkedIn etc. offer federated online “identities” without actually knowing to whom that identity belongs to. In essence they issue attestations to e-mail addresses and there is no way of knowing who is controlling that e-mail address.
“On the Internet, nobody knows you’re a dog.” Peter Steiner, The New Yorker, 5. July 1993
This finally brings us to self-sovereign identity. This term is often misunderstood as meaning that an entity can self-issue claims about themselves without the need for trusted issuers. This is wrong in the sense that claims still need to be issued by someone whom everyone trusts same as before. What SSI means is that the entity carried its data with him and has control over it. This means controls over both storage and access. For example, traditionally you would walk into institution A to acquire a certain document which institution B needs in order to provide a service to you. This can be simplified in a federated system by having institutions A and B talk directly to each other but this still does not solve the fundamental problem that the entity to whom this data belongs to and about whom it actually is, does not have direct control and is dependent on the services provided by institutions A and B. The relationship is setup in a way that the entity has to ask for permission to use its data.
A FUNDAMENTAL SHIFT
With SSI this model is flipped around and the entity controls the data and access to it while the institutions A and B would ask the entity to provide tem access to its data. This is a fundamental shift in the balance of power between entities and service providers on the Internet. The SSI ecosystem revolves around decentralized identifiers (DID) and Verifiable Credentials (VC), both of which are standardized by the W3C. We can think of a DID as a document identifier which is not stored centrally with some institution but rather on a distributed network, most often a blockchain. The control of the DID Document and its associated public key(s) is proved by the possession of a paired private key. Now that we have an identifier we need something for it to identify. This is where the VCs come into play. VCs are claims made about an entity which are stored in a standardized form as JSON-LD documents. Claims can be anything, from an entities name, relation to another entity, or even full documents. UNISOT through its UNISOT ID service offers a full SSI solution with a registered DID schema on the BSV ledger (did:unisot). Our solution follows the Verifiable Credential model as defined by the W3C as well as the DID specification.
The image above shows how these concepts come together. We see a traditional issuer issuing a claim (VC) to a citizen (holder) and at the same time storing the signature of the issued VC on a distributed ledger (blockchain). The holder countersigns the VC with his own private key thus creating a strong proof of ownership. Seeing as how the VC is in essence a JSON file it would be easy for someone else to get a hold of the claim not intended for them. By countersigning the claim with the holder’s private key and storing the signature on the blockchain we are creating a strong link between the holder and the VC. The Verifier, which is in essence any third part wishing to verify a claim, asks the holder to present the VC and checks the signature of the VC on the blockchain.
This way the verifier can be sure as to who issued the VC, who it was intended for and that no tampering has been done after the issuance. This model fosters standardization amongst data processors by having them adapt to the data format used by the holders and it can be argued is an effective deterrent against large-scale ransomware attacks. For example, ransomware attacks on healthcare institutions are very tempting due to the time sensitive nature of the data and while SSI would not be able to help with the internal data we can see that it would be very useful for an individual to have his entire medical history in personal possession alongside it being stored with medical practitioners.
SSI has also been recognized by the EU as an effective way of bridging the gap between identity systems of different member states which often refuse to share data cross border to national laws. By transferring the ownership of the data into the hands of the citizen these limitations are bypassed as the citizen has the right to use the data as he sees fit. This has led to the creation of the European Self-Sovereign Identity Framework (ESSIF) which aims to become a golden standard in SSI space and have the same effect for identity globally as GDPR has had for privacy.
If we look closely towards the BSV ecosystem and how SSI can provide new opportunities here we can see that one of the problems plaguing the blockchain space in general is the inherent user unfriendliness of blockchain addresses which are represented as meaningless strings of characters such as for example “n1aAmTXAg4o44Z9k8YCQncEY91r3TV7WU4”. In the BSV ecosystem one of the ways to mitigate this issue has been presented by nChain and MoneyButton with their Paymail identity scheme which links BSV addresses to e-mail like naming format, for example “email@example.com”. The address is resolved through DNS SRV records which points to a server containing a list of supported services. While definitely a step in the right direction, Paymail ultimately still validates the “identity” of the e-mail in question and not the individual. While this can be solved by establishing the identity of the owner at the time of issuance it still leads to a serviced solution depending on DNS lookups. The schema also in essence represents a federated system based on domains. By enhancing the Paymail with SSI in the form of issuing a VC for a given Paymail address these issues can be effectively mitigated creating a synergy between the two identity solutions in the BSV ecosystem.
UNISOT Enterprise Architect
Leave A Comment