Copyright © 2017 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
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.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
Comments regarding this document are welcome. Please file issues directly on GitHub, or send them to public-vc-comments@w3.org (subscribe, archives).
This document was published by the Verifiable Claims Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation. Comments regarding this document are welcome. Please send them to public-vc-comments@w3.org (subscribe, archives).
Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 March 2017 W3C Process Document.
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:
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:
The basic components of a set of verifiable claims are shown in the diagram below:
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.
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:
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.
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.
The Verifiable Claims Use Cases[VC-USECASES] document outlines a number of key topics that readers may find useful, including:
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:
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.
This document attempts to communicate the concepts outlined in the Verifiable Claims space by using specific terms to discuss particular concepts. This terminology is included below and linked to throughout the document to aid the reader:
It is currently possible to include multiple subjects in a credential. The terminology above glosses over that fact. The group is debating if the terminology should be modified to include this nuance, or if the nuance would make grasping the basic concepts more difficult.
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.
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.
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:
The following properties are optional in the Entity Profile Model:
Additionally, any property name not listed above is permitted as an optional custom property.
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:
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 [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:
The following example demonstrates how to express a simple entity profile.
{
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": ["Entity", "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 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.
{
"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.
{ "@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.
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: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.
{
"@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="
}
}
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 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.
{
"@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"
}
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.
{
"@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
}
}
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: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.
{
"@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="
}
}
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.
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 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.
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 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.
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.
Bearer claims containing PII or unique identifiers can be correlated. Bearer claims can be tracked based on usage patterns.
Inspector-verifier (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 entity
profile.issued
date must be in the expected range. For example, an inspector-verifier may wish to ensure that the recorded issued date of valid claims is not in the future.ageOver
.