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.