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.
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.
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.
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.6
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.
L.1 Digital driving
license
Asako just passed the final test to receive a drivers
license. As she is still a new driver, and may be pulled
over for a traffic violation, she would like to receive a
credential that asserts a
claim that she has right to drive a car. She
requests a credential from the certifying authority
(issuer) that she can use to
prove to the officer (credential
verifier) that her claim is valid.
L.2 Seamless
immigration
Tom is a frequent international traveler. In order to
speed processing through immigration check points, he
applies for a digital passport from his governmental
authority. After satisfying background check requirements,
the authority issues Tom an electronic version of his
passport. This version is verifiable and retains a history
of all the places he visits so that immigration officials
can quickly and easily evaluate his suitability as a
visitor to their country. Once they are satisfied, they
will automatically add the details of this new visit to
Tom's passport.
L.3 Speedy air travel
Security for air travel is more and more rigorous,
requiring more and more time to validate each passenger.
Ivan has a collection of verifiable credentials that are
assembled into his air travel Identity Profile.
When Ivan needs to pass through a security checkpoint at
his airport, he presents this profile before entering the
line. Because his identification can be immediately and
automatically verified, he is permitted to skip the long
line and go straight to the metal detector.
L.4 Refugee crisis
Thousands of people each year are displaced because of
man-made and natural disasters. Anoushka is one such,
having been forced to flee her village along with her
mother and younger brother. They reach an IFRC center just
across the border in a relatively safe area, but with no
documentation. Since the government of her homeland is in
turmoil, there is no way for the IFRC staff to easily
establish their identities. Fortunately, Anoushka had been
issued a self-sovereign proof of birth, attached to which
is the proof of birth and marriage for her parents. She is
able to retrieve this because it is available from many
places often the Internet. Since it is verifiable, the IFRC
is comfortable vouching for them and resettling them in a
safer area for the duration of the conflict.
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.
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.
It MUST be possible
for a verifier to verify that the
credential is an authentic statement of an issuer'sclaims 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.
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 claimissuer.
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.
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 —
He is the child in the birth certificate.
The mother in the birth certificate, the person in the
passport, the spouse in the marriage license are all the
same person.
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
Threat: Terrorist / Identity fraud. A
bad actor could be impersonating Sam to attain a
passport. Of course, if a bad actor were to be able to
collect the required verifiable credentials—mother’s
passport, birth certificate, and marriage license, that
actor has already significantly compromised the system.
Response: Identity assurance based
on the presentation
and other data, above and beyond what is in the
presentation and the
claims.
Response: Identity assurance based
on the contents of the claims,
potentially with enhanced data embedded in the
claims, i.e., data not
currently in passports, birth certificates, or
marriage license. For example, a biometric template
could be embedded in the birth certificate claim and that template could be used for
interactive identity assurance at the time of
submitting the presentation.
Threat: Exposure of private information.
By storing potentially compromising information in
credentials and sending them
over the network, we are increasing the attack surface
for the subjects of those credentials.
Response: Encrypt the claims (once by issuer, every verifier gets the same encrypted blob)
Response: Encrypt the claims uniquely for each verifier. This may leak usage data to the
issuer, assuming the
holder must ask for a new,
encrypted credential for
each verifier.
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:
Certification in Fiji and Australia. NOAA relies on an
international certification agency, PADI, with relevance in
multiple jurisdictions.
Each of these credentials is
issued by different schools in the name of PADI.
Each credential has an independent
expiration cycle.
Pat grants NOAA permission (the capability) to validate
future credential status changes.
On each trip, Pat creates a certified log of all
divers, effectively issuing a verified credential about other
credentials.
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.
PADI is liable for correctly certifying dive
schools.
Dive schools are liable for correctly certifying Pat's
knowledge and skills.
Pat is liable for representing the facts in their
application and maintaining the revocable capability.
NOAA is liable for verifying the
credentials and Pat's assertions claiming them, and
for assuring Pat's continued good standing for the
required credentials.
Pat is liable for making sure all divers, on each trip,
have valid credentials and are properly
logged.
Diver's are liable for presenting valid
credentials, specifically credentials
for which they are the subject, including
any formal identity credentials, e.g.,
passport or driver's license.
Threat model
Threat: Issuer is
compromised. One of the dive schools had their
private keys stolen, but the school itself only ever
issues valid certificates.
Response: Use multi-sig to prevent
theft of a single key from relevance
Response: Hardware wallet to
minimize threat of network-based attack
Response: Biometrically locked
hardware wallet
Response: Frequent rotation to
minimize exposure from stolen keys
Response: Enhanced background
checks for all individuals with access to keys
Response: Instead of institutional
keys, sign certificates with individuals' keys plus
credential from the school.
Threat: A dive school could issue unearned
certificates.
Response: Audit certificate
issuance. Record all issuance, systemically spot check
for validity.
Response: Background checks on
schools prior to authorization
Response: Limit the number of
certificates that can be issued to limit impact of
violation
Response: Limit time horizon that
the school may issue on behalf of PADI to require
re-validation of qualifications
Response: Use revocation
mechanisms for school's authorization credentials
Threat: Dive school could issue certificates with
a revoked authorization.
Response:Holders
should verify the authorization, before they buy the
course
Response:Holders
should verify the authorization at the point of
receiving the credential
Response:Verifiers should also verify the
authorization of the issuer
Threat: Pat could send a proxy to earn their
certificate.
Response: School should use
multi-factor identity assurance during registration and
onsite when testing.
Response: Dive school retains
video surveillance of event for future audits
Response: Dive boat or test center
takes photos of participants and logs them for later
audit
Threat: Pat or another dive master could lie
about a diver being on the boat.
Response: NOAA requires divers
listed to submit endorsement that they were there (they
endorse the dive log); divers mutually sign each
other's log entries
Response: Boat owner signs dive
log
Response: Pre-register excursion
and expected diver list
Response: Ongoing signed
provenance data about Pat's job assignments (location,
dates, correspondence, etc) by/with NOAA Manifest
"souls on board" before/after including crew
Response: Independent ID proofing
of offline credentials (signed picture and/or photo
ID)
Threat: Malware could take control of issuer or verifier
agent.
Response: Run virus and malware
scans regularly
Response: Isolate issuer agent
system to an air-gapped environment
Threat: Pat is phished, and Pat gives capability
to the wrong person/entity.
Response: Use better identity
assurance for the verifier, i.e., don't give capability
to strangers.
Response: Use Object Capabilities
based on strong authentication and well-known public
keys.
Threat: Issuer spoofs Pat,
and Pat receives VC from non-PADI-certified
instructor.
Response: Pat runs PADI's wallet
software to make sure any certificates they receive are
authentic.
Response: Pat checks the VC with a
PADI-provided tool before accepting it
Response: Pat checks the VC with a
standard tool, to see that (1) There really is a PADI
authentication and (2) PADI authentication is actually
from PADI
Threat: Pat presents a fake credential as a PADI
certification.
Response: NOAA verifies the
signature on the certification credential AND on the
PADI authentication credential.
Threat: Pat's laptop on the boat could be
compromised.
Response: Use air-gapping
techniques, such as QR codes, to limit impact of
compromise
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:
Current US passports do not establish explicit
relationship between parent and child.
When one parent travels with a minor, the other parent
is required to grant permission for the trip, thus implying
guardianship or responsibility.
The DID or other Digital Identity system replaces the
role of the notary in the paper/physical world
Credentials must be coordinated between two verifiers
(agent and airline) for two individuals, and a digital
coupon is used.
The relationship of the minor to the non-traveling
parent must be established, in order for the permission to
be considered.
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.
Submitted to HappyAir, includes Malathi and Anand's
passport, assertion of permission, birth certificate and
Frequent Flyer coupon.
Trust Hierarchy
Malathi is liable for her claim of parentage as well as
securing right to admission for herself and her son at
their destination (visa may be required).
Malathi and Rajesh are both liable for attestation of
permission to fly with Anand without the other parent.
Malathi is liable for the cost of her ticket and her
son’s ticket.
The agency is liable for issuing valid tickets and for
verifying the credentials provided by the travelers.
The airline is liable for issuing tickets and,
ultimately, fulfilling the terms of travel
The airline is liable for accepting the upgrade coupons
at ticketing.
The airline is liable for verifying the credentials in
the birth certificate match the credentials in the
permission letter.
The check-in agent, TSA agent, and passport control at
the destination are liable for identity assurance at
various points of travel, using information contained in
the verifiable
credentials.
Threat model
Threat: Stolen Key. Malathi steals
Rajesh’s key in order to fake travel permission.
(Kidnapping her own kids and fleeing Rajesh.)
Response: Rajesh could store his
key with a trusted third party, such as an
attorney.
Response: Rajesh could use a
hardware wallet with pin or biometric.
Response: Rajesh could use a
passphrase on his key
Threat: Stolen Key 2 Ticket purchaser
has Malathi’s credentials,
impersonating her to purchase a ticket. This could enable
a third-party kidnapping.
Response: Travel permission can be
restricted to specific date and or trip minimizing
abuse potential.
Response: Embed identifying
characteristics or biometric into the credentials so
that verifiers can independently verify the subject in front of them is the subject in the credential.
Response: Malathi could use a
hardware wallet with pin or biometric.
Response: Malathi could use a
passphrase on her key
Threat: Exposure of private information.
By storing potentially compromising information in
credentials and sending them over the network, we are
increasing the attack surface for the subjects of those credentials.
Response: Encrypt the claims (once by issuer;
every verifier gets the same
encrypted blob)
Response: Encrypt the claims uniquely for each verifier. This may leak usage data to the
issuer, assuming the
holder must ask for a new,
encrypted credential for
each verifier.
Response: Encrypt the presentation uniquely for
each verifier. No issuer involved
Threat: Stolen coupon Rajesh falsifies
the upgrade coupon.
Response: HappyAir signs the
coupon with secure credentials.
Response: Travel agent verifies
the coupon through a distributed status registry,
verifying it is still valid
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:
Expanding on these steps:
Jane asks her User Agent to help her get a verifiable credential about her
identity.
They are satisfied, so the issuer
generates a verifiable
credential for Jane that includes information about
her identity linked to their own trusted credential.
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.
A.
Terminology
This section is non-normative.
The following terms are used to describe concepts in this
specification.
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.
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).
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.
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.