Verifiable Claims Data Model and Representations

Abstract

Driver's licenses are used to claim that we are capable of operating a motor vehicle, university degrees can be used to claim our education status, and government-issued passports enable holders to travel between countries. This specification provides a standard way to express these sorts of claims on the Web in a way that is cryptographically secure, privacy respecting, and automatically verifiable.

1. Introduction

Granting a benefit requires proof and verification. Some benefits demand a formal process that includes three parties. In this process, the holder asks for the benefit and the inspector-verifier grants or denies the benefit based on verification of the holder’s qualification from a trusted issuer.

For example, we use a driver's licenses to prove that we are capable of operating a motor vehicle, a university degree to prove our education status, and government-issued passports to grant travel between countries. This specification provides a standard way to express these claims on the Web in a way that is cryptographically secure, privacy respecting, and automatically verifiable.

For those that are unfamiliar with the concepts related to verifiable claims, the following sections provide an overview of:

what a verifiable claim contains,
an ecosystem where verifiable claims are expected to be useful, and
the use cases and requirements that informed this specification

1.1 What is a Verifiable Claim?

In order to explore what makes a verifiable claim useful, it is helpful to understand the basic terminology used to talk about a verifiable claim:

entity: A thing with distinct and independent existence such as a person, organization, concept, or device.
subject: An entity about which claims may be made.
claim: A statement made by an entity about a subject. A verifiable claim is a claim that is effectively tamper-proof and whose authorship can be cryptographically verified. Multiple claims may be bundled together into a set of claims.

The basic components of a set of verifiable claims are shown in the diagram below:

Figure 1 The basic components of a set of verifiable claims.

Claim set metadata refers to information about the set of verifiable claims, such as the entity that made the claims and an expiration date for the claims.

1.2 Ecosystem Overview

This section outlines a basic set of roles and an ecosystem where verifiable claims are expected to be useful. In this section, we 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 are introduced in this specification:

Issue

The VCWG is actively discussing the number of roles and terminology used in this specification. The group expects terminology and role identification to be an ongoing discussion and will be influenced by public feedback on the specification. At present, the following incomplete list of roles and terminology have been considered: Subject, Issuer, Authority, Author, Signatory, Holder, Presenter, Asserter, Claimant, Sharer, Subject's Agent, Prover, Mediator, Inspector, Evaluator, Verifier, Consumer, and Relying Party. Some of these are aliases for the same concept, others are possibly new roles in the ecosystem. Reviewers should be aware that the terminology used in this document is not necessarily final and the group is actively soliciting feedback on the roles and terminology used in this specification.

holder: An entity that is in control of one or more verifiable claims. Examples of holders include students, employees, and customers.
issuer: An entity that creates a verifiable claim, associates it with a particular subject, and transmits it to a holder. Examples of issuers include corporations, governments, and individuals.
inspector-verifier: An entity that receives one or more verifiable claims for processing. Examples of inspector-verifiers include employers, security personnel, and websites.
identifier registry: Mediates the creation and verification of subject identifiers. Examples of identifier registries include corporate employee databases, government ID databases, and distributed ledgers.

Figure 2 The roles and information flows that form the basis for this specification.

Note

The ecosystem above is provided as an example to the reader in order to ground the rest of the concepts in this specification. Other ecosystems exist, such as protected environments or proprietary systems, where verifiable claims also provide benefit.

1.3 Use Cases and Requirements

The Verifiable Claims Use Cases[VC-USECASES] document outlines a number of key topics that readers may find useful, including:

a more thorough explanation of the roles introduced above,
the needs identified in market verticals like education, finance, healthcare, retail, professional licensing, and government,
common tasks and requirement performed by the roles in the ecosystem, and
common sequences and flows identified by the Working Group.

As a result of documenting and analyzing the use cases document, a number of desirable capabilities have been identified as requirements for this specification, specifically:

Holders MUST receive and store verifiable claims from issuers through an agent that the issuer does not need to trust.
Holders SHOULD be positioned between issuers and inspector-verifiers and mediate the transmission of verifiable claims.
Holders MUST provide verifiable claims to inspector-verifiers through an agent that inspector-verifiers needn't trust; they only need to trust issuers.
Verifiable claims MUST be associated with subjects, not particular services; holders SHOULD decide how to aggregate and manage verifiable claims.
Holders SHOULD be able to easily control and own their own identifiers.
Holders MUST control which verifiable claims to use and when.
Holders MUST be able to freely choose and change the agents they employ to help them manage and share their verifiable claims.
Holders that share verifiable claims MUST NOT be required to reveal the identity of the inspector-verifier to issuers.
A verifiable claim MUST be expressed in one or more standard, machine-readable data formats for expressing verifiable claims which can also be extended with minimal coordination.
Verifiable claims MUST be able to be indepenently issued, stored, and verified.
Verifiable Claims MUST be able to be revoked by the issuer.

Issue

There are other requirements listed in the Verifiable Claims Use Cases document that may or may not be aligned with the requirements listed above. The VCWG will be ensuring alignment of the list of requirements from both documents over time and will most likely move the list of requirements to a single document.

3. Data Model

This section describes a data model for entity profiles and entity credentials, the latter covering both claims and verifiable claims, that is compatible with the requirements and use cases expected to be addressed by this group.

3.1 General Characteristics

Both the Entity Profile Model and Entity Credential Model consist of a collection of name-value pairs which will be referred to as properties in this document. The following subsections describe the required and optional properties for both. The link between the two is in the id property. The Entity Profile Model defines a subject identifier in the id property, while the claims section of the Entity Credential Model uses the id property to refer to that subject identifier.

This document purposely defines the data model without using a concrete syntax such as WebIDL, JSON, or JSON-LD to avoid implying a bias towards any particular one syntax. Section 4. Syntaxes defines how the data model is to be expressed in those representation languages.

3.2 Entity Profile Model

Unlike the properties in the claim section of the Entity Credential Model, the properties in the Entity Profile Model are merely information that, together with a subject identifier id, constitute an entity profile. The properties are not claims and are not intended to be verifiable.

The following properties are required in the Entity Profile Model:

id: This is a URI representing the subject. This identifier MAY be long-lived but does not have to be.
type: This is an unordered set of URIs representing the types or classes of which this data set is a member. As an entity profile, at a minimum the class "Entity" must be a member of the set. Additional application-specific values are permitted in the set.

The following properties are optional in the Entity Profile Model:

signature: The method used for a signature will vary by representation language. However, if present this property is expected to have a value that is a set of name-value pairs including at least a signature, a reference to the signing entity, and a representation of the signing date.

Additionally, any property name not listed above is permitted as an optional custom property.

3.3 Entity Credential Model

Unlike the properties in the Entity Profile Model, the properties in the claim section of the Entity Credential Model are claims made by an entity about the subject defined in an entity profile. The Entity Credential Model includes both issuance-related properties and the aforementioned claim property that further contains the properties of the claim itself.

The following properties are required in the Entity Credential Model:

id

URI representing this specific entity credential

type

This is an unordered set of URIs representing the types or classes of which this data set is a member. As an entity credential, at a minimum the class "Credential" must be a member of the set. Additional application-specific values are permitted in the set.

claim

This is the actual claim. Its value is a set of properties as follows:

The following properties are required in a claim value:

id: The subject of the claim, the property value is expected to be a valid Entity Profile id.
At least one custom property: N/A

Additionally, any property name not listed above is permitted as an optional custom property.

The following properties are optional in the Entity Credential Model:

issuer: This is a URI for the issuer of the claim.
issued: This is the date, in string format, when the claim was issued.

Additionally, any property name not listed above is permitted as an optional custom property.

3.4 Verifiable Claims Model

The claims in the Entity Credential Model can be made verifiable by adding the following property to the Entity Credential Model:

signature: The method used for a signature will vary by representation language. However, this property is expected to have a value that is a set of name-value pairs including at least a signature, a reference to the signing entity, and a representation of the signing date.

3.5 Revocation Model

Revocation information for the claims in the Verifiable Claims Model may be provided by adding the following property:

revocation: The value of this property MUST be a revocation scheme that provides enough information to determine whether or not the credential has been revoked. The revocation scheme will vary depending on a variety of factors, such as whether it is simple to implement or privacy-enhancing.

Issue 35: Establish criteria for use cases, provide outlet for examples

The group is currently determining whether or not they should publish a very simple scheme for revocation as a part of this specification.

4. Syntaxes

This section defines how the data model described in Section is realized in each of 3 different languages: JSON, JSON-LD, and WebIDL. Although syntactic mappings are only provided for these three different languages, applications and services may also use any other data representation language (XML, for example) that can support the data model.

4.1 JSON

4.1.1 Expressing an Entity Profile in JSON

In JSON [JSON], an instance of the Entity Profile Model is expressed as a single JSON object whose properties are the entity profile's properties, with the following value type assignments:

Any number value MUST be represented as a Number type.
Any boolean value MUST be represented as a Boolean type.
Any sequence value MUST be represented as an Array type.
Any unordered set of values MUST be represented as an Array type.
Any set of properties MUST be represented as an Object type.
Any empty value MUST be represented as a null value.
Any other value MUST be represented as a String type.

The following example demonstrates how to express a simple entity profile.

Example 1: A simple entity profile

{
  "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "type": ["Entity", "Person"],
  "name": "Alice Bobman",
  "email": "alice@example.com",
  "birthDate": "1985-12-14",
  "telephone": "12345678910"
}

4.1.2 Expressing an Entity Credential in JSON

In JSON, an instance of the Entity Credential Model is expressed as a single JSON object whose properties are the entity credential's properties, with the following value type assignments:

Any number value MUST be represented as a Number type.
Any boolean value MUST be represented as a Boolean type.
Any sequence value MUST be represented as an Array type.
Any unordered set of values MUST be represented as an Array type.
Any set of properties MUST be represented as an Object type.
Any empty value MUST be represented as a null value.
Any other value MUST be represented as a String type.

The following example demonstrates how to express an entity credential containing a simple (unverifiable) claim about a particular subject. In this case, the claim is that the subject with the Entity Profile id of did:ebfeb1f712ebc6f1c276e12ec21 is 21 years of age or older. While a human reading the property ageOver may be able to guess its meaning by its name, no machine-readable semantics for the name are provided. There is information about the claim itself, such as an identifier for the entity that issued it and a date for when it was issued.

Example 2: A simple claim

{
  "id": "http://example.gov/credentials/3732",
  "type": ["Credential", "ProofOfAgeCredential"],
  "issuer": "https://dmv.example.gov",
  "issued": "2010-01-01",
  "claim": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "ageOver": 21
  }
}

The following example demonstrates how to express the same claim about the same subject, but in a verifiable form. As such, it contains a signature that can be used to verify its entire contents, including the claim.

Example 3: A simple verifiable claim

{
  "@context": "https://w3id.org/security/v1",
  "id": "http://example.gov/credentials/3732",
  "type": ["Credential", "ProofOfAgeCredential"],
  "issuer": "https://dmv.example.gov",
  "issued": "2010-01-01",
  "claim": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "ageOver": 21
  },
  "revocation": {
    "id": "http://example.gov/revocations/738",
    "type": "SimpleRevocationList2017"
  },
  "signature": {
    "type": "LinkedDataSignature2015",
    "created": "2016-06-18T21:19:10Z",
    "creator": "https://example.com/jdoe/keys/1",
    "domain": "json-ld.org",
    "nonce": "598c63d6",
    "signatureValue": "BavEll0/I1zpYw8XNi1bgVg/sCneO4Jugez8RwDg/+
    MCRVpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCuFibcC1wps
    PRdW+gGsutPTLzvueMWmFhwYmfIFpbBu95t501+rSLHIEuujM/+PXr9Cky6Ed
    +W3JT24="
  }
}

The following example demonstrates how one could express the same claim about the same subject using a JSON Web Token.

Example 4: A JOSE JWT verifiable claim

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2Rtdi
5leGFtcGxlLmdvdiIsImlhdCI6MTI2MjMwNDAwMCwiZXhwIjoxNDgzMjI4ODAwL
CJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJkaWQ6ZWJmZWIxZjcxMmVi
YzZmMWMyNzZlMTJlYzIxIiwiZW50aXR5Q3JlZGVudGlhbCI6eyJAY29udGV4dCI
6Imh0dHBzOi8vdzNpZC5vcmcvc2VjdXJpdHkvdjEiLCJpZCI6Imh0dHA6Ly9leG
FtcGxlLmdvdi9jcmVkZW50aWFscy8zNzMyIiwidHlwZSI6WyJDcmVkZW50aWFsI
iwiUHJvb2ZPZkFnZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly9kbXYu
ZXhhbXBsZS5nb3YiLCJpc3N1ZWQiOiIyMDEwLTAxLTAxIiwiY2xhaW0iOnsiaWQ
iOiJkaWQ6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiYWdlT3ZlciI6Mj
F9fX0.LwqH58NasGPeqtTxT632YznKDuxEeC59gMAe9uueb4pX_lDQd2_UyUcc6
NW1E3qxvYlps4hH_YzzTuXB_R1A9UHXq4zyiz2sMtZWyJkUL1FERclT2CypX5e1
fO4zVES_8uaNoinim6VtS76x_2VmOMQ_GcqXG3iaLGVJHCNlCu4

The JWT above was produced using the inputs below:

Issue

A number of the concerns have been raised around security, composability, reusability, and extensibility with respect to the use of JWTs for Verifiable Claims. These concerns will be documented in time in at least the Verfiable Claims Model and Security Considerations section of this document.

// JWT Header
{
  "alg": "RS256",
  "typ": "JWT"
}
// JWT Payload
{
  "iss": "https://dmv.example.gov",
  "iat": 1262304000,
  "exp": 1483228800,
  "aud": "www.example.com",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "entityCredential": {
    "@context": "https://w3id.org/security/v1",
    "id": "http://example.gov/credentials/3732",
    "type": ["Credential", "ProofOfAgeCredential"],
    "issuer": "https://dmv.example.gov",
    "issued": "2010-01-01",
    "claim": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "ageOver": 21
    }
  }
}

The following example demonstrates how to express a more complex set of verfiable claims about a particular subject.

Example 5: A more complex verifiable claim

{
  "@context": [
    "https://w3id.org/identity/v1",
    "https://w3id.org/security/v1"
  ],
  "id": "http://example.gov/credentials/3732",
  "type": ["Credential", "PassportCredential"],
  "name": "Passport",
  "issuer": "https://example.gov",
  "issued": "2010-01-01",
  "claim": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "name": "Alice Bobman",
    "birthDate": "1985-12-14",
    "gender": "female",
    "nationality": {
      "name": "United States"
    },
    "address": {
      "type": "PostalAddress",
      "addressStreet": "372 Sumter Lane",
      "addressLocality": "Blackrock",
      "addressRegion": "Nevada",
      "postalCode": "23784",
      "addressCountry": "US"
    },
    "passport": {
      "type": "Passport",
      "name": "United States Passport",
      "documentId": "123-45-6789",
      "issuer": "https://example.gov",
      "issued": "2010-01-07T01:02:03Z",
      "expires": "2020-01-07T01:02:03Z"
    }
  },
  "signature": {
    "type": "LinkedDataSignature2015",
    "created": "2016-06-21T03:40:19Z",
    "creator": "https://example.com/jdoe/keys/1",
    "domain": "json-ld.org",
    "nonce": "783b4dfa",
    "signatureValue": "Rxj7Kb/tDbGHFAs6ddHjVLsHDiNyYzxs2MPmNG8G47oS06N8i0Dis5mUePIzII4+p/ewcOTjvH7aJxnKEePCO9IrlqaHnO1TfmTut2rvXxE5JNzur0qoNq2yXl+TqUWmDXoHZF+jQ7gCsmYqTWhhsG5ufo9oyqDMzPoCb9ibsNk="
  }
}

4.2 JSON-LD

JSON-LD [JSON-LD] is a data storage and expression approach called Linked Data. It is a way of expressing information on the Web that is both simple and extensible.

4.2.1 Expressing an Entity Profile in JSON-LD

Instances of the Entity Profile Model are expressed in JSON-LD in the same way they are expressed in JSON (Section 4.1.1 Expressing an Entity Profile in JSON), except that there is an additional property @context. Each property of the entity profile, such as name or email, is given context via the @context value. Other contexts can be used or combined to express any arbitrary information about an entity profile in idiomatic JSON.

The following example demonstrates how to express a simple entity profile.

Example 6: A simple entity profile

{
  "@context": "https://w3id.org/identity/v1",
  "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "type": ["Entity", "Person"],
  "name": "Alice Bobman",
  "email": "alice@example.com",
  "birthDate": "1985-12-14",
  "telephone": "12345678910"
}

4.2.2 Expressing an Entity Credential in JSON-LD

Instances of the Entity Credential Model are expressed in JSON-LD in the same way they are expressed in JSON (Section 4.1.2 Expressing an Entity Credential in JSON), except that there is an additional property @context. Each property of the entity credential expression, along with each sub-property within the claim property (such as the generic issuer property or the app-specific ageOver), is given context via the @context value. Other contexts can be used or combined to express any arbitrary information about claims in idiomatic JSON.

The following example demonstrates how to express a simple (unverifiable) claim about a particular subject. In this case, the claim is that the subject with the Entity Profile id of did:ebfeb1f712ebc6f1c276e12ec21 is 21 years of age or older. While a human reading the property ageOver may be able to guess its meaning by its name, the context maps it to a global identifier (URL) where a document could be retrieved that provides its semantics in a machine-readable data format. There is also information about the claim itself, such as an identifier for the entity that issued it and a date for when it was issued.

Example 7: A simple claim

{
  "@context": "https://w3id.org/identity/v1",
  "id": "http://example.gov/credentials/3732",
  "type": ["Credential", "ProofOfAgeCredential"],
  "issuer": "https://dmv.example.gov",
  "issued": "2010-01-01",
  "claim": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "ageOver": 21
  }
}

Example 8: A simple verifiable claim

{
  "@context": [
    "https://w3id.org/identity/v1",
    "https://w3id.org/security/v1"
  ],
  "id": "http://example.gov/credentials/3732",
  "type": ["Credential", "ProofOfAgeCredential"],
  "issuer": "https://dmv.example.gov",
  "issued": "2010-01-01",
  "claim": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "ageOver": 21
  },
  "signature": {
    "type": "LinkedDataSignature2015",
    "created": "2016-06-18T21:10:38Z",
    "creator": "https://example.com/jdoe/keys/1",
    "domain": "json-ld.org",
    "nonce": "6165d7e8",
    "signatureValue": "g4j9UrpHM4/uu32NlTw0HDaSaYF2sykskfuByD7UbuqEcJIKa+IoLJLrLjqDnMz0adwpBCHWaqqpnd47r0NKZbnJarGYrBFcRTwPQSeqGwac8E2SqjylTBbSGwKZkprEXTywyV7gILlC8a+naA7lBRi4y29FtcUJBTFQq4R5XzI="
  }
}

The following example demonstrates how to express a more complex set of verifiable claims about a particular subject.

Example 9: A more complex verifiable claim

{
  "@context": [
    "https://w3id.org/identity/v1",
    "https://w3id.org/security/v1"
  ],
  "id": "http://example.gov/credentials/3732",
  "type": ["Credential", "PassportCredential"],
  "name": "Passport",
  "issuer": "https://example.gov",
  "issued": "2010-01-01",
  "claim": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "name": "Alice Bobman",
    "birthDate": "1985-12-14",
    "gender": "female",
    "nationality": {
      "name": "United States"
    },
    "address": {
      "type": "PostalAddress",
      "addressStreet": "372 Sumter Lane",
      "addressLocality": "Blackrock",
      "addressRegion": "Nevada",
      "postalCode": "23784",
      "addressCountry": "US"
    },
    "passport": {
      "type": "Passport",
      "name": "United States Passport",
      "documentId": "123-45-6789",
      "issuer": "https://example.gov",
      "issued": "2010-01-07T01:02:03Z",
      "expires": "2020-01-07T01:02:03Z"
    }
  },
  "signature": {
    "type": "LinkedDataSignature2015",
    "created": "2016-06-21T03:43:29Z",
    "creator": "https://example.com/jdoe/keys/1",
    "domain": "json-ld.org",
    "nonce": "c168dfab",
    "signatureValue": "jz4bEW2FBMDkANyEjiPnrIctucHQCIwxrtzBXt+rVGmYMEflHrOwf7FYLH60E3Oz54VwSSQCi9J4tXQIhv4SofT5opbcIUj7ji6QrC6c+a3YLjg8l/+/uFjhzsLelAO4gh2k0FJxM04ljH0GZGuXTzhRnqTzJTnYSVo72PC92NA="
  }
}

Issue 54

The group is currently considering which expressions of the data model should be listed in the spec. WebIDL and XML are two of the expressions that are being considered.

5. Privacy Considerations

This section details the general privacy considerations and specific privacy implications of deploying the verifiable claims data model into production environments.

5.1 Spectrum of Privacy

It is important to recognize that there is a spectrum of privacy that ranges from pseudo-anonymous to strongly identified. Depending on the use case, people have different appetites when it comes to what information they are willing to provide and what information may be derived from what is provided.

Figure 3 - Privacy is a spectrum that ranges from pseudo-anonymous to fully identified.

For example, one would most likely desire to remain anonymous when purchasing alcohol because the regulatory check that’s required is solely whether or not the person is above a particular age. However, when a doctor is writing a prescription for a patient, the pharmacy fulfilling the prescription is required to more strongly identify the medical professional. Therefore it is important to recognize that there is not one approach to privacy that works for all use cases; privacy solutions tend to be use case specific.

Issue

Note that even if one may desire to remain anonymous when purchasing alcohol, a photo ID may still be required to provide appropriate assurance to the merchant. The merchant may not need to know your name or other details (other than that you are over a certain age), but in many cases a mere proof of age may still be insufficient to meet regulations.

The Verifiable Claims data model strives to support the full spectrum of privacy and does not take philosophical positions on the right level of anonymity for any particular transaction. The following sections provide guidance for implementers that want to avoid specific scenarios that are hostile to privacy.

5.2 Personally Identifiable Information

The data associated with verifiable claims stored in the credential.claim field are largely susceptible to privacy violations when shared with Inspector-verifiers. Personally identifying data such as a government-issued identifier, shipping address, and full name can be easily used to determine, track, and correlate an entity. Even information that does not seem personally identifiable like the combination of a birth date and zip code have very powerful correlation and de-anonymizing capabilities.

Implementers are strongly advised to warn Holders when they share data with these sorts of characteristics. Issuers are strongly advised to provide privacy-protecting credentials when possible. For example, issuing ageOver credentials instead of birthdate credentials when the Inspector-verifier desires to determine if an entity is over the age of 18.

5.3 Identifier-based Correlation

Subjects of verifiable claims are identified via the credential.claim.id field. The identifiers that are used to identify the subject of a claim create a danger of correlation when the identifiers are long-lived or used across more than one web domain.

If strong anti-correlation properties are a requirement in a system using verifiable claims, it is strongly advised that identifiers are bound to a single origin or that identifiers are single-use or not used at all and are replaced by short-lived, single use bearer tokens.

5.4 Signature-based Correlation

The contents of verifiable claims are secured via the credential.signature field. The credential.signature.signatureValue field creates a danger of correlation when it is used across more than one web domain and the value does not change.

If strong anti-correlation properties are desired, it is strongly advised that signature values and metadata are regenerated each time using technologies like group signatures.

5.5 Device Fingerprinting

There are mechanisms external to Verifiable Claims that are used to track and correlate individuals on the Internet and the Web. Some of these mechanisms include Internet Protocol address tracking, Web Browser fingerprinting, Evercookies, Advertising Network trackers, mobile network position information, and in-application Global Positioning System APIs. The use of Verifiable Claims cannot prevent the use of these other tracking technologies. In addition, when these technologies are used in concert with Verifiable Claims, new correlatable information may be discovered. For example, a birthday coupled with a GPS position can be used to strongly correlate an individual across multiple websites.

It is advised that privacy preserving systems prevent the use of these other tracking technologies when verifiable claims are being utilized. In some cases, these tracking technologies may need to be disabled entirely on devices that transmit verifiable claims on behalf of the Holder.

5.6 Favor Abstract Claims

In order to enable recipients of verifiable claims to use them in a variety of circumstances without revealing more personally identifiable information than necessary for the transaction, issuers should consider limiting the information published in a claim to a minimal set needed for the expected purposes. One way to avoid placing personally identifiable information in a claim is to use an "abstract" property that meets the needs of inspector-verifiers without providing specific information about the subject.

An example in this document is the use of the ageOver property as opposed to a specific birthdate that would constitute much stronger personally identifiable information. If retailers in a market commonly require purchasers to be older than a specific age, an issuer trusted in that market may choose to offer a credential claiming that subjects have met that requirement as opposed to offering claims of their specific birthdates. This enables individual customers to purchase items without revealing specific personally identifiable information.

5.7 The Principle of Minimum Disclosure

Privacy violations occur when information divulged in one context leaks into another. Accepted best practice for preventing such violations is to limit the information requested, and received, to the absolute minimum necessary. This minimal disclosure approach is required by regulation in multiple jurisdictions, including HIPAA in the US and GDPR in the EU.

With verifiable claims, minimal disclosure for issuers means limiting the content of a claim to the minimum required by potential inspector-verifiers for expected use. For inspector-verifiers, it means limiting the scope of claims request or required for accessing services.

For example, a driver's license containing a driver's ID number, height, weight, birthday, and home address is an example of a claim set containing more information than is necessary to establish that the person is above a certain age.

It is considered a best practice for issuers to atomize information or use a signature scheme that allows for selective disclosure. For example, an issuer that issues driver's licenses could issue a claim set containing every attribute that appears on a driver's license in addition to individual claims (a singular claim containing the person's birthday), and individual claims that are more abstract (a singular claim containing an ageOver attribute). In addition, the issuer is encouraged to provide secure HTTP endpoints for retrieving single-use bearer claims to promote the pseudonymous usage of claims when it is safe for the issuer to issue such claims.

Similarly, inspector-verifiers are urged to only request information that is absolutely necessary for a particular transaction to occur. This is important for at least two reasons: 1) it reduces the liability on the inspector-verifier for handling highly sensitive information that it does not need, and 2) it enhances the privacy of the individual by only asking for information that is required for the particular transaction.

5.8 Bearer Claims

Issue

Bearer claims containing PII or unique identifiers can be correlated. Bearer claims can be tracked based on usage patterns.

5.9 Validity Checks

Issue

Inspector-verifier (corporation) is required to check revocation via Issuer (government).

5.10 Storage Providers and Data Mining

When a holder receives a claim from an issuer, the claim will need to be stored somewhere (e.g. in a credential repository). Holders are warned that the information in a verifiable claim may be sensitive in nature and highly individualized, making it a high value target for data mining. Therefore, there may be services that store verifiable claims for free and mine personal data and sell it to organizations that desire individualized profiles on people and organizations (i.e. if the service is free, you are the product).

It is suggested that holders be aware of the terms of service for their credential repository, specifically the correlation and data mining protections that are in place for those who store their verifiable claims at the service provider.

There are a number of effective mitigations for data mining and profiling:

Use service providers that do not sell your information to third parties.
Use software that encrypts verifiable claims such that a service provider cannot view the contents of the claims.
Use software that stores verifiable claims locally on a device that you control and that does not upload or analyze your information beyond your expectations.

5.11 Aggregation of Claims

Issue

Aggregation of claims can reveal more information than just the attributes being aggregated.

5.12 Usage Patterns

Despite the best efforts to assure privacy, the actual use of verifiable claims can potentially lead to de-anonymization and a loss of privacy. This correlation can occur:

When the same claim is presented to the same inspector-verifier more than once – that inspector-verifier could infer that the holder is the same individual.
When the same claim is presented to different inspector-verifiers, and either those inspector-verifiers collude or a third party has access to transaction records from both inspector-verifiers – the observant party could infer that the individual presenting the claims is the same person at both services, i.e., the accounts are controlled by the same person.
When the same subject identifier of a claim refers to the same subject across presentations or inspector-verifiers. Even when different claims are presented, if the subject identifier is the same, inspector-verifiers (and those with access to inspector-verifier logs) could infer that the holder of the claims is the same person.
When the underlying information in a claim can be used to identify an individual across services – using information from other sources (including information provided directly by the user), inspector-verifiers can use the information inside the claim to correlate the individual with an existing profile. For example, if a holder presents claims that include zip code, age, and sex, the inspector-verifier can potentially correlate the subject of that claim with an established profile [see Sweeney 2000 Simple Demographics Often Identify People Uniquely].
When passing the identifier of a claim to a centralized revocation server – the centralized server can correlate the claim usage across interactions. For example, if a verifiable claim is used for proof of age in this manner, the centralized service could know everywhere that claim was presented: all liquor stores, bars, adult stores, lottery purchases, etc.

It’s possible to mitigate this in part:

Use a globally unique identifier as the subject for any given claim and never re-use that claim.
If the claim supports revocation, use a globally distributed service for revocation.
Design revocation APIs that do not depend on submitting the ID of the claim, e.g., use a revocation list rather than a query.
Avoid associating personally identifiable information with any particular long-lived subject identifier.

It is understood that these mitigation techniques are not always practical or even compatible with necessary usage. Sometimes correlation is the point.

In state prescription monitoring programs, usage monitoring is a requirement: enforcement entities need to be able to confirm that individuals are not cheating the system to get multiple prescriptions for controlled substances. This statutory or regulatory need to correlate usage overrides individual privacy concerns.

Verifiable claims will so be used to intentionally correlate individuals across services, for example, when using a common persona to log in to multiple services, so all activity on each of those services is intentionally linked to the same individual. This is not a privacy issue as long as each of those services uses the correlation in the expected manner.

Privacy risks of claim usage occur when unintended or unexpected correlation arises from the presentation of verifiable claims.

5.14 Frequency of Claim Issuance

Issue

The rate at which an issuer issues claims may be a privacy violation.

5.15 Prefer Single Use Claims

Issue

Single-use, origin bound claims are generally safer than long-lived claims.

Abstract

Status of This Document

1. Introduction

1.1 What is a Verifiable Claim?

1.2 Ecosystem Overview

1.3 Use Cases and Requirements

2. Terminology

3. Data Model

3.1 General Characteristics

3.2 Entity Profile Model

3.3 Entity Credential Model

3.4 Verifiable Claims Model

3.5 Revocation Model

4. Syntaxes

4.1 JSON

4.1.1 Expressing an Entity Profile in JSON

4.1.2 Expressing an Entity Credential in JSON

4.2 JSON-LD

4.2.1 Expressing an Entity Profile in JSON-LD

4.2.2 Expressing an Entity Credential in JSON-LD

5. Privacy Considerations

5.1 Spectrum of Privacy

5.2 Personally Identifiable Information

5.3 Identifier-based Correlation

5.4 Signature-based Correlation

5.5 Device Fingerprinting

5.6 Favor Abstract Claims

5.7 The Principle of Minimum Disclosure

5.8 Bearer Claims

5.9 Validity Checks

5.10 Storage Providers and Data Mining

5.11 Aggregation of Claims

5.12 Usage Patterns

5.13 Sharing Information with the Wrong Party

5.14 Frequency of Claim Issuance

5.15 Prefer Single Use Claims

6. Security Considerations

6.1 Unsigned Claims

6.2 Bundling Dependent Claims

6.3 Highly Dynamic Information

7. Verification

7.1 Structural Validity

7.2 Entity Validity

7.3 Fitness for Purpose

A. References

A.1 Normative references

A.2 Informative references