Compliance & standards

Every specification Tessaliq implements, with a link to its public version, along with the external test results that are publicly verifiable.

Architectural rationale — verify, never store

Tessaliq is built on one invariant: the verifier never stores personal identity data. Not a hashed copy, not a derivative, not a « just in case » cache. The verifier receives a cryptographic presentation from the wallet, checks it against the policy, issues a signed receipt, and discards the presentation contents.

This is a deliberate design choice, not a feature. A single server-side database containing identifying information is, by construction, a single point of breach. When it is compromised, every record held in it is exposed at once — the operator did not need to misuse the data, the attacker did it for them. Every quarter brings a new example. The architectural response is to not build the database in the first place.

An EUDI-wallet-based verifier eliminates that vector. There is no central identity database to breach at Tessaliq. The user's credential stays in their wallet; only the derived attribute required by the Relying Party (for example age_over_18: true) crosses the network; the signed receipt seals the verification fact without the identifying payload. A compromise of the verifier leaks at most the policy catalog and session metadata (IDs, timestamps) — none of which identify a user.

The same property enables offline receipt verification: any third party can audit a receipt via the public JWKS, without access to a centralized identity store. See the interactive verifier to try it.

Protocols

• OpenID for Verifiable Presentations 1.0 Final — verifier side
  Spec
• High Assurance Interoperability Profile (HAIP) 1.0 Final
  Spec
• W3C Digital Credentials API — Chrome and Safari paths
  Working draft

Credential formats

• ISO/IEC 18013-5 — mdoc / mobile driving licence, with session transcript verification
  Part of the EU age verification blueprint.
• ISO/IEC 18013-7 1ed — online presentation of an ISO/IEC 18013-5 mDL.
• SD-JWT-VC — IETF draft, selective disclosure with optional key-binding JWT
  IETF draft
• eu.europa.ec.av.1 — European Age Verification profile
  Blueprint published by the European Commission for the seven pilot Member States (France, Denmark, Greece, Italy, Spain, Cyprus, Ireland).

Cryptography

• RFC 9180 HPKE — Hybrid Public Key Encryption, ECDH-ES + AES-128-GCM / AES-256-GCM, P-256 curve.
• JWE — JSON Web Encryption for Digital Credentials API response wrapping.
• ES256 — ECDSA P-256 signatures for verification receipts and JAR signing.
• X.509 SAN DNS / X.509 hash — dual-mode client ID prefix schemes for OID4VP JAR authentication.
• Noir / Barretenberg — zero-knowledge proofs for age verification (alpha).

OpenID Foundation conformance

All plans are immutable and publicly accessible on the OpenID Foundation certification site. Clicking a plan opens the full module list with pass/fail status per module.

Total: 24/24 modules passed, zero warning, covering the 2×2 matrix SD-JWT-VC + mdoc × standard + HAIP.

Self-certification statement

The OpenID Foundation launched self-certification for OpenID4VP 1.0, OpenID4VCI 1.0 and HAIP 1.0 on 26 February 2026. Tessaliq self-certifies conformance against the four plans listed above. The plans are immutable and independently verifiable on the OpenID Foundation test platform — anyone can click a plan link, read the module list, and confirm pass/fail status without contacting us.

Tessaliq has not submitted the plans for Foundation review yet (that step involves a per-specification fee and is planned post-SASU incorporation). The self-certification claim stands on the publicly verifiable immutable plans themselves.

Receipt verification

Every verification returns a signed JWT receipt that can be checked cryptographically by any third party — an auditor, a Relying Party, a regulator — using only the public JWKS endpoint. No need to call the Tessaliq API.

• Receipt specification — format, claims, signature, verification procedure, guarantees and limitations.
  Spec v1 draft
• Open-source verifier library — @tessaliq/receipt-verifier, MIT, offline-capable.
  Source
• Interactive verification — paste or drop a receipt JWT and check it in your browser.
  Verify a receipt ↗

Purpose & legal basis declarations (DPV)

Every Tessaliq verification policy carries a machine-readable W3C Data Privacy Vocabulary declaration: purpose, legal basis, retention. The declaration is exposed on GET /v1/policies so auditors can discover the privacy posture of every policy without running the verifier, and embedded as JSON-LD in every signed receipt so the posture is cryptographically attested per verification — not a free-text promise on a privacy page.

Tessaliq defaults: retention P0D (zero retention by design), legal basis LegalObligation (the relying party tells the verifier which obligation it acts under — typically ARCOM SREN for age verification, or AMLR Art. 24 for identity). Relying parties can override by configuring the policy.

Regulatory frameworks

• Regulation (EU) 2024/1183 — eIDAS 2.0, amending the eIDAS regulation for the European Digital Identity Framework.
• Commission Implementing Regulation (EU) 2025/848 — detailed rules for national registers of wallet-relying parties (Article 5c(8)).
• Commission Implementing Regulation (EU) 2026/798 — remote onboarding of users to European Digital Identity Wallets.
• EU Age Verification blueprint — `eu.europa.ec.av.1` profile, adopted by seven pilot Member States (FR, DK, GR, IT, ES, CY, IE).
• Loi SREN (France) — framework for age verification when accessing adult content online, supervised by the ARCOM.

External contributions

ENISA public consultation on the EUDIW Cybersecurity Certification Scheme — position paper submitted 2026-04-17 on the draft scheme v0.4.614 and the security requirements v0.5.614 (deadline 30 April 2026). Three recommendations around the scope exclusion of relying parties (Annex X, Note X.2.1, p. 91) and the collusion threat (TR84).