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.
When a verifier performs the process of validating a
verifiable credential, it is useful to be able to raise the confidence level
that the subjects identified in a verifiable credential are the same
ones that interacted with the issuer when it performed its vetting process
to issue the verifiable credential. 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
2. 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.
2. 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. Each confidence method is bound to one or more subjects
in the verifiable credential, and provides enough information for a
verifier to determine whether the holder can generate a verifiable presentation to increase the verifier's confidence that they are the same
entity referenced by the confidence method. This is referred to as satisfying
the confidence method. It is required that the issuer verifies that the
holder can satisfy each confidenceMethod the issuer includes in the
claims of the verifiable credentials they issue.
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.
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 1: 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.
3. 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.
4. 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.