Every dependency added to a credential is a component that can fail on someone else’s premises.
This page sets out the structural failure modes that shaped the architecture of the Internet Identity Card —
and, just as importantly, the problems it does not solve.
Last updated: 02 August 2026
None of the failure modes below is a failure of cryptography. In each of them the algorithms hold. What failed was everything the credential depended on: a database that pooled identity attributes for millions of people, a broker standing between the holder and the verifier, a server that held custody of secrets it did not need, a subcontractor inserted into the trust chain, a build pipeline that shipped something other than the reviewed source.
An offline-first credential is a response to that observation. It does not make the holder invulnerable. It removes categories of component from the path between “this person holds a credential” and “this verifier can check it” — and a component removed from the verification path cannot introduce a failure through that path.
When identity attributes are pooled so that a service can verify them on demand, the pool itself becomes the target. The economics are brutally asymmetric: the operator must defend every entry point indefinitely; an attacker needs one. And unlike a password, the attributes held in these repositories — date of birth, national identifiers, document numbers — cannot be rotated. The individual carries the exposure for life, or until a state agency reissues the document.
Mechanism: the value at risk scales with the size of the pool, while the cost of attacking it does not. Aggregation is therefore not a neutral implementation detail — it is the dominant term in the risk calculation.
An IIC card is issued as an individual artefact. There is no central repository of cardholders, no directory that must be queried at verification time, and no issuer-held copy of the identity payload. Each card carries its own encrypted data, decrypted locally with the Card Passphrase. There is no issuer-operated repository of cardholder identity payloads, and therefore no pool whose compromise scales across holders.
Scope note: this does not eliminate the databases that organisations keep for their own purposes. It removes the credential layer as a reason to build another one.
Throughout this page, broker means a party, other than the holder and the verifier, on which an act of verification depends — because it must be queried while the check is taking place, or because it signs the assertion the verifier relies upon. A publisher of a public key that has already been distributed is not a broker in this sense: nothing is asked of it at verification time.
Federated identity concentrates trust in a broker that issues or signs the assertions on which every downstream party relies. This is efficient, and it explains why the model is so widely deployed. It also means the broker is a single point of catastrophic failure whose internal state the relying parties cannot inspect. When the broker’s signing material or session material is compromised, downstream controls — including multi-factor authentication — are bypassed rather than defeated, because the attacker arrives holding what looks like a completed authentication.
Mechanism: a forged or replayed assertion is indistinguishable from a legitimate one at the point of verification. Detection therefore depends on the broker’s own telemetry, which the relying party does not control and cannot audit.
Verification of an IIC card involves no broker. The card contains its own verification engine, and at v9.0 the signature is a hybrid construction combining classical ECDSA P-256 with ML-DSA-65 (NIST FIPS 204), as specified in the technical documentation. This page describes the rationale, not the normative construction. A verifier checks the artefact in front of them, offline, against material embedded in that artefact. In that path there is no upstream assertion to forge, no session token to replay, and no third-party availability on which the check depends.
Scope note: this shifts trust rather than abolishing it. The verifier still trusts the issuer’s signing key — but that trust is exercised against a fixed, inspectable artefact instead of a live service. The issuer remains a trust anchor; it is not a verification-time dependency.
Encrypting data before storing it on a server is necessary but not sufficient. Once an encrypted archive leaves the perimeter, the defence reduces entirely to the cost of deriving the key. Rate limiting, lockouts, monitoring and revocation all become irrelevant, because the attacker is no longer interacting with the service. The remaining question is arithmetic: how expensive is one guess, multiplied by how many guesses are needed.
Mechanism: exfiltration converts an online authentication problem, where the defender sets the rules, into an offline cracking problem, where the attacker does. Any metadata left unencrypted alongside the ciphertext lets the attacker rank targets before spending a single cycle.
The architecture provides for no server-side copy: Https Card operates no store of issued cards or backups, and none is required at any point in issuance or verification. Cards use AES-256-GCM with authenticated encryption, and keys are derived with Argon2id (RFC 9106) at 96 MiB of memory, four iterations and a parallelism of four — parameters chosen to remain workable on a mid-range phone while raising the per-guess cost of offline attack by orders of magnitude relative to iteration-only derivation. The .iic backup format uses the same memory-hard derivation with a random per-backup salt, so that a backup is no weaker than the card.
Scope note: memory-hardness raises cost, it does not create impossibility. A weak passphrase remains a weak passphrase — the design reduces the attacker’s advantage, it does not substitute for the holder’s choice. Holders remain free to store their own cards wherever they wish, including on third-party services; the architecture neither requires this nor governs it.
Identity data rarely stays where it was collected. Processing is delegated to operators, platforms and subcontractors, each of which needs a working copy to perform its function. The individual has no relationship with these parties, cannot enumerate them, and in most cases learns of their existence only from a breach notification. Regulatory accountability may remain with the controller; the exposure does not.
Mechanism: each delegation duplicates the data and adds an independent attack surface, while the number of intermediaries is invisible to the person whose data is being copied.
An IIC card is a single self-contained HTML file. It makes no network call in normal operation, embeds no third-party script or CDN reference, and carries a Content-Security-Policy that permits no external resource to be loaded at all. Presenting a card to a verifier transfers a file; it does not enrol the holder in a processing chain. Within the credential verification path, no third party processes, stores or attests to the identity data. The components that remain are ones the holder already controls or chooses — the device, the operating system and the browser — and their limits are stated below.
Scope note: this concerns the credential. Whatever an organisation does with the identity data after reading a card is governed by its own processing arrangements, not by ours.
A user who verifies a signature verifies that a file came from the publisher. It does not follow that the file corresponds to the source the publisher reviewed. Between source and artefact sits a build system, and that system signs whatever it is given. This is the failure mode that most directly concerns anyone distributing security software — including us.
Mechanism: code signing attests to origin, not to correspondence with reviewed source. Closing that gap requires a published hash of the released artefact, a build that reproduces it, and a timestamp that cannot be backdated by the publisher.
Each IIC release is produced by a deterministic build, and the SHA-256 digest of the release is published on the verification page so that any recipient can confirm that the file they hold is the file that was released. Https Card additionally submits the digest of each generator release for anchoring on the Bitcoin and Ethereum blockchains, which places the existence of that exact artefact at that moment beyond our own ability to revise. The resulting transactions are listed on the documentation page; each can be inspected on a public block explorer without reference to us. Each card also carries an embedded self-integrity check that recomputes its own hash at load and refuses to operate on mismatch.
Scope note: anchoring is an issuer operation performed once per release. It is not a credential function, it does not happen offline, and it proves existence and integrity at a point in time — not the absence of defects.
A design document that only lists advantages is marketing. These are the constraints an offline-first credential accepts, stated plainly, because a verifier who discovers them later is entitled to distrust everything above. They are carried through to the residual-risk section of the published threat model, not confined to this page.
Offline revocation is not achievable. Revocation is the transmission of new information, and no artefact can learn offline that it has been withdrawn. This is a property of the problem, not a gap in the implementation, and any product claiming otherwise is describing something else. The realistic approaches are short-lived credentials, whose validity window bounds the exposure, and status information fetched in advance while connectivity exists. Both trade freshness against independence; neither delivers both.
Cryptography attests that a credential was issued by a given issuer and has not been altered. It says nothing about whether the underlying claim was true at issuance. The strength of that claim rests entirely on the issuer’s verification procedures, which are an organisational matter and outside the reach of any signature scheme.
A card is decrypted in the holder’s browser. Malware with control of that environment can observe the passphrase and the plaintext at the moment of use. Removing the server from the architecture concentrates the remaining risk at the endpoint; it does not make the endpoint trustworthy.
There is no recovery path. Absent a custodian holding a copy, a lost passphrase means an unrecoverable card — the direct and unavoidable cost of removing custodians. Nor does any client-side scheme defend against a holder compelled to unlock a card under duress.
Several of the modes above concern functions an identity credential does not perform — customer databases, payment processing, corporate email — and nothing here suggests that an offline credential substitutes for securing them. The claim is narrower and, we think, more defensible: these failure modes are properties of architecture rather than of the competence of the parties involved. Where a component is unnecessary to the credential, removing it removes its failure mode too.
The comparison below concerns the path between a holder presenting a credential and a verifier checking it. A broker-dependent model is any architecture whose verification depends on a broker as defined above. Individual deployments vary considerably: the column describes the model, not any specific product, organisation or implementation.
| Component in the verification path | Broker-dependent model | Internet Identity Card |
|---|---|---|
| Network connectivity at verification | Required | Not required |
| Central directory of holders | Present | None |
| Broker availability at verification | On the critical path where a live query is required | Not on the path |
| Server-side copy of identity payload | Present in many centralised deployments | None |
| Runtime third-party code or CDN | Implementation-dependent | None — single file, CSP permitting no external resource |
| Telemetry or analytics at use | Implementation-dependent | None |
| Signature scheme | Classical, varies | Hybrid ECDSA P-256 + ML-DSA-65 (FIPS 204) |
| Artefact integrity evidence | Publisher signature | Published SHA-256, deterministic build, blockchain-anchored release digest, embedded self-check |
| Revocation | Requires an information update mechanism | Not available offline — see limits above |
The full cryptographic construction, threat model and verification procedure are set out in the technical documentation.
The failure modes set out on this page are described at the level of architecture. They are drawn from publicly documented incidents, regulatory findings and official reviews published over the past decade, but no organisation, product or incident is named, and none is intended to be identifiable. Naming would add nothing: the argument concerns properties of system design, not the conduct of any particular party.
Nothing on this page is a statement about the security posture, past or present, of any organisation, nor an assertion that any product of Https Card — Internet Identity Card Ltd would have been suitable for any particular use case. All trademarks remain the property of their respective owners.
This page is a statement of design rationale. It is not legal, regulatory or security advice. Corrections are welcome at contact@internetidentitycard.com and will be actioned promptly.