This specification defines mechanisms that can be used with the
Verifiable Credentials Data Model v2.0 to increase a verifier's
confidence that a presenter of a verifiable credential is,
in fact, appropriately related for its use. In the simplest
situation, this means the presenter is the original, legitimate
recipient of the credential. This specification defines a data
model for expressing confidence methods and evidence in a
verifiable credential and provides examples of how to use
it.
Status of This Document
This section describes the status of this
document at the time of its publication. A list of current W3C
publications and the latest revision of this technical report can be found
in the
W3C standards and drafts index.
This is an experimental specification and is undergoing regular
revisions. It is
not fit for production deployment.
Publication as
a Working Draft does not imply endorsement
by W3C and its Members.
This is a draft document and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to cite this document as other
than a work in progress.
This document was produced by a group
operating under the
W3C Patent
Policy.
W3C maintains a
public list of any patent disclosures
made in connection with the deliverables of
the group; that page also includes
instructions for disclosing a patent. An individual who has actual
knowledge of a patent that the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
This specification defines two extensible mechanisms that
Issuers
can use to help Verifiers increase their confidence that the
presentation of a given Verifiable Credential is legitimate.
The confidenceMethod property enables issuers to provide
specific
techniques for improving the confidence that a candidate party
is one of the subjects in a VC. For example, improving
confidence
that the presenter of a marriage license is one of the parties
involved: the officiant, one of the spouses, or one of the
witnesses.
The confidenceMethod property can be used to specify a
particular biometric, cryptographic key, or other mechanism that
the presenter can use to demonstrate that they are that subject
in the VC. It is up to the verifier to decide whether to require
the presenter to use the confidence method, or to use a
different mechanism to increase their confidence about whether,
for example, the presenter is the same entity the issuer made
claims about in the VC. Such a decision can impact the
verifier's liability when accepting VCs during certain use
cases.
The assuranceLevel property enables issuers to declare the
level of assurance that the issuer established before issuing
the
credential to its initial recipient. For example,
an issuer can declare that they used a particular identity
proofing process, signifying standard levels of assurance like
IAL 3 defined in [NIST-SP-800-63-4]. This can
help verifiers understand the level of assurance that
the issuer had at the time of issuance as an input for their own
informed decisions about whether to accept them.
Both of these mechanisms are extensible using JSON-LD to
define a new type of confidence method or assurance level.
For example, when an employer (the
issuer) issues a corporate identification card to an
employee (the
subject), it might require that the employee bind a
particular cryptographic
key (verification
method) to the verifiable credential during the
issuing process. In that
case, the issuer can use this specification to convey to the
verifier
which cryptographic key was bound during the initial identity
assurance process.
In other words, an issuer can use this specification to
convey which
provable mechanisms it used to bind claims in a verifiable credential so
that a verifier can increase their confidence in the truth
of a variety of
things, including the following:
a particular identifier in the verifiable credential
refers to the same
subject the issuer intended it to refer to,
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY and MUST in this document
are to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, they appear in all
capitals, as shown here.
A conforming document is any concrete expression of
the data model
that follows the relevant normative requirements in Section
4. Data Model.
A conforming processor is any algorithm realized as
software and/or
hardware that generates and/or consumes a conforming document. Conforming
processors MUST produce errors when non-conforming documents
are consumed.
The Verifiable Credentials specification defines an
evidence property:
Evidence can be included by an issuer to provide the verifier
with
additional supporting information in a verifiable credential.
This
could be used by the verifier to establish the confidence with
which
it relies on the claims in the verifiable credential. For
example, an
issuer could check physical documentation provided by the
subject or
perform a set of background checks before issuing the
credential. In
certain scenarios, this information is useful to the verifier
when
determining the risk associated with relying on a given
credential.
This property is expected to be used at the top level of the
credential, effectively providing "supporting information" for
the entire credential.
The example provided in the specification illustrates how this
might be used:
Example 1: Example of evidence supporting a skill achievement credential
{
...
"evidence": [{
// url to an externally hosted evidence file/artifact
"id": "https://videos.example/training/alice-espresso.mp4",
"type": ["Evidence"],
"name": "Talk-aloud video of double espresso preparation",
"description": "This is a talk-aloud video of Alice demonstrating preparation of a double espresso drink.",
// digest hash of the mp4 video file
"digestMultibase": "uELq9FnJ5YLa5iAszyJ518bXcnlc5P7xp1u-5uJRDYKvc"
}
]
}
This example is accompanied by the following note:
Note: Evidence has a different purpose from securing mechanisms
The evidence property provides information that is
different
from and
information to the securing mechanism used. The evidence
property is
used to express supporting information, such as documentary
evidence, related to
the verifiable credential. In contrast, the securing
mechanism
is used to
express machine-verifiable mathematical proofs related to the
authenticity of
the issuer and integrity of the verifiable credential.
For
more
information about securing mechanisms, see Section
#securing mechanisms.
As demonstrated, the evidence property is expected to provide
evidence, such as the mp4 video file in the example.
This specification presents two additional measures that
provide mechanisms for increasing the verifier's confidence in
specific subjects without revealing unnecessary personal
information. Rather than provide additional "evidence", the additional properties of
confidenceMethod and assuranceLevel provide
distinct attestations from the issuer:
A top-level property, this presents evidence
independently evaluatable by the verifier without further
interaction with either the issuer or the holder. For
example, the issuer might provide a video of the subject
performing some specific action such as performing a task.
A subject-level property, this defines mechanisms the
verifier can use to increase the confidence that a
subject of the VC is also the subject of another
interaction. For example, the issuer might provide
a verification
method, such as a public key, by
which the verifier could apply a proof-of-use protocol to
establish that a current user has the ability to sign
cryptographic challenges using the same cryptographic
secrets believed by the issuer to be under the control of
the subject. This is sometimes called "proof-of-control".
A subject-level property,
this allows issuers to attest to having established a known Assurance Level according to public standards such as NIST-SP-800-63-4 and EIDAS2. Rather than providing evidence to be evaluated or a mechanism to be applied, this property simply describes the issuers own processes for identifying the subject before issuing the credential.
4. Data Model
This specification defines the confidenceMethod property for
expressing
confidence method information in a credentialSubject in a
verifiable credential.
confidenceMethod
If present, the value of the confidenceMethod property is
one or more
confidence methods as defined below. Each confidence method
specifies the specific
type of confidence method and any reference data that might
be required to evaluate the method. The method is bound to a
subject
in the verifiable credential and provides enough
information for a
verifier to evaluate whether a particular candidate
party is, for their purposes, the same entity referenced in
the credential. THe verifier evaluates the confidence
method, executing the process of that method. Successful
evaluation indicates the credential has satisfied the
confidence method and the verifier can safely rely on that
belief to provide services.
Each confidence method MUST specify its type and MAY
specify an id. The precise properties and semantics of
each confidence method are determined by the
specific confidenceMethod type definition.
assuranceLevel
(Feature at Risk) Issue 1
If present, the value of the assuranceLevel property is
one or more assurance levels, defined below. Each assurance
method specifies the specific type of assurance level and
any reference data that might be required to evaluate the
method. The method is bound to a subject in the
verifiable credential and provides information about the
level of assurance that the issuer had about the subject at
the time of issuance. This can help a verifier
understand the means by which the verifier established their
own level of assurance that for that subject. Different
subjects may have different assurance level, allowing the
issuer to use different levels of assurance for different
subjects in the same credential. For example, an issuer can
use a high level of assurance for the subject that is the
officiant or spouse in a marriage license, but a lower level
of assurance for the witnesses to that ceremony.
Each assurance level MUST specify its type and MAY
specify an id. The precise properties and semantics of
each assurance level are determined by the
specific assuranceLevel type definition.
A verifier can decide to accept claims in a verifiable credential
without requiring use of the confidence method, or use a
different mechanism to
increase their confidence about whether, for example, the
holder is the same
entity the issuer made claims about in the verifiable credential. Such a
decision can impact the verifier's liability when accepting
verifiable credentials during certain use cases.
A verifier can validate that the holder controls, or has
been designated
the ability to use, a confidence method by verifying the proof of the verifiable presentation using the
information in the
confidence method. The confidence method can include the
verification key, or
the type of the confidence method can define that the
verification key is to be
inferred from other properties in the verifiable credential,
such as the
credentialSubject.id.
The following example demonstrates the various types of
confidence methods
that can be used, including public cryptographic keys,
verification methods,
and Decentralized Identifier Documents.
Example 2: Usage of the confirmationMethod property of type VerificationKeyConfirmation
A confidence method can express various metadata such as the
issuer's level
of confidence that the holder is the subject of the
verifiable credential, specific form factors or mechanisms of
authenticators, and/or
references to other verifiable credentials or versioned
trust frameworks.
For example, an issuer can make a claim about a
confidence method that
is based on a cryptographic key pair, but to produce a signature
using that key,
the holder has to unlock a device using multi-factor
authentication.
5. Confidence Methods
VerificationConfidence
VerificationConfidence specifies how to use a verification
method in a controlled identifier document such as a DID
document.
BiometricImageConfidence
BiometricImageConfidence specifies how to use an image
in a verifiable credential for recognizing the subject of
the credential.
5.1 Verification Confidence
TBD
5.2 Biometric Image Confidence
TBD
5.3 Biometric Vector Confidence Method
(Feature at Risk) Issue 2: This feature is unstable and continues to be refined by the Task Force
The Biometric Vector Confidence Method is unstable and continues to be refined by the Task Force. The following concerns are actively being worked on at present:
1) The specification needs to be agnostic to biometric matching providers and not favor any particular proprietary or open approach/types.
2) Model/vector data might be combined since they are associated with one another. It doesn't really make sense to decouple the model and the vector information. base64url encoded CBOR might be a better approach to hold this information.
3) How do we specify examples with open matching models, which need to exist in the spec.
4) Clarify that the issuer can provide multiple vectors from different providers when the credential is issued.
5) There is no standardized ZKP to do biometric matching yet, but the group believes that is the ideal end-state.
6) Issuers putting service URLs into the biometric matching model might not be the best design and will need to be refined. More work will need to be done to figure out how the negotiation is performed between the holder and the verifier, and the holder and the issuer.
7) Where should this information be published? Is it safe to put this in the DID Document?
8) Describe "ideal state" use cases in the specification.
9) How do holder's find "the right" biometric provider? Is it asking too much of the holder? Is that a security/privacy risk? How much are we asking holder's to do?
10) Do application integrity checks need to be performed for local device checks?
11) Nonces need to be added to the model.
A BiometricVectorConfidenceMethod enables an issuer to embed
biometric vectors in a verifiable credential so that a
verifier can increase their confidence that the
presenter is the same individual the issuer made
claims about. Unlike raw biometric data (e.g., photos, audio
recordings), biometric vectors are compact mathematical
representations produced by a matching model. Vectors from different
models are not interchangeable.
A biometric vector confidence method MUST specify the following properties:
id
A unique identifier for this confidence method instance. Enables a
person to maintain multiple biometric enrollments for different contexts.
type
The value MUST be BiometricVectorConfidenceMethod.
biometricModality
The biometric modality. Expected values include face, voice,
fingerprint, palmprint, iris, and retina.
captureFormat
The capture format. Expected values include video, static-image,
image-sequence, and audio.
biometricModel
An object identifying the matching model, containing a type property
(MUST be BiometricMatchingModel) and a matchingModel property
(vendor and model identifier, e.g., realeyes-2026-v3.2).
biometricVectors
Multibase-encoded (base64url-nopad) biometric vector. The format is
specific to the matching model that generated it.
A biometric vector confidence method MAY also specify:
service
A service endpoint for server-assisted verification, following the
service definition structure from Decentralized Identifiers (DIDs) v1.0 [DID-CORE],
containing id, type (BiometricVerificationService), and
serviceEndpoint properties.
Two implementation scenarios are supported: client-side local processing
and user-selected provider. In both cases, a fresh biometric sample is
captured and compared against the enrolled vectors. The result is
expressed as a BiometricVerificationCredential.
5.3.1 Client-Side Verification
In this scenario, biometric verification happens entirely on the
holder's device. No biometric data leaves the device; a
zero-knowledge proof demonstrates the match.
The following example demonstrates a credential with a biometric vector
confidence method for client-side verification:
Example 3: Client-side biometric vector confidence method
{"@context":["https://www.w3.org/ns/credentials/v2","https://www.w3.org/ns/credentials/examples/v2"],"id":"http://example.edu/credentials/3732","type":["VerifiableCredential","UniversityDegreeCredential"],"issuer":"https://example.edu/issuers/14","validFrom":"2026-01-01T00:00:00Z","credentialSubject":{"id":"did:example:ebfeb1f712ebc6f1c276e12ec21","confidenceMethod":{"id":"urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d","type":"BiometricVectorConfidenceMethod","biometricType":"face","inputType":"video","biometricModel":{"type":"BiometricMatchingModel","matchingModel":"realeyes-2026-v3.2"},"biometricVectors":"uAVvLMv6gm...MNam"},"degree":{"type":"BachelorDegree","name":"Bachelor of Science"}}}
The holder's device captures a fresh biometric sample, compares it
locally against the enrolled biometricVectors, and produces a
BiometricVerificationCredential asserting the match. Note that the
credentialSubject.id in the verification output references the
confidence method id from the credential above, linking the
verification result to the specific biometric enrollment:
Example 4: Verification output for client-side biometric match
The example-biometric-zkp-2028 cryptosuite does not exist at the
time of this writing. It is included here to illustrate how a future
zero-knowledge proof cryptosuite could be used for client-side
biometric verification. This area is under active research.
5.3.2 User-Selected Provider
In this scenario, the holder selects a trusted biometric
verification service. The wallet presents available options and the
holder consents before any biometric data is transmitted. The
holder's biometric data is sent only to their chosen provider, not
to the verifier.
The following example demonstrates a credential with a biometric vector
confidence method that includes a service endpoint:
Example 5: User-selected provider biometric vector confidence method
{"@context":["https://www.w3.org/ns/credentials/v2","https://www.w3.org/ns/credentials/examples/v2"],"id":"http://example.edu/credentials/3732","type":["VerifiableCredential","UniversityDegreeCredential"],"issuer":"https://example.edu/issuers/14","validFrom":"2026-01-01T00:00:00Z","credentialSubject":{"id":"did:example:ebfeb1f712ebc6f1c276e12ec21","confidenceMethod":{"id":"urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d","type":"BiometricVectorConfidenceMethod","biometricType":"face","inputType":"video","biometricModel":{"type":"BiometricMatchingModel","matchingModel":"realeyes-2026-v3.2"},"service":{"id":"urn:uuid:service-1","type":"BiometricVerificationService","serviceEndpoint":"https://api.realeyesit.com/verify/v3"},"biometricVectors":"uAVvLMv6gm...MNam"},"degree":{"type":"BachelorDegree","name":"Bachelor of Science"}}}
The verification flow ensures that the biometric provider and
verifier do not need to know about each other:
The verifier requests biometric verification from the
holder, specifying accepted biometric providers and a challenge
nonce.
The wallet presents the accepted providers to the holder, who
selects their preferred provider and consents to the
verification.
The wallet transmits the biometricVectors, a fresh biometric
capture, and the challenge nonce to the selected provider's
serviceEndpoint.
The provider compares the fresh capture against the enrolled
vectors and issues a signed BiometricVerificationCredential with
the challenge nonce embedded.
The wallet presents the BiometricVerificationCredential to the
verifier, who validates the proof and checks the embedded
challenge matches their original request.
The challenge nonce prevents replay attacks and proves the verification
was performed in response to the verifier's specific request.
As with the client-side scenario, the credentialSubject.id in the
verification output references the confidence method id from the
credential above:
Example 6: Verification output for user-selected provider biometric match
A technique for establishing the identity of an individual in
terms of real-world evidence and observations, according to a
specific process, typically defined by national and
international standards organizations like NIST in the US and
eIDAS in the EU.
5.6 Security Considerations
Issue 4: Add Security Considerations section
Add security considerations section that includes at least the
following topics:
Since confidence methods can be selectively disclosed,
verifiers need to
explicitly ask for confidence methods in high-assurance use
cases when
dealing with proof mechanisms that allow for selective or
unlinkable disclosure.
5.7 Privacy Considerations
Issue 5: Add Privacy Considerations section
Add privacy considerations section that includes at least the
following topics:
Confidence methods are expected to be selectively disclosed,
as they might not
be necessary in many low-assurance use cases, or where
high-assurance is
achieved through a different means such as in-person
verification against a
photo.
If a confidence method is unlinkably disclosed, it can
reveal
correlatable identifiers, such as public cryptographic key
identifiers.
Strongly advise against using biometrics for confidence
methods unless
absolutely required. Warn that verifiers should only require
biometric photos
as a last resort and should destroy the information after
the transaction
is complete.