Self Sovereign Credentials

Verifiable Credential

A verifiable credential is one a third party can verify without asking the issuer.

Difference between SSL and SSI

In SSL, a certificate issued by a CA is trusted blindly.

In SSI, the verifier checks the signature itself. With web DID, it gets the public keys from the signer. Or the signer publishes its public keys to a central registry. Then the verifier reads them from that registry.

Credentials are sent in plain text

A credential, such as a degree or driver's license, is sent to a verifier as plain text. The data itself isn't encrypted.

This is why digital signatures are used here.

DID

DID stands for Decentralized Identity. It's the ID of an entity. It's like a user ID in centralized identity systems. Normally, identities are centralized. The credentials sit on a central server.

DID Doc

why DID doc is necessary

With SSI, the client app sends its self-signed credential in a header. This header can't be too big. It mainly holds the DID and basic information.

The receiver then uses the DID value to fetch the DID doc as a separate entity. This document holds all the needed information. For example, the public key and URLs for other services it exposes. These can be used to get verifiable credentials.

The DID value must follow a set syntax. This schema already defines how to fetch the DID doc.

did:web:widget-x.foo.com # This DID means, the doc is available on web via https://widget-x.foo.com/.well-known/did.json

Verifiable Presentation

It's the verifiable credential the holder presents to the verifier.

1. It can hold the full credential from the issuer, or part of it.
2. The credential also holds the issuer's signature.
3. The holder signs it to prove their identity.

Multiple proofs

The verifiable presentation has a parent proof for the whole DID document. The DID document holds the issuer's proof inside.