Trust Architecture

IDToken’s trust model is fundamentally different from traditional authentication: trust is not self-declared (like creating an account with an email), but anchored in a government-issued document and verified through a PKI governance chain defined by international standards.

The Trust Chain

Every IDToken credential traces back to a government-issued passport through a series of cryptographic verifications:

PKI Governance (ISO 22385)

The VDS PKI chain follows the ESEDS (Electronic Scheme for Electronic Documents with Security) model defined by ISO 22385:

Verification Steps

To verify an IDToken VDS, the auth server walks the full chain:

1. Decode the VDS binary (Base45/Base64/hex auto-detected)
2. Parse the header to extract IAC, certificate reference, manifest ID
3. Fetch Governance List — identifies authorized Scheme Operators
4. Fetch Scheme List — for the IAC found in the VDS header (e.g., “VDS” for Otentik)
5. Fetch TSL — the Trust Service List for the relevant geographic region
6. Resolve CA certificate — locate the Certificate Authority from the TSL
7. Validate signing certificate — check expiry, revocation status, and that the UsageList includes the VDS manifest ID
8. Verify ECDSA signature — SHA-256(header || SHA-256(payload)) against the signing certificate’s public key

Caching

Trust lists are cached locally to avoid repeated network fetches. The default cache TTL is 1 hour for all artifacts (Governance List, Scheme Lists, TSLs, manifests, and VDS Revocation Lists).

For details on the VDS format, signature model, and manifest system, see The VDS Credential.

Issuance Integrity

The trust chain above verifies that an existing VDS is authentic. But how does IDToken ensure that the data in the VDS was genuinely extracted from a government document in the first place?

The answer: issuance stations never call BioSeal directly. Every issuance request goes through the IDToken Auth Server, which verifies the passport chip’s cryptographic proof (ICAO SOD signature chain + Active Authentication) before forwarding to BioSeal. See Issuance Integrity for the full architecture.

Trust Levels

IDToken assigns three trust levels based on how the VDS was issued:

Level	Name	Issuance Method	Assurance
1	Self-issued	Selfie + document photo (no NFC)	Low
2	Operator-verified	NFC read + operator present	Substantial (eIDAS)
3	Full verification	NFC + Active Auth + biometric match	High (eIDAS)

Trust levels flow through the entire system:

• Stored in the VDS as auxiliary data
• Included as a JWT claim after authentication
• Used by relying parties to gate access (e.g., “require trust level 3 for financial transactions”)
• Mapped to SAML AuthnContextClassRef for enterprise SSO

VDS Revocation

VDS credentials can be revoked through two mechanisms:

1. Enrollment revocation — the auth server marks the tokenId as revoked in its database. The VDS itself remains valid, but authentication is blocked.
2. VDS Revocation List (VRL) — the VDS fingerprint (SHA-256 of raw bytes) is checked against the VRL published by the Trust Service List. This catches credentials revoked at the PKI level.

What Makes This Different?

Traditional Identity	IDToken
User creates an account with email/password	Identity derived from a government passport
Trust is self-declared	Trust is PKI-backed, traceable to VDSIC
Identity verification is optional (email link)	Identity verified biometrically against NFC chip photo
Server stores personal data	Server stores only a public key binding
Password can be phished or leaked	Credential is cryptographically signed, hardware-bound
No assurance levels	Three trust levels aligned with eIDAS