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.

The expiration for OpenID4VP requests has been increased from 2 minutes to 5 minutes.

The increased expiration time helps prevent failed presentations due to the user taking a bit longer to go through the presentation flow.

You can now issue SD-JWTs via OpenID4VC with X509 certificates!

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

When creating an SD-JWT credential template, you will now be able 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 SD-JWT credentials.

The mDOC debugger now shows a document selector if a DeviceResponse contains multiple mDOCs. Previously only the first document was selected.

We have also improved the error handling for the mDOC and SD-JWT VC debuggers, showing the internal error message if the parsing failed. Since the tool is used for debugging, it makes sense to display the internal error message.

Try it out in our mDOC debugger or SD-JWT VC debugger.