The lifecycle of a verifiable credential consists in a sequence of steps, each with a specific architectural function, that together produce a credential a citizen can carry, present, and have verified anywhere, without the issuer needing to be reached.
Most descriptions of digital identity focus on one step at a time. Issuance. Storage. Verification. This edition walks through all of them, in order, so the full lifecycle is visible as one system.
In our website, we published a demo walkthrough as a structural sketch of the same flow. This edition is the analysis layer: what each step requires, why each matters, and how they connect.
The six-step lifecycle
Step 1 — The citizen requests a credential
The process begins when a citizen — or an entity acting on behalf of one — requests a credential from an issuing authority. A ministry, a civil registry, a licensing body, a public university. The request may arrive through a digital portal, a mobile app, or in person.
One architectural decision is already in place at this point, made upstream before any form is submitted: whether the system will produce a verifiable credential — a cryptographically portable, citizen-held data object — or a database record with a digital interface. The consequence of that decision surfaces across the remaining steps.
Step 2 — The authority verifies identity and eligibility
The issuing authority confirms that the requesting citizen is who they claim to be and that they meet the eligibility requirements for the credential.
The infrastructure for this step is mature — civil registries, biometric enrollment systems, prior records, cross-agency data exchange where authorized. The logic is sound: verify deeply once, so the citizen does not have to prove themselves from scratch for every subsequent use.
Step 2’s investment compounds across the lifecycle because the credential it produces is designed to travel independently. That is what the next steps make possible.
Step 3 — The authority cryptographically signs the credential
The credential is signed with the issuing authority’s private key. The signature binds the credential’s contents to the issuer’s cryptographic identity. Anyone holding the issuer’s corresponding public key can verify the credential later without needing to contact the issuer.
Step 4 — The credential is delivered to the citizen’s wallet
The signed credential is delivered to the citizen’s digital wallet — SovraWallet or any W3C-compatible wallet. The citizen holds it. They can carry it, present it, and manage it. The issuing authority does not retain a live copy tied to each subsequent use.
This step is what makes the credential citizen-held rather than issuer-held. The citizen carries the proof itself. From this moment forward, the credential is in the citizen’s possession as an instrument they control.
Step 5 — The citizen presents the credential to a verifier
When the citizen needs to prove something — to a bank, a government agency, an employer, a healthcare provider — they present the credential from their wallet. The delivery mechanism is typically a QR code, an NFC tap, or a deep link. The citizen controls what to share and when.
Because the credential itself is cryptographically self-contained, the verifier does not need a prior relationship with the issuer. They do not need to know the issuer in advance. They do not need an API integration with the issuer’s database. They need the credential and the issuer’s public key.
Step 6 — The verifier confirms cryptographically
The verifier receives the credential, retrieves the issuer’s public key from the public registry, and checks the cryptographic signature locally. The verification is a mathematical operation: the signature is valid, or it is not. No call to the issuer. No institutional integration required. No API handshake.
This is what the W3C standard was designed to enable. Together with step 3, step 6 completes the cryptographic arc that makes the credential genuinely portable: valid across institutions, across administrations, across time.
What the six steps produce together
A credential that has completed all six steps can be:
Carried anywhere — it lives with the citizen, not in an institutional database
Verified anywhere — by any verifier with access to the issuer’s public key, with no contact with the issuer required
Portable across administrations — no single organization needs to remain operational for the credential to remain valid
Selectively presentable — the citizen chooses what to share, and when
Cryptographically resilient — the signature cannot be forged, and revocation is a cryptographic operation
These properties are what make a verifiable credential qualitatively different from a digital document. They are what the W3C standard was designed to deliver. And they are what the six-step architecture produces when it is implemented end to end.
On this topic: previous editions
In March, we published a deep-dive on what happens after a verifiable credential is issued — the downstream lifecycle of presentation, selective disclosure, and revocation. This edition is the upstream companion: how the credential is produced in the first place. Together, the two pieces describe the full arc.
Continue the conversation
More technical resources on the verifiable credentials stack — including deployment case studies and the open specifications Sovra builds on — are available at sovra.io/knowledge.
If you are working on identity in government or enterprise and a specific step in this lifecycle raises a question for your context, reply. We read every response.
If this edition was useful, forwarding it to one colleague working on digital services is the most direct way to grow this community.
Subscribe to The Identity Brief — published every Thursday.
The Identity Brief is published weekly by Sovra — the Digital Identity Stack for the Institutional World.