Fixed a bug in DCQL query building where a presentation template requesting multiple credentials could be satisfied with some of them missing. When one of the requested credentials was trusted by both a DID and a certificate, the remaining credentials ended up optional in the generated query, so a wallet presenting only that one credential could still reach a verified result.

The query now requires every requested credential (and, for a credential trusted by both a DID and a certificate, one of its two trust paths). No action is required: affected presentation templates now behave as intended.

The description of a presentation template is no longer required. When you leave it out, it is excluded from the generated DIDComm verification request or the DIF Presentation Exchange Definition.

Note that the description is not sent when using the v1 OpenID4VC version, as DCQL does not allow to define the purpose of the request.

You can create or update a presentation template without a description over the API, or leave the Description field empty in the dashboard. Existing templates are unaffected.

See presentation templates for details.

An issuer certificate or DID on a trusted entity can now be restricted to the credential types it is trusted for, using the new credentialTypes field (the same format ETSI LoTEs already use).

This is useful when one ecosystem signs different credentials under different roots or DIDs. Without a restriction, a trusted entity holding both a PID root and an attestation root also accepts a PID signed under the attestation root.

In the dashboard, add the types under Credential Types on a certificate or DID of a trusted entity.

See Restricting certificates and DIDs to credential types for details.

An ETSI LoTE that is disabled after repeatedly failing to refresh is now ignored when verifying presentations and when restricting issuance to trusted wallets. Previously the last successfully fetched entries of a disabled LoTE were still trusted.

Verifying an SD-JWT VC signed with an X.509 certificate no longer verifies the credential's iss claim against the signing certificate. Previously the iss had to match a SAN-URI or SAN-DNS entry in the certificate and had to be an HTTPS URI. These legacy checks rejected otherwise-valid credentials from external issuers whose certificates do not encode the issuer URL in a Subject Alternative Name, and mainly affected SD-JWT VC verification.

The certificate chain is still validated against your trusted issuers. No action is required: presentations that previously failed on an iss mismatch now verify.

Keys returned by the API no longer include the keyBackend string by default. On GET /v1/wallets/{walletId}/keys, request ?include=keyBackend to get it as an object with the backend's id, type, name and keyTypes, the same shape GET /v1/wallets/{walletId}/key-backends returns. This matches how the API's other relations, such as certificate, are included.

If your integration reads a key's keyBackend, add ?include=keyBackend and read keyBackend.type instead. The keys returned when deleting a key or cancelling its deletion don't include it; list the key to see its backend. To filter keys by backend, use ?filter[keyBackend.type]= instead of ?filter[keyBackend]=, with the same values. See Keys.

Credential and presentation templates that use a did:web or did:webvh issuer/verifier can now sign with a P-256 key instead of the default Ed25519. Pick this when a holder wallet or relying party requires P-256 (also called secp256r1/ES256).

In the dashboard, choose the key type from the issuer/verifier dropdown when creating a credential or presentation template. Over the API, pass the signer as an object with a keyType, for example issuer: { signer: "did:web", keyType: "P-256" } or verifier: { signer: "did:webvh", keyType: "P-256" }. Existing templates and the bare-string form ("did:web") keep signing with Ed25519, so nothing changes unless you opt in. did:cheqd remains Ed25519 only.

See issuing credentials and presentation templates for details.

You can now keep your certificates' signing keys in Google Cloud KMS. The keys are generated there and never leave it: every signature happens inside Cloud KMS. The leaf certificate derived from such a root uses Cloud KMS too, so your credentials are signed there as well.

• API: pass keyBackend: "gcpKms" when creating a certificate (POST /v1/wallets/{walletId}/certificates) or a signing request (POST /v1/wallets/{walletId}/certificates/csrs). GET /v1/wallets/{walletId}/key-backends lists the backends available to you.
• Dashboard: pick a Key Backend when creating a certificate or a signing request.

Cloud KMS keys must use P-256. They're available from the Builder tier upwards, with an allowance per tier and a monthly charge for each extra key. Nothing changes for existing integrations: software stays the default.

Read more in External Key Backends and Billing and Usage.

Downgrading your plan (for example from Pro to Builder) under Settings -> Billing failed without showing an error, and no downgrade was scheduled. This is fixed: the downgrade is scheduled again and takes effect at the end of your current billing period.

If a plan change fails in the future, the dashboard now shows an error message. If you tried to downgrade recently, try again. No other action is required.

Some wallets send a wallet attestation that fails verification, for example because it has expired. Previously this blocked issuance even when none of the offered credentials required a wallet attestation.

A wallet attestation is now only verified when a credential in the offer is restricted to trusted wallets. For other offers the attestation is ignored, so these wallets can receive the credential. No action is required.