How verifiable information moves between organizations.
Issuer, holder and verifier roles
Issuer
The issuer digitally signs the credential so another system can later verify who signed it and check that the signed information has not been altered.
Holder
The person, organization, system or AI agent that receives the credential and can present it elsewhere.
Verifier
The verifier checks the digital proof rather than manually checking a document or contacting the source every time.
Issuer
The issuer digitally signs the credential so another system can later verify who signed it and check that the signed information has not been altered.
Holder
The person, organization, system or AI agent that receives the credential and can present it elsewhere.
Verifier
The verifier checks the digital proof rather than manually checking a document or contacting the source every time.
Issuer
The issuer digitally signs the credential so another system can later verify who signed it and check that the signed information has not been altered.
Holder
The person, organization, system or AI agent that receives the credential and can present it elsewhere.
Verifier
The verifier checks the digital proof rather than manually checking a document or contacting the source every time.
Wallet functionality, built into the experience.
A digital wallet lets a holder receive, store and present verifiable credentials when another organization needs to check them.
That does not have to mean downloading a separate wallet app. Depending on the workflow, credentials can be managed through an existing mobile app or a cloud-based experience.
Truvera provides wallet infrastructure that can work behind those experiences, so organizations can make credentials available through the services people already use.
Verification proves who issued it. Trust rules decide who counts.
A valid credential can prove who issued it. But the recipient still needs to know whether that issuer is trusted for that information.
Truvera can support trusted ecosystems that define:
Share what is needed. Add stronger assurance when the workflow requires it.
Share only what is needed
Depending on the credential type and verification flow, the holder can share only the attributes needed for the interaction rather than an entire credential or record.
For example, a service may need proof of a required fact rather than a complete identity record.
Add assurance that the credential is being used by the intended person.
Some workflows also need stronger assurance that the credential is being used by the person it was issued to.
Where required, credentials can be bound to the intended holder. Biometric verification is one possible approach for higher-assurance workflows, but it is not required for every Truvera implementation.
The experience should fit the workflow, not the other way around.
Depending on the workflow, credential functionality can sit inside an existing mobile app, cloud-based experience or AI-agent environment.
Truvera can sit behind those experiences through:
Built to work beyond one system.
Truvera is built around open standards so verifiable information is not tied to a proprietary document format or a single application.
Depending on the workflow, Truvera supports standards and specifications from organizations including the W3C, OpenID Foundation, DIF and IETF.
