Skip to main content

Decentralized Identity

Learning Objectives​

By the end of this lesson, you will be able to:

  • Define decentralized identity (DID) and self‑sovereign identity (SSI) in engineering terms.
  • Explain the roles of DIDs, wallets, and verifiable credentials.
  • Map decentralized identity concepts onto real‑world systems (e.g., education, access control).
  • Reason about how DIDs and credentials can be layered on top of L1/L2 blockchains.

Introduction​

Traditional identity systems are usually centralized: governments, corporations, or platforms issue and control your digital identity. In decentralized systems, the goal is different: identity should be user‑controlled, portable, and verifiable without a central authority.

In the Flow Initiative, you will see decentralized identity as one way to:

  • Represent users across protocols,
  • Anchor trust to cryptographic proofs, and
  • Reduce reliance on opaque, centralized identity providers.

This lesson treats decentralized identity as a system design pattern, not just “Web3 identity.” You will learn the core primitives and how they can be composed with L1/L2 infrastructure.

What Is Decentralized Identity?​

Decentralized identity (often called DID or SSI — self‑sovereign identity) is a model where:

  • Users own and control their identifiers.
  • Credentials are issued once, stored by the user, and shared selectively.
  • Verification is cryptographic and can be done without contacting the issuer.

From an engineer’s view, this is a trust‑minimized identity layer that can sit on top of blockchains, distributed ledgers, or other public‑goods infrastructure.

Key Properties​

  • User‑controlled: no single entity fully owns or revokes your identity.
  • Portable: you can use the same identity across different services.
  • Privacy‑preserving: you can share only the attributes you choose.
  • Verifiable: anyone can cryptographically verify that a claim is real.

These are not just philosophical goals; they are design constraints that shape how you build identity systems.

Core Components​

1. Decentralized Identifiers (DIDs)​

A DID is a persistent, user‑controlled identifier for a person, organization, or device.

  • It looks like a string such as did:example:123....
  • It is created by the user (or via a wallet), not issued by a central registry.
  • The DID resolves to a DID Document that contains public keys and service endpoints used to interact with the identity [web:183][web:187].

Crucially, the DID document typically does not store private data; it stores cryptographic material and endpoints that let others authenticate the identity.

2. Identity Wallets​

An identity wallet is a software tool that:

  • Stores the user’s private keys.
  • Manages multiple DIDs and associated credentials.
  • Handles signing, encryption, and connection‑establishment for DID‑based protocols [web:182][web:189].

The wallet is the user‑facing layer of the identity system, similar to how a blockchain wallet manages private keys for on‑chain accounts.

3. Verifiable Credentials (VCs)​

A verifiable credential is a cryptographically signed statement about the user, such as:

  • “Issued by University X, this person completed Course Y.”
  • “Issued by Employer Z, this person is our employee.”

Key properties:

  • The issuer signs the credential with a private key.
  • The holder stores it in their wallet.
  • When needed, the holder can present a proof (often selective) to a verifier [web:183][web:189].

The verifier can check the signature against the issuer’s public key (often stored on a DID) to confirm authenticity.

4. Trust Ecosystem​

A trust ecosystem defines:

  • Who is an allowed issuer.
  • What credential types exist.
  • How revocation or updates work.

This can be governed by a decentralized trust framework (e.g., a consortium‑style governance body) rather than a single company or government.

How DIDs and Credentials Work Together​

A typical flow for decentralized identity looks like this:

  1. Setup

    • The user creates a DID and stores it in a wallet.
    • The DID document is published to a blockchain or distributed ledger for discovery.

  2. Issuance

    • An issuer (e.g., university, employer) creates a verifiable credential about the user.
    • The issuer signs the credential and sends it to the user’s wallet.

  3. Storage

    • The user keeps the credential in the wallet, possibly alongside others.
    • The user can choose which credentials to keep, delete, or rotate.

  4. Presentation

    • A verifier (e.g., job platform, protocol, service) requests a proof of a specific attribute.
    • The wallet constructs a cryptographic proof (e.g., a zero‑knowledge or selective‑disclosure proof) and sends it.

  5. Verification

    • The verifier checks:
      • The issuer’s signature.
      • The credential’s validity (e.g., not expired or revoked).
    • The verifier accepts or rejects the claim.

At no point is the user forced to share a full “profile.” Only the required attributes are revealed.

Why This Matters for Flow Engineers​

Flow Initiative trainees will work on systems that need:

  • Cross‑protocol identities — the same person or node appearing in multiple chains and tools.
  • Trust‑minimized verification — confirming claims without calling a central authority for every check.
  • Privacy‑respecting access control — allowing users to share only what is necessary.

Decentralized identity helps you:

  • Represent students, engineers, or nodes as reusable DIDs.
  • Issue certificates or achievements as verifiable credentials.
  • Design access control where the system checks proofs, not centralized databases.

In African‑centric contexts, this is especially relevant when:

  • Centralized identity systems are fragmented or weak.
  • Users want to control their data and move it across borders.
  • Education and employment records need global, tamper‑resistant verification.

How Blockchain Fits In​

Blockchain is not the only place to store decentralized identity data, but it is a natural fit for several pieces:

  • DID registries — DID documents or DID roots can be anchored to a chain.
  • Credential registries — hashes or revocation lists can be stored on‑chain.
  • Governance — on‑chain protocols or L1s can coordinate issuers, verifiers, and rules for trust frameworks [web:183][web:188].

L1s and L2s can then:

  • Accept proofs tied to DIDs,
  • Verify credentials stored off‑chain but referenced on‑chain.

From an engineering standpoint, the chain is often the issuance or verification anchor, not the place where all user data lives.

Practical Examples You Will Encounter​

Example 1: Education Credentials​

  • A university acts as an issuer.
  • It issues verifiable credentials for degrees, transcripts, or course completions.
  • Students store them in identity wallets.
  • Employers act as verifiers and can instantly confirm authenticity without calling the registrar’s office every time [web:191][web:188].

In Flow, this could become:

  • A credential system for completion of lessons or tracks.
  • A wallet‑style interface for trainees where they collect Flow‑issued credentials.

Example 2: Node or Contributor Identity​

  • A decentralized protocol wants to identify honest validators or contributors.
  • It issues DIDs and credentials to operators that pass certain tests.
  • Those credentials can be reused across different services or layers.

Engineers can then design stake‑based or reputation‑based systems where credentials are part of the security model.

Example 3: Cross‑Platform Access​

  • A user has a DID issued by a trusted identity‑provider network.
  • Multiple services accept that DID as valid.
  • The user never needs to create a new account on each service; they reuse their existing identity.

This is how you can reduce authentication friction while preserving control.

Practical Exercises​

Exercise 1: Sketch a Simple DID Flow​

On paper or in a text editor, sketch a simple flow with three roles:

  • Holder (user),
  • Issuer (e.g., a “Flow Education” issuer),
  • Verifier (e.g., a protocol or service).

For each step:

  • Write what data or message is exchanged.
  • Mark whether it is stored on‑chain, in the wallet, or elsewhere.

This is a mental model of how the three roles interact.

Exercise 2: Map a Real‑World System to DIDs​

Pick a real‑world identity‑heavy system you know (e.g., school ID, national ID, crypto wallet):

  • Identify who currently acts as the issuer and who as the holder.
  • Explain how DID‑style identity would change that:
    • Who would now control the identifier?
    • Where would the credential live?
    • How would verification work?

Write a short note with your answers.

Exercise 3: Relate to a Flow Lab​

Imagine a Flow lab or future project that uses:

  • User accounts,
  • Reputation, or
  • access control.

Design a small schema:

  • Which entities should have DIDs?
  • What kind of verifiable credentials should they hold?
  • How would a verifier in that system check the credentials?

Write it in a markdown note so you can expand it later.

Self‑Assessment​

Rate yourself from 1 to 5:

  • I can explain what a DID and a verifiable credential are.
  • I can see how DIDs differ from email‑style identifiers.
  • I can connect decentralized identity to real‑world use cases (e.g., education, access control).
  • I can imagine how DIDs and credentials might sit on top of an L1/L2 stack.

Action item: write a short note in your Flow lab repo describing one concrete place where DIDs and verifiable credentials could improve privacy or trust.

Next Steps​

  • Read the next lesson in the ecosystem section (or the next track) that builds on identity and trust.
  • Use this conceptual model whenever you encounter identity‑focused protocols or specs.
  • Treat decentralized identity as a layered engineering primitive that can be composed with L1/L2 systems, not as a separate “Web3 identity” silo.

Video​