19 FAQs on Verifiable Credentials and Self-Sovereign Identity

9 min readMay 31, 2021

This article has some FAQs on the basics of Verifiable Credentials (VCs) and Self-Sovereign Identity (SSI).

What is an Identity?

An identity is a unique characteristic, value, or document that has a one-to-one relationship with only one entity. For individuals, identity is biometric information, a unique number such as a driver’s license number, etc. However, the key aspect is that this information must be owned solely by that entity.

What is Self-Sovereign Identity (SSI)?

SSI is a digital movement that aims to enable individuals or organizations to have sole ownership of their identity, and to have control over how their data is shared and used.

What are Verifiable Credentials (VCs)?

Verifiable credentials, or VCs in short, are tamper-evident credentials that can be verified cryptographically.

There are three essential components of verifiable credentials, and they are:

It is machine verifiable.
It is secure and tamper-evident.
Has been issued by a competent authority.

Here’s how a VC looks like

{
  // 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:73: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/keys/1",
    // the digital signature value
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
 }
 }

Who are Issuers, Holders, and Verifiers in a Verifiable Credential?

An issuer is an entity that is authorized to issue a credential. These issuers are typically government organizations, healthcare centers, banks and financial institutions, schools and universities, startups, etc.

A holder is someone who is the owner of the credential and has complete control over how it can be managed, with whom these credentials can be shared, or revoked. Holders are typically individuals or organizations.

A verifier is an entity that verifies a credential and ensures that it comes from a competent issuer, is tamper-evident, and is still relevant (not expired or revoked). A verifier takes the verifiable presentation from the holder to determine its authenticity.

What’s the Difference Between a Verifiable Credential and a Verifiable Claim?

At the basic level, a claim is a statement. A claim becomes a credential when it is verifiable and backed by evidence.

In the digital identity world, a verifiable claim is a piece of information about the subject, and these are made by an issuer. To become a credential, each of these claims must be verifiable in some way.

Specifically, the verifier must be able to ascertain the following.

Who issued the credential?
That the credential has not been tampered with since it was issued
That the credential has not expired or been revoked

How to Verify a Credential?

With physical credentials, this is accomplished through some proof of authenticity embedded directly in the credential itself like a chip or hologram. It can also be done by checking directly with the issuer that the credential is valid, accurate, and current. But this manual verification process can be difficult and time-consuming — a major reason why there is a worldwide black market in falsified credentials.

This brings us to one of the fundamental advantages of verifiable credentials: using cryptography and the Internet, they can be digitally verified in seconds. This verification process can answer the following four questions:

Is the credential in a standard format and does it contain the data the verifier needs?
Does it include a valid digital signature from the issuer?
Is the credential still valid, that is, not expired or revoked?
If applicable, does the credential (or its signature) provide cryptographic proof that the holder of the credential is the subject of the credential?

(Credits to the book “Self-sovereign identity“ for this explanation)

What are Decentralized Identifiers (DIDs)?

A basic building block of SSI is Decentralized Identifiers (DIDs). These are a type of unique identifiers (URI) that enable entities to generate and control their identifiers in the digital world.

These DIDs come with certain properties and they are:

Does not require a centralized registration authority
Many DIDs use the distributed ledger technology or any other decentralized network, though it is not mandatory
It is a permanent identifier because it does not depend on a single third-party or centralized registry for its existence.
Can be cryptographically verified
They connect a DID subject (the entity identified by the DID) with a DID document (a set of data that describes the DID subject) to enable the subject to have trustable interactions.
They are interoperable and portable, provided they conform to the existing standards laid down by W3C

What is a DID Document?

A DID document is a JSON-LD object that contains a set of data that describes the DID subject including the cryptographic signatures, verification methods, or just about anything that will enable the DID subject to have trustable interactions with other entities on the network.

What is a DID Resolution?

DID resolution is the process of getting from a DID to its DID Document. It is analogous to the resolution of DNS name to IP address

DID Document contains metadata of a DID subject. It contains the minimum amount of information to connect with the DID subject. The key information contained in a DID document is public keys, service endpoints, and authentication methods.

What is a DID Method?

DID methods are the component that helps a DID to resolve a DID document. It defines how DID documents are created, read, updated, and deleted on a network.

DID methods are often associated with a verifiable data registry, which is a system that brings together DIDs, DID documents, and DID methods. Some examples of verifiable data registries are trusted databases, decentralized databases, distributed ledger, and government ID databases like DigiLocker. Sometimes, more than one type of registry can be used in the same ecosystem.

A DID document looks like this:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    // used to authenticate as did:...fghi
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
}

In terms of implementation, a DID method is defined by its specification that precisely defines how DIDs and DID documents are created, updated, deactivated, and resolved.

What is a Sidetree Protocol?

Sidetree protocol is an open blockchain-agnostic protocol developed by DIF and supported by Microsoft. The core idea of this protocol is to create decentralized identifiers that can run on any distributed ledger system.

This protocol is designed to overcome many technical problems in existing implementations that include high throughput and cost, presence of centralized authorities, lack of scalability, and more. The Sidetree protocol bridges the need for a decentralized and open protocol as it batches together JSON (a standard for representing structured data) operations to lower the associated costs, improve throughput, enhance scalability, and at the same, allow these operations to be anchored to any decentralized identity network.

It also helps to create unique identifiers that are controlled and managed by users with their public key infrastructure. Further, it conforms to the W3C specifications, so developers can use the decentralized identifier (DID) methods.

What are Peer DIDs?

Peer DIDs are implemented as a direct interaction between the two parties to a transaction.

The way that two entities interact with each other directly without involving a network is the core principle of peer DID methods.

The idea behind creating these peer DID methods is to ensure a cheap, fast, secure, and scalable way to create and maintain private relationships between two entities. Let’s say, Alice and Bob are two entities who are interacting with each other, so only both of them care about the transaction and have a need to resolve their respective DIDs.

What are Zero-Knowledge Proofs?

A Zero-Knowledge Proof (ZKP) is a cryptographic protocol where one entity can prove its identity to another entity without having to reveal the identifiable data of the transaction.

When you say that an entity has an identity, what you mean is that the entity has a series of claims that are used to uniquely identify it. Breaking it down further, we can say that this process comprises of two steps,

Creating a claim, where each claim is a subset that contributes to making an individual unique. Some examples of claims are date of birth, passport number, driver’s license, Social Security Number, or any other government-ID that belongs only to an entity and can be used solely to identify it.
Proving the claim — A means by which this claim is proven without the actual information.

What is IPFS?

InterPlanterary File System (IPFS) is a peer-to-peer network for storing files and tracking their versions in a distributed file system. It works by connecting all devices on a network to the same file system, and each file in it is identified by a unique crypto hash of its contents.

What are BBS+ Signatures?

The BBS+ signature scheme is a Digital Signature Scheme (DSS) with two distinct parties, namely, the signer and the signature holder. Here the signature holder is the owner of a signature while the signer is the entity authenticating that the signature belongs to the holder.

It is based on Pedersen commitment, a scheme that allows a sender to commit to a secret value that can be revealed in the future. Until then, the sender transmits a commitment to preserve the secret.

This commitment is the connecting aspect between the signature holder and the signer, and the contents are blinded until the holder decides to reveal it.

Also, these signatures give complete control to the holder to decide when and what must be revealed, and follow the principles of Zero-Knowledge Proofs (ZKPs) where the holder can prove the required identity to another entity without having to reveal the identifiable data of the transaction.

What is a Custodial Wallet?

In the context of a decentralized wallet, having private keys means that you have full control over the contents of your wallet. A decentralized wallet may be capable of holding your crypto funds or holding your digital identity, typically on your hardware (i.e. no central servers CRUDing your data). However, many people are not acquainted with digital wallet, blockchain technology, and the concept of public-private keys. A Custodial Wallet is defined as a wallet in which the private keys are held by a third party. Meaning, the third party has full control over the contents of your wallet while you only have to permit CRUD operations on wallet contents. That way you don’t have to worry about losing your private key.

What is PKI?

Public Key Infrastructure, or PKI in short, is a cryptographic system that consists of a key pair, one private and the other public. Both these keys work in tandem and are used for encrypting data and sharing it with others, so the contents can be seen only by the intended recipient.

Let’s understand how it works with an example. When Alice wants to send a message to Bob, she encrypts the message with Bob’s public key and sends it. In turn, Bob uses his private key that’s associated with the public key to decrypt and read the message.

What is a Verifiable Presentation?

A verifiable presentation is the collation of credentials that a holder wants to share with a verifier.

A holder can get signed credentials from different issuers and store them in the digital wallet. When the holder wants to share a set of credentials, they are collated into a presentation, and this is shared with the verifier.

What is SSIaaS?

SSI as a service is what Affinidi’s core aims to build for our applications. An application (i.e. an organization, a developer) that wishes to leverage SSI principles for their users’ identity can currently consume our SDK methods. The idea is to enable applications to do things like DID creation, VC sharing, etc. via API endpoints i.e. SSIaaS

To learn more about what we do, check out our Developer resources. You can also join our mailing list to stay abreast of exciting developments at Affinidi.