The VDS Credential
A Visible Digital Seal (VDS) is a compact, cryptographically signed digital credential defined by ISO 22376:2023. It is the identity foundation of IDToken — every user’s identity originates from a VDS derived from their government-issued passport.
Unlike passwords, tokens, or self-declared accounts, a VDS carries verifiable proof of who someone is, signed by a certified authority and traceable through a governed PKI chain.
What a VDS Contains
Section titled “What a VDS Contains”A VDS is a self-contained data structure that carries identity data, a biometric photo, and a cryptographic signature — all in a format compact enough to fit in a QR code.
The signature covers both the header and the payload, ensuring that neither the identity data nor the metadata (timestamp, manifest reference, certificate reference) can be modified without detection.
How the Signature Works
Section titled “How the Signature Works”VDS uses a two-step hash process for signing, which allows the payload to be verified independently of its size:
This design means a verifier can confirm the header independently and then check the payload against the hash — useful for large payloads or partial verification scenarios.
| Curve | Hash Algorithm | Signature Size |
|---|---|---|
| P-256 | SHA-256 | 64 bytes |
| P-384 | SHA-256 | 96 bytes |
| P-521 | SHA-512 | 132 bytes |
IDToken uses P-256 exclusively.
The Manifest System
Section titled “The Manifest System”Every VDS is created according to a manifest — an XML document that defines the payload schema, validation rules, and authorization requirements for a specific use case.
| Property | Description |
|---|---|
| Manifest ID | 6 hex characters uniquely identifying the use case (e.g., 0A0001 for IDToken) |
| Payload schema | Defines which fields exist, their types, and constraints (max length, encoding, etc.) |
| AuthorizedUsage | A UUID + OID pair that must match the signing certificate’s UsageList |
| Extensions | Additional rules: validity periods, biometric data formats, display instructions |
Manifests are published by the Scheme Operator and fetched during verification to validate the payload structure.
IDToken Manifest
Section titled “IDToken Manifest”The IDToken identity credential uses manifest 0A0001, which defines these payload fields:
| Field | Key | Type | Constraints |
|---|---|---|---|
| Given name | gn | String | Max 39 chars |
| Family name | fn | String | Max 39 chars |
| Date of birth | dob | Date | ISO format |
| Nationality | nat | String | 3-letter ISO code, C40 encoded |
| Document number | doc | String | Passport/ID number |
| Token ID | tid | String | UUID, unique per VDS |
| Expiry | exp | Timestamp | Issuance + 2 years |
| Photo | photo | Binary | WEBP portrait (200x200px, ~900 bytes) |
| Face template | face | Binary | id3 format, 140 bytes fixed |
The photo is displayed on the IDToken card and consent screens. The face template is a mathematical representation of facial features used for 1:1 biometric matching — it is never displayed to the user.
UUID Authorization
Section titled “UUID Authorization”UUIDs create a binding between what a VDS represents (defined by the manifest) and who is allowed to create it (authorized by the signing certificate). This prevents an issuer authorized for one type of VDS from signing a different type.
During verification, the manifest’s UUID is checked against the certificate’s UsageList extension. If the UUID is not present, the VDS is rejected — even if the signature is mathematically valid.
Encoding and Carriers
Section titled “Encoding and Carriers”The assembled VDS binary can be encoded for different carriers:
| Encoding | Use case |
|---|---|
| Base45 | Primary encoding for IDToken QR codes (compact, URL-safe) |
| Base64 | Alternative encoding for API transport |
| Base32 | Compatibility with legacy systems |
| Raw binary | NFC or direct data transfer |
The encoded VDS is typically rendered as a QR code (Error Correction Level M) that the IDToken mobile app scans during enrollment.
VDS Revocation
Section titled “VDS Revocation”Individual VDS instances can be revoked independently of their signing certificate through VDS Revocation Lists (VRLs).
How It Works
Section titled “How It Works”Revocation Reasons
Section titled “Revocation Reasons”| Reason | Description |
|---|---|
| Key compromise | The signing key used for this VDS was compromised |
| Superseded | The VDS has been replaced by a newer instance |
| Cessation of operation | The issuer has ceased operations |
| Certificate hold | VDS temporarily suspended (can be reinstated) |
| Privilege withdrawn | The subject’s authorization was revoked |
Real-Time Status (VOCSP)
Section titled “Real-Time Status (VOCSP)”For time-sensitive verification, an OCSP-compatible protocol (VOCSP) provides real-time VDS status checking without downloading the full VRL.
Standards Alignment
Section titled “Standards Alignment”VDS implements the Electronically Signed Encoded Data Set (ESEDS) concept from ISO 22385:2023 — a framework for structured data sets that are cryptographically signed to ensure origin and integrity.
| Standard | What it defines |
|---|---|
| ISO 22376:2023 | VDS technical specification — data structure, encoding, cryptography, payload format |
| ISO 22385:2023 | ESEDS trust framework — governance roles, interoperability, trust hierarchy |
| ISO/IEC 15459-2 | Prefix format (IAC + CIN identifiers) |
| ISO 19785 | CBEFF biometric data format (used for face templates) |
ESEDS Roles Mapped to IDToken
Section titled “ESEDS Roles Mapped to IDToken”Verification Process
Section titled “Verification Process”When the IDToken auth server receives a VDS (during enrollment or authentication), it performs a multi-step verification:
For details on the PKI governance chain, see Trust Architecture. For how VDS credentials are created, see VDS Issuance.
Header Format Reference
Section titled “Header Format Reference”The VDS header (version 3) is 18, 19, or 21 bytes depending on payload size:
| Offset | Length | Field | Description |
|---|---|---|---|
0x00 | 1 | Marker | Always 0xDE |
0x01 | 1 | Version + length type | Bits 7-6: payload length type, Bits 3-0: version (3) |
0x02 | 2 | IAC | Scheme Operator identifier (3 C40-encoded chars) |
0x04 | 6 | Certificate reference | CA reference (4 chars) + Certificate ID (4 chars) + reserved |
0x0A | 3 | Manifest ID | Use-case identifier (hex) |
0x0D | 4 | Timestamp | Unix epoch UTC |
0x11 | 1, 2, or 4 | Payload length | Size depends on payload length type bits |
Prefix Identifiers
Section titled “Prefix Identifiers”| Identifier | Length | Description | Example |
|---|---|---|---|
| IAC (Issuing Agency Code) | 3 chars | Identifies the Scheme Operator | VDS (Otentik) |
| CIN (Company ID Number) | 3 chars | Identifies the deployment environment | EU5 (production), OT6 (POC) |
Signing Certificate Requirements
Section titled “Signing Certificate Requirements”Certificates used to sign VDS instances must meet specific requirements:
| Extension | Requirement |
|---|---|
| KeyUsage (critical) | digitalSignature + nonRepudiation |
| CertificatePolicies | At least one policy OID |
| AuthorityInfoAccess | id-ad-caIssuers for CA certificate retrieval |
| ExtendedKeyUsage | Should include VDSSigningEKU (OID 1.3.6.1.4.1.51528.2.2) |
| UsageList | Must contain the AuthorizedUsage UUID for each manifest the issuer is authorized to sign |
VDSIC OID Arc (1.3.6.1.4.1.51528)
Section titled “VDSIC OID Arc (1.3.6.1.4.1.51528)”| OID | Name | Purpose |
|---|---|---|
.1.1 | UsageList | SET OF UUIDs authorizing specific manifest types |
.1.2 | TrustedTimestamp | Header timestamp is reliable (skip current-time validation) |
.2.1 | TestCertificate | Certificate is for testing only |
.2.2 | VDSSigningEKU | Extended Key Usage for VDS signing |