[EDITOR'S DRAFT] Proposed Verifiable Claims Architecture

It is currently difficult to transmit banking account information, proof of age, education qualifications, healthcare data, and other sorts of verified information via the Web. These sorts of data are often referred to as verifiable claims. This a summary of an architecture that aspires to address part of this problem.

Long-term goals for the Verifiable Claims work include:

Proposed Verifiable Claims Architecture Goals

Architectural goals for the Verifiable Claims work include:

The Structure of a Verifiable Claim

In order to understand the Verifiable Claims Architecture, we propose the following terminology:

A statement about a Subject.
The entity that a Claim is about. The Subject is identified by an identifier.
Verifiable Claim
A Claim where the authenticity, integrity, and non-repudiability of its authorship can be verified.

A set of verifiable claims is composed of four parts:

Fig. 1 - The structure of a set of verifiable claims

Claim set metadata covers associated information, such as the entity that made the claims and an expiration date for the claims.

Architecture Block Diagram

A basic architecture for verifiable claims must distinguish the essential roles of core actors and the relationships between them; how do they interact? A role is an abstraction that might be implemented in many different ways. The separation of roles suggests likely interfaces and/or protocols for standardization. The following roles exist in the Verifiable Claims Architecture:

Acquire verifiable claims from an Issuer and selectively provide them to Inspectors. The Holder is often, but not always, the Subject of the claims.
Issue verifiable claims to Holders.
Request verifiable claims from Holders in order to authenticate them.
Identifier Registry
Mediate creation and verification of globally-unique identifiers
Fig. 2 - Roles and information flows in the basic Verifiable Claims architecture

As the diagram above depicts, the basic verifiable claims architecture separates the basis for identification, the generation of claims associated with an identifier, and the processes for managing and using claims.

Although other claims mechanisms already exist, they suffer a number of inherent limitations, mostly caused by tight integration between the production of an identifier and the production of claims, and/or the production of claims and the storage of claims. The proposed basic architecture decouples the production of an identifier, the production of claims, and the storage/usage of claims. This ensures a more modular, flexible, and competitive ecosystem.

An Exemplary Use Case

In order to understand how all of the actors and roles in the ecosystem interact, consider the following use case:

Jane wants to apply to graduate school at multiple universities. To do so, she must take an exam and send the results of that exam to each university.

Holder Registers Subject Identifier

In order for Jane (Holder and Subject) to have information assigned to her, she must get an identifier (Subject Identifier).

Fig. 3 - The Holder Registers Subject Identifier

Holder Requests Claim from Issuer

Jane (Holder) then takes a university entrance exam at a testing facility (Issuer) and receives proof (set of verifiable claims) that she achieved a good score.

Fig. 4 - Holder Requests Claim from Issuer

Holder Presents Claim to Inspector

Jane (Holder) applies to a university (Inspector) which asks her to provide proof (Verifiable Claims) that she got a good score on the entrance exam.

Fig. 5 - Holder Presents Claim to Inspector

The university checks Jane's claims and verifies that she qualifies to apply to graduate school.

Detailed Verifiable Claims Architecture Details

This document attempts to provide a high-level overview of the Verifiable Claims Architecture. While the authors have tried to ensure that it is an accurate representation of the architecture, details have been omitted that may be interesting to those that want to dive in a bit deeper by reading the Detailed Verifiable Claims Architecture.

Architecture Benefits to Stakeholders

All Stakeholders