Certificate signing requests can now include your organization's name, organization identifier (such as VATPL-66312312312) and organizational unit. You can also add DNS names, email addresses and URIs as subject alternative names.

Add them when you create a certificate signing request, or set them over the API. See organization details and subject alternative names.

You can now add your EUDI registration to a presentation template. Your registrar issues an access certificate, which says who you are, and an EU Registration Certificate (ETSI TS 119 475), which says what you are registered to request. Next to it, the registrar dataset tells the wallet where to look up your registration. Paradym validates both against your access certificate and sends them with every OpenID4VP request created from the template, in the verifier_info parameter.

Add them in the new EU Registration section of a presentation template, or set eudi.registrationCertificate and eudi.registrarDataset over the API. They are available from the Builder tier, for templates requesting SD-JWT VC or mDoc credentials. See the presentation templates guide for the details.

d-you, the German EUDI Wallet, now requires a registration certificate to verify its PID. The d-you guide is updated to show how to get one from the German Sandbox registrar and add it to your template.

This feature is experimental and may still change. Existing templates are unaffected.

Presentation templates can now define transactions the holder must explicitly authorize when presenting, such as a payment or a document signature. The wallet signs the transaction data into the key binding of the presented credential, cryptographically binding the presentation to that exact transaction.

To use it, give the signing credential of a presentation template an id and add a transactions array with the transaction type, the credentialIds that may authorize it and the attributes each request must supply. You can also configure transactions in the dashboard template builder. When creating a verification from that template, pass the transaction values in transactionData. The verification resource returns the encoded and decoded entries from creation, and the credential that signed each entry once verified.

Transactions are only supported with OpenID4VC version v1 and sd-jwt-vc signing credentials.

Every credential of a presentation template now has an id: the one you set, or a random one assigned by Paradym. Existing templates have ids assigned. Each presented credential of an OpenID4VC or DIDComm verification now returns the id of the template credential it was requested for, and its type.

See the presentation templates documentation and the create verification API.

did:cheqd (both did:cheqd:mainnet and did:cheqd:testnet) is deprecated and will be removed from Paradym in two steps:

• December 1, 2026: new cheqd DIDs can no longer be created. Existing cheqd DIDs keep working.
• March 1, 2027: cheqd support is removed. Credentials can no longer be issued, revoked or verified with a cheqd DID.

We recommend migrating to did:webvh (AnonCreds and SD-JWT VC) or X.509 certificates (SD-JWT VC). Wallets with a cheqd DID show a warning in the dashboard, and their DIDs are marked as deprecated under Trust → Identifiers. Owners of these wallets will also get an email.

The did:cheqd deprecation guide explains how to check whether you are affected and how to migrate. Still depending on did:cheqd? Contact us and we'll help you plan the migration.

Paradym can now act as an OpenID Provider, so an application that already speaks OpenID Connect can verify a credential from the user's wallet, to sign them in or for any other check. The wallet owner registers an OAuth client under Settings → OAuth Clients, adds the scopes it may request, each verifying with a presentation template, and your application redirects users to Paradym: they present a credential and your application gets back an ID token with the verified attributes. The Verification with OpenID Connect guide has the full setup, and the OAuth clients endpoints are in the API reference.

These features are experimental and may still change.

OpenID4VP redirect flow

Sign-in is built on this, but it stands on its own: any OpenID4VC verification request can opt into a redirect flow by providing a redirectUri and a client-generated challenge. The wallet then returns the user-agent to your application, which finishes by exchanging the challenge for the result rather than polling or waiting for a webhook. That exchange is what binds the result to the device that presented. It is opt-in and non-breaking, but adds a pendingRedirect verification status and an openid4vc.verification.pendingRedirect webhook event, so add a branch if you switch exhaustively on status. See the redirect flow guide.

Restricting the flows a presentation template allows

Presentation templates now carry openId4Vc.allowedFlows. Restrict it to sameDevice and every OpenID4VC request created from that template must use the redirect flow, moving the decision from each caller to the template, where the policy belongs. Leave it out to place no restriction, so existing templates are unaffected. See the presentation templates guide.

New guide: assurance level and security model

A new guide on choosing the right assurance level and security model covers how your effective assurance depends on the protocol features you enable, the issuers you trust and the credential itself, and recommends a concrete high-assurance setup based on the OpenID4VC High Assurance Interoperability Profile.

Paradym now retries a webhook when your server does not respond with a 2xx status code within 5 seconds. A failed webhook is retried 10 times over about 3 days, starting with retries a few minutes apart. Previously it was sent only once.

Every attempt sends the same message with the same webhookId, a new X-Paradym-Webhook-Delivery-Id header identifies the webhook sent to your endpoint, and a new X-Paradym-Webhook-Attempt-Id header identifies each attempt. A webhook can now reach you more than once. Use webhookId to skip webhooks you have already processed.

Webhooks with verification data (openid4vc.verification.data and didcomm.verification.data) are retried too, but only within 15 minutes, because Paradym keeps the credential data no longer than that. See verification data access for how the options compare.

You can also see every webhook sent to an endpoint with the result of each attempt, and resend webhooks that failed, using the new webhook delivery endpoints. See timeouts and retries for how it works.

Retries are on for every webhook, and there is nothing to set up.

Paradym now maintains common trusted entities for popular ecosystems and keeps them up to date, so you no longer have to collect issuer certificates or trust lists yourself. Link one to a presentation template like any of your own trusted entities.

Find them on the Trusted Entities page or through the API. See the common trusted entities docs for details.

To use EUDI lists of trusted entities (LoTEs) defined in common trusted entities, you must be on a paid tier.

The pre-made Proof of Age template in the dashboard now contains only age_over_18 and age_over_21. The EU Age Verification profile allows no other attributes in this credential, and France Identité's Proof of Age credential no longer contains issuing_country or expiry_date. The France Identité guide and the Proof of Age example templates are updated to match.

If your presentation template for Proof of Age (eu.europa.ec.av.1) requests issuing_country, expiry_date, issuing_authority, age_in_years or age_birth_year, remove those attributes. Wallets that follow the profile, such as France Identité, can't answer a request for them.

Certificate signing requests of type verifierSignRequest now expose an openId4VpX509SanDns capability. It is enabled by default and, as before, includes a subjectAlternativeName DNS entry in the request that the imported certificate must carry. Disable it to import a certificate signed by a registrar that strips the entry, such as the German EUDI Wallet Sandbox. Such a certificate can still sign OpenID4VP requests using the x509_hash client identifier (OpenID4VP v1), but not the x509_san_dns client identifier (used by the legacy OpenID4VC version).

You can toggle the capability in the dashboard when creating a certificate signing request, or set capabilities.openId4VpX509SanDns through the API. See the certificate capabilities docs for details.

You can now download a certificate signing request (CSR) directly as a .pem file from the dashboard. Open the request's ⋯ menu in the My Certificates list under the "Trust" tab and use Download request. This makes it easy to upload the CSR to certificate issuers that expect a file, such as the German EUDI Wallet Sandbox registrar.

The Copy public key option has been removed, as the German EUDI Wallet Sandbox registrar now accepts the certificate signing request directly instead of a raw public key. See the certificates guide for details.