[EDITOR'S DRAFT] Verifiable Claims Working Group Frequently Asked Questions

The mission of the Verifiable Claims Working Group is to make expressing, exchanging, and verifying claims easier and more secure on the Web. Please review the draft charter if you have not already done so.

What problem is this work attempting to address?

There is currently no widely used self-sovereign and privacy-enhancing standard for expressing and transacting verifiable claims (aka: credentials, attestations) via the Web.

These problems exist today:

Is there agreement that this is a problem?

Yes, there is broad consensus on the problem statement and how to address it.

A Community Group of 77 people have been incubating this work for almost 2 years, performing market research as well as researching technical approaches to the problem. In September 2015, forty-three (43) organizations that either issue verifiable claims or consume verifiable claims were surveyed to determine their needs in this space. In January 2016, extensive interviews were conducted among industry experts that have worked in this space over the past 15 years. There is a Verifiable Claims Final Report summarizing the findings and consensus around the problem statement.

In May 2016, an industry survey was performed. These are the findings from that industry survey:

What kind of requirements have been identified for a self-sovereign, privacy-enhancing verifiable claims ecosystem?

A self-sovereign, privacy-enhancing, verifiable claims ecosystem is defined as having the following requirements:

What is the scope of this work?

The Verifiable Claims Working Group will focus on data model and syntaxes for Verifiable Claims.

Why is there no Javascript API for Web Browsers?

An early version of the Verifiable Claims Working Group charter included a Javascript browser API, but the proposal raised concern among W3C members that doing so would be controversial.

It was asserted that OpenID Connect or potentially the FIDO, Web Authentication, or Credential Management API should be the protocol that carries verifiable claims. This resulted in strong opinions on either side of the debate on exactly what a verifiable claims browser API should standardize (a new protocol, or a protocol based on existing protocols).

In the end, there was consensus that having a standard data model and a few syntaxes for expressing that data model would increase interoperability and allow for experimentation in the use of verifiable claims in a variety of existing protocols to see if those existing protocols would be capable of achieving the use cases and verifiable claims architecture that has been proposed.

Has this work been incubated in a Community Group?

Yes. The proposed charter, architecture, specification, and all supporting documentation has been incubating for 2+ years in the Credentials Community Group, Web Payments Community Group, and the Verifiable Claims Task Force. The work has been reviewed by over 50 organizations with strong support for the identified problem statement, goals, and general direction of the work.

How does Blockchain or Decentralized Ledger Technology relate to this work?

In general, Verifiable Claims can be stored or referenced by Blockchain and Decentralied Ledger technology. The proposed data model and syntaxes are designed to be storage system and transaction protocol agnostic and thus complimentary to Blockchain and Decentralized Ledger Technology.

How is confidence/level of assurance guaranteed?

Verifiable Claims are designed to have a flexible trust model where the inspector of a verifiable claim can apply local confidence/LoA rules to a set of claims, or delegate that responsibility to a third party (much like trust is delegated to third parties via the Certificate Authority system today). The important point to remember is that there may be many different types of confidence/LoA guarantees related to Verifiable Claims and all of them may co-exist in the proposed architecture.

Is there a proposed architecture where these verifiable claims are used?

Yes, there is a proposed Verifiable Claims Architecture. Note that all parts of the architecture are not going to be achieved with the first iteration of the Verifiable Claims Working Group. Instead, a minimal first step is being proposed. Understanding the long-term vision/architecture of where some of the community would like to end up is captured in the previously linked document.

Wouldn't starting in a single industry vertical, like education, be a better strategy?

It has been proposed that starting the Verifiable Claims work in a single industry vertical, like education, would help focus the work on a specific solution. Then, if the work is successful, it could be generalized to other market verticals.

Survey responses to the charter, interviews, and ad-hoc conversations on the matter show that this approach is not desirable for at least two reasons. The first is that responses indicate that there are already point solutions in the marketplace and because each approach was hyper focused on a specific vertical that the solutions tended to make assumptions on the market vertical in which they were operating leading to solutions that don't scale outside of the vertical. The second is that there are already organizations from finance, education, healthcare, and government involved with use cases that they would like to have addressed in the first iteration. These same organizations have noted that it would be a mistake to start in any specific vertical rather than a more generalized approach.

Is this yet another attempt to "solve the Identity problem" on the Internet?

No, "Identity" is a standardization tar pit and the proposers of the Verifiable Claims Working Group would like to stay as far away from trying to "solve Identity" as possible. What is being proposed by the Verifiable Claims Working Group Charter is to address a very specific problem: How does entity X make a statement about entity Y in a verifiable manner? A side-effect of solving that problem may result in eating away at the "Identity Problem" but that is certainly not the primary goal of the Verifiable Claims Working Group.

What are the ecosystem benefits for stakeholders?

At least the following benefits have been documented by organizations participating in the pre-standardization activity:

All Stakeholders

What are the economic incentives for using verifiable claims?

There are a number of economic incentives and business models that have been identified to ensure that there is an incentive for all actors to participate in the ecosystem. These incentives are broken down by actor below:

What does "self-sovereign" mean?

In a self-sovereign system, users exist independently from services. To contrast, in a service centric system users are tightly bound to a particular service.

A verifiable claims ecosystem that is self-sovereign has the following qualities:

What is meant by "service-centric"?

A service-centric system, users are tightly bound to services. To contrast, in a self-sovereign system, users exist independently from services.

A verifiable claims ecosystem that is service-centric (LDAP, SAML, OpenID Connect) has the following qualities:

How is this work different from LDAP, SAML, or OpenID Connect?

LDAP, SAML, and OpenID Connect are attribute exchange systems that are service-centric. The proposed work is attempting to create a self-sovereign, privacy-enhancing system, but there is overlap.

The proposed work is focusing first on data formats, vocabularies, and syntaxes for the expression of verifiable claims. If successful, the work could be re-used via SAML and OpenID Connect-based systems (and, in fact, a document explaining how that should happen is one of the proposed outputs of the group).

Why isn't work on a privacy-enhancing attribute exchange protocol in the charter?

Attribute exchange protocols such as SAML and OpenID Connect exist and it is unclear if those protocols could address the problem statement or not. So, working on a protocol was controversial as some asserted that the protocol is a solved problem while others asserted that a new protocol would be necessary. There was, however, no real controversy around a data model, vocabularies, and syntax(es) for the expression of verifiable claims. It may be that this output could be married with existing attribute exchange systems to achieve a solution to the problem statement noted earlier in the FAQ. If not, work on a new privacy-enhancing attribute exchange protocol may be suggested by the yet-to-be created Working Group.