Identity proofing and holder binding

Confidence in an authority-issued credential rests on a question that is easy to state and harder to operationalize: how sure is the issuing authority that a credential belongs to the right person? In a decentralized trust model, the issuer is out of the transaction loop once a credential is issued, so the assurance that matters most is established before the credential ever reaches a relying party. The strength of that assurance is set during issuance, not at presentation.

This page explains the three distinct moments where identity is verified, why holder binding is the most consequential of them, and why confidence established once can be reused across the ecosystem rather than re-litigated at every interaction.

The three verification moments

Confidence in a credential depends on three separate verification moments, each serving a different purpose and each governed differently.

The first moment sets the assurance ceiling. The rigor of identity proofing at record creation or update determines the maximum assurance any credential derived from that record can carry. No later step can raise a credential above the assurance of the proofing that underpins it.

The second moment connects the credential to a person. A credential is only as trustworthy as the process that binds it to its rightful holder during provisioning.

The third moment is where the holder demonstrates control at the point of use. For many transactions, the biometric access controls already built into a modern device, such as facial recognition or fingerprint authentication, provide sufficient assurance that the person presenting the credential is its holder. Higher-risk use cases may justify additional verification, but the need for it should be determined explicitly by the sensitivity of the credential and the nature of the transaction rather than applied uniformly.

Why holder binding is the pivotal decision

The most consequential identity assurance decision in the credential lifecycle is often not how a credential is presented, but how confidently the issuing authority and its ecosystem partners bind the credential to the correct individual during provisioning.

At the point of provisioning, a liveness check that confirms the person is physically present and matches the identity record can significantly strengthen holder binding. This is a one-time event, not ongoing surveillance. The biometric is used solely to confirm the binding and can be discarded once the process is complete.

For credentials derived from high-assurance authoritative records, stronger holder-binding measures may be appropriate. These can include document verification, facial matching against authoritative records, and liveness detection. The objective is to ensure that a high-assurance credential is issued only to the person entitled to receive it.

Where holder binding takes place is a policy choice

The key decision is not whether holder binding should occur, but where. The matching process can be performed by the issuance platform before the credential is delivered, or by the wallet when the credential is claimed. Both approaches can achieve the same assurance outcome. They differ in:

• Where biometric processing occurs, on a server controlled by the issuance platform or on the holder's device.
• Who controls the matching logic and is accountable for its accuracy.
• How responsibilities are allocated across the issuing authority, issuance platform, and wallet provider.

What matters is that the holder-binding event is performed, documented, and governed appropriately. The choice between locations is a governance and privacy-design decision rather than a difference in assurance.

Biometrics belong to proofing, not to the credential

This framing clarifies the role of biometrics in the ecosystem. Biometrics are most valuable as a proofing and holder-binding mechanism, not as an attribute carried inside the credential. The ecosystem gains assurance from the fact that a biometric check occurred, not from sharing biometric information with relying parties.

A biometric template is a digital representation of a person's unique physical characteristics, such as a face or fingerprint, that can be used to recognize them. Where biometric processing is used for identity proofing or holder binding, only the outcome of that process, such as identity confirmed, should be reflected in the credential. Raw biometric data, facial images, fingerprints, and other reusable biometric information should not be credentialized. This is consistent with the broader principle that several categories of information warrant exclusion from default credential attributes. See Policy considerations.

Establish confidence once, reuse it across the ecosystem

The policy objective should be to establish confidence once and then allow that confidence to be reused. Where high-quality identity proofing and holder binding have already occurred at issuance, relying parties should not need to repeat identity verification unnecessarily. This reduces friction for users, lowers compliance costs, and limits the collection and storage of personal information across the ecosystem.

When the three verification moments work together, they establish that:

• the issuing authority knows who the individual is,
• the credential has been issued to the correct individual, and
• relying parties can trust the resulting credential without conducting their own extensive identity verification.

This improves trust while reducing the overall privacy footprint of the ecosystem. It is also why selective disclosure and derived assertions are so effective: a relying party that can rely on a high-assurance, well-bound credential rarely needs the underlying identity data at all.

How this relates to the rest of the ecosystem

Identity proofing and holder binding sit upstream of almost every other governance question:

• They set the assurance level that credential design can rely on.
• They underpin lifecycle management, because a credential is only worth updating or revoking if it was bound to the right person in the first place.
• They interact with delegation and representation, where the person presenting a credential may not be its subject. See Policy considerations.

The chain of cryptographic trust that lets a relying party verify which issuer signed a credential is a separate question, covered in Chain of trust. Identity proofing and holder binding answer the complementary question of which person the credential belongs to.

Frequently asked questions

What is the difference between identity proofing and holder binding?

Identity proofing is the process of verifying a person against authoritative records to establish or update an identity record. Holder binding is the separate step of confirming that the person requesting a credential is the person that identity record belongs to, so the credential is provisioned to the correct individual. Proofing sets the assurance ceiling for any credential derived from the record. Holder binding connects a specific credential to its rightful holder at the moment of issuance.

Should biometric data be stored in a verifiable credential?

No. Biometrics are most valuable as a proofing and holder-binding mechanism, not as an attribute inside the credential. Where a biometric check is used during issuance, only the outcome of that check should be reflected in the credential, such as identity confirmed. Raw biometric data, facial images, and fingerprints should not be credentialized, and the biometric used to confirm binding can be discarded once the process is complete.

Where should holder binding take place?

Holder binding can be performed by the issuance platform before a credential is delivered, or by the wallet when the credential is claimed. Both approaches can achieve the same assurance outcome. They differ in where biometric processing occurs, who controls the matching logic, and how responsibilities are allocated across the ecosystem. The important policy requirement is that the holder-binding event is performed, documented, and governed appropriately, not which actor performs it.

Do relying parties need to repeat identity proofing?

Generally no. The policy objective is to establish confidence once and allow it to be reused. Where high-quality identity proofing and holder binding have already occurred at issuance, relying parties can trust the resulting credential without repeating identity verification. This reduces friction, lowers compliance costs, and limits how much personal information is collected and stored across the ecosystem.