Issuance Integrity

The IDToken trust model depends on a critical assumption: that every VDS was genuinely derived from a government-issued identity document. This page explains how the architecture enforces that guarantee — even if an issuance station is compromised.

Key Architectural Decision

Issuance stations never call BioSeal directly. Every issuance request goes through the IDToken Auth Server, which independently verifies the cryptographic proof from the document chip before forwarding the payload to BioSeal for signing.

The Problem

The BioSeal Issuance Service is a pure signing service — it constructs the VDS, signs it with an HSM-backed key, and returns a cryptographically valid seal. BioSeal has no mechanism to verify that the payload data originated from an authentic document chip.

If a rogue application or compromised issuance station could call BioSeal directly with fabricated identity data, the result would be a validly signed VDS containing entirely fictional information.

Attack Scenarios

Scenario	Description	Impact
Rogue app	A fake IDToken app skips passport reading and submits arbitrary data	Validly signed VDS with fabricated identity
Stolen credentials	Attacker obtains BioSeal API credentials and calls it directly	Validly signed VDS without any document
Insider threat	Authorized operator deliberately issues VDS for non-existent identities	VDS indistinguishable from legitimate issuance
Trust level inflation	Compromised station claims level 3 for a photo-only issuance	Relying parties grant high-assurance access to weakly verified identities

The Solution: IDToken Server as Gatekeeper

The IDToken Auth Server sits between every issuance station and BioSeal. It holds the only BioSeal credentials, verifies the cryptographic proof from the passport chip, and only forwards verified payloads.

Why the IDToken Server, Not BioSeal

Concern	IDToken Server as gatekeeper
BioSeal API surface	Internal only — no public exposure
Credential management	Only the IDToken server holds BioSeal credentials
Verification logic	ICAO/SOD verification lives alongside VDS trust chain verification
Audit	All issuance events in one audit trail with authentication events
Blast radius	Compromised station has zero direct access to BioSeal

ICAO Cryptographic Proof

Every e-passport chip contains cryptographic proof that the IDToken server verifies independently.

Security Object of the Document (SOD)

The SOD is a CMS (PKCS#7) signed object containing:

• Hash values of each Data Group (DG1 = MRZ data, DG2 = face photo, etc.)
• The Document Signer Certificate (DSC), issued by the Country Signing CA (CSCA)
• A digital signature over the hash list, created by the document signer

The SOD proves that the data groups were written by the issuing State and have not been modified.

Active Authentication (AA)

Active Authentication proves the chip is genuine (not cloned) by having the chip sign a random challenge with its internal private key. The private key never leaves the chip — it cannot be copied.

Verification Flow

The IDToken Auth Server performs these checks on every issuance request:

Step	Verification	Reject if
A	Parse SOD, extract DSC, verify DSC chains to a known CSCA (via ICAO PKD)	Unknown CSCA, invalid chain, expired DSC
B	Verify SOD signature using DSC public key	Signature invalid
C	Compute SHA-256 of raw DG1 and DG2, compare against SOD hash values	Hash mismatch (data was tampered)
D	Verify AA response signature over challenge using chip’s public key (DG15)	Signature invalid (chip is cloned)
E	Parse DG1, compare gn, fn, dob, nat, doc against submitted payload	Any field mismatch (station altered data)
F	Verify face template was derived from DG2 photo (id3 Face SDK 1:1 match)	Match score below threshold

Only after all checks pass does the server forward the verified payload to BioSeal.

Trust Level Enforcement

The IDToken server enforces trust level requirements before calling BioSeal:

Trust Level	documentProof required?	SOD verification	AA verification	Payload cross-check
1 — Self-issued	No	No	No	No
2 — Operator-verified	Yes (SOD only)	DSC → CSCA chain	Optional	DG1 vs payload
3 — Full verification	Yes (full)	DSC → CSCA chain	Chip genuineness	DG1 + DG2 vs payload

The server refuses to forward a trust level 3 request to BioSeal without valid Active Authentication proof. A compromised station cannot inflate the trust level.

ICAO PKD Integration

To verify SOD signatures, the IDToken server maintains a cache of Country Signing CA (CSCA) certificates from the ICAO Public Key Directory.

Aspect	Approach
Source	ICAO PKD subscription (or national mirror such as the French ANTS distribution)
CSCA cache	Refreshed daily, stored in Redis alongside existing VDS trust chain cache
CRL refresh	Every 6 hours, for revoked Document Signer Certificates
Offline fallback	Verification continues against cached certificates if PKD is unreachable
Coverage gaps	Countries not in ICAO PKD: SOD verification failure results in downgraded trust level (2 → 1)

This is architecturally consistent with the existing VDS trust chain caching already implemented for Otentik governance lists, TSLs, and CA certificates.

Station Authentication

The IDToken server verifies the identity of the calling station before processing any issuance request:

Method	Description
mTLS client certificate	Each station has a unique client certificate issued by id3. The server verifies it before accepting requests.
Station registration	Each station is registered with a stationId, allowed operator list, and geographic location. Unregistered stations are rejected.
Rate limiting	Per-station issuance limits (e.g., max 50/day). Anomalous bursts trigger alerts.

For high-security deployments, TPM-based station attestation can verify that the station software has not been modified.

Issuance Audit

All issuance events are recorded in the same audit trail as authentication events:

Control	Description
Per-station logs	stationId, operator, tokenId, timestamp, trust level, SOD verification result
Operator shift checks	Issuances outside scheduled hours trigger alerts
Geographic consistency	Station in Paris issuing from an IP in another country → flag
Document uniqueness	Same passport number producing multiple tokenId values → flag
Country analysis	Station processing passports from unexpected countries → flag
Biometric deduplication	Optional: cross-check face templates to detect duplicate enrollments

Residual Risk

Risk	Likelihood	Mitigation
Stolen genuine passport	Low	Biometric check at station (thief’s face won’t match DG2). Requires colluding operator to bypass.
CSCA key compromise	Very low	National security incident — outside IDToken’s threat model. ICAO CRL handles revocation.
Trust level 1 (no NFC)	Inherent	Self-issued credentials bypass chip verification by design. Relying parties must require level 2+ for sensitive operations.
Colluding operator	Very low	Real passport scanned, VDS redirected. Mitigated by audit logs, biometric deduplication, dual-operator policies.
IDToken server compromise	Very low	Server holds BioSeal credentials. Mitigated by hardened deployment, HSM for keys, least privilege, audit, monitoring.