]> Https Card - Internet Identity Card Ltd

124 City Road London EC1V 2NX United Kingdom contact@internetidentitycard.com https://www.internetidentitycard.com

Security digital identity post-quantum cryptography hybrid signatures ML-DSA offline verification This document describes the Internet Identity Card (IIC) credential format, version 9.0: a digital identity credential implemented as a single self-contained HTML file that can be generated, stored, transferred, and cryptographically verified entirely offline, without servers, brokers, or network connectivity. Identity data is encrypted with AES-256-GCM under keys derived by Argon2id; authenticity is provided by a hybrid signature combining ECDSA P-256 with ML-DSA-65 (NIST FIPS 204) under a crypto-agile suite registry; and integrity is provided by an embedded SHA-256 self-check over a canonical serialization of the document. Each exported credential embeds its own verification engine, so verification requires only a standard web browser. This document is published for informational purposes, to describe a deployed format whose underlying constructions are disclosed as open prior art. Discussion Venues Source and discussion for this document are coordinated by the author; comments are welcome by email.

Introduction Most deployed digital identity systems assume network connectivity at verification time: reaching an issuer endpoint, a status service, a wallet backend, or a platform intermediary. This assumption fails in settings where identity verification matters most: border crossings and field operations without coverage, disaster response, air-gapped environments, and any scenario in which a credential must remain checkable long after the issuing infrastructure has changed or disappeared. The Internet Identity Card (IIC) takes the opposite starting point: the credential itself carries everything required for its own verification. An IIC credential is a single HTML file embedding the encrypted identity payload, the cryptographic parameters, the public verification material, and a complete verification engine executable in any modern browser, including from removable media with no network interface present. A second design concern is longevity. An identity credential may need to remain verifiable for decades, well into the period in which large-scale quantum computers may threaten classical public-key signatures. Version 9.0 of the format therefore signs every credential with a hybrid scheme combining classical ECDSA P-256 with ML-DSA-65, the module-lattice signature standardized by NIST as FIPS 204 , under a crypto-agile suite registry that allows future algorithm transitions without changes to the container format. This hybrid-during-transition approach follows the guidance of national cybersecurity agencies, including ANSSI . This document describes the format as deployed, for informational purposes. The underlying constructions are separately disclosed as open prior art under CC BY 4.0 , and a systems paper describing the architecture and its rationale is available . This document does not define an interchange standard and does not request any IETF standards action.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Credential (or "card"):

A single self-contained HTML file produced by an IIC generator, carrying an encrypted identity payload, signature material, and an embedded verification engine.

Generator:

The issuer-side application that creates credentials, holds the signing keys, and exports standalone credential files.

Suite:

A named, ordered list of signature algorithms registered in the crypto-agile suite registry ().

Receipt:

A machine-readable record of a document-signing event produced by a credential ().

Zone:

A delimited region of the credential file whose content is excluded from, or specially handled by, the canonical serialization ().

Architecture Overview An IIC v9.0 credential contains, in distinct structural zones:

• an identity payload encrypted with AES-256-GCM under a key derived from a holder passphrase via Argon2id (96 MiB memory, 4 iterations, 4 lanes, random per-credential salt);
• an authenticated header binding the format version, a per-credential identifier, an export timestamp, and the active suite identifier into the AEAD associated data;
• a hybrid signature block over the credential's signed core, together with the corresponding public keys;
• a SHA-256 self-integrity digest over the canonical serialization of the file;
• an embedded verification engine (approximately 54 KB), carried as a base64 payload and activated at load time by a bootstrap that attaches it as an inline script element, requiring neither eval nor WebAssembly, so that a strict Content Security Policy suffices; and
• optionally, a blockchain timestamp anchor reference and a freshness token chain.

Verification of a credential, of its signed core, and of receipts it has produced requires no network access and no installed software other than a standard web browser. A typical secure credential is approximately 210 KB.

Crypto-Agile Suite Registry Every credential names its algorithm suite through a registry identifier bound into the authenticated header. Algorithms are registry entries exposing a uniform keygen/sign/verify interface; suites are named lists of algorithm identifiers. Version 9.0 defines: The active suite, hybrid-v1, combines:

• ecdsa-p256: ECDSA over the NIST P-256 curve with SHA-256 ; 33-byte compressed public key, 64-byte signature.
• ml-dsa-65: ML-DSA-65 ; 1952-byte public key, 3309-byte signature.

Verifiers MUST reject credentials whose declared suite they do not implement. Introducing a successor suite requires registering a new identifier and shipping verifier support; it does not require changes to the container format, and credentials issued under an earlier suite remain verifiable indefinitely by conformant verifiers.

Signed Core Construction Signing operates over a canonical byte string binding the payload to the public keys and a timestamp: Each algorithm in the active suite signs the same digest independently. The two key pairs are generated and stored independently, so the compromise of one signing key does not affect the other.

Hybrid Verification Rule A hybrid signature is valid if and only if:

1. every non-deprecated component of the declared suite verifies successfully; and
2. at least one post-quantum component verifies successfully.

Deprecating a component (for example, the classical component after a quantum break of ECDSA) is a verification-time policy option that requires no change to already-signed material. Because condition (2) always requires a valid post-quantum component, the rule structurally excludes downgrade to classical-only acceptance. Combined with public timestamp anchors (), this rule addresses the harvest-now, forge-later attack model: an adversary who records signed material today and breaks the classical component in the future still cannot forge authorship, and a post-deprecation forgery carrying only a broken classical signature fails both the post-quantum check and the pre-deprecation anchor requirement.

Canonical Serialization and Page Integrity The credential verifies its own byte-level integrity offline. A canonical snapshot of the document is captured before any script mutation occurs, and elements whose state is legitimately dynamic (such as a network-status indicator) are normalized, so that the digest does not depend on the runtime environment (for example, whether the file is opened without network connectivity). Sealing at generation time assembles the full HTML with a 64-character placeholder zone, computes the SHA-256 digest of that serialization, and replaces the placeholder with the digest. Verification restores the placeholder, recomputes, and compares. Any byte change outside the placeholder zone MUST trigger a fail-closed lockdown of the credential. Because a self-serialized document simultaneously carries heterogeneous-size hybrid signatures, a self-referential integrity digest, and a post-signing anchor reference, these zones are resolved in a fixed neutralization order using length-preserving placeholders; a complete description of this construction is given in . This snapshot-based approach is deliberately independent of fetch-based re-reading of the file, which is unavailable on file:// and blob: origins in common browsers, precisely the offline deployments this format targets.

Document-Signing Receipts A credential can sign external content, producing chained receipts. Version 9.0 receipts (version string "3.0") have the following structure (informative rendering): Both algorithms co-sign the same payload hash. The legacy ECDSA fields are preserved so that earlier ECDSA-only verifiers continue to validate the classical component; hybrid-aware verifiers validate the hybrid block under the rule of . The chain fields (seq, prevHash) prevent silent reordering or truncation of a receipt sequence. Earlier (version "2.0", ECDSA-only) receipts remain verifiable for backward compatibility.

Deterministic Build and Release Anchoring The generator is built deterministically: identical source inputs always produce a byte-identical output file, so a given release corresponds to a single well-defined SHA-256 digest that third parties can independently recompute. At each release, the issuer submits the release digest to one or more public blockchain timestamping services, committing it to public ledgers (Bitcoin and Ethereum in current practice). Anchoring is an issuer-performed, per-release, online operation, structurally separate from the credential's own offline operation. Its purpose is longevity: the existence and integrity of a given release can later be established from public ledgers alone, independent of the issuer's continued operation. Combined with the deterministic build, an anchor is a commitment to the semantic content of the release, reproducible by any party who rebuilds from the same sources.

Security Considerations This entire document concerns a security mechanism; this section summarizes properties and limits.

Threat Model Summary The format defends against: network adversaries (defeated by offline operation and AEAD encryption); storage adversaries obtaining the file at rest (AES-256-GCM under Argon2id-derived keys, with memory-hard parameters chosen above common minimum recommendations); forgers (SHA-256 self-integrity with fail-closed lockdown, and the hybrid signature rule of ); and future quantum adversaries against authorship (ML-DSA-65 component plus pre-deprecation anchors). AES-256 retains approximately 128-bit strength against Grover-type quantum search.

Explicit Non-Goals Offline revocation is impossible in principle: revocation is new information, and information requires a channel. A purely offline verifier cannot learn that a credential valid yesterday was revoked today. Realistic approximations are short-lived credentials (bounding exposure by the export timestamp bound into the AEAD associated data) and status lists retrieved while connectivity is available and consulted offline. Implementations MUST NOT claim offline revocation. Compromised endpoints are out of scope: malware on the issuer's or verifier's device reads plaintext before encryption or after decryption, and a malicious browser or operating system can subvert any in-page cryptography. Key custody binding (that a signing key belongs to a particular real-world identity) is external to the format: the file proves what was signed, not who the signer is. Coerced disclosure of secrets defeats any cryptography. Generator provenance is a trust prerequisite: a verifier given a tampered generator loses all guarantees. The deterministic build and public anchoring of exist to make generator authenticity independently checkable. In the deployment described by this document, the generator, the companion wallet application, and issued credentials are not publicly distributed; access is granted through a controlled onboarding process. Only this format description and the referenced specifications and defensive publications are public. This document does not depend on public distribution of the generator or of any credential: it documents the credential file format and its verification properties, which a conformant verifier can check given only a credential file and the relevant public keys.

Algorithm Agility The suite registry () is the format's response to the possibility that any single algorithm may fail. In July 2026, a structural weakness was disclosed in the HAWK signature scheme, then in its third round of evaluation in the NIST post-quantum signature standardization process and previously considered secure after two years of expert review . The HAWK development team subsequently announced the withdrawal of their candidate from the NIST process , and NIST confirmed that HAWK will not be standardized or deployed, while noting that the finding does not affect any of its finalized PQC standards, including ML-KEM and ML-DSA . This episode illustrates the risk this design anticipates: that a scheme reviewed by specialists for an extended period can still conceal a fatal weakness. The format deliberately uses only finalized standards (FIPS 204, FIPS 186-5, SP 800-38D, RFC 9106, FIPS 180-4) and requires at least one valid post-quantum component at verification time.

IANA Considerations This document has no IANA actions. The suite registry of is maintained by the issuer as part of the format; it is not an IANA registry.

References Normative References National Institute of Standards and Technology National Institute of Standards and Technology Informative References ANSSI Technical Disclosure Commons, no. 11121 Technical Disclosure Commons, no. 10795 Anthropic NIST pqc-forum (public mailing list) Disclosure thread and withdrawal announcement by the HAWK team National Institute of Standards and Technology Statement confirming the HAWK withdrawal IACR Cryptology ePrint Archive (in moderation); specification corpus: DOI 10.5281/zenodo.21738537

Acknowledgments The constructions described here are disclosed as open prior art on Technical Disclosure Commons under CC BY 4.0; the complete v9.0 specification corpus is archived with DOI 10.5281/zenodo.21738537.