Introduction
The Verifiable Claims Working Group at the W3C is developing standards for
expressing and exchanging "claims" that have been verified by a third
party and to make them easier and more secure on the Web.
This document does NOT attempt to define an architecture for the support of
Verifiable Claims. Instead it expresses the sorts of needs that real users have
that could be addressed through support for some sort of self-sovereign claim
environment. It attempts to use terminology that is consistent with the other
deliverables of the Verifiable Claims Working Group (you can see the relevant
terms in Appendix A).
Importance of this work
Entities (people, organizations, devices) need to make many kinds of
claims as part of their everyday activities. As more and more of these
important activities move to the Internet, entities need to be able to
transmit instantly verifiable claims (e.g., about their location,
accomplishments, value, what-have-you). From educational records to payment
account access, the next generation of web applications will authorize
entities to perform actions based on rich sets of credentials issued by
trusted parties. Human- and machine-mediated decisions about job applications,
account access, collaboration, and professional development will depend on
filtering and analyzing growing amounts of data. It is essential that data be
verifiable.
Standardization of digital claim technologies makes it possible for many
stakeholders to issue, earn, and trust these essential records about their
counterparties, without being locked into proprietary platforms.
Use case model
This document presents an aggregate use case model, 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.
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.
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.
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:
-
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.
Verifiable Credentials
-
Advanced Open Water Instructor
-
Drysuit Dive Certification
-
Night Diving Certification
-
Search & Recovery Dive Certification
-
Fiji PADI School Affiliation Certification
-
Australia PADI School Affiliation Certification
-
Signed log entry of dive event
Verifiable Presentation
Trust Hierarchy
-
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
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 of the passport is a
parent, 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.
-
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
-
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.
-
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
Example Verifiable Credentials
Focal Use Case: International Travel with Minor
{
"@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 */}
}
{
"@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 */}
}
{
"@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 */}
}
{
"@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 */}
}
{
"@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 */}
}
