Truvera Documentation portal
WebsiteTruvera Workspace
  • Truvera overview
    • Decentralized identity explained
    • Roadmap
    • Subscription plans & billing
  • Solutions
    • Biometric-Bound Credentials
  • Truvera Workspace
    • Create an organization profile (DID)
    • Issue verifiable credentials
      • Filtering, downloading and deleting credentials
    • Verify credentials
    • Create a schema
    • Create a design
    • Team management
      • Inviting a team member
      • Removing a team member
      • Changing team member roles
      • Data retention policies
      • Sub-accounts
    • Revoking credentials
    • Ecosystem Tools
      • Ecosystem set up
      • Ecosystem example
    • Monetizing credentials
      • Setting up monetizable credentials
    • Creating API keys and webhook endpoints
    • Transaction history
    • Custom branded distribution emails
    • Truvera Workspace release notes
      • 2025 Release notes
        • Release notes Q1 2025
      • 2024 Release notes
        • Release Notes February 2024
        • Release Notes March 2024
        • Release Notes April 2024
        • Release Notes May 2024
        • Release Notes June 2024
        • Release Notes July 2024
        • Release Notes August 2024
        • Release Notes September 2024
        • Release Notes October 2024
        • Release notes November 2024
        • Release notes December 2024
  • Truvera API
    • Getting started
    • Webhooks
      • Webhooks API endpoints
    • Sample Postman collections
      • Issue-Store-Verify sample flow
      • Create ecosystems
      • Issue monetizable credentials
      • Create sub-accounts
      • Issue OpenID credentials
    • Truvera Swagger UI
    • DIDs
    • Profiles
    • Credentials
    • Presentations
      • Proof templates
      • Proof requests
      • Other proof endpoints
    • Registries
    • Revocation Status
    • Credential Schemas
    • Jobs
    • Templates
    • Sub-accounts
    • Teams
    • Messaging
    • OpenID
      • OpenID Issuance and Verification Integration Guide
    • iden3comm
    • Ecosystem Tools
      • Trust Registry Integration Guide
      • Creating a Trust Registry
      • Inviting participants
      • Verifiers and Public info
      • Trust Registry Schemas
      • Trust Registry Proof Templates
      • Reports
      • Updating and Deleting Trust Registry
    • Issuing paid credentials (KVAC algorithm integration)
    • Data
    • Verify
    • Keys
    • Schemas
  • System architecture
    • Proposed architecture with Truvera
    • Revocation
    • System scalability
    • Security policies
    • How data is processed and stored
  • Supported standards
    • Interoperability with OpenID
  • Credential wallet
    • Create and manage DIDs in the Truvera Wallet
    • White label wallet
      • Configuration
        • Enabling and Disabling Features
        • Customizing the Styling
        • Configuring for Android Builds
        • Configuring iOS Builds
      • Publishing in App Stores
        • Android Build Testing and Publishing
        • iOS Build Testing and Publishing
    • Wallet SDK
      • Getting started
        • Example Credential
        • Presentation definition
        • Verify credentials
      • Cloud wallet
      • Biometric plugin
      • Ecosystem Tools
    • Download Truvera Wallet
    • Truvera Wallet release notes
      • Release Notes 2025Q1
      • Release Notes 2024Q4
      • Release Notes 2024Q3
        • Release Notes September 2024
        • Release Notes August 2024
        • Release Notes July 2024
      • Release Notes June 2024
      • Release Notes May 2024
      • Release Notes April 2024
  • Open source community
    • Code of Conduct
    • Truvera Credential SDK
    • Blockchain archives
      • DOCK token
        • Migration terms and conditions
  • Support
    • System Status
    • Discord
    • Support services
    • Security policy
Powered by GitBook
On this page
  • What are biometric-bound credentials?
  • How user stored biometrics work
  • What is a biometric-bound credential?
  • How to implement biometric-bound credentials?
  • Samples taken by issuer and verifier approach
  • Samples taken by identity wallet approach
  • Privacy concerns and suggested solutions

Was this helpful?

Edit on GitHub
  1. Solutions

Biometric-Bound Credentials

PreviousSolutionsNextTruvera Workspace

Last updated 4 months ago

Was this helpful?

What are biometric-bound credentials?

Biometric is a a physical characteristic, e.g. eye, finger, face, voice, gait. When a person’s physical attribute is measured it is translated to something that can be stored - an enrollment template.

After the enrollment is complete, to match the biometric the physical attribute is measured again and translated to something that can be matched - a candidate sample. The sample is then matched with the template. The match score is compared with a threshold to return a positive or negative result.

There are different ways to store biometrics.

How user stored biometrics work

Relying parties use open standards to verify credentials issued by their trusted biometric providers. Relying parties never see biometric data.

1. Check the biometric and issue an enrollment credential containing the biometric data and a private identifier

2. Check the biometric against the enrollment credential and issue a biometric-check credential with the private identifier

3. Relying parties verify that a biometric-check credential is recent, trusted, and contains the expected private identifier

What is a biometric-bound credential?

Wallet-bound Credential - the credential was put into a wallet at issuance, and taken from the same wallet at verification. It is assumed that the same person is in control of the wallet at both times.

Biometric-bound Credential - the same person who received the credential at issuance presented the credential for verification.

We suggests 2 possible approaches on how to implement biometric-bound credentials and address these concerns.

How to implement biometric-bound credentials?

Samples taken by issuer and verifier approach

In this model the issuer and verifier agree on a common provider of biometrics.

Issuer requires holder to enrol in the biometric service and provide a biometric sample through the service before the issuer will issue a credential.

The issued credential contains a link to the biometric template.

At time of verification, verifier requires holder to provide a biometric sample through the same service and checks that it matches the template linked in the credential.

Pros
Cons

Can use biometric hardware provided by the issuer and verifier

Biometric service can correlate issuer, verifier, and holder *

Being outside of the holder’s control can mean it is more trusted

Every issuer and verifier needs to integrate with the biometric service**

*Some biometric services are designed to be privacy preserving

**Biometric standards can reduce cost of integration and lock-in

Samples taken by identity wallet approach

In this approach issuer asks the holder to provide a proof of biometric check before issuing a primary credential.

Identity wallet detects the request, processes biometric, enrolls the holder, issues a credential and provides the credential to the issuer.

Primary credential with biometric binding is issued by the issuer.

Verifier asks for primary credential with a proof of biometric check.

Wallet detects the request, processes biometric, and provides compound proof to the verifier.

Primary credential: the credential which contains the attributes of interest to the verifier in addition to the biometric binding attributes

Biometric Enrollment

Holder sets up a wallet integrated with the biometric service. When a biometric binding is first required, the holder wallet enrolls the holder in the biometric service.

The biometric service issues a credential that generally contains at least the following attributes:

  1. An attribute that contains the enrollment template - the reference biometric sample that is stored during enrollment to which future biometric samples are compared

  2. Attributes that can be embedded in primary credentials to bind them to valid biometric verification credentials issued to the same holder

Biometric data needs to be converted to a text based format so it can be embedded in JSON. The most popular method is to use "Base64" encoding.

A sufficiently privacy preserving biometric template can be embedded directly in the primary credential, avoiding the need for an enrollment credential.

The biometric enrollment and initial verification credentials may be issued using the same biometric sample to avoid an additional sample being taken from the holder.

The biometric binding attributes can usually be a smaller size than embedding the biometric template directly in a credential.

The enrollment credential contains the PII that would previously be stored in the BSP’s database.

Issuance

Holder requests a primary credential from the issuer. Issuer requests a proof of a recent biometric check.

The holder’s identity wallet detects that the request includes biometric binding attributes, and triggers the associated plugin that requests a biometric verification credential from the biometric service.

Biometric service requests to verify the biometric enrollment credential. Biometric service checks a new biometric sample against the template included in the enrollment credential. Biometric service issues a credential showing a valid biometric check, that contains the biometric binding attributes and a timestamp of the check.

The wallet provides the biometric verification credential to the issuer, who checks that the credential is recent.

Issuer issues the primary credential, with additional biometric binding attributes including the identity of the issuing biometric service.

Verification

Verifier requests a compound proof of a primary credential and a recent biometric verification credential.

The holder’s identity wallet detects that the request includes biometric binding attributes, and triggers the associated plugin that requests a biometric verification credential from the biometric service. The wallet’s biometric plugin follows the same process as was used during issuance to obtain a recent biometric verification credential.

Holder provides the biometric verification credential in a compound proof with the primary credential

Verifier checks that the biometric verification credential is from a trusted biometric service provider that was used at issuance and that the biometric binding attributes of the primary credentials matches the biometric binding attributes in the biometric verification credential.

Benefits

  • Biometric is taken on the device, and only accessed by the biometric service provider

  • Biometric service doesn’t have to store holder data, yet has assurance that the data has not been manipulated by the holder

  • Issuer and verifier do not need to integrate with the biometric service

  • Holder wallet can easily integrate with multiple biometric services

  • Trust registry can list biometric services that should be trusted within an ecosystem

  • The biometric service providers can enforce that all interactions are with a trusted wallet

Privacy concerns and suggested solutions

How to store the enrollment template in a privacy preserving manner?

Identity Wallet Approach: Have the identity subject hold a tamper-proof verifiable credential issued by the biometric service provider.

Issuer-Verifier Approach: Depends on the specific biometric service used.

How to bind a credential to a biometric template without correlation by the verifier?

The verifier checks a Zero-Knowledge Proof (ZKP) comparing the biometric binding attributes of the primary credential with the biometric verification credential without disclosing the binding attributes.

How to bind a credential to a biometric template without correlation by the issuer?

Use blind signatures to not disclose the actual binding attribute.

.

Documentation how to add a biometric service plugin
Cover

Centralized

Biometric provider stores biometric data from multiple people in a common database. Each relying party integrates with the provider, and may see biometric data.

Cover

Decentralized

Biometric provider stores each person’s data in a different sharded vault which cannot be reconstructed without the biometric vector.

Cover

User-stored

Biometric data is securely stored on the person’s device using tamper-proof credentials.