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.
Enhance website usability by removing the need to manually enter verifiable claims
Reduce fraud by creating a standard way to share verifiable qualifications
Ensure maximum privacy in claims sharing mechanism
Proposed Verifiable Claims Architecture Goals
Architectural goals for the Verifiable Claims work include:
Separate production and control of an identifier from the production of claims associated with the identifier
Separate control of claims sharing from creation of claims
Develop standards for interactions between architectural roles, independent of market vertical
Re-use existing protocols where appropriate
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.
Issuer
Issue verifiable claims to Holders.
Inspector
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
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
Reduced software costs via standards-based, off-the-shelf verifiable
claim repository software.
Issuers
Any person or organization may issue verifiable claims, not just a select few.
Reduced software costs via standards-based, off-the-shelf verifiable claim
issuing software.
Reduced infrastructure costs due generalized claim issuing software.
Inspectors
Better understanding of the user due to a richer set of verifiable claims
to choose from
Increased ability and choice to trust authenticity of verifiable claims
Any person or organization may inspect and verify the validity of a set of
verifiable claims.
Reduced software costs via standards-based, off-the-shelf verifiable claim
inspection software.
