Verifiable Credentials Use Cases

W3C Working Group Note

This version:
https://www.w3.org/TR/2019/NOTE-vc-use-cases-20190924/
Latest published version:
https://www.w3.org/TR/vc-use-cases/
Latest editor's draft:
https://w3c.github.io/vc-use-cases/
Previous version:
https://www.w3.org/TR/2017/NOTE-verifiable-claims-use-cases-20170608/
Editors:
Shane McCarron (Spec-Ops)
Joe Andrieu (Legendary Requirements)
Matt Stone (The Brightlink)
Tzviya Siegman (Wiley)
Gregg Kellogg (Spec-Ops)
Ted Thibodeau, Jr. (OpenLink Software, Inc.)
Authors:
Nate Otto (Badge Alliance)
Sunny Lee (Badge Alliance)
Brian Sletten (Bosatsu Consulting, Inc.)
Daniel Burnett (Standards Play)
Manu Sporny (Digital Bazaar, Inc.)
Ken Ebert (Sovrin Foundation)
Participate:
GitHub w3c/vc-use-cases
File a bug
Commit history
Pull requests

Abstract

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.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document represents a concise but limited collection of use cases readers should review alongside the Verifiable Credentials Data Model.

The work on this document was carried out under tight time constraints due to limitations of the W3C process and publishing deadlines. Under such conditions, errors are unavoidable and some of the ideas presented here are incomplete. The Working Group hopes that in the future, W3C process can be revised to better support the dynamic nature of standards work in a more consistent way across different groups.

Comments regarding this document are welcome. Please file directly on GitHub, or send them to [email protected] (subscribe, archives).

This document was published by the Verifiable Claims Working Group as a Working Group Note.

GitHub Issues are preferred for discussion of this specification.

Publication as a Working Group Note does not imply endorsement by the W3C Membership. 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 work in progress.

This document was produced by a group operating under the W3C Patent Policy.

This document is governed by the 1 March 2019 W3C Process Document.

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

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

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

1.2 Use case model

This document presents an aggregate use case model, comprised 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.

2. User Roles

There are four roles supported by verifiable credentials: Issuer, Verifier, Subject, and Holder.

Verifiable Credential User Roles
Figure 1 Verifiable Credential User Roles
Issuer
The entity that creates a claim and associates it with a particular subject.
Verifier
The entity verifying a claim about a given subject.
Subject
The entity about whom a claim is issued.
Holder
A role an entity may perform by possessing one or more verifiable credentials. A holder is usually, but not always, the subject of the verifiable credentials that they are holding. Holders store their credentials in credential repositories.

3. User Needs

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

Verifiable Credential User Needs
Figure 2 Verifiable Credentials, Example Domains for User Needs

3.1 Education

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

E.1 Digital transcript
Joleen is the registrar of Mega University and, by virtue of her office, is responsible for the integrity, accuracy, and security of academic records. Joleen has been a pioneering registrar in advocating an "extended transcript" that includes not only the standard set of course grades but also adds supplementary information on learner competencies. These might include work experiences and non-educational but marketable skills. Upon the request of her students, Joleen issues a digital credential that includes an extended transcript.
E.2 Taking a test
Eunice is about to take her ACT (a test used to evaluate her readiness for college). When she arrives at the testing center, she is required to present identification. Her government-issued identity certificate is acceptable, as the verifiable credentials contained in it reflect all of the required attributes and it is difficult to counterfeit.
E.3 Transferring schools
Rocky is an undergraduate student at Wossamotta U. His school provides a credential repository service to all students and alumni, so he chooses to use it. In his third year, Rocky decides to transfer to Moosylvania Tech. They do not offer a service, but he does not want to continue to use the service of his old (and now rival school) so he moves his claims to the service offered by his bank without needing to have them reissued.
E.4 Online classes
In MOOC and other online learning systems, being able to reliably identify participants is vital to ensure the individual evaluation and certification. Nick is participating in a course online and takes a test. He is required to provide his credentials to prove his identity before the test, and then to allow the system to issue a verifiable credential regarding the results of his test.

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

R.1 Address verification
Francis has found the perfect pair of shoes. When processing orders, Giant Shoe Company wants to be certain that his shipping address is accurate (inaccurate addresses are very expensive in terms of customer service). They offer a discount for customers who make verifiable addresses available as part of the checkout process. Francis offers his certificate and gets the perfect shoes for even less than he expected.
R.2 Adult beverages
June goes to her local beer and wine store to buy a bottle of wine. She submits her identity credential that lets the liquor store owner know that she is over 21 without having to reveal her actual date of birth, her address, or her state ID number.
R.3 Fraud detection
On a bright Sunday, Oskar remembers that he still needs to buy his wife a precious gift for their wedding anniversary. However, he is acutely aware that it is precisely in weekends that gangs set up fraudulent web shops that claim to sell such gifts, while in fact they only take the cash, and disappear on Mondays. So before actually purchasing a gift from the web shop of his choice, he requests the shop to provide a credential issued by the chamber of commerce, that contains proof of legitimacy. After having verified that the shop is legit, he can purchase his gift.

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

F.1 Reuse know your customer
Jane is opening an account at MidBank in Finland. As part of that process, the bank asks her to provide two from a variety of possible sources to confirm her identity — a so-called "Know Your Customer" check. She selects government-supplied verifiable credentials that confirm she receives postal mail at a certain address and that she has a national ID card. Confirming these allows the bank to open her account and be confident in her identity when she conducts transactions.
Now that the account is open, Jane is issued a digitally-signed credential for her checking account at MidBank. This credential verifies that Jane has an account at MidBank and has access to her associated checking account. Since MidBank (and all banks in Finland) are required to perform "Know Your Customer" checks on accounts, this credential can also be used as sufficient verification by other financial institutions. This can help Jane assure destination banks that she is verified, thereby allaying concerns about misdirected transactions and money laundering.
F.2 Money transfer
Susan wants to send funds to her family in another country via a popular money transfer service. She has verifiable credentials in her credential repository that can be used to share her identity profile. She has also been sent a credential from her family verifying their banking information. By sharing these with the money transfer service, they can automatically verify the source and destination of funds, thus being confident in the delivery of those funds and satisfying various regulations regarding prevention of money laundering.
F.3 Closing account
John opens a checking account at Big Bank Co and is issued a verifiable credential indicating that the account exists, that the bank verified John's identity, and that John has access to the account. Some time later, John is moving to a new city and decides to close that account. Big Bank Co needs to revoke that claim as part of their normal account closing process.
F.4 Trying out a new service
Nikita has several accounts with BigBank, as well as a brokerage account with WallStreetCo. She had placed all of her claims in a credential repository at BigBank that came free when she opened her accounts. WallStreetCo is now offering a new repository that has an interface she thinks she will prefer. Nikita copies her claims from BigBank into the repository at WallStreetCo to experiment with their service, but continues to use the service from BigBank while she is testing.
F.5 New bank account from home
Alice wants to open a new bank account. BigOnlineBank offers the ability to do this from home if she can provide electronic credentials. She offers government-issued certificates that verify her identity (address, national identity number, etc.), and opens her new account from her couch.

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

H.1 Prescribing
Barney is a physician, and has recently become board certified in his state. The state's board issues Barney a digital certificate confirming that he is certified to practice medicine in that state. Barney can now use this certificate when writing prescriptions and referrals, thereby improving accountability and verifiability.
H.2 Online pharmacy
iPharmacy receives a prescription for Bob electronically from a local clinic. It includes a certificate about the physician that issued the prescription as well as one about Bob. iPharmacy's system automatically verifies the ability of the physician to write prescriptions, as well as Bob's insurance coverage. When Bob arrives to pick up his medication, iPharmacy further correlates his identity with the certificate, thereby improving the end-to-end accountability of their system.
H.3 Insurance claim
Tracy has a sore throat soon after moving to a new town. She finds a physician through her health care network and goes in for treatment. She is a new patient, so the clinic needs to know who she is and how she will be paying. When checking in, she presents her verifiable credential that demonstrates her identity and her proof of insurance. When the clinic submits this to the insurance company, they can automatically ascertain that she submitted her proof of identity and insurance to the provider and granted the physician the ability to submit the claim for payment.
H.4 Traveling illness
John is on the vacation of a lifetime, travelling the world. Falling ill, he visits a health clinic in a country in which he does not live. At the clinic, he is asked for proof of identity. He provides a credential that verifies his name and address, but elects not to disclose his marital status nor his social security number, as those are neither requested nor required at this clinic. He further marks the disclosure as expiring in 30 days—he does not want his information verifiable after that time.
H.5 Proving Legal Disability Status
Trina, who is legally blind, is currently unemployed, and needs to use the local free disability ride service to get to the employment office. To use this service, she is required to verify that she maintains legal disability status. Trina provides her government-issued disability credential to sign up for the ride service, and is not required to disclose her specific disability to the ride service, as this could put her at personal risk.

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

C.1 Find a doctor
Jason is looking for a new primary care physician. His health provider includes information on their web site about the physicians they have on staff, including verifiable credentials about their education, board certification, and continuing education. Jason can verify these credentials and be confident that his new physician satisfies his requirements.
C.2 Busy doctor
Barney was a board-certified physician, but he ran out of time to complete his continuing education requirements and his certification lapsed. Since the board can revoke his certification, credential verifiers will automatically be aware that he can no longer issue prescriptions or perform medical procedures.
C.3 Bad university
Jane was issued a certificate by BigTraining Co., indicating that she was a trained Project Manager. It was later discovered that BigTraining Co. was not actually training anyone, and their organization's certificate was revoked via the US Department of Education's Accreditation Database. Jane's credential is therefore invalid, and prospective employers will be aware of this when they check her certifications.
C.4 New employer
Jessica is a medical doctor practicing in the United States. She has a variety of digital claims that explain her qualifications, schooling, continuing education achievements, and board certifications. These are all stored in the credential repository provided by her employer. When she is offered a position with another health provider network, she can automatically transfer all of these claims to her new employer.
C.5 Social authority
Josie is a healthcare worker that has created a profile on a professional social network to make herself readily available for new opportunities in the workforce. She lists her employment history and credentials including degrees, certificates, and digital badges. The website requests verification of her credential claims in order for her credentials to be visible when she posts messages. Josie authorizes the sharing of the relevant claims with the website, and the site verifies them before allowing Josie to expose them.
"Freedom?" is an online forum that encourages free discussion about issues controversial in Freedonia. The forum allows users to register anonymous accounts, but it also allows users to obtain badges based upon real-world certifications. Paula has been certified as an aid worker, and wishes that information to be marked on her posts. She shares her certificate with the forum, but limits it to only verifying that she is the holder of the certificate, that she is the subject of it, and that she is an aid worker. In this way she maintains her anonymity in this controversial forum while still being able to assist her fellow countrymen.
C.6 Job applicant
Software Co. has posted an open position online and they are receiving thousands of applications. Cindy has applied for the job. Unlike many applicants, she has attached her education credentials—college degree, additional specific software training, etc. Software Co. evaluates these credentials automatically as they receive her application. Because her materials are verifiable and verified, her application is immediately forwarded as a viable candidate.

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

D.1 Devices during manufacturing

Bob, the director of production at HVAC Manufacturing, issues a device-identifying verifiable credential (e.g. IDevID, IAK) at the factory for an energy-saving fan controller IoT device.

Carol, senior quality engineer at Certifications Testing Lab, issues a certification of specification-compliance verifiable credential to the fan-controller device at the certification lab during the manufacturing process.

When the fan controller is installed at the customer's office at Modern Office Spaces, the controller's identifying credential can be verified by Sam, IT technician, to establish the identity of the controller as part of the on-boarding of the new controller. The controller's specification-compliance credential is verified to demonstrate the controller's Energy-Star compliance.

D.2 Devices during delivery

As the fan controller leaves the factory, additional verifiable credentials are issued by Vince, a systems engineer at VAR Resellers, as he verifies the manufacturer's configuration matches the verifiable credentials accompanying the device. He then installs a software package specific to Modern Office Spaces needs and issues verifiable credentials that establish evidence of possession by VAR Resellers and the software additions Vince made to the device.

Finally, upon delivery to Sam, the end customer, the verifiable credentials show that the fan controller has been securely handled and contains the correct features and certifications.

D.3 Devices setup for operating autonomously

Sam, the new device owner, needs to trust the device originated from HVAC Manufacturing and was handled correctly at Certifications Testing Lab and installed with the correct software package at VAR Resellers. After Sam verifies each of the verifiable credentials, he issues another verifiable credential for fan controller #37 which includes assertions relating to trust: device manufacturer model/version, software manufacturer model/version, security versions of components TCB, and associated devices the fan controller is authorized to interact with including thermostat-board-room.

The thermostat-board-room monitors room temperature. When the temperature is too hot it switches the fan controller #37 on and later when the temperature reaches a comfortable level, off. The device makes sure the control signals from thermostat-board-room are authorized (namely, that Sam intended for thermostat-board-room to control the fan controller).

Sam is concerned about the security of the smart board room. He configures the autonomously interacting devices to re-verify device trustworthiness attributes periodically by re-checking that the device originated from HVAC Manufacturing and was handled correctly by Certifications Testing Lab and installed with the correct software package by VAR Resellers.

Sam may update the device’s software occasionally during its lifetime. Even though Sam is applying the update, VAR Resellers supplies the correct update. The device ensures that only VAR Resellers is able to supply the updated software image and that only Sam is able to apply the update.

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

Note

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.

Verifiable Credential User Tasks
Figure 3 Verifiable Credential User Tasks

4.1 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 Reuse know your customer, E.1 Digital transcript, L.1 Digital driving license, H.1 Prescribing

4.2 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 Adult beverages, H.4 Traveling illness

4.3 Verify Claim

Requirement
It MUST be possible for a verifier to verify that the credential is an authentic statement of an issuer's claims about the subject. The verifying entity must have the capability to connect the issuer’s identity to its credential identifier and the subject's identity to their identifier as indicated in the credential. The issuer’s verification information, such as its public key, must be discoverable from the credential record and verifiably linked to the issuer. It MUST be possible to do this in an automated fashion.
Motivations
In many environments (such as order processing) information such as a payer's address, citizenship, or age need to be automatically verified in order to complete the transaction.
Needs
F.2 Money transfer, C.1 Find a doctor, E.2 Taking a test, R.1 Address verification, F.5 New bank account from home, H.2 Online pharmacy, C.6 Job applicant

4.4 Store / Move Claim

Requirement
It MUST be possible for the holder of a claim to store that claim in one or more credential repositories. It MUST also be possible for the holder to move a claim among credential repositories, and to do so without requesting a new claim from the claim issuer.
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 Trying out a new service, E.3 Transferring schools, C.4 New employer

4.5 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 Social authority, E.4 Online classes

4.6 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 Closing account, C.2 Busy doctor, C.3 Bad university

5. Focal Use Cases

Focal Use Cases are meant to provide examples where a blend of features from verifiable credentials standard may be used together to solve complex or challenging marketplace needs.

5.1 Citizenship by Parentage

Background

Sam wants to claim US citizenship because his mother is American. Sam has a digital birth certificate from Kenya, where he was born while his Mother was in the Peace corps. He also has a digital version of his mother's US passport. Because his mother’s name changed between his birth and the issuance of the passport, Sam also has a marriage license with her maiden and married names. Sam is applying for a new passport from the US Secretary of State.

Distinction

This use case is challenging because the mother’s name changed, by marriage, between the issuance of the birth certificate and passport.

Scenario

Sam’s mother emailed him the certificate, license, and passport as independent Verifiable Credentials. He then creates a verifiable presentation which includes those credentials, a statement of their relationship to each other and his relationship to his mother. He then visits the US Secretary of State website, creates an account, starts the application for a passport, and uploads his new verifiable presentation as supporting evidence. After processing the application, Sam is issued both a traditional passport and a new digital passport.

Verifiable Credentials

Birth Certificate
Establishes relationship to mother with maiden name
Marriage License
Establishes mother's name change
Mother’s Passport
Establishes mother's US citizenship
Sam’s Passport
Establishes Sam is the child in the birth certificate

Verifiable Presentation

A verifiable presentation which includes those three credentials, adds his name, photo, and demographic data along with the assertions that —

Trust Hierarchy

Sam is legally liable for his claim to the rights of citizenship. The state department is on the hook for verifying the underlying credentials and Sam’s claims, including correlating against any additional data they might already have.

Threat model

5.2 Expert Dive Instructor

Background

Pat earned multiple diving credentials while living and working in Fiji and Australia. Later, Pat is hired by NOAA as a Dive Instructor, which requires that they maintain certification as an instructor with additional specialist diver certifications in dry suit, night diving, and search and recovery. The dive instructor certification is public record, but the additional specialist certifications are private because they are for personal diving, not acting as an instructor.

Part of Pat's job is logging the certifications of fellow divers during NOAA sanctioned dives.

Distinction

This use case is difficult because:

Scenario

When Pat applied for his job at NOAA, he provided verifiable credentials issued by different dive schools licensed by PADI to do so. NOAA verifies cryptographically that the certifications were issued by PADI-approved dive schools and that the credentials were still in good standing by checking both the certifications' *and* the dive schools' revocation services.

Upon accepting the job, Pat issues NOAA a revocable token that allows NOAA to check the current status of all of his certifications — not just the status of a single verifiable credential. After any specific certification expires — and Pat renews it — NOAA's next check of Pat's certifications returns the status of the renewed certification, not just the status of the (now expired) verifiable credential.

When Pat takes a group of divers on NOAA sanctioned dives, he records the verifiable credentials for each diver (which demonstrate their diving certifications), creates a verifiable credential including those credentials; he signs and archives it on his laptop.

When Pat retires from NOAA, he revokes that token and NOAA staff is no longer able to monitor his non-public certification status.

Verifiable Credentials

Verifiable Presentation

Trust Hierarchy

Threat model

5.3 International Travel with Minor and Upgrade

Background

Malathi is traveling internationally with her 8-month-old son, Anand. His father, Rajesh, is staying home. Malathi has enough frequent flyer miles to upgrade the ticket to first class.

Distinction

This use case is difficult because:

Scenario

Malathi obtains permission from Rajesh stating she is allowed to take the baby out of the country.

Prior to booking the trips, Malathi visits HappyAir.com to request an upgrade to first class. HappyAir issues a verifiable credential redeemable for a first class upgrade on an international flight.

She books the plane tickets through her travel agent who adds the lap child to the ticket.

HappyAir verifies that Malathi has a signed statement from Anand’s other parent stating that she may exit the country with him.

Verifiable Credentials

Malathi's passport
Establishes identity of the traveling parent
Anand's passport
Establishes identity of the minor
Anand's Birth Certificate
Establishes relationship to parents and provides link from Rajesh to Anand that qualifies the permission to travel
Permission to travel from Rajesh
  • Grants permission from non-traveling parent for minor to travel.
  • Identity matches identity of the parent in the birth certificate, establishing relevance.
Upgrade coupon for first class ticket
Introduces commercial value in a verifiable credential

For details, refer to Example Verifiable Credentials in Appendix

Verifiable Presentation

Submitted to HappyAir, includes Malathi and Anand's passport, assertion of permission, birth certificate and Frequent Flyer coupon.

Trust Hierarchy

Threat model

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

6.1 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
Figure 4 Verifiable Credential Creation Flow Diagram

Expanding on these steps:

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

6.2 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
Figure 5 Verifiable Credential Usage Flow Diagram
  1. Jane decides to shop on the website WinesOfTheWorld.example.com (merchant).
  2. The merchant's site requires Jane be 21 years of age and requests (via a user agent-supported API call) that Jane prove this.
  3. Jane's user agent asks her credential repository for the proof.
  4. 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).
  5. Jane selects one of these, and authorizes that it be shared with the merchant.
  6. 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.
  7. The merchant's server verifies that the claim is valid and satisfies the requirement.
  8. The merchant redirects the user agent to the web site with appropriate authorization.

A. Terminology

This section is non-normative.

The following terms are used to describe concepts in this specification.

claim
An assertion made about a subject.
credential
A set of one or more claims made by an issuer. A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified. The claims in a credential can be about different subjects.
entity
A thing with distinct and independent existence, such as a person, organization, or device that performs one or more roles in the ecosystem.
holder
A role an entity might perform by possessing one or more verifiable credentials and generating presentations from them. A holder is usually, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories.
issuer
A role an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder.
presentation
Data derived from one or more verifiable credentials, issued by one or more issuers, that is shared with a specific verifier. A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs).
repository
A program, such as a storage vault or personal verifiable credential wallet, that stores and protects access to holders' verifiable credentials.
subject
A thing about which claims are made.
verification
The evaluation of whether a verifiable credential or verifiable presentation is an authentic and timely statement of the issuer or presenter, respectively. This includes checking that: the credential (or presentation) conforms to the specification; the proof method is satisfied; and, if present, the status is successfully checked.
verifier
The entity verifying a claim about a given subject.

B. Example Verifiable Credentials

Focal Use Case: International Travel with Minor

Example 1: Malathi's passport (simple model)
{
  "@context": [
    "https://w3id.org/credentials/v1",
    "https://example.com/travel-vocab/v1"
  ],
  "id": "urn:uuid:9f6878c8-73c7-11e8-ab37-23a1a3504fd0",
  "type": ["VerifiableCredential", "PassportCredential"],
  /* gov't DID */
  "issuer": "did:example:CCnF3zFaXkPN4zB94XaomRdvw2zX3XHPVX3aExcgo6PV",
  "expires": "2028-01-01T00:00:00Z",
  "claim": {
    "id": "did:example:BcRisGnqV4QPb6bRmDCqEjyuubBarS1Y1nhDwxBMTXY4",
    "givenName": "Malathi",
    "familyName": "Hamal",
    "citizenship": "US",
    /* any other claims made by gov't */
  },
  "proof": {/* signature by gov't */}
}
Example 2: Malathi's passport (passport is a document model)
{
  "@context": [
    "https://w3id.org/credentials/v1",
    "https://example.com/travel-vocab/v1"
  ],
  "id": "urn:uuid:9f6878c8-73c7-11e8-ab37-23a1a3504fd0",
  "type": ["VerifiableCredential", "PassportCredential"],
  /* gov't DID */
  "issuer": "did:example:CCnF3zFaXkPN4zB94XaomRdvw2zX3XHPVX3aExcgo6PV",
  "expires": "2028-01-01T00:00:00Z",
  "claim": {
    "id": "did:example:BcRisGnqV4QPb6bRmDCqEjyuubBarS1Y1nhDwxBMTXY4",
    "passport": {
      "id": "urn:uuid:79c181dc-73c7-11e8-8c1f-2bb1fd2d268a",
      "type": "Passport",
      "traveler": {
        "id": "did:example:BcRisGnqV4QPb6bRmDCqEjyuubBarS1Y1nhDwxBMTXY4",
        "givenName": "Malathi",
        "familyName": "Hamal",
        "citizenship": "US"
      },
      /* any other passport fields */
    }
  },
  "proof": {/* signature by gov't */}
}
Example 3: Anand's passport
{
  "@context": [
    "https://w3id.org/credentials/v1",
    "https://example.com/travel-vocab/v1"
  ],
  "id": "urn:uuid:b306614c-73c7-11e8-b596-47e8c5ce9144",
  "type": ["VerifiableCredential", "PassportCredential"],
  /* gov't DID */
  "issuer": "did:example:CCnF3zFaXkPN4zB94XaomRdvw2zX3XHPVX3aExcgo6PV",
  "expires": "2020-01-01T00:00:00Z",
  "claim": {
    "id": "did:example:8vFBbPrhBUyG6DEzVncBZpzBNsmRrbfsQKXQKPLskBCu",
    "givenName": "Anand",
    "familyName": "Hamal"
    "citizenship": "US",
    /* any other claims made by gov't */
  },
  "proof": {/* signature by gov't */}
}
Example 4: Anand's birth certificate
{
  "@context": [
    "https://w3id.org/credentials/v1",
    "https://example.com/travel-vocab/v1"
  ],
  "id": "urn:uuid:05a47fe2-73c8-11e8-ac1e-7fe0051a1d75",
  "type": ["VerifiableCredential", "BirthCertificate"],
  "issuer": "did:example:CCnF3zFaXkPN4zB94XaomRdvw2zX3XHPVX3aExcgo6PV",
  "expires": "2020-01-01T00:00:00Z",
  "claim": {
    "id": "did:example:8vFBbPrhBUyG6DEzVncBZpzBNsmRrbfsQKXQKPLskBCu",
    "citizenship": "US",
    "birthDate": "2017-10-01T00:00:00Z",
    "birthPlace": {
      "type": "Hospital",
      "address": {
        "type": "US address",
        "addressLocality": "Denver",
        "addressRegion": "CO",
        "postalCode": "80209",
        "streetAddress": "123 Main St."
      }
    },
    "givenName": "Anand",
    "familyName": "Hamal",
    "parent": [{
      "id": "did:example:BcRisGnqV4QPb6bRmDCqEjyuubBarS1Y1nhDwxBMTXY4",
      "type": "Person",
      "givenName": "Malathi",
      "familyName": "Hamal",
      "maidenName": "Holla"
    }, {
      "id": "did:example:BgXRjB4RPrrsUVoVNaYNwzfznKsWep7AWrZkiyVcorEN",
      "type": "Person",
      "givenName": "Rajesh",
      "familyName": "Hamal"
    }]
  },
  "proof": {/* signature by gov't */}
}
Example 5: Permission to travel from Rajesh using schema.org vocab
{
  "@context": [
    "https://w3id.org/credentials/v1",
    "https://example.com/travel-vocab/v1"
  ],
  "id": "urn:uuid:58c08196-73c6-11e8-b030-3bd8a829a356",
  "type": ["VerifiableCredential", "ChildTravelPass"],
  "issuer": "did:example:BgXRjB4RPrrsUVoVNaYNwzfznKsWep7AWrZkiyVcorEN",
  "expires": "2018-07-01T00:00:00Z",
  "claim": {
    "id": "did:example:8vFBbPrhBUyG6DEzVncBZpzBNsmRrbfsQKXQKPLskBCu",
    "potentialAction": {
      "type": "TravelAction",
      "agent": "did:example:8vFBbPrhBUyG6DEzVncBZpzBNsmRrbfsQKXQKPLskBCu",
      "participant": "did:example:BcRisGnqV4QPb6bRmDCqEjyuubBarS1Y1nhDwxBMTXY4",
      "location": {
        "type": "Country",
        "address": {
          "addressCountry": "CA"
        }
      }
    }
  },
  "proof": {/* signature by Rajesh proving control of DID */}
}

C. Acknowledgements

This section is non-normative.

The editors are thankful to the contributions from the Web Payments Workshop, the Web Payments Community Group, the Web Payments Interest Group, the Credentials Community Group, the Verifiable Claims Task Force, and the Verifiable Claims Working Group.

D. References

D.1 Informative references

[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986