Verifiable Credentials Use Cases

A verifiable claim is a qualification, achievement, quality, or piece of information about an entity's background such as a name, government ID, payment provider, home address, or university degree. Such a claim describes a quality or qualities, property or properties of an entity which establish its existence and uniqueness. The use cases outlined here are provided in order to make progress toward possible future standardization and interoperability of both low- and high-stakes claims with the goals of storing, transmitting, and receiving digitally verifiable proof of attributes such as qualifications and achievements. The use cases in this document focus on concrete scenarios that the technology defined by the group should address.

Introduction

The Verifiable Claims Working Group at the W3C is developing standards for expressing and exchanging "claims" that have been verified by a third party and to make them easier and more secure on the Web.

This document does NOT attempt to define an architecture for the support of Verifiable Claims. Instead it expresses the sorts of needs that real users have that could be addressed through support for some sort of self-sovereign claim environment. It attempts to use terminology that is consistent with the other deliverables of the Verifiable Claims Working Group (you can see the relevant terms in Appendix A).

Importance of this work

Entities (people, organizations, devices) need to make many kinds of claims as part of their everyday activities. As more and more of these important activities move to the Internet, entities need to be able to transmit instantly verifiable claims (e.g., about their location, accomplishments, value, what-have-you). From educational records to payment account access, the next generation of web applications will authorize entities to perform actions based on rich sets of credentials issued by trusted parties. Human- and machine-mediated decisions about job applications, account access, collaboration, and professional development will depend on filtering and analyzing growing amounts of data. It is essential that data be verifiable.

Standardization of digital claim technologies makes it possible for many stakeholders to issue, earn, and trust these essential records about their counterparties, without being locked into proprietary platforms.

Use case model

This document presents an aggregate use case model, composed of Needs, Roles, Tasks, and Sequences. Taken together, these models define the use cases that the Verifiable Claims Working Group has addressed.

User needs define the problem space addressed by verifiable credentials. User Roles specify the roles different entities play when interacting with verifiable credentials. Tasks define the functions users can accomplish, and sequences demonstrate how tasks might be realized, by interactions between entities over time.

As with all models, this use case model is neither exhaustive nor complete. The listed uses cannot capture all possible use cases. Similarly, the models do not completely characterize the use cases represented. However, the combined model is intended to provide specific, coherent guidance for the work ahead.

User Needs

Verifiable credentials address user needs in a number of key domains:

  %%{init:{'flowchart':{'nodeSpacing': 20, 'rankSpacing': 10}}}%%
    flowchart TD
    classDef Domain stroke:#000,stroke-width:3px,padding:2px;
    classDef Problem stroke:#222,stroke-width:1px,padding:2px;
    classDef Education fill:#ffe4e6
    classDef Retail fill:#ffefd6
    classDef Finance fill:#fffdd0
    classDef Healthcare fill:#dff6d1
    classDef Credentials fill:#bffedb
    classDef Legal fill:#beddfe
    classDef Devices fill:#fcdfef

  E(Education) --- E.1[E.1 Digital Transcript]
  E.1 --- E.2[E.2 Taking a Test]
  E.2 --- E.3[E.3 Transferring Schools]
  E.3 --- E.4[E.4 Online Classes]
  R(Retail) --- R.1[R.1 Digital Transcript]
  R.1 --- R.2[R.2 Taking a Test]
  R.2 --- R.3[R.3 Transferring Schools]
  R.3 --- R.4[R.4 Bona-fide Shopper]
  F(Finance) --- F.1["F.1 Reuse Know
  Your Customer"]
  F.1 --- F.2[F.2 Money Transfer]
  F.2 --- F.3[F.3 Closing Account]
  F.3 --- F.4[F.4 Trying out a new service]
  F.4 --- F.5["F.5 New Bank 
Account from Home"]
  H(Healthcare) --- H.1[H.1 Prescribing]
  H.1 --- H.2[H.2 Online Pharmacy]
  H.2 --- H.3[H.3 Insurance Claim]
  H.3 --- H.4[H.4 Traveling Illness]
  H.4 --- H.5["H.5 Proving Legal 
  Disability Status"]
  C(Professional Credentials) --- C.1[C.1 Find a Doctor]
  C.1 --- C.2[C.2 Busy Doctor]
  C.2 --- C.3[C.3 Bad University]
  C.3 --- C.4[C.4 New Employer]
  C.4 --- C.5[C.5 Social Authority]
  C.5 --- C.6[C.6 Job Applicant]
  L(Legal Identity) --- L.1[L.1 Digital Driver's License]
  L.1 --- L.2[L.2 Seamless Integration]
  L.2 --- L.3[L.3 Speedy Air Travel]
  L.3 --- L.4[L.4 Refugee Crisis]
  D(Devices) --- D.1["D.1 Devices 
  During Manufacturing"]
  D.1 --- D.2[D.2 Devices During Delivery]
  D.2 --- D.3["D.3 Device setup for
  operating autonomously"]
  class E,E.1,E.2,E.3,E.4 Education
  class R,R.1,R.2,R.3,R.4 Retail
  class F,F.1,F.2,F.3,F.4,F.5, Finance
  class H,H.1,H.2,H.3,H.4,H.5 Healthcare
  class C,C.1,C.2,C.3,C.4,C.5,C.6 Credentials
  class L,L.1,L.2,L.3,L.4 Legal
  class D,D.1,D.2,D.3 Devices
  class E,R,F,H,C,L,D Domain
  class E.1,E.2,E.3,E.4,R.1,R.2,R.3,R.4,F.1,F.2,F.3,F.4,F.5,H.1,H.2,H.3,H.4,H.5,C.1,C.2,C.3,C.4,C.5,C.6,L.1,L.2,L.3,L.4,D.1,D.2,D.3 Problem

Verifiable Credentials, Example Domains for User Needs

Education

The education domain includes all levels of the educational experience; from primary through professional continuing education.

Retail

The retail domain encompasses all things where there is an exchange of value on an individual level. This includes brick-and-mortar store fronts, web-only venues, and even person-to-person sales.

Finance

The Finance domain includes banking, brokerage, insurance, and other industries where there is a high value placed on knowing exactly with whom you are dealing.

Healthcare

Privacy is critically important in the healthcare industry. This domain looks at everything from physical interaction to connecting patients and providers with service organizations.

Professional Credentials

In many aspects of life it is important to know that entities are who they say they are, and that they can do what they say. Professional accreditation is one way of learning about the abilities of an entity. Being able to verify these credentials is essential to their value.

Legal Identity

For many transactions, an entity must be able to prove some aspect of their identity in a way that can be quickly verified. Governments and other widely recognized entities are well positioned to provide such identification in a verifiable digital form.

Devices

Intelligence devices are created and deployed so that they can interact with other entities (people, organizations, devices). Establishing trust and maintaining secure relationships with these devices is especially critical.

User Tasks

Use cases are often used as a driver for requirements. While the users of verifiable credentials have needs across many domains, the tasks associated with those needs span the domains. This section summarizes those tasks, as well as requirements related to the tasks, and maps the tasks and requirements back to the associated needs.

It is worth noting that the subject may or may not be the same entity as the holder. There are no tasks in these examples that require participation of the subject.

Issue Claim

Requirement: It MUST be possible for any entity to issue a verifiable credential.
Motivation: Individuals and organizations need a way to issue claims about themselves or others that can be verified and trusted.
Needs: F.1, E.1, L.1, H.1

Assert Claim

Requirement: It MUST be possible for the holder of a verifiable credential to restrict the amount of information exposed in a credential they choose to share. It also MUST be possible for the holder to limit the duration for which that information is shared.
Motivations: Credentials may be issued about a subject that include multiple attributes, only some of which are required when verifying a specific criteria is satisfied. The holder should have the ability to satisfy the criteria without revealing additional attributes that are not required.
Needs: R.2, H.4

Verify Credential

Requirement

It is expected to be possible for a verifier to verify that the credential is an authentic statement of an issuer's claims about the subject. Verifiers MUST have the capability to cryptographically prove that a credential has not been tampered with since issuance (authenticity) and that the issuer continues to assert the claims as true (currency).

To check authenticity, the issuer's verification method(s), such as a public key, must be discoverable from the credential itself. It is expected that the issuer identifier either is itself cryptographically verifiable, or that it can be used to reliably discover the cryptographic material necessary to confirm that the content of a credential has not been changed since issuance. It is understood that verification depends on the verifier's acceptance of the robustness of the cryptographic mechanisms used for testing authenticity and for discovering verification methods. An untrusted verification method cannot be relied upon for verification.

Verifiers must also be able to inquire about the current status of a credential without revealing to the issuer

The entity requesting that status
The credential for which status is being checked
The subject of the credential being checked

Requiring that verifiers perform this status check is what enables issuers to revoke, suspend, or otherwise moderate the status of the credential.

Similarly, if a discovery mechanism is used to retrieve verification methods for a given issuer, verifiers must be able to do so without revealing unnecessary information to the issuer.

In short, it must be possible to fully verify a credential without leaking usage data to the issuer or anyone else. This is to avoid the so-called "phone home" problem.

Motivations

In many environments (such as order processing), information — such as a payer's address, citizenship, or age — needs to be automatically verified to complete the transaction.

It MUST be possible to verify these in an automated fashion.

Needs

F.2, C.1, E.2, R.1 , F.5, H.2, C.6

Validate Claim

Requirement

It MUST be possible for a verifier to check whether a given claim is appropriate for a particular use. That is, given a credential that is authentic and current, the verifier needs to interpret the claims in the context of their own 'business rules' concerning, for instance, which parties are acceptable authorities, and which cryptographic mechanisms are acceptable for what situations.

Is the issuer someone we know?
Are the claims made by this issuer appropriate for this particular issuer's authority?
Is the holder's presentation an appropriate use of the credential?

The first and second questions will be answered because either the verifier already knows the public identifiers for the issuers it recognizes for specific claims, or there is a discovery mechanism whereby verifiers can find appropriate issuers given their business requirements.

The business rules may allow the use of certain credentials for specific situations, even when verification fails. For example, a suspended or expired professional license may be accepted by an employer as evidence of past experience without it being treated as a current qualification for roles that require that license. For this reason, current status (as part of verification) only deals with the status of the credential as maintained by the Issuer. Timeliness is the domain of validation.

It's important to note that the bounds of authority for a given issuer are specific claim types made by them and relied upon by others. While a region's DMV (Department of Motor Vehicles) or equivalent agency might be an acceptable authority for an individual's driving privilege, it should probably not be treated as authoritative for an individual's hair color or current address, even though DMVs regularly include such claims in today's driver's licenses.

Unlike verification, it may not always be possible to automate validation. Some use cases require human review before accepting a particular credential for a particular use. For example, a digital proof of age system might need a trusted human agent to visually compare the holder/presenter in real-space to a reference photo securely referenced in the VC, before accepting a credential as valid.

Motivations

Verifiers need to be able to apply their own policies and rules to the information they rely on to run their "business" (which we mean broadly, to encompass all activity focused towards a goal).

Given this need, any given VC might be verified but not usable in a particular situation. For example, a self-issued driver's license would likely not be acceptable for a car rental by most car rental agencies, even though the verification succeeds.

Even so, in other cases, such as at a go-cart racing facility, it may be entirely appropriate to accept the name and image from a self-issued license for the purpose of leaderboards, announcements, and correspondence.

These business rules are entirely the province of the verifier. Only after satisfying their rules should a verifier rely upon a claim as an accepted fact for specific use.

Needs

F.2, C.1, E.2, R.1 , F.5, H.2, C.6

Store Claim

Requirement: It MUST be possible for the holder of a claim to store that claim in one or more credential repositories.
Motivation: A claim is under the control of its holder. That holder will choose where their claims are stored based upon a variety of factors (e.g., employer requirements, convenience, service levels, provider cost, business intelligence). The holder needs to be able to easily choose among various credential repositories, and also to be able to migrate their claims to another without requesting new claims from the claim issuer.
Needs: F.4, E.3, C.4

Retrieve Claim

Requirement: It MUST be possible for a holder to select if and which appropriate credential should be sent to a verifier.
Motivations: A verifier may require that a holder verify aspects of their suitability for a transaction. In this case, the holder must be able to select which, if any, verifiable credential stored with their credential repository is used to satisfy the verifier.
Needs: C.5, E.4

Revoke Claim

Requirement: It MUST be possible for the issuer of a claim to revoke it, after which it will no longer satisfy verification procedures.
Motivation: An entity (issuer) discovers that a claim they have issued and are endorsing for an end user (subject), is no longer valid and wishes to revoke the issued claim.
Needs: F.3, C.2, C.3

User Sequences

The transaction examples in this section show basic ways in which verifiable credentials might be used. They are not meant to be architecturally constraining. Instead, they are meant to help illustrate the basic way it could be done in a typical commerce situation. Again — please remember that it is just an example, and should not be thought of as the canonical way such a claims environment must be implemented.

How a Verifiable Credential Might Be Created

In this first example, a user will request a verifiable credential—a confirmation of their identity. Consider this illustration:

Verifiable Credential Creation Flow Description — Verifiable Credential Creation Flow Diagram

Expanding on these steps:

Jane asks her User Agent to help her get a verifiable credential about her identity.
Her user agent connects her to a credential issuer that is able to verify her identity.
The issuer examines her documentation.
They are satisfied, so the issuer generates a verifiable credential for Jane that includes information about her identity linked to their own trusted credential.
The issuer delivers the verifiable credential back to Jane's User Agent.
Jane views the verifiable credential to ensure it reflects her requirements.
When she is satisfied, she instructs her User Agent to save the verifiable credential so she can use it in the future.
The UA communicates with her credential repository, instructing it to store the new verifiable credential.
The credential repository returns a list of the verifiable credentials it is holding for Jane to the UA.
The UA shows Jane her verifiable credential collection — confirming everything she has available.

How a Verifiable Credential Might Be Used

In this example, a holder of a claim needs to use that claim in a typical commerce situation:

Verifiable Credential Usage Flow Diagram

Jane decides to shop on the website WinesOfTheWorld.example.com (merchant).
The merchant's site requires Jane be 21 years of age and requests (via a user agent-supported API call) that Jane prove this.
Jane's user agent asks her credential repository for the proof.
The credential repository shows Jane some verifiable credentials it holds that can support her age claim (e.g., her passport, driving license, and birth certificate).
Jane selects one of these, and authorizes that it be shared with the merchant.
The credential repository returns the selected credential as a response to the user agent-supported API call, which in turn delivers it to the merchant.
The merchant's server verifies that the claim is valid and satisfies the requirement.
The merchant redirects the user agent to the web site with appropriate authorization.