[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:

Establish an architecture where the holder of a verifiable claim is in
complete control of their identifier, where their claims are stored, and
how they are used.

The Structure of a Verifiable Claim

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

Claim

A statement about a Subject.

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:

Holder

Acquire verifiable claims from an Issuer and selectively provide them to
Inspectors. The Holder is often, but not always, the Subject of the claims.

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

Levels competitive playing field (not just a few super-providers)

Ability to participate in broader ecosystem resulting in common tooling to
process verifiable claims

Avoidance of vendor-specific solutions and lock-in

Holders

No identity provider lock-in

Digital claims that can be used in more than one location

Ability to aggregate verifiable claims as cohesive digital identities

Privacy-enhanced sharing mechanism

Control of confidential information

Elimination of repetitive input at websites

Reduction in the need to input personally identifiable information (PII)

Higher-stakes verifiable claims being stored resulting in more value-added
services on top of storage services

Any person or organization may provide verifiable claims storage and management
solutions, not just a few super providers