During the spring of 2022, I was involved in a project where I had to get familiar with the European Blockchain Services Initiative, EBSI [¹]. EBSI is an initiative between 29 countries (i.e., all EU member states together with Norway and Lichtenstein) with the goal of building public infrastructure. Infrastructure on which actors can build services for all EU citizens across country boarders and to do this with the use of Blockchain technologies. As interesting as this is in and of itself, this blog post is not about EBSI, but another concept that I encountered within the scope of the project, namely Self Sovereign Identities and Verifiable Credentials. Something that is part of EBSIs vision to enable, and something that, when I heard about it, got me very excited. In this post I want to explain what the concepts are, and why I think that they are exciting.

Self Sovereign Identities

Self-Sovereign Identities (SSI) are quite a large subject apparently. So large that it was a whole book written about it [²]. Although I have not read said book, it is probably worth a read if one wants to dig even deeper into the concept of SSIs. However, in this post we will focus on the basics. But before we can start discussing Self Sovereign Identities, we must first think a little bit about identities in general. Because identity is one of these subjects that seems basic (see also time/dates), but the more you think about it, the more complex you realize that it is.

In everyday life, there are a plethora of situations where one must provide some sort of evidence for their identity but that is usually not something that we think too much about. We are so used to just showing our ID-card or passport and get on with our day. However, if we stop to think a little bit about what is going on in that situation, we realize that such an interaction is not really an ID-check at all but instead, it is a display of trust. Because the one that wants to see your ID, commonly referred to as the relying party, has no way of knowing that the information on the ID card is correct. Instead, they must choose to trust the issuer of the ID card. In Sweden, that would typically by the Swedish police authority but in e.g., the case of an access card to enter your office, the issuer will probably be your employer. Both of these systems rely on the fact that the relying party trusts that if the issuer has issued an ID card, then that issuer have taken measures to assure that the information from the ID-card is correct.

But how can the issuer of an ID card know that the information is correct? In Sweden, the process is like the following for passports: The person that wants a passport (the subject) goes to the police authority to request said document. Most often than not, that person will already be a holder of a passport that is still valid and can thus use their old passport to identify themselves. In this case, the police authority does not do any verification of the actual identity, but instead they trust themselves to have correctly issued the old passport. However, the chain must start somewhere and, in the case where a person does not have a valid ID, they will have to bring someone with a valid ID and some relation to you to attest that you are who you are. That person can be e.g., a parent (which is commonly how children get their first passports), a grandparent, spouse, etc. In case no such person is around, an employer or someone at a governmental authority might also be eligible to attest your identity [³]. In this case, the police authority trusts themselves to have issued the attesters ID correctly, and trust that the attester speaks the truth. This is enforced by Swedish law and lying about someone’s identity is a crime. In other countries, e.g., Denmark, they do not require any relation between the attester and the subject. It is enough if the attester has had their digital identity for 30 days.

Once a person has acquired a physical identity document, this can be transferred into a digital identity. In Sweden (once again), there is a system called BankId which is an ID solution, to which you are onboarded by your bank. It is the de-facto digital identity solution in Sweden, and you can use it for almost everything digital. From sending money, to signing digital documents and even just signing into companies websites. It is used everywhere which means that everyone has to trust Finansiell ID-Teknik BID AB, which is the company that owns the service [⁴], which in turn is owned by the major banks in Sweden. It works such that when a user wants to authenticate something, it signs the request to the relying party which in turn verifies the signature towards the BankId’s verification server [⁵]. This system works very well in general, and most citizens are happy with it since it provides high security and users do not have to create user accounts everywhere. However, the system also allows Finansiell ID-Teknik BID AB to register exactly when and where users use their BankId to authenticate themselves. They know every time you sign into your bank, when you file your taxes, whenever you sign an agreement to buy or sell property, if you have been in contact with the bailiff agency, etc. And although they should not be able to see any actual data after that (such as who you are sending money to), even knowing where someone authenticates can be revealing enough. This problem of digital identity solutions that allows the issuer to track the subject around the internet is not unique. One of the most common federated authentication schemes Oauth2 also has this problem, meaning that whenever you choose the “Sign in with Facebook” and “Sign in with Google” button on some service, Facebook or Google is allowed to track you throughout the web [⁶].

So, now that we know about how identities work in the physical world, and the issues you might face when transferring them into the digital realm, let us look at how this problem can be solved with Self Sovereign Identities. In a way, SSIs is a way to design digital identities more like how physical documents work. The core idea about a self-sovereign identity is that the proof of the identity should belong to the user after it has been issued, and that it should not require any further interaction with the issuer and thus, the issuer would not be able to track the subject. In the later sections, we will go into more technical details about how this is achieved.

Decentralized Identifiers

One core component of the SSIs is something called a Decentralized Identifier (DID), which is standardized in a recommendation from w3c [⁷] since 2021. A DID is really just a string that is used to describe any natural person, legal entity or anything else that needs an identity, and it looks like: <protocol>:<domain>:<identifier>. Where an example could be: did:ebsi:zvHWX359A3CvfJnCYaAiAde for a DID that was stored on EBSI. The DID does not contain any more information in and of itself, but the subject that owns the DID, can then choose to refer to a DID when doing things online, e.g., registering for a service, by referring multiple different sources to a DID, it is possible to create a complete identity. The nice thing about a DID is that it is nothing that limits a person to only having one DID. E.g., a person could have one DID when representing their employer and another one when they only represent themselves. For this to work, the w3c standard describes that a DID must be resolvable into a DID-document which describes metadata about the DID. An example of such a document can be seen below:

{
  "id": "did:ebsi:zvHWX359A3CvfJnCYaAiAde",
  "authentication": [{
    "id": "did:ebsi:zvHWX359A3CvfJnCYaAiAde#keys-1",
    "type": "Ed25519VerificationKey2018",
    "controller": "did:ebsi:zvHWX359A3CvfJnCYaAiAde",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
}

as we can see, the document specifies the DID together with a public key. This is essential, because this means that if we receive a message which has been signed with the private key that corresponds to the public key in the DID document, we know that this message cannot have come from anyone, but the entity described by this DID. This is due to how public key cryptography works. A reminder of how public key cryptography works can be found in: [⁸].

Verifiable Credentials

Verifiable Credentials (VC) is, yet another, w3c recommendation [⁹] which describes something that can best de understood as a digital credential document. A VC can describe virtually anything about a subject which makes its uses extremely flexible. But common examples of a VC include passports and university diplomas. According to the recommendation, a VC is represented as a JSON document that includes the subject DID, some attributes about the subject (such as nationality, or graduation university) and the proof, which is the signature of the VC, made by the issuer. This proof part is crucial to the self-sovereign part as we will see. Below is an example VC from the w3c recommendation:

{
  // set the context, which establishes the special terms we will be using
  // such as 'issuer' and 'alumniOf'.
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  // specify the identifier for the credential
  "id": "http://example.edu/credentials/1872",
  // the credential types, which declare what data to expect in the credential
  "type": ["VerifiableCredential", "AlumniCredential"],
  // the entity that issued the credential
  "issuer": "https://example.edu/issuers/565049",
  // when the credential was issued
  "issuanceDate": "2010-01-01T19:23:24Z",
  // claims about the subjects of the credential
  "credentialSubject": {
    // identifier for the only subject of the credential
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    // assertion about the only subject of the credential
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  // digital proof that makes the credential tamper-evident
  // see the NOTE at end of this section for more detail
  "proof": {
    // the cryptographic signature suite that was used to generate the signature
    "type": "RsaSignature2018",
    // the date the signature was created
    "created": "2017-06-18T21:19:10Z",
    // purpose of this proof
    "proofPurpose": "assertionMethod",
    // the identifier of the public key that can verify the signature
    "verificationMethod": "https://example.edu/issuers/565049#key-1",
    // the digital signature value
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}

Once this document is issued to the user, the user stores it in a wallet, which is a term from the web3 space. Although it is surrounded by quite a lot of fuzz, in practice, it is simply an application that manages your private keys in a secure and user-friendly way. This wallet would then hold all the users VCs together with the key pairs for the users various DIDs. So, if we take the example of requesting a digital passport, the lifecycle of such a VC would be as following:

1. You go to the police office and request a VC that matches your passport, you ask them to issue the VC to a DID of your choice and you sign the request with your wallet.
2. The issuer, the police authority in this case, issues a VC with the same information that is in your physical passport, and signs it with their private key.
3. You download the VC and store it on your wallet.
4. When requested, e.g., at the boarder when traveling abroad, you show your VC to the boarder control (which is relying party in this case).
5. Since the VC is signed and the relying party knows the public key of the Swedish police authority, all they have to do is to verify the signature and since they trust the Swedish police authority, they know that the information in the VC is correct.

Notice how the relying party never have to contact the police authority to verify the VC, which means that the Swedish government cannot keep track of your travel patterns. Much like with physical passports however, a VC can also be set to have an expiry date. After which the subject will have to request a new one.

Verifiable Presentations

The lifecycle described above, although correct, lacks an important part to be complete, namely Verifiable Presentations (VP). A VP is a representation of one or many VCs which is the first important part. It is possible to combine multiple VCs into one VP. There are multiple reasons for why you would want to do that, for example if you have degrees from multiple different universities or perhaps you are a doctor that have one VC that attests this fact, together with a VC that is issued by the hospital on which the doctor works.

The second and perhaps most important reason why a VP is needed, is because the VP is signed by the same key as the users DID. So, the VP becomes a proof of possession of the DID key. That is, by submitting a verifiable presentation, the user can prove that they are the rightful holder of the original credential.

And the third and last reason why a verifiable presentation is a great thing is also exemplified by the above example, albeit not that obvious. In the above example, it was said that the Swedish government cannot keep track of their citizens travel habits. That is unfortunately not true from that example alone, since if you are traveling to e.g., Denmark, there is nothing stopping the Swedish government from signing an agreement with Denmark, that stipulates that Denmark will inform Sweden about all their citizens that enters the country. A verifiable presentation can remove this problem by making use of something known as Zero Knowledge Proofs (ZKP), which is also described in the w3c document [¹⁰], as a way of proving some attribute from the VC without disclosing the actual value. Which in this case would mean that you would be able to prove to the Danish border control that you are the holder of a Swedish passport, and thus eligible for entering the country, but nothing more about who you are. And since you have not revealed any information about yourself you do not have to trust the Danish government to not reveal any of your information, because the Danish government does not have any information about you to report.

Conclusions

By bringing all these concepts together, we can bring back control of the users’ data to the actual user. Once the issuer has issued a credential, the control over that credential is transferred to the user and the issuer has no more control over it. Instead, it is completely up to the user how they want to use their credential. First, to whom they want to show it, but by making use of a verifiable presentation, they can even decide exactly what data they want to reveal about themselves and thus, the control about their personal data is back completely in the hands of the user. And this is why I think these concepts are so awesome.