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

Request

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

Unauthenticated, returns JSON whose certificate field contains the PEM.

Revocation

Credentials can be revoked and their status published to a Token Status List, served unauthenticated at GET /status-lists/{publicId}. A credential is only revocable if its issuance profile had credential status enabled at issuance — see Revoke a credential.

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
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, and confirm certificate posture and issuer-trust sources are set for production rather than left at their defaults — see Go live for the full operator checklist.

Was this page helpful?