ceven

Paradym

Issues verifiable credentials to users, verifies identity claims against trust registries, and automates the lifecycle of digital proofs within your app.

Try Paradym in Ceven

Ask Ceven anything
Standard

Why use Ceven?

  1. AI native Paradym integration

    • Describe the outcome and Ceven picks the right Paradym calls, fills the parameters, and checks the result.
    • Structured, agent friendly tool schemas so each call runs reliably instead of by guesswork.
    • Rich coverage for reading, writing, and querying your Paradym data, across all 69 of its actions.

  2. Managed auth

    • Built in OAuth with automatic token refresh and rotation.
    • One place to manage, scope, and revoke Paradym access.
    • Per user and per environment credentials instead of shared keys.

  3. Agent optimized design

    • Actions are tuned from real success and error rates so reliability climbs over time.
    • Full execution logs so you always know what ran in Paradym, when, and on whose behalf.
    • The agent pauses and asks when Paradym is unclear instead of plowing ahead.

  4. Enterprise grade security

    • Fine grained access so you control which agents and people can reach Paradym.
    • Least privilege by default, read scopes first and only the writes a workflow needs.
    • A full audit trail of every Paradym action to support review and sign off.

Supported tools

Every action Ceven's agents can run on Paradym, and when to use it.

Issue credential
Use this when a user meets requirements and needs a signed verifiable credential issued to their wallet.
Verify proof
Validate a presented credential proof against the issuer registry to ensure it is authentic and current.
Revoke credential
Invalidate a specific credential by updating the revocation list. Use this when a user status changes.
Get credential status
Pull the current state of a credential to check if it is active, expired, or revoked.
Create schema
Define the structure and fields for a new type of verifiable credential before issuing it to users.
List issued credentials
Pull a list of all credentials issued by the organization, optionally filtered by schema type.
Get issuer metadata
Pull the public keys and endpoint configuration for a specific identity issuer.
Search credentials
Query issued credentials by user identifier or specific metadata tags.
Update schema
Modify an existing credential schema to add new attributes for future issuances.
Generate proof request
Create a request for specific attributes that a user must present to satisfy a verification check.
Delete credential
Permanently remove a credential record from the management console.
Get registry state
Pull the current state of the decentralized identifier registry to verify root trust.

12 actions · scroll to see them all

Frequently asked questions

Ceven never sees or stores your private signing keys. Paradym manages the cryptographic keys within its own secure hardware security modules or your chosen KMS. When Ceven triggers an issue credential action, it sends the request to the Paradym API, which signs the credential internally and returns the signed object. The workflow agent only handles the metadata and the resulting verifiable credential string. This architecture ensures that even if a workflow is compromised, the underlying root of trust remains secure within the Paradym vault, as the agent has no ability to export keys or sign arbitrary data outside the defined API scope.
Yes. Ceven is designed to be agnostic to the underlying credential standard used by Paradym. If your workflow requires selective disclosure, the agent uses the SD JWT endpoints to request only the necessary fields. For high privacy requirements where zero knowledge proofs are needed, the agent leverages the AnonCreds over DIDComm path. You can mix and match these standards within a single workflow. For example, you can issue an SD JWT for a basic user profile but require an AnonCreds proof for a high value financial transaction, and Ceven will handle the different request and response formats automatically.
Ceven implements a robust retry logic with exponential backoff for all Paradym verification calls. If the API is unreachable, the agent can be configured to either fail closed, which denies access until verification is successful, or fail open, which allows a temporary grace period. You can define this behavior in the workflow settings. If the failure is due to a malformed proof rather than a system error, Ceven captures the specific error code from Paradym and can trigger a user facing notification asking the person to re upload their credential or check their wallet app.
Absolutely. This is a primary use case for Ceven. You can connect Paradym to your HR system or CRM. For instance, if an employee status changes to terminated in Workday, Ceven detects that event and immediately calls the Paradym revoke credential action. This ensures that the digital identity is invalidated in real time across all relying parties. You can also set up time based triggers where the agent checks for expiring credentials every twenty four hours and sends a reminder to the user to renew their proof before it becomes invalid.
Yes. Paradym imposes strict rate limits on the issuance and verification endpoints based on your current subscription tier. For example, the starter tier has a lower threshold for requests per second compared to the enterprise tier. If a Ceven workflow triggers a bulk issuance for thousands of users at once, you may encounter 429 too many requests errors. To mitigate this, Ceven provides a batching mode for Paradym actions that queues requests and spreads them over a longer window to stay within your tier limits without crashing the workflow.
The trust registry acts as the source of truth for which issuers are trusted. When Ceven performs a verification, it does not just check the signature of the credential but also queries the Paradym registry to ensure the issuer is still valid and authorized. You can use Ceven to manage this registry by automating the addition or removal of trusted issuers based on your partner agreements. If a partner is offboarded from your ecosystem, a single workflow can remove their public key from the registry, instantly invalidating all credentials issued by that partner across your entire application.
Yes. Ceven can act as the bridge during a migration. You can build a workflow that pulls user data from a legacy SQL database, validates the information, and then uses the Paradym issue credential action to create a verifiable version of that identity. This allows you to move users over in batches. The agent can track who has been migrated in a separate table and provide a report on the progress. This avoids a big bang migration and lets you test the verification flow with a small subset of users before fully deprecating your old identity provider.
Verification requires access to the Paradym API or a cached version of the trust registry to check revocation lists and public keys. While the credential itself is held offline in the user wallet, the act of verifying it through Ceven happens in the cloud. If your use case requires truly offline verification, you would need to deploy the Paradym verification logic to an edge environment. Ceven can manage the deployment of those configurations, but the actual real time check of a presented proof will always require a network call to the registry or a locally hosted mirror of the trust data.

Alternatives to Paradym

Other tools that solve a similar problem. Ceven supports these too, so you can switch or run more than one at once.

Cheqd logoCheqdDock logoDockTrinsic logoTrinsic

Try Ceven on your stack

Plug Ceven on top of the tools you already run. Connect Paradym and the rest of your stack, describe the outcome, and its agents handle the work end to end, days of it in minutes.

Get started for free