A credential 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 credentials 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.

Status of This Document

This specification was published by the Credentials Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

If you wish to make comments regarding this document, please send them to public-credentials@w3.org@w3.org (subscribe, archives).

Table of Contents

1. Introduction

A credential 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 credentials 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.

Issue 1

Create a better introduction to the use cases.

2. Glossary

There is certain terminology used throughout this document that has a very specific meaning. In order to state explicitly what that meaning is, the following definitions are provided:

a thing with distinct and independent existence such as a person, organization, or instance of a software program.
a qualification, achievement, quality, or piece of information about an entity’s background such as a name, government ID, payment processor, home address, or university degree.
credential exchange
a transmission of a credential from one entity to another entity.

3. Roles

Each interaction in a Credentials scenario involves a number of entities. In order to make it clear who the actors are, the following roles are defined:

an entity that is in control of a particular credential. Typically an credentialee is also the primary topic of the information in a credential and is the entity that initiates the transmission of the credential.
an entity that creates and assigns credentials to credentialees.
an entity that requests a credential from an credentialee.
user agent
a program, such as a browser or other Web client, that mediates the communication between the credentialee and the requestor.
credential service
a program, such as a credential storage vault or personal credential wallet, that stores and protects access to an credentialee's credentials.

4. Design Criteria

When exploring systems design, there are concepts that clearly fit into use cases and concepts apply to all use cases. We are calling the latter class of concepts design criteria, which are goals that should be kept in mind while designing the overall credentials system.

4.1 Data Portability

Ensure credentials may be easily moved from one credential service to another.

4.1.1 Examples

  • Yannos has been storing all of his credentials at his college credential service and, upon graduating, would like to move them to a more long-term storage service. All of the credentials are moved without having to re-issue or re-assign any of the credentials.

4.1.2 Details

4.2 Data Rights

Ensure credentials may be dynamically annotated with acceptable use information when transmitted to requestors.

4.2.1 Examples

  • Rosa is transmitting her email address to a group buying website and wants to ensure that her email address will not be used for unsolicited emails. She attaches a "no advertising" assertion to her email credential to ensure that it isn't re-transmitted to 3rd parties for advertising purposes.

4.2.2 Details

4.3 Legacy Support

Ensure the Credentials solution can provide an abstraction layer that integrates with existing authentication methods (eg: email, username/passwords, etc.)

4.3.1 Examples

  • Petra goes to login to a website, but does not have any credentials. She does, however, have a username/password based account on the website. She is able to bypass the credential-based login and use a username/password login instead.

4.3.2 Details

4.4 Flexible Access Control

Ensure that a credentialee may provide access to their credentials in an interactive and non-interactive manner. Access granted by the credentilee may be revoked at a later time by the credentialee.

4.4.1 Examples

  • Ralph is buying wine at an online wine store. The wine store interactively requests a proof-of-age and shipping address credential from Ralph before completing the transaction.
  • The Good Food grocery store requests non-interactive access to each of their customer's email credentials when they sign up for a loyalty card. If a product recall notice is ever issued for an item a customer purchased, the latest email address for the customer is fetched and the product recall notice is forwarded to the customer.
  • Jackie allows TrustMart to automatically retrieve her latest address and phone credentials. She then receives unsolicited junkmail that she knows came from TrustMart. She deauthorizes TrustMart from pulling her latest address and phone credentials.

4.4.2 Details

4.5 Reuse and Extend

Consider using existing, widely deployed identity provider mechanisms (e.g. Facebook Connect, OpenID Connect, G+ Sign-In, etc.) to integrate with the credential sharing process. Only invent a new mechanism if the current identity provider mechanisms do not provide the functionality necessary to achieve the use cases promoted by the group.

4.5.1 Examples

  • Charlie uses an OpenID Connect login process to login to a website, which also transmits his credential service URL. The website uses the credential service URL to request additional credentials that the website needs to verify his education credentials.

4.5.2 Details

4.6 Identifier Alignment

Enable credentials to be issued by systems in a way that allows each system to align their internal identifiers with the other.

4.6.1 Examples

  • Virginia Tech (a university) and the US Department of Education would like to update the loan status of a particular individual. Both systems support credentials, but neither of them desire to use the universal identity URL in their internal systems (due to legacy system limitations). Both systems use a common internal identifier, such as a loan ID embedded in a credential, to align the data in both systems with the other.

4.6.2 Details

5. Use Cases

The following use cases outline scenarios that are targeted to be supported in the set of Credentials 1.0 specifications.

5.1 Verifiable Claims

A requestor cryptographically verifies that an issuer has made a particular set of claims about an entity. A claim would consist of an assertion about a particular qualification, achievement, or attribute of the entity.

5.1.1 Examples

  • A university would like to verify that an incoming student has achieved an acceptable score on the GRE by verifying their score report with Educational Testing Service (ETS).
  • A bank would like to perform "Know Your Customer" clearing on a new customer by checking to see that they are a citizen of Finland and that they have a current national ID card issued to them by their government.
  • A hospital would like to ensure that a prospective employee is licensed to practice medicine in their state as well as having up-to-date certificates related to areas of specialization.

5.1.2 Details

This is the base use case for the credentials work. It establishes the need for a way to make claims about an entity and a way to cryptographically verify that the claims were made by a particular issuer. Roles Requirements

5.2 Storage

Store a credential via the Web in a way that is easy to share with a requestor given authorization by the credentialee. Ensure that the credential is easy to synchronize between devices.

5.2.1 Examples

  • Cal receives a credential asserting that TrustCorp has verified that his email address is valid. Cal stores the credential with his CredVaultCorp credential vault. He also configures his personal credential vault to backup his credentials from his CredVaultCorp vault on a regular basis.

5.2.2 Details Roles Requirements

5.3 Interactive Transmission

A credentialee requests access to a restricted portion of a requestor's website. The requestor interactively requests one or more credentials previously stored with the credentialee's credential service. The credentialee authorizes the transmission of the credentials to the requestor.

5.3.1 Examples

  • Roxy visits the FineWines.com website and selects a number of wines to purchase. The website requests a proof-of-age and shipping address credential from Roxy. Roxy's IronVaultCorp credential service delivers both credentials, allowing her to finalize the transaction.

5.3.2 Details Roles Requirements

5.4 Non-interactive Transmission

A requestor requests credentials from a credential service that have been pre-authorized to be accessed through a non-interactive channel.

5.4.1 Examples

  • A grocery store wants to send out a product recall notice and requests an up-to-date email address from each of their customers' credential service to ensure that they're sending it to the correct email address. The customers have previously authorized ongoing access to their preferred email address credential.

5.4.2 Details Roles Requirements

5.5 Need-to-Know

A credentialee accesses a restricted portion of a website without revealing secrets that are not vital in order to be granted access.

5.5.1 Examples

  • Umal provides a credential stating that he is over the age of 13 in order to buy access to a PG-13 rated movie. This enables the online retailer to avoid collecting information on a minor while ensuring that the proper age check is performed before granting him access to the movie.

5.5.2 Details Roles Requirements

5.6 Composability

Multiple credentials from multiple issuers are composed together to grant authorization to access a system.

5.6.1 Examples

  • Marisol wants to open a bank account at a new bank. The bank requires two valid forms of identification. She uses a US Password credential and a Colorado drivers license credential to prove that she is who she says she is to the bank.
  • Harpreet needs to access a secure Department of Defense facility. He provides his government ID credential, his Top Secret facility access credential, and his SCIF room assignment to get access to the building entrance.

5.6.2 Details Roles Requirements

5.7 Endorsements

A credential may be endorsed/counter-signed by one or more entities. Signatures can be either dependent on one another (chained together), or multiple signatures on original credential (part of a mathematical Set).

5.7.1 Examples

  • MidBank is attempting to establish a solid credit rating and hires three credit ratings agencies to audit its books. Each firm determines that the bank should have a AA credit rating and digitally countersigns the same credential 3 times to demonstrate the credit worthiness of the bank.
  • Two people get married and get a marriage credential which needs to be digitally signed by the person that married them and the witness, in that order. The credential is first issued by the person that married them, and is then counter-signed by the witness.
  • A learner named Olivia is choosing among summer internships, some of which offer opportunities to earn badges that are endorsed by her school. These are badges that could be used to fulfill an interest-driven learning graduation requirement her district has recently implemented. With the additional information provided to her by the school’s endorsement of certain badges, her choice among internships is made much simpler. This example came from the Open Badges Endorsement Framework Working Paper, which was created by the Badge Alliance Endorsement Working Group.

5.7.2 Details Roles Requirements

5.8 Pseudo-anonymity

Access a restricted area of a website using a credential without revealing any personally identifying information. Personally identifying information is available to law enforcement via a court order.

5.8.1 Examples

  • Roman would like to purchase access to an adult website without revealing any personally identifying information. He transmits an age verification credential and an an email mixnet credential to the merchant. The merchant is not able to use that information to identify Roman.

5.8.2 Details Roles Requirements

5.9 Identity Aliases

A credentialee uses a short-identifier text string to lookup an entity identity URL.

5.9.1 Examples

  • Gunther enters a short-identifier that he believes identifies The Smart Store into a UI. The UI displays a certificate of authenticity that indicates the short identifier is in fact for The Smart Store. Gunther uses the short identifier to make a payment to the store. The short identifier is expanded to an identity URL and then the identity URL is used to determine the primary payment account for the identity URL.

5.9.2 Details Roles Requirements

6. Acknowledgements

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