Introduction

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 personal data is shared and used.

Under self-sovereign identity model, individuals and organizations (holders) who have one or more identifiers (something that enables a subject to be discovered and identified) can present claims relating to those identifiers without having to go through an intermediary.

What is an Issuer, Holder, and Verifier?

Issuer: An entity that issues a credential. Eg: a test management facility like a hospital that issues a patient record like “Covid -ve“. Issuer has the right to revoke a credential

Holder: An entity that has lifecycle control over the issued credentials like sharing, deleting. Eg: A patient that holds a credential issued by an issuer on their wallet (a wallet could be an app that stores users credential data locally or a custodial wallet managed on behalf of a holder)

Verifier: An entity that verifies if the credential shared by a holder is valid (i.e. if the credential comes from a trusted issuer, not revoked by the issuer). Eg: An access management system installed at a facility like airport that allows / denies access based on if the holder is covid -ve/+ve. Verification could be a combination business logic like “is the credential is issued in the last 14 days” and “is it issued by an issuer that is recognized“

Note: One entity can play multiple roles. Eg: A hospital can play the role of a verifier and an issuer

Here are some basic terminologies used in the SSI ecosystem: https://www.w3.org/TR/vc-data-model/#terminology

What is a Verifiable Credential and Verifiable Claim?

The term “credential” can imply any (tamper-resistant) set of information that some authority claims to be true about you, and that enables you to convince others (who trust that authority) of these truths. Eg: A diploma issued by a university proves you have an educational degree. A passport issued by a government of a country proves you are a citizen.

Every credential contains a set of claims about the subject of the credential i.e. about the holder. These claims are made by an Issuer.

To qualify as a credential, the claims must be verifiable in some way. This means a verifier must be able to determine the following:

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

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.
Physical CredentialDigital Verifiable Credential

What is a Decentralized identifier (DID) and DID Document?

DID is a type of identifier that enables a verifiable, decentralized digital identity. It is based on the Self-sovereign identity paradigm. A DID uniquely identifies an entity (like a person or organization). These identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, identity provider, or certificate authority. Generation and control over DID lies with the identity owner i.e. DID subject (eg: through private keys in a wallet).

DIDs are persistent, cryptographically verifiable, and are dereferencable.

DIDs are building blocks for verifiable credentials, wallets, etc. To make all this work, we need to be able to “resolve” DIDs to their associated DID Documents. This process fulfills a similar purpose as DNS does in the classic web.

DIDs have a foundation in URIs. A simple way to think about DID is that it is a new type of URI that does not require a centralized authority to register, resolve, update, or revoke.

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 in order to connect with the DID subject. The key information contained in a DID document are public keys, service endpoints, and authentication methods.

DID Document

What is a DID Method?

DID method is used to resolve a DID to DID Document. To use a DID with a particular distributed ledger or network requires defining a DID method in a separate DID method specification. A DID method specifies the set of rules for how a DID is registered, resolved, updated, and revoked on that specific ledger or network. This design eliminates dependence on centralized registries for identifiers as well as centralized certificate authorities for key management—the standard pattern in hierarchical PKI (public key infrastructure). Because DID records are on a distributed ledger, each identity owner may serve as its own root authority—an architecture referred to as DPKI (decentralized PKI). Examples:

  • did-jolo is a DID method implementation for anchoring DIDs using the Ethereum Rinkeby Testnet, and persisting DID Documents on IPFS.

  • did-elem is an implementation of the Sidetree protocol that uses the Ethereum blockchain as the ledger layer and IPFS as the Content-addressable storage layer.

    What is DID Anchoring and DID Resolution?

    In this context, an “anchor” is a digital fingerprint / reference of data stored externally. The main idea of anchoring a DID is to make the DID resolvable via a Distributed Ledger.

In the context of did:jolo method, DID Anchoring refers to creating the mapping from DID to IPFS address. This anchoring process is analogous the the Create step of a CRUD database. This process is also tied to the creation of the DID, as the Ethereum key pair used to generate the DID should also be the one to perform anchoring transaction.

DID Resolution is the operation of deriving DID Document for a DID. In the context of did:jolo, DID Document resolution is achieved by querying the registry smartcontract with a DID. If that DID is registered, an IPFS address will be returned. Otherwise, an empty address is returned. This IPFS address can then be resolved through IPFS to the DID Document.

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 hodling your crypto funds or holding your digital identity, typically on your own 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 control over the contents of your wallet while you only have to give permission to do CRUD operations on wallet contents. That way you don’t have to worry about losing your private key.

What is SSI as a Service?

Affinidi provides building blocks for interested developers to build their applications using the Self Sovreign Identity paradigm. The way we do this is by providing a set of REST endpoints that can be easily used to enable basic SSI principles. We call this offering SSI as a Service.

Here's a big picture overview of Affinidi's Stack:

This diagram shows how Affinidi's Software Components interact with each other

Big Picture Overvier Affinidi