Traditional PKI, the certificate authorities, trust stores, and X.509 infrastructure that this course has been built around, is a centralized trust model. Trust flows from a root CA, down through intermediate CAs, to end-entity certificates. The root CA is the anchor. If you trust the root, you trust everything it signs.
That model has served the internet extraordinarily well for thirty years. But it has known limitations: root CA compromise can undermine trust globally, the CA/Browser Forum governs which roots are trusted in ways that are not fully transparent or democratic, and the model does not extend naturally to peer-to-peer or machine-to-machine trust scenarios that don't fit the client-server architecture it was designed for.
A set of emerging technologies, decentralized identifiers, verifiable credentials, and decentralized PKI, propose a different approach. This lesson covers what those technologies are, where they stand, what the PQC migration requirement looks like for them, and what the honest picture is about their near-term adoption prospects.
The single most important insight of this lesson: Decentralized PKI systems face an identical PQC migration requirement as traditional PKI. Blockchain keys using secp256k1 or Ed25519 are broken by Shor's algorithm just as surely as RSA and ECDSA are. The decentralization of the trust model does not change the underlying cryptographic vulnerability. PQC migration is not optional for decentralized identity, it is just less organized.
Click each concept to see what it is, who controls it, and where it stands in 2025.
A Decentralized Identifier (DID) is a new type of identifier defined in the W3C DID Core 1.0 specification (published as a W3C Recommendation in July 2022). Unlike a traditional identifier such as a domain name (which requires ICANN and a registrar) or an email address (which requires a mail provider), a DID can be created and controlled by its subject without any central authority.
A DID looks like this: did:example:123456789abcdefghi
The structure is: did:[method]:[method-specific-identifier]. The "method" specifies how the DID is created, resolved, and managed. Different DID methods use different underlying technologies, some use blockchains, some use distributed ledgers, some use peer-to-peer protocols, and some (like did:web) use conventional web infrastructure.
Each DID resolves to a DID Document — a JSON-LD document that contains the public keys, authentication methods, and service endpoints associated with the identifier. The DID Document is what enables cryptographic verification of claims made by the DID subject.
PQC implication: DID Documents contain public keys. If those keys use secp256k1 or Ed25519, as most current DID implementations do, they are vulnerable to Shor's algorithm. Migrating DID Documents to ML-DSA or other PQC-compatible keys requires updating the DID Document, which in turn requires the DID controller to sign the update with a current valid key. This is manageable in theory but complex at scale across millions of active DIDs.
A Verifiable Credential (VC) is a W3C-standardized data model for expressing credentials in a way that is cryptographically verifiable, privacy-respecting, and machine-readable. Think of it as a digital version of a physical credential, a driver's license, a university degree, a professional certification, that can be verified without contacting the issuer.
The VC ecosystem has three roles: the Issuer (who creates and signs the credential, e.g., a university), the Holder (who stores and presents it, e.g., a graduate), and the Verifier (who checks it, e.g., an employer). The cryptographic proof in a VC is typically a digital signature over the credential data.
VCs are a compelling model for several use cases: government-issued identity credentials, professional certifications, supply chain attestations, and health records. Several national digital identity programs (EU Digital Identity Wallet, various US state mDL programs) are building on or toward VC-compatible architectures.
PQC implication: VC proofs are digital signatures. If the issuer's signing key uses ECDSA or Ed25519, the VC's cryptographic proof is vulnerable to Shor's algorithm. The VC Data Model does not specify which signature algorithm to use, that is left to implementations. Moving to ML-DSA for VC issuance is technically straightforward but requires ecosystem-wide coordination across issuers, holders, and verifiers.
The Trust over IP Foundation is a Linux Foundation project that develops governance frameworks and technical standards for decentralized digital trust. Where W3C defines the data models (DIDs, VCs), ToIP addresses the governance layer, the policies, legal frameworks, and trust registries that make decentralized credentials usable in real-world institutional contexts.
ToIP's key contribution is the Trust over IP stack — a four-layer architecture separating the technical infrastructure (Layer 1), peer-to-peer protocol (Layer 2), data exchange (Layer 3), and application ecosystem (Layer 4). This layering is useful because it allows different governance decisions to be made at different layers without redesigning the whole stack.
ToIP is where the bridge between decentralized identity and traditional PKI governance is being built. Several ToIP working groups are actively engaged on PQC migration planning for decentralized identity infrastructure, which means practitioners from this course have a potential contribution point here.
did:x509 is an IETF draft DID method that derives a DID from an existing X.509 certificate chain. This is significant because it creates a bridge between traditional PKI (which organizations have invested heavily in) and decentralized identity infrastructure (which is emerging but not yet broadly deployed).
In did:x509, the DID is constructed from the fingerprint of an X.509 certificate, and the DID Document is derived from the certificate's public key and subject information. This means an organization with an existing CA-signed certificate can participate in DID-based ecosystems without rebuilding its identity infrastructure from scratch.
For PQC migration: if the underlying X.509 certificate uses ML-DSA (which is exactly what traditional PKI migration produces), the derived did:x509 DID automatically inherits the PQC-safe key. This makes did:x509 one of the most pragmatic near-term bridges, organizations that complete their traditional PKI PQC migration get decentralized identity compatibility as a byproduct.
Status: did:x509 is an active IETF draft as of 2025. It is being implemented by Microsoft (Azure attestation), PKIC members, and several government digital identity programs. It is not yet a ratified standard, but it has sufficient momentum and implementation activity to be taken seriously as a near-term bridge technology.
Most blockchain-based identity systems, including the DID methods built on Ethereum, Bitcoin, Hyperledger, and similar platforms, rely on elliptic curve cryptography for key management and signature operations. The two most common curves are:
Traditional PKI has a clear governance structure: CAs issue certificates, browsers and operating systems control trust stores, NIST and the CA/Browser Forum set requirements. When NIST publishes a migration mandate, the CA ecosystem responds, not instantly, but through defined channels with clear accountability.
Decentralized identity has no equivalent governance structure for migration mandates. A DID method built on a public blockchain cannot be updated by any single authority. Each DID controller must independently update their DID Document with a new PQC-compatible key. Millions of DIDs, each requiring individual owner action, with no central coordinator to enforce or incentivize compliance.
The practical consequence: Decentralized identity systems will have a longer and messier PQC migration than traditional PKI, not because the technical path is harder, but because the governance path is harder. This is one of the most honest critiques of decentralized trust models: decentralization that works well for censorship resistance works against coordinated cryptographic transitions.
It is worth being honest about the political landscape around DIDs. When the W3C DID Core 1.0 specification was published as a Recommendation in 2022, it was notably opposed by several major browser vendors, including the teams representing Mozilla and Opera. Their published objections covered several concerns:
These are legitimate concerns, not just incumbent-vendor protectionism. The DID ecosystem has worked to address some of them, notably through increased focus on did:web and did:key (which don't require blockchains) and through the ToIP governance work that addresses the decentralization theater problem. But the browser vendor objections signal that DID adoption in the web browser trust model is not assured.
Despite the browser objections, decentralized identity is seeing genuine deployment in specific verticals. Click each to see the status.
Having covered the concepts, the standards, the objections, and the deployments, here is the honest picture of where decentralized trust infrastructure is heading, and what it means for practitioners.
Traditional PKI is not going away. The CA/Browser Forum trust model will continue to govern TLS for the foreseeable future. The PQC migration you've worked through in this course is the right near-term investment regardless of what decentralized identity does.
Decentralized identity will grow, but primarily in specific verticals (government digital identity, healthcare, supply chain, enterprise HR) and through hybrid architectures that bridge traditional PKI with emerging DID infrastructure. did:web and did:x509 are the most pragmatic near-term bridges: they work with existing PKI, don't require blockchain infrastructure, and have real implementation momentum.
The blockchain-based DID methods will remain important in specific communities (Web3, cryptocurrency-adjacent identity, specific national digital identity programs) but will not displace CA-based PKI as the dominant trust model for the broader internet within this decade.
The practical takeaway: Complete your traditional PKI PQC migration first. That work is urgent, well-defined, and directly serves your organization. If you are also working in or adjacent to decentralized identity, as a developer, a policy person, or an entrepreneur, bring your PQC knowledge to those conversations. The decentralized identity ecosystem needs practitioners who understand that secp256k1 and Ed25519 require the same migration urgency as RSA and ECDSA. That awareness is not yet universal in Web3 communities.
This is the lesson that was added for you. If you're interested in Web3, decentralized identity, or the entrepreneurial space at the intersection of cryptography and digital trust, you now have the vocabulary and the framing to engage with those communities from a position of genuine knowledge.
The most useful contribution you can make in Web3 identity communities right now is the one this lesson has prepared you for: explaining clearly that secp256k1 and Ed25519 face the same Shor's algorithm vulnerability as RSA and ECDSA, and that the decentralized identity ecosystem needs PQC migration planning just as urgently as traditional PKI. That message is not widely understood in Web3 circles, and practitioners who can make it credibly are genuinely needed.
For most SMBs, decentralized identity is a watch-and-wait topic. The EU Digital Identity Wallet mandates may eventually affect how your European customers authenticate to your services. SMART Health Cards may become relevant if you operate in or adjacent to healthcare. Supply chain VCs may appear in your procurement requirements if you supply regulated goods into EU markets.
The practical near-term action is awareness: when a vendor or partner mentions "verifiable credentials" or "decentralized identity," you now know what questions to ask. Specifically: what DID method are they using, what cryptographic keys underpin it, and what is their PQC migration plan? Those three questions will reveal whether they've thought seriously about long-term security.
If your organization is evaluating or deploying any VC or DID-based system, for employee credentials, supply chain, healthcare data, or digital identity, add PQC readiness to your evaluation criteria now. Ask vendors: what signature algorithm does your VC proof use, and what is your migration path to ML-DSA? What DID method do you support, and does it allow key rotation to PQC keys?
The did:x509 bridge is worth tracking specifically. If your organization completes its traditional PKI migration to ML-DSA certificates, you may get decentralized identity compatibility as a near-free byproduct through did:x509. That is an efficiency worth capturing in your migration planning, document the did:x509 compatibility as an output of your CA migration work, and it becomes part of the value story you present to leadership for the migration investment.
One deliverable remains: the Personal PQC Readiness Roadmap. It brings together everything from Units 0–5 into your 2-year forward plan. Build it well, it is the document that turns this course into a commitment.