This specification defines mechanisms that can be used with the [[[VC-DATA-MODEL-2.0]]] to increase a [=verifier|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.
This is an experimental specification and is undergoing regular revisions. It is not fit for production deployment.
Determining that a current presenter is the [=subject=] of a [=Verifiable Credential=] is a key concern for verifiers.
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 conforming document is any concrete expression of the data model that follows the relevant normative requirements in Section .
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:
{
...
"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:
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:
| evidence | 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. |
|---|---|
| confidenceMethod | 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". |
| assuranceLevel | 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. |
This specification defines the `confidenceMethod` property for expressing confidence method information in a `credentialSubject` in a [=verifiable credential=].
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.
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 [=data integrity proof|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.
{
"@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": "2010-01-01T19:23:24Z",
"credentialSubject": {
"confidenceMethod": [{
"type": "BiometricPortraitImage",
"image": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAZABkAAD",
}, {
"id": "urn:uuid:818d5ca0-3978-11f0-8658-4f17a1afd652#key-abc",
"type": "JsonWebKey",
"controller": "urn:uuid:818d5ca0-3978-11f0-8658-4f17a1afd652",
"publicKeyJwk": {
"crv": "Ed25519",
"x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ",
"kty": "OKP",
"kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A"
}
}, {
"id": "did:example:123#key-567",
"type": "Multikey",
"controller": "did:example:123",
"publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}, {
"id": "did:example:1234",
"type": "DecentralizedIdentifierDocument"
}],
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"proof": { ... }
}
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.
VerificationConfidence specifies how to use a verification method in a controlled identifier document such as a DID document.
BiometricImageConfidence specifies how to use an image in a verifiable credential for recognizing the subject of the credential.
TBD
TBD
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 biometric vector confidence method MUST specify the following properties:
A biometric vector confidence method MAY also specify:
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`.
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:
{
"@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:
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiableCredential", "BiometricVerificationCredential"],
"issuer": "did:example:holder-device",
"validFrom": "2026-05-15T14:30:00Z",
"validUntil": "2026-05-15T14:45:00Z",
"credentialSubject": {
"id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
"biometricMatch": {
"type": "BiometricMatch",
"matchingMethod": "client-side-zkp",
"matchDate": "2026-05-15T14:30:00Z",
"matchResult": "verified",
"confidence": "0.96"
}
},
"proof": {
"type": "DataIntegrityProof",
"cryptosuite": "example-biometric-zkp-2028",
"created": "2026-05-15T14:30:05Z",
"challenge": "9a4f2c8b-3e7d-4f1a-b5c9-2d8e6f0a1b3c",
"verificationMethod": "did:example:holder-device#key-1",
"proofPurpose": "authentication",
"proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndTeel..."
}
}
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.
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:
{
"@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 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:
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiableCredential", "BiometricVerificationCredential"],
"issuer": "did:web:realeyesit.com",
"validFrom": "2026-05-15T14:30:00Z",
"validUntil": "2026-05-15T14:45:00Z",
"credentialSubject": {
"id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
"biometricMatch": {
"type": "BiometricMatch",
"matchingMethod": "server-assisted-video-stream",
"matchDate": "2026-05-15T14:30:00Z",
"domain": "https://verifier.example/",
"matchResult": "verified",
"confidence": "0.94"
}
},
"proof": {
"type": "DataIntegrityProof",
"cryptosuite": "ecdsa-rdfc-2019",
"created": "2026-05-15T14:30:05Z",
"challenge": "9a4f2c8b-3e7d-4f1a-b5c9-2d8e6f0a1b3c",
"verificationMethod": "did:web:realeyesit.com#key-1",
"proofPurpose": "assertionMethod",
"proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndTeel..."
}
}
NIST_800-63-4 defines an assurance level based on the [[NIST-SP-800-63-4]] specification.
EIDAS_LOA defines an assurance level based on the [[EIDAS2]].
TBD
TBD
Some terminology used throughout this document is defined in the Terminology section of the [[[VC-DATA-MODEL-2.0]]] specification as well as the Terminology section of the [[[CID]]] specification. This section defines addition terms used throughout this specification.