Copyright © 2017 the Contributors to the Verifiable Claims Data Model and Representations Specification, published by the W3C Credentials Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available.
A self-sovereign architecture for verifiable claims is one where the holder of a verifiable claim is in complete control of their identifier, where their verifiable claims are stored, and how they are used. There is currently no widely used self-sovereign, privacy-enhancing standard for expressing and transacting verifiable claims (aka: credentials, attestations) via the Web.
This specification describes a data model for a digital identity profile and a collection of digital entity credentials that assert verifiable claims about that identity profile. It also describes how to express that data model in JSON, JSON-LD, and WebIDL.
This specification was published by the W3C Credentials Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups.
Drawn initially from [ IDENTITY-CREDENTIALS], this document is intended to provide a rough outline of the kind of standardization work that a Verifiable Claims Working Group might do.
If you wish to make comments regarding this document, please send them to public-credentials@w3.org (subscribe, archives).
We typically use credentials, or claims made by others about our identities, to authenticate ourselves and ultimately gain access to various services. For example, we use email addresses to identify ourselves to online services, driver's licenses to prove that we are capable of operating a motor vehicle, university degrees to prove we are well-trained and knowledgeable, and government-issued passports to travel between countries or to access financial services. It is the goal of this specification to provide an easy, standard way to express such credentials on the Web.
There are a number of desirable capabilities for these kinds of credentials, referred to in this specification as entity credentials, that have been identified as requirements for this specification:
This specification is based upon work presented in [ IDENTITY-CREDENTIALS]. In particular, examples from that document have been used to infer a simple but extensible data model capable of representing the unbounded variety of attributes that could be claimed in entity credentials. This document is intended to provide only one example of what could potentially be defined and standardized in a Recommendation-track Working Group at W3C. The two pieces of possible standardization work demonstrated in this document are:
The remainder of this specification is structured as follows: first, some general definitions of terms are provided. Second, the data model is described in text prose to avoid any suggestion of bias in terms of syntactic representation. It is also presented as a UML diagram. Third, instructions are provided for how to express instances of the data model in terms of JSON, JSON-LD [JSON-LD], and WebIDL.
This document attempts to communicate the concepts outlined in the Open Credentials space by using specific terms to discuss particular concepts. This terminology is included below and linked to throughout the document to aid the reader:
This section describes a data model for identity 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.
Both the Identity 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 Identity 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. Expressing Identity Profiles, Entity Credentials, and Verifiable Claims defines how the data model is to be expressed in those representation languages.
Unlike the properties in the claim section of the Entity Credential Model, the properties in the Identity Profile Model are merely information that, together with a subject identifier id, constitute an identity profile. The properties are not claims and are not intended to be verifiable.
The following properties are required in the Identity Profile Model:
The following properties are optional in the Identity Profile Model:
Additionally, any property name not listed above is permitted as an optional custom property.
Unlike the properties in the Identity 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 identity 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:
The following properties are required in a claim value:
Additionally, any property name not listed above is permitted as an optional custom property.
The following properties are optional in the Entity Credential Model:
Additionally, any property name not listed above is permitted as an optional custom property.
The claims in the Entity Credential Model can be made verifiable by adding the following property to the Entity Credential Model:
Revocation information for the claims in the Verifiable Claims Model may be provided by adding the following property:
The group is currently determining whether or not they should publish a very simple scheme for revocation as a part of this specification.
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.
In JSON, an instance of the Identity Profile Model is expressed as a single JSON object whose properties are the identity profile's properties, with the following value type assignments:
The following example demonstrates how to express a simple identity profile.
{
"id": "did:ebfeb1f712ebc6f1c276e12ec21",
"type": ["Identity", "Person"],
"name": "Alice Bobman",
"email": "alice@example.com",
"birthDate": "1985-12-14",
"telephone": "12345678910"
}
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:
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 Identity 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.
{
"id": "http://example.gov/credentials/3732",
"type": ["Credential", "ProofOfAgeCredential"],
"issuer": "https://dmv.example.gov",
"issued": "2010-01-01",
"claim": {
"id": "did: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.
{
"@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: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.
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:
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: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:ebfeb1f712ebc6f1c276e12ec21",
"ageOver": 21
}
}
}
The following example demonstrates how to express a more complex set of verfiable claims about a particular subject.
{
"@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: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="
}
}
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.
Instances of the Identity Profile Model are expressed in JSON-LD in the same way they are expressed in JSON (Section 4.1.1 Expressing an Identity Profile in JSON), except that there is an additional property @context. Each property of the identity 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 identity profile in idiomatic JSON.
The following example demonstrates how to express a simple identity profile.
{
"@context": "https://w3id.org/identity/v1",
"id": "did:ebfeb1f712ebc6f1c276e12ec21",
"type": ["Identity", "Person"],
"name": "Alice Bobman",
"email": "alice@example.com",
"birthDate": "1985-12-14",
"telephone": "12345678910"
}
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 Entity Credentials 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 Identity
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.
{
"@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: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.
{
"@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: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.
{
"@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: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="
}
}
In WebIDL, an instance of the Identity Profile Model is expressed as an Interface whose attributes are the identity profile's properties, with the following value type assignments:
The following example demonstrates how to express a simple identity profile.
[Constructor]
interface IdentityProfile {
attribute DOMString id;
attribute FrozenArray<DOMString> types;
attribute DOMString name;
attribute DOMString email;
attribute DOMString birthDate;
attribute DOMString telephone;
};
This identity profile expression could then be used as follows in JavaScript:
var identity = new IdentityProfile();
profile.id = "did:ebfeb1f712ebc6f1c276e12ec21";
profile.type = ["Identity", "Person"];
profile.name = "Alice Bobman";
profile.email = "alice@example.com";
profile.birthDate = "1985-12-14";
profile.telephone = "12345678910";
In WebIDL, an intance of the Entity Credential Model is expressed as an Interface whose attributes are the claim's properties, with the following value type assignments:
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 Identity
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.
interface CredentialBase { attribute DOMString id; attribute FrozenArray<DOMString> type; attribute DOMString issuer; attribute DOMString issued; }; [Constructor] interface Credential :CredentialBase{ attributeClaim1claim; }; [Constructor] interface Claim1 { attribute DOMString id; attribute unsigned short ageOver; };
This entity credential expression could then be used as follows in JavaScript:
var claim = new Claim1();
claim.id = "http://example.gov/credentials/3732";
claim.ageOver = 21;
var credential = new Credential();
credential.type = ["Credential", "ProofOfAgeCredential"];
credential.issuer = "https://dmv.example.gov";
credential.issued = "2010-01-01";
credential.claim = claim;
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.
interface VerifiableCredentialBase :CredentialBase{ attributeSignaturesignature; }; [Constructor] interface Signature { attribute DOMString type; attribute DOMString created; attribute DOMString _creator; attribute DOMString domain; attribute DOMString nonce; attribute DOMString signatureValue; }; [Constructor] interface VerifiableCredential1 :VerifiableCredentialBase{ attributeClaim1claim; };
This verifiable entity credential expression could then be used as follows in JavaScript:
var claim = new Claim1();
claim.id = "http://example.gov/credentials/3732";
claim.ageOver = 21;
var signature = new Signature();
signature.type = "LinkedDataSignature2015";
signature.created = "2016-06-18T21:10:38Z";
signature.creator = "https://example.com/jdoe/keys/1";
signature.domain = "json-ld.org";
signature.signatureValue = "g4j9UrpHM4/uu32NlTw0HDaSaYF2sykskfuByD7UbuqEcJIKa+IoLJLrLjqDnMz0adwpBCHWaqqpnd47r0NKZbnJarGYrBFcRTwPQSeqGwac8E2SqjylTBbSGwKZkprEXTywyV7gILlC8a+naA7lBRi4y29FtcUJBTFQq4R5XzI=";
var credential = new VerifiableCredential1();
credential.type = ["Credential", "ProofOfAgeCredential"];
credential.issuer = "https://dmv.example.gov";
credential.issued = "2010-01-01";
credential.claim = claim;
credential.signature = signature;
The following example demonstrates how to express a more complex set of verfiable claims about a particular subject.
[Constructor] interface VC2 :VerifiableCredentialBase{ attribute DOMString name; attributeClaim2claim; }; [Constructor] interface Claim2 { attribute DOMString id; attribute DOMString name; attribute DOMString birthDate; attributeGendergender; attributeNationalitynationality; attributeAddressaddress; attributePassportpassport; }; enum Gender { "male", "female" }; [Constructor] interface Nationality { attribute DOMString name; }; [Constructor] interface Address { attribute DOMString type; attribute DOMString addressStreet; attribute DOMString addressLocality; attribute DOMString addressRegion; attribute DOMString postalCode; attribute DOMString addressCountry; }; [Constructor] interface Passport { attribute DOMString type; attribute DOMString name; attribute DOMString documentId; attribute DOMString issuer; attribute DOMString issued; attribute DOMString expires; };
This verifiable entity credential expression could then be used as follows in JavaScript:
{
var nationality = new Nationality();
nationality.name = "United States";
var address = new Address();
address.type = "PostalAddress";
address.addressStreet = "372 Sumter Lane";
address.addressLocality = "Blackrock";
address.addressRegion = "Nevada";
address.postalCode = "23784";
address.addressCountry = "US";
var passport = new Passport();
passport.type = "Passport";
passport.name = "United States Passport";
passport.documentId = "123-45-6789";
passport.issuer = "https://example.gov";
passport.issued = "2010-01-07T01:02:03Z";
passport.expires = "2020-01-07T01:02:03Z";
var claim = new Claim2();
claim.id = "did:ebfeb1f712ebc6f1c276e12ec21";
claim.name = "Alice Bobman";
claim.birthDate = "1985-12-14";
claim.gender = "female";
claim.nationality = nationality;
claim.address = address;
claim.passport = passport;
var signature = new Signature();
signature.type = "LinkedDataSignature2015";
signature.created = "2016-06-21T03:43:29Z";
signature.creator = "https://example.com/jdoe/keys/1";
signature.domain = "json-ld.org";
signature.nonce = "c168dfab";
signature.signatureValue = "jz4bEW2FBMDkANyEjiPnrIctucHQCIwxrtzBXt+rVGmYMEflHrOwf7FYLH60E3Oz54VwSSQCi9J4tXQIhv4SofT5opbcIUj7ji6QrC6c+a3YLjg8l/+/uFjhzsLelAO4gh2k0FJxM04ljH0GZGuXTzhRnqTzJTnYSVo72PC92NA=";
var vc = new VC2();
vc.id = "http://example.gov/credentials/3732";
vc.type = ["Credential", "PassportCredential"];
vc.name = "Passport";
vc.issuer = "https://example.gov";
vc.issued = "2010-01-01";
vc.claim = claim;
vc.signature = signature;
}
This section details the general privacy considerations and specific privacy implications of deploying the verifiable claims data model into production environments.
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.
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.
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.
The data associated with verifiable claims stored in the
credential.claim field are largely susceptible to privacy violations when shared with Inspectors. 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 desires to determine if an entity is over the age of 18.
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.
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.
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.
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 inspectors 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.
Bearer claims containing PII or unique identifiers can be correlated. Bearer claims can be tracked based on usage patterns.
Inspector (corporation) is required to check revocation via Issuer (government).
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:
Aggregation of claims can reveal more information than just the attributes being aggregated.
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:
It’s possible to mitigate this in part:
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.
The rate at which an issuer issues claims may be a privacy violation.
Single-use, origin bound claims are generally safer than long-lived claims.
Claims that are not digitally signed are not verifiable.
Dependent claims should be bundled together so they're not used for the wrong purposes.
Time periods should be shorter for highly dynamic information.
This section describes a number of checks required to verify a claim. Some checks are essential for all verifiable claims, while some are applicable to only some claims.
type and claim are required.
A number of checks must be implemented to ensure a set of entities related to a Credential have mutually compatible properties and are trustworthy.
issuer id must match expectations. Likely, that means it is the id of a known and trusted identity
profile.issued date must be in the expected range. For example, an inspector may wish to ensure that the recorded issued date of valid claims is not in the future.
ageOver.