§ Tier 2 — Advanced

Advanced

You read the Quickstart. You need more control — a specific wallet whitelist, a specific response mode, a legacy policy name, or a webhook-based receipt handoff. This page covers the overrides available on POST /v1/sessions and the runtime feature flags, without drowning in OID4VP spec surface (that's Raw's job).

The useCase → policy mapping

The Quickstart hides the mapping. Here it is, in full. v1 (2026-04-24) supports 9 useCases across 4 jurisdictions.

useCase	Supported jurisdictions	Resolved policy
`age_verification_13_plus`	FR, EU, BYPASS	`av_age_13_plus`
`age_verification_16_plus`	FR, EU, BYPASS	`av_age_16_plus`
`age_verification_18_plus`	FR, EU, BYPASS	`av_age_18_plus`
`age_verification_21_plus`	FR, EU, BYPASS	`av_age_21_plus`
`mdl_age_verification_18_plus`	EU, US, BYPASS	`mdl_age_18_plus`
`nationality_verification_fr`	FR, EU, BYPASS	`nationality_fr`
`nationality_verification_eu`	FR, EU, BYPASS	`nationality_eu`
`residency_verification_fr`	FR, EU, BYPASS	`resident_fr`
`identity_verification`	FR, EU, US, BYPASS	`identity_valid`

Six combinations are explicitly unsupported (age-verification useCases are not mapped for US since no mdoc AV policy exists there; mdl_age_verification_18_plus is not mapped for FR since France does not issue ISO mDLs today). Unsupported combinations return 400 usecase_unsupported.

Pass debug: true on session creation to receive a _debug block in the response with the resolved policy, recommended variant, recommended wallets and the reason string.

Legacy policy parameter

The pre-#156 technical parameter policy is still accepted and will remain so. Use it when the business-level abstraction does not give you the granularity you need — for instance when targeting the ZK proof path (alpha, gated), the Google Wallet ID Pass, or internal test policies.

POST /v1/sessions
{
  "policy": "google_id_pass_age_18",
  "external_ref": "order_abc123"
}

policy and useCase are mutually exclusive. Passing both returns 400 invalid_request.

Full enum of accepted policy names : age_13_plus, age_16_plus, age_18_plus, age_21_plus (ZK path, gated by ZK_PATH_ENABLED), av_age_21_plus (mdoc EU AV blueprint), mdl_age_18_plus (ISO 18013-5 mDL), google_id_pass_age_18 (Google Wallet), nationality_eu, nationality_fr, resident_fr, identity_valid (PID attribute checks).

Credential formats

Each built-in policy declares which credential formats it supports (sd-jwt-vc, mso_mdoc, or both). Tessaliq negotiates the format at OID4VP request time based on what the wallet accepts.

mdoc AV policies (av_age_*) — mso_mdoc only, profile eu.europa.ec.av.1
mDL / Google ID Pass — mso_mdoc, ISO 18013-5 namespace
PID attribute checks — sd-jwt-vc only, credentialType eu.europa.ec.eudi.pid.1
ZK path (age_*) — sd-jwt-vc, requires BN254 field nonce

Response modes and variants

Tessaliq supports four OID4VP response modes. The default is decided per-request based on the client context and policy.

direct_post — plain form-encoded POST. ARCOM profile lock (eu.europa.ec.av.1) forces this mode.
direct_post.jwt — signed JWT response. Default for PID SD-JWT-VC / HAIP.
dc_api / dc_api.jwt — W3C Digital Credentials API browser-native flow (Chrome and Safari). Auto-selected when the SDK detects navigator.credentials.get with DC API support.

HAIP mode can be enabled globally via HAIP_CLIENT_ID_PREFIX=x509_hash (flips client_id scheme from x509_san_dns:… to x509_hash:<hash>). Tessaliq passes HAIP 1.0 Final conformance on four OIDF plans — see the Compliance page for the public test plan IDs.

Webhook vs frontend callback: receipt authenticity

The receipt JWT returned by the SDK callback is authentic — it's signed ES256 by Tessaliq. But for compliance logs you should treat the frontend callback as informational and rely on a server-to-server webhook for authoritative recording.

Register a webhook URL via POST /v1/webhooks (contact support to enable webhook delivery during Alpha). Tessaliq will POST the signed receipt to your URL when a session transitions to verified or failed. Your backend verifies the receipt's ES256 signature against the public JWKS endpoint and stores it in your audit log.

The JWKS is at https://api-staging.tessaliq.com/.well-known/jwks.json. Downloading it once and pinning the keys in your verifier removes the need to call Tessaliq on every verification.

Runtime feature flags

Exposed via environment variables, effective across all sessions for a given Tessaliq deployment. Contact support if you need a dedicated instance with a custom flag profile.

ZK_PATH_ENABLED (default: false) — gates the Noir ZK circuit path. When false, policies age_* return 503 zk_path_disabled. mdoc AV policies are unaffected. Currently disabled in production pending the Barretenberg March-2026 security fix and the Noir 1.0 migration.
HAIP_CLIENT_ID_PREFIX (default: x509_san_dns, also accepted: x509_hash) — switches the JAR client_id scheme.
OIDF_CONFORMANCE_MODE — enables test hooks used only by the OpenID Foundation conformance suite. Off in production.

Read Raw → Back to Quickstart