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 is a
preview
Do not attempt to implement this version of the specification. Do not
reference this version as authoritative in any way.
Instead, see
https://w3c.github.io/vc-confidence-method/ for the Editor's draft.
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 First Public 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 evidenceproperty provides information that is
different
from and
information to the securing mechanism used. The evidenceproperty 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
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
6. Assurance Levels
NIST_800-63-4_LOA
NIST_800-63-4 defines an assurance level based on the
[NIST-SP-800-63-4] specification.
EIDAS_LOA
EIDAS_LOA defines an assurance level based on the
[EIDAS2].
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.
8. Security Considerations
Issue 1: 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.
9. Privacy Considerations
Issue 2: 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.