Tessaliq

How it works

A plain-language walkthrough of what happens when Tessaliq verifies an identity attribute — the actors, the protocols, the cryptography and what Tessaliq does not do. Intended for developers, architects and technical-minded prospects who want to know before integrating.

The four actors

A verification flow always involves the same four parties: 

flowchart LR
    U([User]) ---|holds credentials| W([Wallet])
    U ---|initiates verification| RP([Relying Party SaaS])
    RP <-->|OID4VP / DC API| W
    RP -->|verification request| T[Tessaliq verifier]
    T -->|signed receipt| RP
    T -.->|validates against| TA[(Trust anchors / IACA / JWKS)]
    classDef actor fill:#18181b,stroke:#52525b,color:#f4f4f5
    classDef core fill:#27272a,stroke:#a5b4fc,color:#f4f4f5
    class U,W,RP actor
    class T core

The diagram above is logical. In practice Tessaliq runs as an API that the RP calls server-side, plus an optional Web SDK that runs in the user's browser to coordinate with the Digital Credentials API.

The OpenID4VP flow

OpenID for Verifiable Presentations (OID4VP 1.0 Final) is the standard protocol Tessaliq uses to request and receive a presentation from a wallet. Here is a full sequence. 

sequenceDiagram
    autonumber
    participant RP as Relying Party
    participant T as Tessaliq API
    participant U as User browser
    participant W as EUDI Wallet

    RP->>T: POST /v1/sessions (policy)
    T-->>RP: session_id + request_uri
    RP->>U: redirect / QR with request_uri
    U->>W: open request_uri
    W->>T: GET signed Authorization Request JWT (JAR)
    T-->>W: request object (policy, claims, nonce)
    W->>W: user consents, selective disclosure
    W->>T: POST vp_token (OID4VP response)
    T->>T: verify signature, trust chain, nonce, disclosures
    T->>T: persist session state: verified
    RP->>T: GET /v1/sessions/{id}
    T-->>RP: state + signed receipt (JWT ES256)
    RP->>RP: verify receipt offline via published JWKS

Two details matter:

The Digital Credentials API flow

The W3C Digital Credentials API (DC API) is the newer browser-native path, available in Chrome (behind a flag in Chrome 128+) and Safari 26+. Instead of redirecting the user to their wallet via a deep-link, the browser itself brokers the request. 

sequenceDiagram
    autonumber
    participant RP as Relying Party (SaaS)
    participant W as User browser
    participant T as Tessaliq API
    participant Wal as EUDI Wallet

    RP->>T: POST /v1/sessions (policy)
    T-->>RP: session_id + DC API request object
    RP->>W: invoke navigator.credentials.get(digital)
    W->>Wal: OS-level credential chooser
    Wal->>W: user selects credential, consents
    W-->>RP: encrypted response (JWE)
    RP->>T: POST /v1/openid4vp/response (JWE payload)
    T->>T: decrypt with HPKE, verify inside, mark verified
    RP->>T: GET /v1/sessions/{id}
    T-->>RP: state + signed receipt

The DC API path uses HPKE (RFC 9180) for the end-to-end encryption of the presentation: the wallet encrypts the response with an ephemeral key derived for the session, and only the Tessaliq API can decrypt it. Even the RP's own frontend never sees the cleartext credential.

Cryptography summary

Tessaliq keeps the crypto stack narrow and standard:

No custom crypto, no unreviewed primitives. Everything chains to public standards that a security auditor can review against ISO, IETF and OpenID specs. Tessaliq publishes its full list of supported standards and their OIDF conformance plans.

Trust chain — where confidence comes from

"Trusting" a credential presentation means chaining the signature back to a known authority. Tessaliq supports two trust models in parallel: 

flowchart TB
    subgraph mdoc[mdoc ISO 18013-5 X.509 chain]
        IACA[IACA root e.g. France Identite IACA] --> DS[Document Signer Certificate]
        DS --> C1[mdoc credential signed by DS]
    end
    subgraph sdjwt[SD-JWT-VC JWKS]
        REG[Trusted Issuer Registry JWKS endpoints] --> IK[Issuer public key]
        IK --> C2[SD-JWT-VC credential signed by issuer]
    end
    T[Tessaliq verifier] --> IACA
    T --> REG
    style T fill:#27272a,stroke:#a5b4fc,color:#f4f4f5

When the EU rolls out production wallets under eIDAS 2, the authoritative source shifts to the ETSI Trusted List published through the eIDAS Dashboard. Tessaliq will consume that list rather than shipping bundled certificates once that channel is stable.

The signed receipt

Every successful verification produces a compact JWT receipt, signed ES256 with a key whose public JWKS is exposed at /v1/keys/jwks. The RP can verify the receipt offline without calling Tessaliq again — useful for long-term audit storage.

Sample payload:

{
  "iss": "https://api.tessaliq.com",
  "sub": "session:c358892b-7399-4c72-ac43-ac5a6b42528a",
  "iat": 1776436542,
  "exp": 1776440142,
  "policy": "av_age_18_plus",
  "verified": true,
  "proof_hash": "sha256:9b3f2e...",
  "org_id": "3728fa54-6c70-4a60-8a63-87b1da5514b5",
  "credential_format": "mdoc",
  "attestation_provider": "mock://staging"
}

Concretely : a CNIL or ARCOM auditor asking for proof of verification receives a cryptographic artefact, not a request log. The proof_hash binds the receipt to the exact presentation that was verified, so replaying a past receipt on a new session is detectable.

What Tessaliq does not do

Scope clarity, plainly stated:

Next — integrate

If you want to see how to wire this into your own SaaS, head to integration. For the full list of supported standards and public OIDF conformance runs, see compliance.