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. 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 qualifications and achievements. The following use cases focus on concrete scenarios that the technology created by the group should address.
While use cases always evolve, the ones in this document are stable and relatively comprehensive. As such, they are a representative sample that can be used as the basis for establishing the scope for an eventual Working Group.
The Verifiable Claims Task Force at the W3C is investigating the requirements around secure, verifiable, and richly descriptive "claims". The goal of the Task Force is to determine if there is a sufficient understanding and need to merit the creation of a W3C Working Group to develop Recommendations in this space.
People need to make many kinds of claims as part of their everyday lives. As more important business moves to the Internet, people need to be able to transmit instantly verifiable claims about their accomplishments and qualifications. From educational records to payment account access, the next generation of web applications will authorize users to perform actions based on rich sets of credentials issued by trusted parties. Human-mediated decisions about job applications, collaboration and professional development will depend on filtering and analyzing growing amounts of data about individuals' experience and accomplishments.
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.
First, review the basic terminology used in section 2. This will give you a good foundation for understanding the rudimentary examples of how claims might be issued and later verified in section 3.
Finally, review the detailed requirements and supporting scenarios in Section 4. There are also a significant number of "Extended Use Cases" in Appendix A. We expect these are important, but possibly could be dealt with in subsequent phases of work.
The use cases in this document are organized around the basic operations that might be performed on a Verifiable Claim. For each of these operations, the document captures some high level use cases grouped by the requirement they represent. Each use case contains information about its motivation, relative priority, and one or more examples to help define the target beneficiaries of its support.
These examples describe basic ways in which Verifiable Claims might be used. They are not meant to be architecturally constraing. 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.
In this first example, a user will request a Verifiable Claim - a confirmation of their identity. Consider this illustration:
Expanding on these steps:
This sub-section illustrates a simple example of how a claim might be used in a typical commerce situation. Please remember that it is just an example, and should not be thought of as the canonical way such a system must be implemented. First, consider this diagram:
In education, issuers need to reliably identify participants to ensure that participants are properly evaulated and certificates are issued as appropriate. A participant that performs a test on the Web must provide credentials to prove their identity before taking the test, to allow the system to issue a credential certifying the test results. These credentials can then be used as proof of pre-requisites for other courses. Claims from multiple credentials can be combined into a new credential which acts as a digital score report, which allows the holder to do controlled, multipoint display and distribution (on LinkedIn, Credly, Parchment, Monster, or Facebook, for example).
Alternatively, a participant may provide evidence of certain activities (claims) necessary to comply with conformance requirements e.g., “I have maintained my profession by following xyz course,” upon which the issuer may provide a credential asserting these claims.
In addition to the fundamental use cases detailed in Section 4, the task force has captured a number of additional use cases that are relevant to the task and should be kept in mind as further work is done in this space. Those use cases are captured in this appendix, along with an indication as to their relative importance. This appendix is organized with a structure similar to that of Section 4.
Most (bar WebID-TLS) fail to incorporate unambiguous naming using HTTP URIs. In addition, entity names don’t resolve to entity description documents.
Purpose The Country Government does not want to build a centralised repository for citizen’s self-asserted credentials such as contact details and perhaps other claimed attributes such as partner’s name, etc. Alternatively, the objective is to support the marketplace to develop an ecosystem of local or global providers that offer the citizen a range of options to choose from. A standard could enable an approach that would remove dependence on any particular technology or platform as the choice of repository for an individual’s self-asserted profile – for example, personal mobile device, open cloud service, commercial provider website.
Agency and citizen requirements:
Use case – register with service provider
The editor is thankful to the following contributions from the Web Payments Workshop, the Web Payments Community Group, and the Credentials Community Group, specifically (in alphabetical order): TBD