Every digital identity system needs a way to say “this is you.” Email addresses do it for the internet. Phone numbers do it for telecommunications. Government ID numbers do it for public services.
All of these identifiers share one thing in common: someone else controls them. Google controls your email. A telecom controls your phone number. A government agency controls your national ID number. If any of those organizations changes its mind, your identifier can be revoked, reassigned, or shut down.
Decentralized Identifiers, or DIDs, work differently. A DID is controlled by whoever holds the cryptographic key associated with it. In practice, that means you.
This edition explains what a DID actually is at the technical level, how it enables portable digital identity, and why it matters for the 8 million citizens already using verifiable credential infrastructure across Latin America.
If you’re new to verifiable credentials, our previous edition What Happens After a Verifiable Credential Is Issued? covers the credential lifecycle. This edition goes one layer deeper: the identifier that makes credentials portable.
A DID in three parts
A DID is a URI (Uniform Resource Identifier) that follows a specific structure defined by the W3C (World Wide Web Consortium). It looks something like this:
did:web:sovra.io:user:abc123
Every DID has three components.
The scheme is always “did.” This tells any system reading it that what follows is a Decentralized Identifier.
The method describes how the DID can be looked up. Different DID methods use different infrastructure for resolution. did:web uses standard web servers. did:key is self-contained, with the public key embedded directly in the identifier. did:ethr uses the Ethereum blockchain as a registry. The method determines the trust assumptions: who do you rely on to look up this identifier?
The method-specific identifier is unique to the DID subject. Combined with the method, it provides a globally unique identifier that can be resolved to learn more about the subject.
The W3C DID Core specification, now at version 1.1, standardizes this format so that any system implementing the spec can resolve any DID, regardless of method. You can explore how these concepts connect in Sovra’s Knowledge Base.
What happens when you look up a DID
When a system resolves a DID, it retrieves a DID Document. This is a structured data object, typically in JSON or JSON-LD format, that contains everything needed to interact with the DID subject securely.
A DID Document includes:
Public keys (listed under verificationMethod). These are the cryptographic public keys associated with the DID. When someone signs a document with their DID’s private key, any verifier can use the public key in the DID Document to confirm the signature is authentic.
Service endpoints. These are URLs or addresses where you can interact with the DID subject. For a citizen, this might be the endpoint for their digital wallet. For an institution, it might be the URL of their credential issuance service.
Authentication and assertion methods. These define how the DID subject proves they control the DID (authentication) and how they make verifiable claims (assertion). Both reference the public keys listed in the document.
The DID Document is essentially a machine-readable identity card. It says: here are the keys I control, here is how to verify my signatures, and here is how to reach me. Any system that resolves the DID can use this information to verify credentials, authenticate requests, or establish secure communication.
Why portability matters
Traditional identifiers are tied to the institution that issued them. If you move countries, your national ID number stays behind. If you switch email providers, you lose your address. Each identifier lives in the silo of the organization that controls it.
A DID travels with the person. Because the identifier is controlled by the holder’s cryptographic key, and the DID Document can be resolved by anyone, the same identifier works across any system that implements the standard.
Here is what that looks like in practice. A government in Argentina issues a verifiable credential, a digitally signed statement about a citizen, linked to the citizen’s DID. That credential lives in the citizen’s wallet on their phone.
When the citizen presents that credential to a bank in Mexico, the bank resolves the citizen’s DID, retrieves the DID Document, finds the relevant public key, and verifies the credential’s signature. The entire process takes less than a second, requires no communication with the Argentine government, and needs no bilateral agreement between the two institutions.
The DID is the universal anchor that makes this possible. The credential format (W3C Verifiable Credentials) provides the data structure. The DID provides the identifier that connects everything.
If you want to understand what happens after a credential is issued and how the verification flow works in detail, our previous edition What Happens After a Verifiable Credential Is Issued? walks through the full lifecycle.
DIDs in production
This is already running at national scale. At Sovra, 8 million citizens across Argentina, Mexico, and Colombia use DIDs as the foundation of their verifiable credentials. Over 50 million verifications and 100 million API calls have been processed through this infrastructure, each one resolving a DID and checking a cryptographic signature in under a second. You can see the deployments in detail in our case studies.
One link worth reading
In an AI Rush, Sell Trust — Chuy Cepeda, Sovra’s Chief of Strategy, on why the companies that will win the AI era are the ones selling verifiable trust infrastructure, and what that means for governments and institutions evaluating their next move.
The Identity Brief is Sovra’s weekly newsletter on digital identity, verifiable credentials, and trust infrastructure. Subscribe to receive it every Thursday.