Network Working Group M. Benaudis Internet-Draft Https Card - Internet Identity Card Ltd Intended status: Informational August 2026 Expires: 2 February 2027 The Internet Identity Card (IIC) Credential Format: A Self-Contained, Offline-Verifiable Identity Credential with Hybrid Classical and Post- Quantum Signatures draft-benaudis-iic-credential-00 Abstract 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 This note is to be removed before publishing as an RFC. Source and discussion for this document are coordinated by the author; comments are welcome by email. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Benaudis Expires 2 February 2027 [Page 1] Internet-Draft IIC Credential Format August 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 2 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 4. Crypto-Agile Suite Registry . . . . . . . . . . . . . . . . . 4 5. Signed Core Construction . . . . . . . . . . . . . . . . . . 5 6. Hybrid Verification Rule . . . . . . . . . . . . . . . . . . 5 7. Canonical Serialization and Page Integrity . . . . . . . . . 6 8. Document-Signing Receipts . . . . . . . . . . . . . . . . . . 6 9. Deterministic Build and Release Anchoring . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10.1. Threat Model Summary . . . . . . . . . . . . . . . . . . 8 10.2. Explicit Non-Goals . . . . . . . . . . . . . . . . . . . 8 10.3. Algorithm Agility . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. 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 Benaudis Expires 2 February 2027 [Page 2] Internet-Draft IIC Credential Format August 2026 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 [FIPS186] with ML-DSA-65, the module-lattice signature standardized by NIST as FIPS 204 [FIPS204], 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 [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 [TDC11121], and a systems paper describing the architecture and its rationale is available [EPRINT]. This document does not define an interchange standard and does not request any IETF standards action. 2. 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 [RFC2119] [RFC8174] 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 (Section 4). Receipt: A machine-readable record of a document-signing event Benaudis Expires 2 February 2027 [Page 3] Internet-Draft IIC Credential Format August 2026 produced by a credential (Section 8). Zone: A delimited region of the credential file whose content is excluded from, or specially handled by, the canonical serialization (Section 7). 3. Architecture Overview An IIC v9.0 credential contains, in distinct structural zones: * an identity payload encrypted with AES-256-GCM [SP80038D] under a key derived from a holder passphrase via Argon2id [RFC9106] (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. 4. 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: Benaudis Expires 2 February 2027 [Page 4] Internet-Draft IIC Credential Format August 2026 SUITES = { 'hybrid-v1' : ['ecdsa-p256', 'ml-dsa-65'], // active 'pqc-pure-v1': ['ml-dsa-65'] // registered, future } The active suite, hybrid-v1, combines: * ecdsa-p256: ECDSA over the NIST P-256 curve with SHA-256 [FIPS186]; 33-byte compressed public key, 64-byte signature. * ml-dsa-65: ML-DSA-65 [FIPS204]; 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. 5. Signed Core Construction Signing operates over a canonical byte string binding the payload to the public keys and a timestamp: core = 'IIC-CORE-v1|' || payload || '|PK|' || concat(pubkeys) || '|TS|' || timestamp digest = SHA-256(core) sig_i = Sign_i(digest) for each algorithm i in the suite 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. 6. 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. Benaudis Expires 2 February 2027 [Page 5] Internet-Draft IIC Credential Format August 2026 Combined with public timestamp anchors (Section 9), 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. 7. 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 [TDC10795]. 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. 8. 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): Benaudis Expires 2 February 2027 [Page 6] Internet-Draft IIC Credential Format August 2026 receipt = { version: '3.0', payload: { data, cid, fp, ts, nonce, seq, prevHash }, hash: SHA-256(payload), signature: [...], // ECDSA signature (legacy field) publicKey: { JWK }, // ECDSA public key (legacy field) hybrid: { suite: 'hybrid-v1', signatures: { 'ecdsa-p256': ..., 'ml-dsa-65': ... }, publicKeys: { 'ecdsa-p256': ..., 'ml-dsa-65': ... } } } 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 Section 6. 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. 9. 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. 10. Security Considerations This entire document concerns a security mechanism; this section summarizes properties and limits. Benaudis Expires 2 February 2027 [Page 7] Internet-Draft IIC Credential Format August 2026 10.1. 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 Section 6); 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. 10.2. 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 Section 9 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. Benaudis Expires 2 February 2027 [Page 8] Internet-Draft IIC Credential Format August 2026 10.3. Algorithm Agility The suite registry (Section 4) 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 [ANTHROPIC-HAWK]. The HAWK development team subsequently announced the withdrawal of their candidate from the NIST process [PQCFORUM-HAWK], 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 [NIST-PQC]. 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. 11. IANA Considerations This document has no IANA actions. The suite registry of Section 4 is maintained by the issuer as part of the format; it is not an IANA registry. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications", RFC 9106, DOI 10.17487/RFC9106, September 2021, . [FIPS204] National Institute of Standards and Technology, "Module- Lattice-Based Digital Signature Standard", NIST FIPS 204, August 2024, . Benaudis Expires 2 February 2027 [Page 9] Internet-Draft IIC Credential Format August 2026 [FIPS186] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", NIST FIPS 186-5, February 2023, . [SP80038D] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST SP 800-38D, November 2007, . 12.2. Informative References [ANSSI] ANSSI, "Recommandations pour la migration vers la cryptographie post-quantique", 2022, . [TDC11121] Benaudis, M., "Post-Quantum Ready, Offline-Verifiable Digital Identity Credential: Hybrid ECDSA P-256 and ML- DSA-65 Signing with Embedded Offline Verification Engine, Crypto-Agile Suite Registry, and Deterministic Build in a Self-Contained Single-File Document", Technical Disclosure Commons, no. 11121, July 2026, . [TDC10795] Benaudis, M., "Canonical Multi-Zone Neutralization for Self-Serialized Documents Carrying Heterogeneous Hybrid Signatures, a Self-Referential Integrity Digest, and a Post-Signing Timestamp Anchor", Technical Disclosure Commons, no. 10795, July 2026, . [ANTHROPIC-HAWK] Anthropic, "Discovering cryptographic weaknesses with Claude", 28 July 2026, . [PQCFORUM-HAWK] NIST pqc-forum (public mailing list), "HAWK-n Key Recovery Reduces to SVP in Dimension n/2 + 1", Disclosure thread and withdrawal announcement by the HAWK team, 28 July 2026, . [NIST-PQC] National Institute of Standards and Technology, "Post- Quantum Cryptography", Statement confirming the HAWK withdrawal, 2026, . Benaudis Expires 2 February 2027 [Page 10] Internet-Draft IIC Credential Format August 2026 [EPRINT] Benaudis, M., "A Self-Contained, Offline-Verifiable Digital Identity Credential with Hybrid ECDSA P-256 / ML- DSA-65 Signatures", IACR Cryptology ePrint Archive (in moderation); specification corpus: DOI 10.5281/ zenodo.21738537, August 2026, . 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. Author's Address Michael Benaudis Https Card - Internet Identity Card Ltd 124 City Road London EC1V 2NX United Kingdom Email: contact@internetidentitycard.com URI: https://www.internetidentitycard.com Benaudis Expires 2 February 2027 [Page 11]