Paradym now supports version 1 of the OpenID for Verifiable Credentials suite of specifications.

Existing projects will keep using the existent version (from now on called "legacy"), which is based on draft 21 of the OpenID for Verifiable Presentations specification, and drafts 11 through 14 of the OpenID for Verifiable Credential Issuance specification.

New projects will automatically be configured to use version 1. The OpenID4VC version can be changed on a per project basis in the dashboard under Settings → Profile. Old projects can also be upgraded by updating the configuration.

Upgrading to V1 of OpenID4VC is a one-time operation, and cannot be reverted. If migration is not possible but already want to use V1 you can create a new project. In the future all legacy projects will be migrated to V1.

Some notable changes when updating to V1 of OpenID4VC:

• Response encryption is enabled by default for OpenID4VP. Previously, this was only the case for when requesting mDOCs.
• SD-JWT VCs and associated Token Status Lists signed with X509 certificates do not include an iss field anymore.
• SD-JWT VCs, associated Token Status Lists, and OpenID4VP requests signed with an X509 certificate do not include the root certificate in the x5c header anymore to adhere to HAIP requirements.
• OpenID4VP requests signed with an X509 certificate now use the x509_hash client id prefix instead of the x509_san_dns to adhere to HAIP requirements.

Paradym now supports creating Certificate Signing Requests (CSRs) for externally signed certificates. This allows you to use certificates signed by external certificate authorities instead of only using root certificates created within Paradym.

The certificate signing requests are based on PKCS#10, a common format for requesting an external signature on a certificate.

Certificate signing requests can be created for both issuer (issuerSignCredential) and verifier (verifierSignRequest) leaf certificates through the API or dashboard. Once your CSR is signed by an external certificate authority, you can import the resulting certificate back into Paradym. Certificate signing requests are automatically removed after 30 days if no certificate has been imported.

To start using certificate signing requests, check out the Trust -> My Certificates tab in the Paradym dashboard, Create a certificate signing request through the API, or read more in the Certificates documentation.

Creating externally signed certificates is not available in the Free tier, and only available to the Pro and Custom tiers.

An issue has been fixed where mDoc credential templates where using revoked or inactive certificates.

All previously created mDoc credential templates have been updated to use an existent, active, issuer root certificate, if existent.

Project members must now accept an invitation before they are added to a project. This enhances security, and prevents users from being added to projects without their consent.

When you add a member to a project, either through the API or dashboard, an invitation email will be sent, requesting the user to join the project.

An invitation is valid for 7 days, and a total of three invitations can be sent to an user, after which you must wait for an invitation to expire.

To revoke an invitation before it is accepted, you can make a POST request to https://api.paradym.id/v1/projects/{projectId}/members/remove. See the API Reference for detailed usage information.

Note: It is still the case that only the owner of the project is able to add and remove members from a project.

To improve the security of Paradym, we now only accept requests from clients using TLS 1.2+. TLS 1.2 is supported by all modern browsers and clients, as well as iOS and Android versions.

If you are experiencing issues, or are not able to upgrade to TLS 1.2+ you can reach out to us in the Paradym Slack or by sending an email to contact@animo.id.

While Paradym already removed data as soon as possible for most record types, the verification sessions still contained the data from the credentials received in a verification indefinitely.

To better handle different data retention requirements we have added a new configuration option "Verification data access" (verificationDataAccess) to the project settings. The option currently has five options:

• webhook - only emit verification data as webhook
• once - only allow verification data to be retrieved once, with a limit of 15 minutes.
• 15min - only allow verification data to be retrieved for 15 minutes
• 1week (deprecated, see below) - only allow verification data to be retrieved for 1 week
• indefinite (deprecated, see below) - allow verification data to be retrieved indefinitely

For new projects the default is to emit verification data as webhooks (webhook), as we recommend to handle it through webhooks. If you can't rely on webhooks, we recommend setting the access to once (once) or for a maximum of 15 minutes (15min). This should give enough time to fetch the verification data from our API, before it is removed.

For existing projects, we have set the default to indefinite for now (indefinite), to allow for a smoother transition period. You should update your projects to use webhooks (recommended), once (recommend) or 15min.

If the verification data access is set to once, the verification data is only accessible through the "Retrieve verification session by id" endpoints, not through the paginated "Retrieve verification sessions" endpoint.

The 1week and indefinite options are deprecated and only introduced for migration purposes to the newer and shorter retention periods. These options will be removed in the future.

In all cases Paradym will still store the metadata about a verification session in the DIDComm or OpenID4VC verification session. The verification data retention option only covers the actual data from the credentials received in a verification. This includes the following attributes:

• presentedAttributes
• raw
• issuer
• holder

You can configure the data retention for your project in the dashboard under Settings → Project. The Verify Credentials guide has been updated with additional context on setting up and handling verification webhook events.

New verification data webhooks

To integrate with the new data access options, we have added two new verification data webhook events:

• didcomm.verification.data
• openid4vc.verification.data

These two webhook events are similar to their *.verification.verified event counterparts, however this event also contains the data from the credentials received in a verification.

If you're upgrading to handle verification data through webhooks, make sure listen to this event.

Configure webhook event types from dashboard

while you could already specify which event types to register for a specific webhook through the API, it's now also possible to configure this through the dashboard.

This makes it even easier to only listen for webhooks you need in your application, while also enhancing the performance and security.

You can find the new webhook configuration options in the dashboard under Settings → Webhooks.

To ensure Paradym is secure, stable and always available we have introduced additional network security policies on Paradym's cloud services. If you're using the API normally, you should generally not encounter any issues.

Make sure to read the new Network Security and Rate Limiting article in the documentation.

If you have any questions about the new policies you can reach out to us in the Paradym Slack or by sending an email to contact@animo.id.

You can now create multiple credential templates for the same credential type. This works for AnonCreds (reusing an existing schema), mDoc (using the same doctype) and SD-JWT VC (using the same VCT).

This enables you to have mulitple variants of the same credential type, which can be useful for e.g. using different templates and branding for different university diplomas, but still using the same credential type. It can also be useful when drafting up changes to a credential you're issuing, and creating a new template to not impact any issuance flows using the old template.

Example issuance templates for PID and mDL

The documentation has been extended with example issuance templates. Initially we have added the following credentials:

• Issue Person Identification Data (PID) as SD-JWT VC based on the EU Architecture Reference Framework.
• Issue ISO 18013-5 Mobile Driving License as mDoc based on ISO 18013-5.

Both templates also contain example payloads so you can easily use test your new credential template with the Paradym Wallet. Once you have created a credential template, you can also easily create a presentation template based on the credential template from within the dashboard.

If you want us to add specific credential templates, please let us know in the Paradym Slack!

The link contained within the QR code of the authorizationRequestQrUri now correctly includes the client_id and client_id_scheme parameters, resolving interoperability issues with the Paradym Wallet.

You can now issue mDOCs via OpenID for Verifiable Credentials, with X509 certificates!

Start by creating a new X509 root certificate for issuance in the "Trust" page within the dashboard, or using the Certificates API.

When creating an mDoc credential template, you will now need to select the X509 root certificate you created. The root certificate will automatically be used to generate document signing certificates for the issuance of the mDoc credentials.