Do not attempt to implement this version of the specification. Do not
reference this version as authoritative in any way.
Instead, see
https://w3c-ccg.github.io/vc-api-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 alongside the VC API Specification.
This document was published by the VC API Working Group as a
Working Group Note.
GitHub Issues are preferred for
discussion of this specification.
Publication as a Working Group Note does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite this
document as other than work in progress.
This document was produced by a group
operating under the
W3C Patent Policy.
W3C maintains a
public list of any patent disclosures
made in connection with the deliverables of
the group; that page also includes
instructions for disclosing a patent. An individual who has actual
knowledge of a patent which the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
For Verifiable Credentials to be realized as a usable data format there needs to exist a neutral,
standard-governed way for Issuers, Holders and Verifiers of these credentials to transport them between said entities.
TODO: Finish introduction
1.1 Existing Work
TODO: fill in
2. Use Cases
3. Requirements
4. Features and Benefits
5. VC API Actions
5.1 Issuer to Holder
5.2 Present for Verification
5.3 Refresh
6. Focal Use Cases
6.1 Get Digital Permanent Resident Card
Lana is an IT administrator for the United States Citizenship and Immigration Services (USCIS)
Digital Permanent Resident Card (PRC) program. She configures the USCIS website to issue digital
Permanent Resident Cards by utilizing industry standard issuer software and setting up the appropriate
HTTP API Authorizations between systems. Legal Permanent Residents, upon receiving their physical card
in the mail, are given the USCIS website URL, a login account, and PIN code that they may use to manage
their account and pick up their digital Permanent Resident Card. When Louis, a Legal Permanent Resident,
requests a digital Permanent Resident Card via the USCIS website, he authenticates using his login account
and once authenticated, provides a DID associated with his client-side digital wallet against which the
website will issue VCs. The USCIS website then connects to the digital card issuing server, which builds
the Verifiable Credential Permanent Resident Card using Louis' account data, and then utilizes industry
standard HTTP APIs to issue the Permanent Resident Card as a Verifiable Credential. Louis can then use his
Digital Permanent Resident Card in online scenarios when he needs to prove his resident status, such as
when applying for a job.
Requirements:
1. Verify DID Authentication Presentation,
2. API Authorization,
3. Issue Verifiable Credential,
X. Website as Consumer
Contributed by: Digital Bazaar
Mermaid
6.2 Refresh Expired Over Age Token
Riley has onboarded into the TruAge digital age verification system, which has provided her
with a set of Verifiable Credentials that she stores in her digital wallet. A subset of the
Verifiable Credentials that she has received are digitally signed single-use age tokens that
only assert that she is above the age of 21 and are marked as "used" by the TruAge system
when they are submitted as a part of an age-restricted goods purchase, such as buying a
bottle of wine. Eventually, Riley runs out of single use age tokens in her digital wallet.
The digital wallet keeps track of which tokens have been used and once all tokens have been
consumed, contacts a refresh service endpoint listed in one of the TruAge credentials that
provides new over-age tokens. The digital wallet requests a new set of tokens by hitting the
HTTP API of this VC-refresh service listed in the “refreshService” array and POSTing the
original Verifiable Credential containing the refresh service description. The HTTP API
ensures that it has received a valid credential and reissues a set of new digitally signed
single-use age tokens in the response.
Requirements:
1. Start Presentation Flow,
2. Verify Presentation,
3. Issue Verifiable Credential,
4. Refresh Credential
Mermaid
Contributed by: Digital Bazaar
6.3 Execute Multi-stage Presentation Workflow
Description: Ignio, a logistics manager for "Kirk Company", would like to submit all necessary paperwork
to send his company's products across international boundaries. These products are considered hazardous
chemicals and thus are regulated, requiring extra paperwork to be filed before transportation is approved
across boundaries. Some hazardous material shipments are different resulting in different required paperwork,
and Ignio wants to automate as much of the process as possible with Shippers,
their 3rd Party Logistics company (3PL). There are a set of verifiable credentials that Ignio is willing to
share with Customs as well as the transportation company.
When Kirk starts a shipping workflow, his company's systems initiate the workflow by contacting a known
location on the Shipper's Website. A presentation exchange occurs to first DIDAuth the company and send
generic mandatory information for any shipment; if and only if the information provided requires additional
information‒in this case a hazmat certification‒a second exchange is initiated to request this outstanding/required
hazmat info. Once this is received, Shippers can send back a Bill of Lading in VC form. The two (or more)
credential exchanges are composable and idempotent, ending in a valid BoL if successful.
Requirements:
1. Verify DID Authentication Presentation,
2. API Authorization,
3. Issue Verifiable Credential,
X. Website as Consumer,
X. continuous workflow
Mermaid
Contributed by: Digital Bazaar
6.4 Aggregated Credential Workflow
Tod is using digital credentials to apply for a service/qualify for a job/gain access to a programme.
Some of his credentials are available today, some will need to be provided when they are ready
(for example, a criminal background check can take 24-48 hrs to process). He would like these credentials to
be presented to the Verifier (service provider) when ready, without having to constantly return to the Verifier
(service provider) and deliver them "by hand". He should be able to have them released from his Holder directly
as they become available.
Requirements:
X. Verifiable Presentation by policy,
X. Automated notifications,
X. Asynchronous release,
X. Authorized/pre-consented authorization,
X. VP formed with future VCs ("stateful VP")
X. Present Credentials issued by third party?,
Mermaid
Contributed by:SecureKey Technologies Inc.
6.5 Submit/Sign/Verify a test credential to a licensure system
A student, Shabazz, wants to publish their MBLEx test results from an education test provider,
Massage Therapy Test Corp. Massage Therapy Test Corp proxies their authority to sign to a service provider,
SSI Ventures. SSI Ventures issues Shabazz a VC when he logs into his Massage Therapy Test Corp account
and enables his browser-based SSI Wallet, Billfold. The signed VC is then stored in Shabazz’ Billfold™ Wallet
to be presented elsewhere.
In a separate session, Shabazz logs into a web portal of a State Massage Therapy licensure system to
apply for his Massage Therapy license. The licensure specialist at the State checks the issuer using a
State accreditation system, then checks the signature on the test results VC and ingests the
credential’s payload. The licensure specialist then finalizes their workflow and issues
Shabazz a Massage Therapy license.
Requirements:
1. VC Issuance
2. VC Presentation
3. Issuer Lookup (is that business logic?),
4. VP Verification
5. VC Verification
X. Website as Consumer.
X. Issuance-as-a-Service,
Mermaid
Contributed by:RANDA Solutions
6.6 Supply Chain Import
In order to export steel products to the global market, Steel Mills Global must prove
the quality of their products. For this, they rely on Inspectors & Co, an internationally
recognized steel testing company. Upon inspection, Inspectors & Co issues a
Mill Test Report VC to Steel Mills Global.
Steel, Inc. imports and distributes steel products domestically. Negotiating a shipment
Steel Mills Global presents the MTR as proof of product quality. Steel Inc. verifies the
MTR VP and accepts the shipment.
Steel, Inc. initiates the importing procedures, starting out self-issuing an
Import Declaration Form VC. The MTR and IDF are jointly presented to the Customs
authority which verifies the VP. Upon verification the customs release is granted for goods import.
Note: These VC types are taken from the Traceability Vocabulary, a W3C-CCG work item for supply chain use-cases.
Requirements:
1. VC Issuance,
X. Self-Issuance,
X. Re-Presentation and VC+VP Verification across a common supply chain process.
Mermaid
Contributed by:Transmute Industries
A. Terminology
This section is non-normative.
Error
Cannot GET /uploads/XbdC1r/terms.html
B. Acknowledgements
This section is non-normative.
The editors are thankful to the contributions from the VC API Working Group