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 is a
preview
Do not attempt to implement this version of the specification. Do not
reference this version as authoritative in any way.
Instead, see
https://w3c.github.io/vc-use-cases/ for the Editor's draft.
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
in conjunction with the proposed Charter for a Verifiable Claims Working Group.
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 will address.
User needs define the problem space verifiable claims addresses. User Roles specify
the roles different entities play when interacting with verifiable claims. 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 claims: Issuer, Verifier, Subject, and Holder.
Figure 1 Verifiable Claims 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 claims address user needs in a number of key domains:
Figure 2 Verifiable Claims, Example Domains for User Needs
3.1 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 claims 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 claims in her
credential repository that can be used to share her identity profile.
She has also been
sent a claim 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 claim
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.2 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 claims 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 claim regarding the results of
his test.
3.3 Healthcare
Privacy is critically important in the healthcare industry. This domain looks at
everything from physicial 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 claim that demonstrates her identity and her proof of
insurance. When the clinc 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.
3.4 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.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 contuning 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 claims 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 easilty establish their identities.
Fortunately, Anoushka had been issued a self-soverign 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.
4. User Tasks
Use cases are often used as a driver for requirements. While the users of verifiable claims 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.
Figure 3 Verifiable Claims User Tasks
4.1 Issue Claim
Requirement
It MUST be possible for any entity to issue a verifiable claim.
Motivation
Individuals and organizations need a way to issue
claims about themselves or others that can be verified and
trusted.
It MUST be possible for the holder of a claim to
restrict the amount of information exposed in a claim 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'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.
It MUST be possible for a verifier to determine
what pairs of (credential type, issuer) it accepts as valid,
i.e. trusts to be valid, for what purposes.
It SHOULD be possible that VCs that may contain the same information,
but that are issued by different issuers, are all acceptable for one purpose,
but only specific issuers would be allowed for another purpose.
Every verifierMUST make its own decisions in this regard.
As a consequence, it MUST be possible for a verifier to obtain
all information that it finds relevant for making such determinations,
and hence also for issuers to publish (advertise) such information.
It is envisaged that such information would include
syntax and semantics of the claims in the credential,
an endpoint at which the issuer issues these credentials,
and (optionally) other meta-data, such as liability that the issuer takes,
compensations for issue/use of such credentials, procedures that the issuer has followed
to verify the truthfulness of issued claims, etc.
Motivations
Whenever a holder requests a verfier to provide a product or service,
the verfier must return a query for the claims (from issuers that it trusts, and)
that it needs to decide whether or not to provide the requested product or service.
In order for the verfier to decide whether or not it trusts credentials from identifiable issuers,
it needs information, e.g. about the kinds of claims in such credentials, the way that the issuer has verified them, and more.
This requirement becomes increasingly important as the transactions that the verfier must decide on,
come with a higher value (and hence a higher risk).
Needs
every use-case
4.5 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.
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
claims 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 assertion 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.
Response: Blind the claims uniquely for each verifier.
Response: Encrypt the presentation uniquely for each verifier. No
issuer involved.
5.2 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.
In the minor's passport case, the subject is not the holder of the verifiable
credential. The holder(s) of the passport are parents, not the minor.
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.
Issue 1
This is content from the prior discussion—remove the following points?
Parents are the holders of the passport credential
Parents must present the passport credential
In order for one parent to present the passport credential alone, they must give
mutual permission.
This replaces the role of a notarized permission document
Upgrade coupon for first class ticket
Introduces commercial value in a verifiable credential
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 [does the airline issue tickets or do the agents?].
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: Impersonating traveler. Handled by identity assurance, using
information within the credentials
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: False Parent Someone other than than Rajesh, e.g., Fred,
signs the travel permission with a valid key, allowing Malathi to travel without Rajesh’s
permission.
Response: Fred’s actions are fraudulent. Captured in the signed
statement, it would provide evidence for prosecution.
Response: Fred’s credentials won’t match those in Anand’s birth
certificate. By comparing the credentials, HappyAir can prevent this attack
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: Blind the claims uniquely 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 claims 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 Claim Might Be Created
In this first example, a user will request a verifiable claim—a
confirmation of their identity. Consider this illustration:
Figure 4 Verifiable Claim Creation Flow Diagram
Expanding on these steps:
Jane asks her User Agent to help her get a verifiable claim about
her identity.
Her user agent connects her to a certificate issuer that is able
to verify her identity.
The issuer examines her documentation.
They are satisfied, so the issuer generates a verifiable claim for
Jane that includes information about her identity linked to their
own trusted credential.
The issuer delivers the credential back to Jane's User Agent.
Jane views the credential to ensure it reflects her
requirements.
When she is satisfied, she instructs her User Agent to save the
verifiable claim so she can use it in the future.
The UA communicates with her credential repository,
instructing it to store the new claim.
The credential repository returns a list of the claims it is
holding for Jane to the UA.
The UA shows Jane her claim collection—confirming
everything she has available.
6.2 How a Verifiable Claim Might Be Used
In this example, a holder of a claim needs to use that claim in a
typical commerce situation:
Figure 5 Verifiable Claim 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 Jane prove this (via a user agent-supported API call).
The credential repository shows Jane three verifiable claims
it knows of that
can assert this 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 claim 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 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.