This document describes the Verifiable Credentials Vocabulary and Term definitions used for describing Verfiable Credentials [[VERIFIABLE-CREDENTIALS]]. This document provides the RDFS [[RDF-SCHEMA]] vocabulary definition and a description of the JSON-LD context definition for use with defining Verfiable Credentials.
Alternate versions of the vocabulary definition exist in
Turtle and
JSON-LD,
which also includes the @context required for metadata descriptions.
Comments regarding this document are welcome. Please file issues directly on GitHub, or send them to public-vc-comments@w3.org (subscribe, archives).
The Working Group seeks implementation feedback, having set the requirement of at least two implementations of each feature as the exit criteria for the Verifiable Credentials Data Model 1.0 Candidate Recommendation phase. The group aims to obtain reports from two producers and two consumers for each feature if possible. For details, see the test suite and sample implementation report.
This document describes the RDFS vocabulary description used for Verifiable Credentials [[VERIFIABLE-CREDENTIALS]] along with the default JSON-LD Context.
This specification makes use of the following namespaces:
cred:https://w3.org/2018/credentials#dc:http://purl.org/dc/terms/sec:https://w3.org/2018/security#xsd:http://www.w3.org/2001/XMLSchema#The following are class definitions in the cred namespace:
| JsonSchemaValidator2018 |
A type of validator that can be used to syntactically validate JSON documents using the JSON Schema language. |
| ManualRefreshService2018 |
A type of refresh service that must be interacted with in a manual fashion.
|
| RefreshService |
Refresh Service
A refresh service is a mechanism that can be utilized by software agents to retrieve an updated copy of a `verifiable credential`. |
| VerifiableCredential |
Verifiable Credential
A `credential` is a set of one or more claims made by an issuer. A `verifiable credential` is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build `verifiable presentations`, which can also be cryptographically verified. The claims in a credential can be about different subjects. |
| VerifiablePresentation |
Verifiable Presentation
A `presentation` is data derived from one or more `credentials`, issued by one or more `issuers`, that is shared with a specific `verifier`. A `verifiable presentation` is a tamper-evident `presentation` encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs). |
The following are property definitions in the cred namespace:
| credentialSchema |
Credential Schema
The value of the credentialSchema property MUST be one or more data schemas that provide verifiers with enough information to determine if the provided data conforms to the provided schema.
|
| credentialStatus |
Credential Status
The value of the credentialStatus property MUST include the id property, which MUST be a URL, and the type property, which expresses the credential status type (also referred to as the credential status scheme), which MUST provide enough information to determine the current status of the credential (for example, suspended or revoked).
|
| credentialSubject |
Credential Subject
An entity about which claims are made.
|
| evidence |
evidence
The value of the evidence property MUST be one or more evidence schemes providing enough information to a verifier to determine whether the evidence gathered meets their requirements for issuing a credential. The precise content of each evidence scheme is determined by the specific evidence type definition.
|
| expirationDate |
expiration date
The value of the expirationDate property MUST be a string value of an ISO8601 combined date and time string representing the date and time the credential ceases to be valid.
|
| issuanceDate |
issuance date
The value of the issuanceDate property MUST be a string value of an ISO8601 combined date and time string representing the date and time the credential was issued. Note that this date represents the earliest date when the information associated with the credentialSubject property became valid.
|
| issuer |
issuer
The value of the issuer property MUST be a URI. It is RECOMMENDED that dereferencing the URI results in a document containing machine-readable information about the issuer that can be used to verify the information expressed in the credential.
|
| refreshService |
refresh service
The value of the refreshService property MUST be one or more refresh services that provides enough information to the holder's software such that the holder can refresh the credential.
|
| serviceEndpoint |
service endpoint
The value of the serviceEndpoint property MUST be a URL to the service endpoint associated with the subject.
|
| termsOfUse |
terms of use
If specified, the value of the termsOfUse property MUST specify one or more terms of use policies under which the creator issued the credential or presentation. If the recipient (a holder or verifier) is not willing to adhere to the specified terms of use, then they do so on their own responsibility and might incur legal liability if they violate the stated Terms of Use. Each termsOfUse MUST specify its type, for example, IssuerPolicy, and optionally, its instance id. The precise contents of each term of use is determined by the specific TermsOfUse type definition.
|
| verifiableCredential |
verifiable credential
The value of the verifiableCredential property MUST describe a VerifiableCredential.
|