Spherity Research Paper

Securing Digital Identity and Verifiable Credential Wallets against Quantum Vulnerabilities

Attack taxonomy, macro-economic risk, and post-quantum migration corridors

Author

Dr. Carsten Stöcker

Affiliation

Spherity GmbH

Published

2026-05-14

Updated

2026-05-16

This version

https://spherity.github.io/spherity-research/Securing-Digital-Identity-Quantum-Vulnerabilities.html

Latest version

https://spherity.github.io/spherity-research/Securing-Digital-Identity-Quantum-Vulnerabilities.html

1. Introduction

The paper Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations by Babbush et al. estimates that breaking 256-bit ECDLP over secp256k1 can be done with fewer than 1,200 logical qubits and fewer than 90 million Toffoli gates, or with fewer than 1,450 logical qubits and fewer than 70 million Toffoli gates. Under their superconducting architecture assumptions, the runtime can fall to minutes with fewer than half a million physical qubits [1]. The paper also distinguishes fast-clock and slow-clock quantum architectures and uses this distinction to analyze on-spend, at-rest, and on-setup attacks [1].

This is an important result for cryptocurrencies. It is also a signal for digital identity. The common substrate is not Bitcoin. The common substrate is public-key trust. If a public key can be transformed into a private key within an operational time window, then any system that exposes public keys and relies on their secrecy after exposure must be re-analyzed. Identity systems expose such keys in many places: issuer verification methods, wallet holder-binding keys, verifier request keys, trust-list anchors, status-list signing keys, DID documents, X.509 chains, DNSSEC zone keys, WebPKI certificates, and protocol metadata.

The current public debate is too narrow when it frames the problem as whether quantum computers will break Bitcoin. A better research question is: which digital trust fabrics become unsafe when public keys are no longer safe long-term identifiers? Digital identity is one of the largest such fabrics. It is being embedded into public services, enterprise onboarding, mobile wallets, regulated supply chains, digital product passports, healthcare, payments, workforce IAM, critical infrastructure, and AI governance.

The paper therefore reviews quantum risk for digital identity wallets and VC/VP ecosystems. It uses the SSI triangle as the starting model, but extends it to a trust control plane and a semantic supply chain. This is necessary because a verifier does not only check a digital signature. It checks whether the issuer is trusted, whether the credential is current, whether the wallet is acceptable, whether the verifier is authorized, whether the VDR data is correct, and whether the meaning of the claims is stable.

The main recommendation is to start work on PQC identity corridors. A corridor is a bounded identity flow, such as legal-person onboarding or digital product passport signing, in which all public-key dependencies are inventoried and moved to hybrid or post-quantum operation together. This is more realistic than a big-bang migration, and more useful than upgrading transport security alone.

2. Quantum risk as a public-key exposure problem

The Babbush et al. analysis is framed around cryptocurrency signatures. Its deeper lesson is that systems can no longer treat exposed ECC public keys as harmless long-term data. In classical security models, a public key can be public for decades. In a post-quantum threat model, the same public key may become a route to the private key. The practical risk depends on three factors: the algorithm, the public-key exposure surface, and the time window in which the attacker can use the recovered private key.

Public-key exposure means that a public key, verification method, certificate, DID document, trust-list entry, resolver record, registry entry, signed schema, or cryptographic parameter becomes available to an attacker long enough to support quantum-assisted private-key recovery, forgery, impersonation, or registry manipulation.

This creates Public-Key Trust Fabric Risk: the systemic risk that identity, authorization, registry, semantic, and audit systems lose integrity because their public verification material becomes usable for quantum-assisted private-key recovery or forgery.

NIST finalized ML-KEM, ML-DSA, and SLH-DSA in 2024 as the first three post-quantum standards. NIST also states that organizations should begin migration and that many quantum-vulnerable algorithms are expected to be deprecated or disallowed by 2035, with high-risk use cases moving earlier [3,4,5]. Google has publicly set a 2029 timeline for PQC migration and has called out authentication services and digital signatures as priority areas [2].

Transport-layer PQC is necessary but not sufficient. Hybrid ML-KEM in TLS helps protect network sessions against harvest-now-decrypt-later attacks. It does not protect a VC signature, a VP holder-binding proof, a trust list, a status list, a DID document, or a signed schema once the object is copied, archived, logged, audited, or presented offline. Identity systems need object-level PQC and registry-level PQC, not only channel-level PQC.

3. Digital identity system model

The W3C Verifiable Credentials Data Model defines a model in which issuers create credentials, holders store and present them, and verifiers check them. Verifiable presentations can include credentials and proofs, and verifiable data registries can mediate identifiers, verification material, schemas, and revocation registries [6]. OpenID4VCI defines issuance flows and holder binding. OpenID4VP defines presentation flows using a VP token and can run through HTTPS redirects or the W3C Digital Credentials API [9,10,11].

The SSI triangle is useful, but not enough for a post-quantum threat model. The triangle must be embedded in a trust control plane. The control plane includes trust lists, trust registries, trust anchors, wallet provider certification, issuer accreditation, verifier registration, access certificates, status lists, VDR resolution, DID methods, DNSSEC, WebPKI, schema registries, context registries, policy engines, and transparency logs. In EUDI Wallet architectures, for example, trusted lists contain trust anchors, and those trust anchors are used by wallets, issuers, and relying parties to verify providers, access certificates, and other ecosystem actors [13].

A second layer is the semantic supply chain. A credential does not carry value only because it is signed. It carries value because the verifier interprets its type, schema, context, issuer authority, status, and policy meaning. In product passports and supply-chain credentials, this semantic layer links product identifiers, due diligence statements, material data, lifecycle events, customs data, and business roles. Quantum migration must therefore protect not only signatures, but also the signed and versioned meaning of the data.

4. Attack taxonomy for VCs, VPs, wallets, and trust infrastructure

A quantum attacker does not need to attack every part of an identity ecosystem. It is enough to compromise the weakest public-key dependency on the verification path. In identity systems, this path can be longer than in a blockchain transaction. A verifier may depend on the credential proof, the holder-binding proof, the issuer DID or certificate, a trust list, a status list, a DNS name, a schema, a policy registry, and a timestamping or audit service.

5. Identity-specific quantum attack scenarios

5.1 Issuer key compromise

Issuer key compromise is the most direct high-impact case. If a public issuer key is exposed in a DID document, certificate, trust list, or metadata service, a CRQC may derive the matching private key. The attacker could then issue forged credentials. For a government PID issuer, the damage is identity fraud. For a legal-person issuer, the damage can include false corporate authority, fraudulent onboarding, and supply-chain access. For a DPP issuer, the damage can include false product data and fake compliance records.

DID Core recognizes that DID documents express verification methods such as public keys, and that these methods are used for authentication, assertion, and other verification relationships [8]. This makes DID documents useful, but also makes them long-lived public-key exposure points. Post-quantum identity design must therefore treat issuer keys as high-value public assets, not only as key material in a wallet.

5.2 On-presentation attacks

An on-presentation attack is the identity analogue of an on-spend attack. A holder presents a credential to a verifier. The VP includes a proof, a nonce, an audience, a holder-binding key, or a reference to verification material. A fast attacker who sees the relevant public key might derive the private key during the presentation window or shortly after a first presentation. The attacker could then create a valid-looking VP for the same session or for another verifier.

The analogy to Bitcoin is not exact. Most VP flows are not broadcast to a public mempool. They are usually mediated by HTTPS, mobile wallets, browsers, or enterprise APIs. This reduces broad public exposure. It does not remove the risk. Malicious verifiers, compromised relying parties, browser logs, gateway logs, mobile telemetry, support dumps, and archived presentations can expose public keys and proof material. High-value relying parties may also be targeted directly. The right mitigation is not to assume that presentation material is private; it is to use nonce-bound, audience-bound, short-lived, and eventually PQC or hybrid holder proofs.

5.3 On-issuance attacks

OpenID4VCI supports credential issuance flows in which the issuer binds a credential to holder key material. The holder later proves control of the same key during presentation [9]. This mechanism is central to wallet security. It is also a quantum exposure point. If a wallet proof-of-possession key or attestation key is quantum-vulnerable and visible during issuance, an attacker may be able to bind the credential to a key that the attacker can use or derive.

The most sensitive on-issuance targets are high-assurance credentials: national PID, legal-person identity, professional roles, regulated supply-chain roles, pharma trading partner credentials, financial KYC credentials, customs credentials, product-passport issuer rights, and AI-agent delegation credentials. In these cases, a false issuance event can have a longer lifetime than a fraudulent login. It can become a signed input to downstream trust decisions.

5.4 Trust-list and access-certificate attacks

Trust lists are systemic trust objects. The EUDI Wallet Architecture and Reference Framework defines trusted lists that contain trust anchors. It also describes access certificate authorities, wallet provider trust anchors, and trust lists used by wallets and relying parties [13]. A quantum break of a trust-list signing key or access CA key could enable a rogue issuer, verifier, wallet provider, or service endpoint to appear legitimate. This attack can scale across an ecosystem because many verifiers may rely on the same list.

Trust-list migration should therefore be prioritized earlier than ordinary low-value credential migration. The trust-list layer should be hybrid or PQC-signed, monitored, timestamped, and designed for emergency key rollover. Threshold signing and key ceremonies are also relevant, but they do not remove the need for quantum-safe primitives.

5.5 VDR, DNSSEC, WebPKI, and registry attacks

VC ecosystems often rely on VDRs to resolve identifiers and verification material [6]. A VDR can be a blockchain, a database, a trusted registry, a decentralized file system, or another authoritative data source. DNSSEC can also act as identity infrastructure when domains are used to discover issuer metadata, verifier metadata, service endpoints, or DID records. DNSSEC authenticates DNS data through digital signatures over DNS resource record sets [27]. If DNSSEC or WebPKI remains quantum-vulnerable while credentials are upgraded, the verification path remains vulnerable.

There is active IETF discussion on PQC DNSSEC strategy, including the operational effect of larger PQC signatures and the need for conservative as well as lower-impact algorithm options [28]. Identity architectures that use DNS as a VDR or discovery layer should track this work closely. A credential is not quantum-safe if the resolver path that supplies its issuer keys is not safe.

5.6 Status, revocation, and long-term validity

Status is a core identity control. The W3C Bitstring Status List specification provides a compact mechanism for expressing credential status, including suspension and revocation [14]. Yet a status list is still a signed object. If the status signing key is compromised, an attacker can make revoked credentials appear valid or can deny service by marking valid credentials as revoked.

Long-term validity is harder. A credential might be valid at the time of presentation but later unverifiable because the algorithm is broken. Identity ecosystems need rules for timestamping, archival validation, transparency logs, reissuance, and evidence preservation. This is especially important for legal-person credentials, compliance certificates, product passports, audit logs, and AI-agent actions that may be reviewed years later.

5.7 Semantic supply-chain attacks

The semantic layer is a security dependency. A signed credential may remain cryptographically valid while the meaning of a claim changes because a schema, JSON-LD context, namespace, product identifier, vocabulary, or policy authority is replaced, downgraded, or reinterpreted.

A DPP credential may contain a signed claim about recycled content, carbon footprint, due-diligence status, repair instructions, or material composition. If the vocabulary, schema version, or policy authority behind that claim is replaced or downgraded, the surface form of the credential may remain unchanged while the business meaning changes. In this case the verifier sees a valid signature, but the claim no longer has the same governed meaning.

Mitigations include signed and pinned JSON-LD contexts, immutable schema versions, governed vocabulary IRIs, transparent change logs, registry signatures, policy versioning, and explicit rules for deprecation. In a post-quantum setting, these registries and semantic authority records also need hybrid or PQC protection.

5.8 On-setup attacks against privacy-preserving credentials

Privacy-preserving identity systems often use selective disclosure, anonymous credentials, accumulators, pairings, or zero-knowledge proofs. BBS-based VC cryptosuites, for example, are designed to support selective disclosure and unlinkability [15]. Other systems may use RSA-based CL signatures, pairing-based signatures, or SNARKs. These techniques are important for privacy, but many of their current constructions depend on quantum-vulnerable hardness assumptions or setup assumptions.

A PQC migration that only replaces ECDSA issuer signatures is incomplete. The identity community also needs PQC-ready privacy-preserving credentials. This is an open research area. It requires attention to proof size, mobile verification, offline use, unlinkability, issuer privacy, revocation privacy, QR-code limits, and formal security models.

5.9 Agentic AI and Trusted AI

Trusted AI requires traceability, accountability, and controlled authority. OECD AI principles call for traceability across datasets, processes, and decisions, and the EU AI Act imposes requirements such as logging, documentation, robustness, cybersecurity, and human oversight for high-risk AI systems [24,26]. NIST has also framed Trustworthy AI for critical infrastructure as a risk-management problem [25].

AI agents will increasingly sign API calls, procurement events, data-access requests, software actions, payments, and operational commands. Their authority will often be delegated through credentials from legal persons. A quantum break of legal-person identity or agent delegation credentials could create false authority at machine speed. PQC identity corridors for AI should therefore combine short-lived delegation, policy-limited VCs, revocation, device or workload attestation, and PQC/hybrid signatures.

6. Macro-economic exposure: why legal-person identity is larger than Bitcoin

The claim that digital identity is more important than Bitcoin should be made with care. It is not a claim that any single identity credential has more market value than Bitcoin. It is a claim about dependency scope, substitution cost, and contagion channels. Bitcoin is a large but sector-specific asset system. Legal-person identity is a horizontal control layer for the real economy. It is used to establish who a company is, what it is allowed to do, which person or machine may act for it, and which data or product event can be trusted.

The scale difference is visible in macro-economic data. Bitcoin market capitalization was around USD 1.6 trillion on 9 May 2026, with daily volatility [21]. By contrast, world trade in goods and services reached about USD 34.65 trillion in 2025 according to the WTO [17]. UNCTAD reported global trade at a record USD 33 trillion in 2024 [18]. The World Bank reports global GDP in current US dollars above USD 110 trillion for 2024, and has noted that global value chains account for almost half of global trade [19,20].

Legal-person identity sits under many of these flows. It supports enterprise onboarding, beneficial ownership checks, KYC/AML, sanctions screening, procurement, customs, supply-chain due diligence, supplier qualification, electronic seals, product-passport data, industrial IoT authorization, critical infrastructure access, and accountable AI delegation. A broad loss of trust in this layer would not only cause theft. It could raise transaction costs, delay trade, increase manual verification, break automated compliance, create false provenance, disrupt just-in-time operations, and weaken AI accountability.

Digital product passports make the same point in a concrete way. The EU Ecodesign for Sustainable Products Regulation creates the basis for digital product passports, with work on identifiers, data carriers, access rights, registries, and portals [22]. Product passports are intended to support transparency across value chains, including product origin, materials, lifecycle information, and compliance evidence [22,23]. Such data is not useful if the issuer, product identifier, legal entity, supply-chain event, or status record cannot be trusted.

The macro-economic argument therefore has a simple form: cryptocurrency signatures protect asset ownership in a specific network; legal-person identity protects authority and accountability across many networks. The latter is a larger dependency surface. It should receive at least the same public attention in post-quantum migration planning.

7. Standards and readiness gaps

There is no single identity standard that can solve the PQC migration. The identity stack is multi-layered. W3C VC Data Integrity secures credentials and constrained digital documents through signatures and related proofs [7]. W3C VC JOSE/COSE secures credentials and presentations with JOSE, SD-JWT, and COSE [12]. DID Core defines identifiers and verification methods [8]. OpenID4VCI and OpenID4VP define issuance and presentation flows [9,10]. The Digital Credentials API adds browser and user-agent mediation [11]. EUDI Wallet architectures add trusted lists, access certificates, and regulated ecosystem roles [13]. Each layer must be assessed.

Google has made relevant platform moves. Chrome moved toward standardized ML-KEM for hybrid key exchange in BoringSSL and Chrome [30]. Android 17 adds ML-DSA support in Android Keystore and related PQC work for hardware-backed identity and authentication paths [29]. Google Cloud KMS has introduced quantum-safe signatures, including ML-DSA and SLH-DSA capabilities [31]. These are important foundations. They do not by themselves define end-to-end PQC identity profiles for VCs, VPs, trust lists, status lists, DID methods, or semantic registries.

A narrow algorithm substitution model will fail. Identity migration must account for key lifecycle, credential lifetime, presentation frequency, user experience, offline use, QR size, mobile hardware, trust-list governance, compliance rules, and audit requirements. It must also handle legacy credentials and dormant identity records that cannot be reissued quickly.

8. Post-quantum identity corridors

A post-quantum identity corridor is a governed, end-to-end identity exchange path in which all public-key dependencies are inventoried and moved to hybrid or post-quantum readiness together. A corridor is not only a credential format. It is a full path: issuer signature, wallet key storage, holder binding, verifier authentication, issuance channel, presentation channel, trust-list signing, status-list signing, VDR resolution, DID or certificate chain, DNSSEC/WebPKI dependency, schema/context integrity, policy validation, timestamping, audit, and reissuance.

Corridors are useful because identity ecosystems are too fragmented for a single migration event. They allow high-risk flows to move first, while preserving interoperability. They also create test beds for standards work and give platform teams clear requirements. A legal-person onboarding corridor, for example, can test issuer signatures, holder binding, trust-list verification, status checks, and verifier authorization without waiting for every consumer identity use case to migrate.

Candidate corridors should be chosen by risk and leverage. Initial corridors should include legal-person identity, regulated supply-chain credentials, pharma trading partner credentials, digital product passport credentials, critical infrastructure operator credentials, EUDI PID/QEAA flows, financial KYC/AML credentials, and AI-agent delegation credentials. These flows have high assurance needs, long credential lifetimes, and strong macro-economic relevance.

A practical corridor should define at least four artefact classes: a threat model, a cryptographic profile, test vectors, and operational runbooks. The runbooks should include key rollover, emergency revocation, reissuance, downgrade prevention, audit evidence, and fallback rules for offline verification.

8.1 Minimum viable design: PQC legal-person onboarding and data sharing corridor

A concrete legal-person onboarding corridor could be implemented as follows:

1. A business register or authorized legal-person identity issuer issues a legal-person credential using a hybrid or PQC-ready issuer signature.
2. The enterprise wallet stores the credential and uses hybrid or PQC-ready holder binding.
3. The verifier authenticates with a PQC-ready access certificate or verifier credential.
4. The relevant trust list is hybrid or PQC-signed and supports emergency rollover.
5. The relevant status list is hybrid or PQC-signed and supports suspension, revocation, and long-term evidence.
6. DID, VDR, DNSSEC, or certificate-chain dependencies have an explicit migration path.
7. The presentation is nonce-bound, audience-bound, short-lived, and protected against downgrade.
8. Audit evidence is timestamped and can be revalidated or reissued after algorithm deprecation.
9. Schema, context, and vocabulary versions are signed, pinned, and monitored.
10. Emergency procedures define key rollover, verifier fallback, mass reissuance, and public incident communication.
11. E2E data sharing protocol

This corridor is narrow enough to test, but broad enough to expose the main end-to-end dependencies that matter for enterprise identity, EBW, regulated supply chains, and Trusted AI.

8.2 Example: A Transatlantic Legal-Person Onboarding and Data Sharing Corridor

A concrete implementation could start with a transatlantic legal-person identity and data sharing corridor between European and U.S. company identity sources.

On the European side, the corridor could use the European Unique Identifier (EUID) and national business-register data as the authoritative basis for a legal-person credential. The EUID is used in the Business Registers Interconnection System (BRIS), through which EU Member State business registers have been interconnected and searchable since June 2017. For Germany, the Bundesanzeiger Verlag operates the Unternehmensregister, the German Company Register, and is the German member of the European Business Register network. The Unternehmensregister is the central platform for company data in Germany. The Bundesanzeiger Verlag platform also links to the Company Register, Transparency Register, Federal Law Gazette, eBilanz-Online, Legal Entity Identifier Register, and European Business Register.

For the U.S. side, the corridor should not rely on a single federal company-register identifier. The U.S. does not have one national company register comparable to BRIS or the German Unternehmensregister. Legal entities are generally formed and registered at state level, for example through Secretary of State business registries. A U.S. legal-person credential should therefore bind the company’s legal name, jurisdiction of formation, state registry identifier or file number, registered status, registered agent information where available, and source evidence from the relevant state registry. The Employer Identification Number (EIN) may be added as a corroborating tax identifier issued by the IRS, but it should not be treated as proof of legal existence or good standing. If a private or sectoral aggregation service is used, it should preserve the original state source, timestamp, evidence chain, and update status rather than replacing them with an opaque aggregated identifier.

A U.S. register-derived company identifier could be constructed in a way that is functionally similar to the EUID pattern, while remaining clearly distinct from an official national U.S. company identifier. The EUID combines the country code, register identifier, national registration number, and, where applicable, a verification digit. In the U.S., a comparable credential-internal composite identifier could combine: country = US, state or jurisdiction code, state registry authority, state entity ID or file number, and optional checksum, version, or source reference. This creates a stable, machine-readable anchor for verification while preserving the original state registry as the authoritative source.

In such a corridor, a German GmbH receives a verifiable legal-person credential containing its EUID and national register evidence from the Unternehmensregister. This credential could be represented as an EU Company Certificate (EUCC) credential or as an European Business Wallet Owner ID (EBWOID) credential. Here, EUCC refers to a verifiable company credential that contains selected register-derived claims about a legal person, such as legal name, legal form, register number, registered address, status, and representatives. EBWOID refers to a wallet-owner identifier credential for the legal person that binds the enterprise wallet to the organization it represents. The EUCC describes the legal person. The EBWOID binds the wallet instance or wallet owner to that legal person. Together, they support machine-verifiable company authentication, wallet binding, and authorization.

A U.S. corporation or LLC could receive a comparable verifiable credential containing its state of formation, Secretary of State file number or entity ID, legal name, registered status, registered agent information where legally available, and source reference to the relevant state registry. The credential could also include the constructed U.S. state-registry-derived company identifier as a machine-readable anchor. These credentials would not replace the underlying registers. They would make selected register facts machine-verifiable for authentication, onboarding, KYC/KYB, procurement, data-space participation, customs submission, supply chain data charing, and AI-agent delegation.

For PQC-ready Business Wallet use cases, the European credential can be anchored in the EUID and national business-register evidence. For U.S. use cases, the credential can be anchored in the relevant state registry identifier and strengthened through additional corroboration, for example EIN, LEI reference data, beneficial-ownership information where legally accessible, sectoral licenses, tax-status evidence, or regulated-industry registrations. A verifier would then authenticate the company by checking the credential signature, issuer trust status, register evidence, current status or revocation information, and policy rules for the specific transaction.

The same corridor would also test the post-quantum dependencies end to end. The legal-person issuer would use hybrid or PQC-ready issuer signatures. The enterprise wallet would use hybrid or PQC-ready holder binding. Verifiers would authenticate with PQC-ready verifier credentials or access certificates. Trust lists, status lists, schema registries, vocabulary registries, and audit records would be signed, versioned, monitored, and prepared for emergency rollover. This makes the corridor useful not only for legal-person onboarding, but also for cross-border B2B authentication, regulated supply-chain access, digital product passport workflows, and Trusted AI delegation.

The corridor could also support PQC-ready end-to-end communication between authenticated and authorized legal persons. If for instance encryption keys or key-agreement material are registered in a DID document, certificate-bound DID, or equivalent wallet-controlled discovery record, the parties can establish a PQC-ready secure communication channel after mutual authentication and authorization. In an early implementation, this could support encrypted API communication for a digital data-sharing corridor. In a later implementation, the same trust model could support a DIDComm-based persistent channel between enterprise wallets or wallet-connected systems. The important point is that the communication channel would not be established between anonymous endpoints. It would be established between verified legal persons whose credentials, wallet bindings, roles, authorization policies, and key material can be checked before data is exchanged.

9. Recommendations for Google and the wider ecosystem

Google is well positioned to help reframe the public discourse. It has quantum research, cryptography engineering, Chrome, Android, Cloud KMS, identity systems, browser mediation, and developer reach. Google has also already stated that authentication services and digital signatures should be prioritized in PQC migration [2]. The next step is to make digital identity a first-class post-quantum migration topic.

The work should not be Google-centric. The relevant ecosystem also includes the European Commission, ENISA, BSI, ETSI, CEN/CENELEC, W3C, OpenID Foundation, IETF, NIST, EUDI Wallet implementers, European Business Wallet stakeholders, international business wallet and data space projects, qualified trust service providers, business registers, wallet vendors, regulated industry issuers, cloud providers, mobile platform providers, and critical-infrastructure operators.

The most valuable near-term outcome would be a short public position paper and a technical work plan. The position paper should state that identity is a primary PQC risk surface. The work plan should define two or three concrete corridors and publish early interoperability artefacts.

10. Limitations and research agenda

This paper does not claim that a CRQC exists today. The resource estimates in [1] depend on architecture assumptions, error correction, timing, and scale-up assumptions. It also does not claim that every identity presentation is as exposed as a public blockchain transaction. Many VP flows are private, authenticated, and short-lived. The risk argument is about high-value exposure points, reuse, logging, malicious verifiers, public registries, and long-term trust objects.

Several identity standards are still evolving. PQC algorithm identifiers, hybrid signature encodings, Data Integrity suites, JOSE/COSE profiles, device attestation support, and privacy-preserving PQC credentials need further work. Standards bodies should avoid premature fragmentation, but they should not wait until CRQC timelines are certain.

1. Which PQC signature profiles are best for VCs, VPs, trust lists, and status lists when mobile size, QR codes, and offline verification matter?

2. How should hybrid signatures be represented consistently across Data Integrity, JOSE, COSE, SD-JWT VC, and mdoc profiles?

3. How can holder binding be PQC-ready without creating long-lived correlatable public keys?

4. What is the PQC replacement path for BBS+, CL signatures, pairing-based anonymous credentials, accumulators, and ZK proof systems?

5. How should long-term validation work after classical public-key algorithms are deprecated or broken?

6. How should EUDI-style trust lists, access certificates, and wallet attestations migrate without ecosystem downtime?

7. How should DNSSEC and WebPKI migration be coordinated with DID and VDR migration?

8. How should legal-person credentials delegate authority to AI agents in a way that is short-lived, revocable, auditable, and quantum-safe?

11. Outlook

The cryptocurrency analysis in [1] is a useful warning because it turns an abstract quantum concern into an operational attack model. Digital identity needs the same shift. The key question is not only when a quantum computer will break a curve. The key question is whether identity ecosystems will have already built migration paths for the public keys, trust anchors, registries, and semantics that they publish today.

The priority should be calm and concrete engineering: inventory public-key dependencies, avoid unnecessary long-lived key exposure, add crypto agility, pilot PQC corridors in high-risk legal-person and supply-chain flows, and define rules for reissuance and long-term evidence. This work should begin before identity wallets, DPPs, and AI-agent authority systems reach full scale.

Appendix A. Cryptographic asset inventory template

Appendix B. Minimal PQC corridor checklist

The following checklist prioritizes the minimum viable controls for a PQC-ready legal-person onboarding and data-sharing corridor, using MoSCoW levels to separate essential launch requirements from later hardening steps.

MoSCoW levels:

• Must-have: essential for a minimum viable PQC-ready onboarding and data-sharing corridor.
• Should-have: important for resilience, assurance, and long-term operation, but not blocking the first controlled corridor pilot.
• Could-have: useful hardening or usability feature that can be added after the first corridor is stable.
• Won’t-have: not needed for the minimum viable corridor and should be kept out of the first implementation scope.