The Internet Identity Card (IIC) Credential Format: A Self-Contained, Offline-Verifiable Identity Credential with Hybrid Classical and Post-Quantum Signatures

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/.¶

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

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 [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 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:¶

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.¶

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):¶

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.¶

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.¶

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