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
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.