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

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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,
              <https://www.rfc-editor.org/info/rfc9106>.

   [FIPS204]  National Institute of Standards and Technology, "Module-
              Lattice-Based Digital Signature Standard", NIST FIPS 204,
              August 2024, <https://doi.org/10.6028/NIST.FIPS.204>.

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,
              <https://doi.org/10.6028/NIST.FIPS.186-5>.

   [SP80038D] Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: Galois/Counter Mode (GCM) and GMAC", NIST
              SP 800-38D, November 2007,
              <https://doi.org/10.6028/NIST.SP.800-38D>.

12.2.  Informative References

   [ANSSI]    ANSSI, "Recommandations pour la migration vers la
              cryptographie post-quantique", 2022,
              <https://cyber.gouv.fr>.

   [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,
              <https://www.tdcommons.org/dpubs_series/11121>.

   [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,
              <https://www.tdcommons.org/dpubs_series/10795>.

   [ANTHROPIC-HAWK]
              Anthropic, "Discovering cryptographic weaknesses with
              Claude", 28 July 2026,
              <https://www.anthropic.com/research/discovering-
              cryptographic-weaknesses>.

   [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, <https://groups.google.com/a/list.nist.gov/g/pqc-
              forum/c/2r2u6SbHun4>.

   [NIST-PQC] National Institute of Standards and Technology, "Post-
              Quantum Cryptography", Statement confirming the HAWK
              withdrawal, 2026, <https://www.nist.gov/pqc>.

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,
              <https://www.internetidentitycard.com>.

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]