Building on Trusted Wallets, you can now require a key attestation when issuing a credential. A key attestation lets the wallet provider vouch for how the credential's key is protected, so you can limit issuance to keys that meet certain security requirements — as long as you trust the wallet provider.

Add a keyAttestations object to an SD-JWT VC or mDoc credential template (or use the new Key Attestation section in the credential template editor). Its presence means a key attestation is required, and you can optionally constrain two ISO 18045 levels:

{
  "trustedWallets": ["<trusted-entity-id>"],
  "keyAttestations": {
    "keyStorage": ["iso_18045_high"],
    "userAuthentication": ["iso_18045_moderate"]
  }
}

• keyStorage — the required attack potential resistance of the key storage.
• userAuthentication — the required resistance of the user authentication protecting the key.

Both lists are optional (you can require an attestation without constraining the levels), and levels are compared hierarchically so a stronger attested level satisfies a weaker requirement. Because the attestation signer is verified against your trusted wallets, keyAttestations requires at least one trustedWallets entry on the template.

This is non-breaking: templates without keyAttestations are unaffected and do not require a key attestation. See the Key attestations documentation for details.

You can now limit which wallets are allowed to receive a credential during issuance, using OpenID4VCI wallet attestations. This mirrors how trusted issuers already limit who can issue a credential during verification, and reuses the same Trusted Entities.

Trusted entity types

Every DID, X.509 certificate and ETSI LoTE on a trusted entity now has a type: issuer (the default, existing behaviour) or wallet. Issuer entries are used to trust the issuer of a credential during verification; wallet entries are used to trust the wallet during issuance. In the dashboard you can pick the type when adding a DID or certificate to a trusted entity.

Paradym also now supports the EU Wallet Providers List LoTE profile. Its type is inferred automatically as wallet, and credential types do not apply to it. Existing issuer LoTEs and trusted entities are unaffected — everything defaults to issuer.

Trusted wallets on credential templates

SD-JWT VC and mDoc credential templates now accept a trustedWallets field: a list of trusted entity ids whose wallet-typed entries are allowed to receive the credential. Set them via the API when creating or updating a template, or from the new Trusted Wallets section in the credential template editor. When reading a template, request ?include=trustedWallets to get the linked entities back in the response.

When trusted wallets are configured, a wallet attestation is required during issuance and must be signed by one of the trusted wallet providers, otherwise issuance is rejected. When none are configured, any wallet can receive the credential, so this is a non-breaking change. If a credential offer bundles multiple credentials, their trusted wallets are intersected — a wallet is accepted only if its provider is trusted by every credential in the offer that restricts wallets.

When a trusted-wallet credential also uses an Authorization Server, the wallet is trusted through its attestation, so issuance is gated by that attestation and the Authorization Server's redirect URI allow-list is not enforced.

See the Trusted Entities documentation for details.

You can now use the did:webvh DID method when signing credential and presentation templates, alongside the existing did:web and did:cheqd methods.

Select did:webvh when configuring the signing DID for a credential or presentation template. If the DID does not exist yet, Paradym creates and hosts it for you, just like did:web. See How it works for more information.

Credential offers, presentation requests and DIDComm invitations now include direct deeplink URIs in their API responses, alongside the existing universal-link based offerUri / authorizationRequestUri / invitationUri.

Until now these URIs pointed to a Paradym (or custom wallet) invitation page, which then deeplinks into the wallet. In some flows you might want to directly link into the wallet outside of the Paradym invitation page.

The new fields give you the raw scheme directly:

• OpenID4VC issuance offer: offerDeeplinkUri (openid-credential-offer://…) and offerDeeplinkQrUri
• OpenID4VC presentation request: authorizationRequestDeeplinkUri (openid4vp://…) and authorizationRequestDeeplinkQrUri
• DIDComm invitation: invitationDeeplinkUri (didcomm://…) and invitationDeeplinkQrUri

The …DeeplinkUri fields are plain deeplink strings you can place behind a button or render into your own QR code. The …DeeplinkQrUri fields return a QR code image (like the existing …QrUri) whose contents are the deeplink instead of the universal link.

These fields are additive and non-breaking, existing integrations keep working unchanged. See Issue credentials and Verify credentials, or the API Reference for more information.

EU Lists of Trusted Entities (LoTEs) are now available starting from the Builder tier, instead of requiring the Pro tier.

You can now point a trusted entity at a LoTE URL and let Paradym fetch, validate, and keep the list of trusted issuance and revocation certificates up to date automatically, on any Builder plan or higher. Configure it under Trusted Entities or via the API.

No action is required. Existing projects on the Builder tier immediately gain access to this feature.

Paradym can now verify the PID and EEAs from the German EUDI Wallet, as well as issue EAAS.

• ETSI LoTEs of the EU PID Providers List type now cover any SD-JWT VC credential type within the urn:eudi:pid: namespace, so the LoTE is used automatically when verifying a country-specific PID type such as Germany's urn:eudi:pid:de:1. The German test trust list can now also be imported.
• As a temporary workaround for the German EUDI Wallet rejecting DCQL queries that contain trusted_authorities, Paradym omits trusted_authorities from the query when an OpenID4VP request is signed with an Access Certificate issued by the German Sandbox registrar. This may change at any point in the future. The configured trusted issuers are still fully validated by Paradym when the presentation is received.
• You can now copy the public key of a certificate signing request from the dashboard. This makes the registration in the German EUDI Wallet Sandbox Registrar easier. Under My Certificates in the "Trust" tab, open the ⋯ menu of a request and choose Copy public key to copy its SPKI PEM (-----BEGIN PUBLIC KEY-----). The existing Copy request option still copies the full PKCS#10 request.

To verify the German PID, configure a trusted entity with the German test trust list and request urn:eudi:pid:de:1 in your presentation template.

When configuring an ETSI LoTE with custom credential types (e.g. an EU Public EAA Providers List), each credential type can now be an exact or a starts-with match. A starts-with matcher covers every credential type sharing a prefix, which is useful for namespaces where multiple types are registered (for example the urn:eudi:pid: namespace for SD-JWT VCs).

In the dashboard, pick Exact or Starts with from the dropdown next to each credential type when editing a trusted entity's LoTE (Trusted Entities). From the API, pass an object { "type": "startsWith", "value": "urn:eudi:pubeaa:custom:" } instead of a plain string in credentialTypes. This change is backwards compatible: existing exact string matchers keep working.

Not possible to provide credentialTypes for known LoTE types

For LoTE types where the credential types are determined automatically (e.g. EU PID or mDL Providers List) it is not possible anymore to provide custom credential types. All LoTE entries on a Trusted Entity now return the LoTE type (pidProvider, pubEaaProvider, mdlProvider), and only pubEaaProvider LoTE entries are allowed to provide custom credential types.

When fetching an ETSI List of Trusted Entities (LoTE), Paradym now extracts certificates from each entity's Revocation services in addition to its Issuance services.

This means a credential issued by a LoTE-listed provider whose status list is signed by a separate revocation authority is now verified correctly, including its revocation status, as long as both certificates are published in the same LoTE. No action is required; existing LoTE-backed trusted entities pick this up automatically.

When you revoke a credential, Paradym updates and re-signs the status list that tracks its revocation state. Previously this could happen even when the status list was signed by an expired certificate, producing a status list with an invalid signature. Revocation now validates the issuer certificate first and ensures its not expired.

Paradym now automatically generates and hosts an SD-JWT VC Type Metadata document for your SD-JWT VC credential templates. Wallets and verifiers can dereference a credential's vct (type) URL to retrieve a JSON document describing the credential's display information and claim structure, so they can render and validate credentials without relying on the OpenID4VCI issuance flow.

When you create or update an SD-JWT VC template with a Paradym-generated vct URL, Paradym builds the Type Metadata document from the template (name, description, branding, attributes and localization) and serves it at the vct URL. The document is re-published every time the template is saved, so it always stays in sync — including localization, which now flows into the metadata's display arrays.

If you supply your own custom vct, Paradym does not publish the document for you, but you can still retrieve the generated metadata to self-host it — either from the new Type Metadata section on the template detail page in the dashboard, or via the new API endpoint GET /v1/projects/{projectId}/templates/credentials/sd-jwt-vc/{credentialTemplateId}/type-metadata (see the API Reference).

Learn more in the new Credential Metadata guide.