Trust and production

Trust in LutraID today is anchored in a single platform CA that LutraID operates. Every issuer and verifier gets a leaf certificate under it, and relying parties must install its root out of band.

How signing keys are anchored

Each issuer and verifier is issued an EC leaf certificate from the LutraID platform root. Issuer leaves carry the credential_issuer URI in their SANs; verifier leaves carry the verifier resource URI and its DNS name — which is what makes the x509_san_dns: and x509_hash: client identifiers resolvable.

Following the ARF, the self-signed root is stripped from every outbound x5c and COSE x5chain. A wallet therefore cannot bootstrap trust from the credential alone.

GET/v1/trust/platform-root-ca

Installing the root

Editions: Public

curl -s "$LUTRAID_API/v1/trust/platform-root-ca"
# { "certificate": "-----BEGIN CERTIFICATE-----\n…" }

Unauthenticated, returns PEM. On SaaS and self-hosted deployments the root is distributed through the admin console instead.

Not available yet

Plan around these — none of them are implemented:

EU trusted lists, LOTL, VICAL, IACA registriesnot implemented
Registering an external CA or uploading your own rootsnot implemented
Revocation status listsnot implemented
Wallet key attestationpolicy field only, not validated
DID methodsnot implemented
mTLS sender-constrained tokensnot implemented

Assurance profiles accept trustPolicy and issuerCertificateMode values, but the evaluator currently only emits warnings — it never rejects.

Before going live

Give every relying wallet the platform root, keep signing keys in KMS (KEY_BACKEND=aws_kms; demo mode refuses to start with it), and confirm which edition your deployment runs — the route set differs.

Was this page helpful?