Verifiable Credentials Data Model v2.0

This section is non-normative.
Credentials
are integral to our daily lives: driver's licenses confirm
our capability to operate motor vehicles; university degrees assert our level
of education; and government-issued passports attest to our citizenship when
traveling between countries. This specification provides a mechanism for
expressing these sorts of
credentials
on the Web in a way that is
cryptographically secure, privacy respecting, and machine verifiable. These
credentials
provide benefits to us when used in the physical world, but
their use on the Web continues to be elusive.
It is currently difficult to express educational qualifications, healthcare
data, financial account details, and other third-party-
verified
personal information in a machine readable way on the Web. The challenge of
expressing digital
credentials
on the Web hinders our ability to receive
the same benefits from them that physical
credentials
provide in the
real world.
For those unfamiliar with the concepts related to
verifiable credentials
, the following sections provide an overview of:
The use cases and requirements that informed this specification can be found
in
Verifiable Credentials Use Cases
VC-USE-CASES
].
This section is non-normative.
In the physical world, a
credential
might consist of:
Information related to identifying the
subject
of the
credential
(for example, a photo, name, or identification number)
Information related to the issuing authority (for example, a city government,
national agency, or certification body)
Information related to the type of
credential
(for example, a
Dutch passport, an American driving license, or a health insurance card)
Information related to specific properties asserted by
the issuing authority about the
subject
(for example, nationality,
date of birth, or the classes of vehicle they're qualified to drive)
Evidence by which a
subject
was demonstrated to have satisfied the
qualifications required for issuance of the
credential
(for example,
a measurement, proof of citizenship, or test result)
Information related to constraints on the credential (for example,
validity period, or terms of use).
verifiable credential
can represent all the same information that a
physical
credential
represents. Adding technologies such as
digital signatures can make
verifiable credentials
more tamper-evident and
trustworthy than their physical counterparts.
Holders
of
verifiable credentials
can generate
verifiable presentations
and then share these
verifiable presentations
with
verifiers
to prove they possess
verifiable credentials
with specific characteristics.
Both
verifiable credentials
and
verifiable presentations
can be
transmitted rapidly, making them more convenient than their physical
counterparts when establishing trust at a distance.
While this specification attempts to improve the ease of expressing digital
credentials
, it also aims to balance this goal with several
privacy-preserving goals. The persistence of digital information, and the ease
with which disparate sources of digital data can be collected and correlated,
comprise a privacy concern that the use of
verifiable
and easily
machine-readable
credentials
threatens to make worse. This document
outlines and attempts to address several of these issues in Section
8.
Privacy Considerations
. Examples of how to use this data model
using privacy-enhancing technologies, such as zero-knowledge proofs, are also
provided throughout this document.
The word "verifiable" in the terms
verifiable credential
and
verifiable presentation
refers to the characteristic of a
credential
or
presentation
as being able to be
verified
by a
verifier
as defined in this document. Verifiability of a credential does not imply
the truth of
claims
encoded therein. Instead, upon establishing the
authenticity and currency of a
verifiable credential
or
verifiable presentation
, a
verifier
validates the included
claims
using
their own business rules before relying on them. Such reliance only occurs after
evaluating the issuer, the proof, the subject, and the claims against one or
more verifier policies.
This section is non-normative.
This section describes the roles of the core actors and the relationships
between them in an ecosystem where one expects
verifiable credentials
to be useful. A role is an abstraction that might be implemented in many
different ways. The separation of roles suggests likely interfaces and
protocols for standardization. This specification introduces the following
roles:
holder
A role an
entity
might perform by possessing one or more
verifiable credentials
and generating
verifiable presentations
from them. A holder is
often, but not always, a
subject
of the
verifiable credentials
they are
holding. Holders store their
credentials
in
credential repositories
Example holders include students, employees, and customers.
issuer
A role an
entity
can perform by asserting
claims
about one or more
subjects
, creating a
verifiable credential
from these
claims
, and
transmitting the
verifiable credential
to a
holder
. For example, issuers
include corporations, non-profit organizations, trade associations, governments,
and individuals.
subject
A thing about which
claims
are made. Example subjects include human beings,
animals, and things.
verifier
A role an
entity
performs by receiving one or more
verifiable credentials
, optionally inside a
verifiable presentation
for processing.
Example verifiers include employers, security personnel, and websites.
verifiable data registry
A role a system might perform by mediating the creation and
verification
of
identifiers,
verification material
, and other relevant data, such as
verifiable credential
schemas, revocation registries, and so on, which might
require using
verifiable credentials
. Some configurations might require
correlatable identifiers for
subjects
. Some registries, such as ones for
UUIDs and
verification material
, might just act as namespaces for
identifiers. Examples of verifiable data registries include trusted databases,
decentralized databases, government ID databases, and distributed ledgers. Often,
more than one type of verifiable data registry used in an ecosystem.
Figure
The roles and information flows forming the basis for this
specification.
Note
: Other types of ecosystems exist
Figure
above provides an example ecosystem to ground the
rest of the concepts in this specification. Other ecosystems exist, such as
protected environments or proprietary systems, where
verifiable credentials
also provide benefits.
This ecosystem contrasts with the typical two-party or federated identity
provider models. An identity provider, sometimes abbreviated as
IdP
is a system for creating, maintaining, and managing identity information for
holders
while providing authentication services to
relying party
applications within a federation or distributed network. In a federated
identity model, the
holder
is tightly bound to the identity provider.
This specification avoids using "identity provider," "federated identity," or
"relying party" terminology, except when comparing or mapping these concepts
to other specifications. This specification decouples the identity provider
concept into two distinct concepts: the
issuer
and the
holder
For a deeper exploration of the
verifiable credentials
ecosystem and
a concrete lifecycle example, please refer to
Verifiable Credentials Overview
VC-OVERVIEW
].
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words
MAY
MUST
MUST NOT
OPTIONAL
RECOMMENDED
REQUIRED
SHOULD
, and
SHOULD NOT
in this document
are to be interpreted as described in
BCP 14
RFC2119
] [
RFC8174
when, and only when, they appear in all
capitals, as shown here.
conforming document
is a
compacted
JSON-LD
document that complies with all of the relevant "
MUST
" statements in this
specification. Specifically, the relevant normative "
MUST
" statements in
Sections
4.
Basic Concepts
5.
Advanced Concepts
, and
6.
Syntaxes
of this document
MUST
be enforced.
A conforming document
MUST
be either a
verifiable credential
with a media type of
application/vc
or a
verifiable presentation
with a media type of
application/vp
. A conforming document
MUST
be
secured by at least one securing mechanism as described in Section
4.12
Securing Mechanisms
conforming issuer implementation
produces
conforming documents
MUST
include all required properties in the
conforming documents
it produces, and
MUST
secure the
conforming documents
it produces using a securing mechanism described in Section
4.12
Securing Mechanisms
conforming verifier implementation
consumes
conforming documents
MUST
perform
verification
on a
conforming document
as described in Section
4.12
Securing Mechanisms
MUST
check that each
required property satisfies the normative requirements for that property, and
MUST
produce errors when non-
conforming documents
are detected.
This specification includes both required and optional properties. Optional
properties
MAY
be ignored by
conforming issuer implementations
and
conforming verifier implementations
This document also contains examples that contain characters that are invalid
JSON, such as inline comments (
//
) and the use of ellipsis
...
) to denote information that adds little value to the example.
Implementers are cautioned to remove this content if they desire to use the
information as a valid document.
Note
: Human-readable texts in English are illustrative
Examples provided throughout this document include descriptive properties, such as
name
and
description
, with values in English to simplify the concepts in each
example of the specification. These examples do not necessarily reflect the data
structures needed for international use, described in more detail in
Section
11.
Internationalization Considerations
This section introduces some basic concepts for the specification in
preparation for Section
5.
Advanced Concepts
later in the
document.
This section is non-normative.
This specification is designed to ease the prototyping of new types of
verifiable credentials
. Developers can copy the template below and paste it
into common
verifiable credential
tooling to start issuing, holding, and
verifying prototype credentials.
A developer will change
MyPrototypeCredential
below to the type of credential
they would like to create. Since
verifiable credentials
talk about subjects,
each property-value pair in the
credentialSubject
object expresses a
particular property of the credential subject. Once a developer has added a
number of these property-value combinations, the modified object can be sent to
conforming issuer implementation
, and a
verifiable credential
will be
created for the developer. From a prototyping standpoint, that is all a
developer needs to do.
Example
: A template for creating prototype verifiable credentials
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiableCredential", "MyPrototypeCredential"],
"credentialSubject": {
"mySubjectProperty": "mySubjectValue"
After stabilizing all credential properties, developers are advised to generate
and publish vocabulary and context files at stable URLs to facilitate
interoperability with other developers. The
URL above
would then be replaced with the URL of a use-case-specific context. This
process is covered in Section
5.2
Extensibility
. Alternatively,
developers can reuse existing vocabulary and context files that happen to fit
their use case. They can explore the
Verifiable Credential Extensions
for reusable resources.
When two software systems need to exchange data, they need to use terminology
that both systems understand. Consider how two people communicate effectively
by using the same language, where the words they use, such as "name" and
"website," mean the same thing to each individual. This is sometimes referred
to as
the context of a conversation
. This specification uses a similar
concept to achieve similar results for software systems by establishing a
context in which to communicate.
Software systems that process
verifiable credentials
and
verifiable presentations
identify terminology by using
URLs
for each term. However,
those
URLs
can be long and not very human-friendly, while short-form,
human-friendly aliases can be more helpful. This specification uses the
@context
property
to map short-form aliases to the
URLs
Verifiable credentials
and
verifiable presentations
MUST
include a
@context
property
. Application developers
MUST
understand every JSON-LD
context used by their application, at least to the extent that it affects the
meaning of the terms used by their application. One mechanism for
doing so is described in the Section on
Validating Contexts
in
the
Verifiable Credential Data Integrity 1.0
specification. Other specifications that build
upon this specification
MAY
require that JSON-LD contexts be integrity protected
by using the
relatedResource
feature described in Section
5.3
Integrity of Related Resources
or any effectively equivalent mechanism.
@context
The value of the
@context
property
MUST
be an
ordered set
where the first item is a
URL
with the value
Subsequent items in the
ordered set
MUST
be composed of any combination of
URLs
and objects, where each is processable as a
JSON-LD Context
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
"id": "http://university.example/credentials/58473",
"type": ["VerifiableCredential", "ExampleAlumniCredential"],
"issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": "Example University"
The example above uses the base context
URL
) to establish that the data exchange is
about a
verifiable credential
. This concept is further detailed in
Section
5.2
Extensibility
. The data available at
is a permanently cacheable static
document with instructions for processing it provided in Appendix
B.1
Base Context
. The associated human-readable vocabulary document for the
Verifiable Credentials Data Model is available at
The second
URL
) is used to
demonstrate examples. Implementations are expected to not use
this
URL
for any other purpose, such as in pilot or production systems.
When expressing statements about a specific thing, such as a person, product, or
organization, using a globally unique identifier for that thing can be useful.
Globally unique identifiers enable others to express statements
about the same thing. This specification defines the optional
id
property
for such identifiers. The
id
property
allows for expressing statements about specific things in the
verifiable credential
and is set by an
issuer
when expressing
objects in a
verifiable credential
or a
holder
when expressing
objects in a
verifiable presentation
. The
id
property
expresses an
identifier that others are expected to use when expressing statements about the
specific thing identified by that identifier. Example
id
values
include UUIDs (
urn:uuid:0c07c1ce-57cb-41af-bef2-1b932b986873
), HTTP URLs
), and DIDs (
did:example:1234abcd
).
Note
: Identifiers of any kind increase correlatability
Developers are reminded that identifiers might be harmful
when pseudonymity is required. When considering such scenarios, developers are
encouraged to read Section
8.4
Identifier-Based Correlation
carefully
There are also other types of access and correlation mechanisms documented
in Section
8.
Privacy Considerations
that create privacy concerns.
Where privacy is a vital consideration, it is permissible to omit the
id
property
. Some use cases do not need or explicitly need to omit,
the
id
property
. Similarly, special attention is to be given to the choice
between publicly resolvable URLs and other forms of identifiers. Publicly
resolvable URLs can facilitate ease of verification and interoperability, yet
they might also inadvertently grant access to potentially sensitive information
if not used judiciously.
id
The
id
property
is
OPTIONAL
. If present,
id
property
's value
MUST
be a single
URL
, which
MAY
be dereferenceable. It is
RECOMMENDED
that the
URL
in the
id
be one which, if dereferenceable, results
in a document containing machine-readable information about the
id
Credential
ecdsa
ecdsa-sd
bbs
jose
cose
sd-jwt
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732"
"type": ["VerifiableCredential", "ExampleDegreeCredential"],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21"
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:33Z",
"verificationMethod": "did:key:zDnaebSRtPnW6YCpxAhR5JPxJqt9UunCsBPhLEtUokUvp87nQ",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z5WHRyhjLd2H5RFcSqW3bss39zFBvVrVuXUovBpbGX2ATL8vSxwoeoiZFb1eibsdjRQK5GS1nr76RZRKBj7iH9roE"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:33Z",
"verificationMethod": "did:key:zDnaerJh8WwyBVVGcZKKkqRKK9iezje8ut6t9bnNChtxcWwNv",
"cryptosuite": "ecdsa-sd-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0AhVhAfojGD02jMuCezr87Ra8dvWa9ruscwcjDo2jYpvNEzxQthrKO3csDTuvk2A278uD7Cot6fgfm4YXddQ3eKnF91VgjgCQCpvhiT83vvn-T-PFVSUfoo51-s11TfQ39hmlIC61wy2hYINWUMbNH3sN80JcCKn-4fcaBDpSGT7KgsL07bUWUlHrJhVhAG4V_V2OV_xGWDfKU1CH_D53kF5Hy8RBi4S0551TkpUKvouKF5s5a-b1qDh2iNK1RXQyF6vdhbt4Kjo0RfnSYplhAvBoxWd2Xmpe8ERCoO3qs3el64rEmsYuPOgMyQTacrl2tuFLs3ui23JdtCnOSxmcRzVC27r4HIpubjSug4NE261hAcb7bwdJUpxP6Bqp7hiD8O_nFIMxLdzErfU522ZVy4CqLOiEERGMT2jFlgDcxlpkk5ZrMJOl9QfQSLPtjolWIy1hAbOzFKnJtBhSu3lfzmSftTWl1-FLtWu3Lt7ePxpGPbMjr6DVfS3sZL8E6M4uETdce15BsDkThGi_1ZjJ7YG9GLFhADav02TPSZdSV73AqOyZ6ryfuz3Y7pKKuu67dnqNzzXS-H-8-39I1rA759bba_lkqeo8F0lPtT_3liNamnCd-CoFnL2lzc3Vlcg"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"verificationMethod": "did:key:zUC78GzFRA4TWh2mqRiKro1wwRb5KDaMJ3M1AD3qGtgEbFrwWGvWbnCzArkeTZCyzBz4Panr2hLaZxsXHiBQCwBc3fRPH6xY4u5v8ZAd3dPW1aw89Rra86CVwXr3DczANggYbMD",
"cryptosuite": "bbs-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0ChVhQkkdBby2GbmvVh66cM6TNzNfh0hR9ePeG7dWYbHfDxK6CcA_rVoxxsRGIoWX5Gs6ZGgQNPTBeehiEHT_cj-5fjZ6ArTluARHPbaXQzWyXKrVYQGd_DaMQQsoaryttl5TvxnFT-Vm4SkVx03K9qNJ4jhArS1r7HKFDPyyrvPGqNF8bjgNELvoomOjpbD9JEvaGI1pYYJVTGbTfcflzyx41E-f9kSqmf10xYzxJrGfC7b7GPY8X7VjMT__ZKSuwdH-5jak-5gkjocsHI6oxIKlLrhW1Wh5yrDCH-QC823TS8NE9VGBzIFAfUt5qazGEcJ8CxeSPxFgg1LgUmXHTRjMrLAeoNgJipw-F81uEwauN0JK-WcohpmWBZy9pc3N1ZXI"
Protected Headers
"kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
"alg": "ES256"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+jwt
eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGUiOiJFeGFtcGxlQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX0
YEsG9at9Hnt_j-UykCrnl494fcYMTjzpgvlK0KzzjvfmZmSg-sNVJqMZWizYhWv_eRUvAoZohvSJWeagwj_Ajw
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+cose
d28443a10128a05901be7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f353635303439222c2276616c696446726f6d223a22323031302d30312d30315430303a30303a30305a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d584013d7bfd4a7f3c0296d67f24157e4ba5a5fedafc688c5e01bd72f23e1d419d558ec05cddf9ac477fdc9fc7a8b1325dc80968a1bbc95d2c601753693290cbff553
Encoded
Decoded
Issuer Disclosures
eyJpYXQiOjE3NDU3NzY3MTMsImV4cCI6MTc0Njk4NjMxMywiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImRlZ3JlZSI6eyJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyIsIl9zZCI6WyJhbDRaR3cxellsZU1BMTA2SXpiLVhlc0pBbldDZ1NpNW5QbjFKRVYxamo4Il19LCJfc2QiOlsiOC1vWU9FU1JrNjBpbVozblgzY2E5RGxIeXFJcTk4RnQzX19HMUFsYU90MCJdfSwiX3NkIjpbIk9EUGNVWENXbGQtSGlxQ1h5NEhuY1Mxb3hqaURpRE9wMTJ4YlVveEZvU2MiLCJVaGtGbUw3cXc0UVlLWDJjVDNMWFAwcDZ5VHc1UmlIRG5xWGxfMFZLZnhBIl19
YASiTse77TXvt7jYyChZOd6x0TbbBeEVZ14pekiOWw6G6N40a3evbWFBAkuPcStVFZPshFy1GFECySRVAhcD5A
WyIzQkdhQ3BfaTZIV0hEMm5GekZ2blN3IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
WyJld1p0bUpDZHA2VWFWcEVhTXZ0V0FRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
WyJIdThleHpqLTBySDg0aEtwenhnS0VnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
WyJVczR2ekVuVWJuSU96OC1VVDd2OHN3IiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Claim:
id
SHA-256 Hash:
ODPcUXCWld-HiqCXy4HncS1oxjiDiDOp12xbUoxFoSc
Disclosure(s):
WyIzQkdhQ3BfaTZIV0hEMm5GekZ2blN3IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
Contents:
"3BGaCp_i6HWHD2nFzFvnSw",
"id",
"http://university.example/credentials/3732"
Claim:
type
SHA-256 Hash:
UhkFmL7qw4QYKX2cT3LXP0p6yTw5RiHDnqXl_0VKfxA
Disclosure(s):
WyJld1p0bUpDZHA2VWFWcEVhTXZ0V0FRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
Contents:
"ewZtmJCdp6UaVpEaMvtWAQ",
"type",
"VerifiableCredential",
"ExampleDegreeCredential"
Claim:
id
SHA-256 Hash:
8-oYOESRk60imZ3nX3ca9DlHyqIq98Ft3__G1AlaOt0
Disclosure(s):
WyJIdThleHpqLTBySDg0aEtwenhnS0VnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
Contents:
"Hu8exzj-0rH84hKpzxgKEg",
"id",
"did:example:ebfeb1f712ebc6f1c276e12ec21"
Claim:
type
SHA-256 Hash:
al4ZGw1zYleMA106Izb-XesJAnWCgSi5nPn1JEV1jj8
Disclosure(s):
WyJVczR2ekVuVWJuSU96OC1VVDd2OHN3IiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Contents:
"Us4vzEnUbnIOz8-UT7v8sw",
"type",
"ExampleBachelorDegree"
The example above uses two types of identifiers. The first identifier is for
the
verifiable credential
and uses an HTTP-based URL. The second
identifier is for the
subject
of the
verifiable credential
(the
thing the
claims
are about) and uses a
decentralized identifier
also known as a
DID
Software systems that process the kinds of objects specified in this document
use type information to determine whether or not a provided
verifiable credential
or
verifiable presentation
is appropriate
for the intended use-case. This specification defines a
type
property
for expressing object type information. This type
information can be used during
validation
processes, as described in Appendix
A.
Validation
Verifiable credentials
and
verifiable presentations
MUST
contain a
type
property
with an associated value.
type
The value of the
type
property
MUST
be one or more
and
absolute URL strings
. If more than
one value is provided, the order does not matter.
Credential
ecdsa
ecdsa-sd
bbs
jose
cose
sd-jwt
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": ["VerifiableCredential", "ExampleDegreeCredential"]
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:33Z",
"verificationMethod": "did:key:zDnaebSRtPnW6YCpxAhR5JPxJqt9UunCsBPhLEtUokUvp87nQ",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z2F16goBUjRsg2ieNiojpaz313CN98DU4APFiokAUkUvEYESSDmokg1omwvcK7EFqLgYpdyekEoxnVHwuxt8Webwa"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:33Z",
"verificationMethod": "did:key:zDnaerJh8WwyBVVGcZKKkqRKK9iezje8ut6t9bnNChtxcWwNv",
"cryptosuite": "ecdsa-sd-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0AhVhAIC9hFSOtM2k0lFFuKclfp_cYTO5YWhZIYaMEPMcz1jloqTS0Zkww-Lc1U6FP15vJBaIa5ICMknDv16H8r0eh8VgjgCQDJUVkvejrCod7srzLsvKZEVUqzPULOZlb5-cwYdz0K8NYIJNls-gfevdbPuoczDW5TuctpSXJ7V9anf9MrkmJYP7ehVhARNoIdk_H3oT_8HxLP5Fo38e9blzlzSBmFswtxQUPzERVBXcgCU9k6c8pJz_RmjL0Y1eaW50Gl_qs_olK0u7NKlhAD3n7fkV5E-YF4KlodM7PhHP8_kB9you9XtTDVif3tyYsfWewmRysEN0A-EdLZ0WRwSwyJGBaBgGPb5erVUT-ElhAmLyoxIvE3GPC9rTc8tpfNEmTvcwBlpDGMlYkKb52XQeQeQFQwzgCPhpJowOomdMfPUq_xsHih8NsnDN0LXJtVFhArdqKKbPA-tMtA0mMQn1vIZ6mVjeTeJTsdxwZze2EspERwrMcgS25V-fVtjdEXCmNKyL7giUGy4eixjRGYowzpFhADobyi3ucf61IGgBM8_Vy1b8JkaiISFoy_i8ZldQfiqIoG00zU4-jEFuLWvsW7FGfPo0jq-2ZZBvS5H4SjaETJIFnL2lzc3Vlcg"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"verificationMethod": "did:key:zUC78GzFRA4TWh2mqRiKro1wwRb5KDaMJ3M1AD3qGtgEbFrwWGvWbnCzArkeTZCyzBz4Panr2hLaZxsXHiBQCwBc3fRPH6xY4u5v8ZAd3dPW1aw89Rra86CVwXr3DczANggYbMD",
"cryptosuite": "bbs-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0ChVhQkkdBby2GbmvVh66cM6TNzNfh0hR9ePeG7dWYbHfDxK6CcA_rVoxxsRGIoWX5Gs6ZGgQNPTBeehiEHT_cj-5fjZ6ArTluARHPbaXQzWyXKrVYQGd_DaMQQsoaryttl5TvxnFT-Vm4SkVx03K9qNJ4jhArS1r7HKFDPyyrvPGqNF8bjgNELvoomOjpbD9JEvaGI1pYYJVTGbTfcflzyx41E-f9kSqmf10xYzxJrGfC7b7GPY8X7VjMT__ZKSuwdH-5jak-5gkjocsHI6oxIKlLrhW1Wh5yrDCH-QC823TS8NE9VGBzIFAfUt5qazGEcJ8CxeSPxFgg_vwNGMCz741AWQhjph2NJJcybTTnmtmN1AZd15PefM6BZy9pc3N1ZXI"
Protected Headers
"kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
"alg": "ES256"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+jwt
eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGUiOiJFeGFtcGxlQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX0
yLIZkNIu3N3b2JNM69FVtAD9C5iaw7qMRc5TG6Yl8yWUu9ql9cO2sUBzNSSSz7MfqW_PMXxpbqplMKsuheroaA
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+cose
d28443a10128a05901be7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f353635303439222c2276616c696446726f6d223a22323031302d30312d30315430303a30303a30305a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d58402c8dcd949c0418cf1b489b94632ccaea624331ad4881b15e5c3fddb34d86a5128f5442cd5603f3a0a8d8282ac7b13090c79249b048e3433e9eebfed1d0407adf
Encoded
Decoded
Issuer Disclosures
eyJpYXQiOjE3NDU3NzY3MTMsImV4cCI6MTc0Njk4NjMxMywiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImRlZ3JlZSI6eyJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyIsIl9zZCI6WyJEUkg1aWVsZHdHNXJPMlVQNXlYYlBXWHNTaFFNSmxESlJfZlFVbmhZVDNFIl19LCJfc2QiOlsiUzRvTGpDb0dNckpuMnFFR2lXY1JNNmdFNGZ6cVVFcVIzNC1FOWdjZzIyWSJdfSwiX3NkIjpbIlZtWnFMMkpKUFB0RDk2TmxwNE43TzFRMXhFRmNMZ1hCVzVfQWFGQXp4Sm8iLCJaYTdxRkpZSnRSTExSOFNRT1VUYUxwaDZBY21QSGlYVkc5Ni03Wnp3MEtJIl19
ypl46Q1EqUERV-IUUS_-qGoAESfv_WdXwtHOk2vX7QTZNFf0NNfg-w2OR8JPRe97kZBDQLuBZKPJhBXdFjbSwg
WyIxeDVielRkZXhsLW4zWVVIQXF5ZUxBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
WyJablVReVZXRmo0UlFfTHFmOVBkbmN3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
WyI5TG1nOHhaUVJxWEZZaVRlV0hRZjV3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
WyJZMVBDaVA3YnJ3TjFHMEVMWmJXRlZRIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Claim:
id
SHA-256 Hash:
VmZqL2JJPPtD96Nlp4N7O1Q1xEFcLgXBW5_AaFAzxJo
Disclosure(s):
WyIxeDVielRkZXhsLW4zWVVIQXF5ZUxBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
Contents:
"1x5bzTdexl-n3YUHAqyeLA",
"id",
"http://university.example/credentials/3732"
Claim:
type
SHA-256 Hash:
Za7qFJYJtRLLR8SQOUTaLph6AcmPHiXVG96-7Zzw0KI
Disclosure(s):
WyJablVReVZXRmo0UlFfTHFmOVBkbmN3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
Contents:
"ZnUQyVWFj4RQ_Lqf9Pdncw",
"type",
"VerifiableCredential",
"ExampleDegreeCredential"
Claim:
id
SHA-256 Hash:
S4oLjCoGMrJn2qEGiWcRM6gE4fzqUEqR34-E9gcg22Y
Disclosure(s):
WyI5TG1nOHhaUVJxWEZZaVRlV0hRZjV3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
Contents:
"9Lmg8xZQRqXFYiTeWHQf5w",
"id",
"did:example:ebfeb1f712ebc6f1c276e12ec21"
Claim:
type
SHA-256 Hash:
DRH5ieldwG5rO2UP5yXbPWXsShQMJlDJR_fQUnhYT3E
Disclosure(s):
WyJZMVBDaVA3YnJ3TjFHMEVMWmJXRlZRIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Contents:
"Y1PCiP7brwN1G0ELZbWFVQ",
"type",
"ExampleBachelorDegree"
Concerning this specification, the following table lists the objects that
MUST
have a
type
specified.
Object
Type
Verifiable credential
object
VerifiableCredential
and, optionally, a more specific
verifiable credential
type
. For example,
"type": ["VerifiableCredential", "OpenBadgeCredential"]
Verifiable presentation
object
VerifiablePresentation
and, optionally, a more specific
verifiable presentation
type
. For example,
"type": "VerifiablePresentation"
credentialStatus
object
A valid
credential
status
type
. For example,
"type": "BitstringStatusListEntry"
object
A valid terms of use
type
. For example,
"type": "TrustFrameworkPolicy"
evidence
object
A valid evidence
type
. For example,
"type": "Evidence"
refreshService
object
A valid refreshService
type
. For example,
"type": "VerifiableCredentialRefreshService2021"
credentialSchema
object
A valid credentialSchema
type
. For example,
"type": "JsonSchema"
Note
: The Verifiable Credentials Data Model is based on JSON-LD
The
type
system for the Verifiable Credentials Data Model is the same as
for
JSON-LD 1.1
and is detailed in
Section 3.5:
Specifying the Type
and
Section 9: JSON-LD
Grammar
. When using a JSON-LD context (see Section
5.2
Extensibility
), this specification aliases the
@type
keyword to
type
to make the JSON-LD documents
more easily understood. While application developers and document authors do
not need to understand the specifics of the JSON-LD type system, implementers
of this specification who want to support interoperable extensibility do.
All
credentials
presentations
, and encapsulated objects
SHOULD
specify, or be associated with, additional, more narrow
types
(like
ExampleDegreeCredential
, for example) so software systems can
more easily detect and process this additional information.
When processing encapsulated objects defined in this specification, such as
objects associated with the
credentialSubject
object or deeply nested therein,
software systems
SHOULD
use the
type
information specified in encapsulating
objects higher in the hierarchy. Specifically, an encapsulating object, such as
credential
SHOULD
convey the associated object
types
so that
verifiers
can quickly determine the contents of an associated object based
on the encapsulating object
type
For example, a
credential
object with the
type
of
ExampleDegreeCredential
, signals to a
verifier
that the
object associated with the
credentialSubject
property contains the
identifier for the:
Subject
in the
id
property.
Type of degree in the
type
property.
Title of the degree in the
name
property.
This enables implementers to rely on values associated with the
type
property
for
verification
. Object types and their associated values are
expected to be documented in at least a human-readable specification that can
be found at the
URL
for the type. For example, the human-readable
definition for the
BitstringStatusList
type can be found at
. It is also
suggested that a
machine-readable version
be provided through HTTP content negotiation at
the same URL.
When displaying a
credential
, it can be helpful to have
text provided by the
issuer
that furnishes the
credential
with a name and a short description of its
purpose. The
name
and
description
properties
serve these purposes.
name
An
OPTIONAL
property that expresses the name of the
credential
. If
present, the value of the
name
property
MUST
be a string or
a language value object as described in
11.1
Language and Base Direction
. Ideally, the name of a
credential
is concise, human-readable, and could enable an individual to
quickly differentiate one
credential
from any other
credentials
they might hold.
description
An
OPTIONAL
property that conveys specific details about a
credential
. If
present, the value of the
description
property
MUST
be a
string or a language value object as described in
11.1
Language and Base Direction
. Ideally, the description of a
credential
is no more than a few sentences in length and conveys enough
information about the
credential
to remind an individual of its contents
without having to look through the entirety of the
claims
Example
: Use of the name and description properties
Credential
ecdsa
ecdsa-sd
bbs
jose
cose
sd-jwt
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": ["VerifiableCredential", "ExampleDegreeCredential"],
"issuer": {
"id": "https://university.example/issuers/565049",
"name": "Example University",
"description": "A public university focusing on teaching examples."
},
"validFrom": "2015-05-10T12:30:00Z",
"name": "Example University Degree",
"description": "2015 Bachelor of Science and Arts Degree",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": {
"id": "https://university.example/issuers/565049",
"name": "Example University",
"description": "A public university focusing on teaching examples."
},
"validFrom": "2015-05-10T12:30:00Z",
"name": "Example University Degree",
"description": "2015 Bachelor of Science and Arts Degree",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:33Z",
"verificationMethod": "did:key:zDnaebSRtPnW6YCpxAhR5JPxJqt9UunCsBPhLEtUokUvp87nQ",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z2LeuoNi3yR1b6c3fkRsEvXJ5ex8X4RdutyK7L6HAo2bJQwr21w85Y5KWy3DptXR8ke52Assqik6wKTy9DKqkEZ2r"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": {
"id": "https://university.example/issuers/565049",
"name": "Example University",
"description": "A public university focusing on teaching examples."
},
"validFrom": "2015-05-10T12:30:00Z",
"name": "Example University Degree",
"description": "2015 Bachelor of Science and Arts Degree",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:33Z",
"verificationMethod": "did:key:zDnaerJh8WwyBVVGcZKKkqRKK9iezje8ut6t9bnNChtxcWwNv",
"cryptosuite": "ecdsa-sd-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0AhVhA5A-VvZ6RF2KlLjsYsx1DosYuzhbD7hn6N6gTF5yv22oTPKcqHyElGQn3TcerwktEbNrRiuWMvmfuw1XmwhCk-lgjgCQCHC44msX1XnfID2VfkUX1j1PHUzfjdORSePcGUhVB3KxYIBeo1lJt0Rp-So7_Ch6hiCE36oR-r6WyVaT6r-o0Nf1nh1hATMKDPXogkIVw6n-pqlDoJMti8cCVJvle_IWSAqv5vShtqt5E6NEJ3PTiK7NwSMSGMVE0XdJXZlEj3xck6UL0vlhAa7ltjeSjPD1TD52OkPPjuQrhADwoTsDXERr-UCuNICq-uxKiFsxebXjys1SeHIFzT0TQA5TlTl-J55vFL90q-lhAi8EKNrgQiKdl_EAlgv3aS15FLuIpUmfROB6srPRpHI4cz-kC8xlarcp9XMqHIpL5hncUJd2EoGTmMpm3nzs3PVhAr4sC2Lin-35yxMSvWXrq7cEGw4IomJnayfWsxmXencGOmXQzZxJbsUHmLCAprm51apFj19BZED6G-82Ilx0ZvlhADRiBGvSKeF3hYkihvS7kkZDnySRU4Q4yfNm_Hwe6kysHhtP5rnbu3LYfU-hI_0P6FbZJrPQ7uifIMg2QMHxARFhAxjQMayCxmcOVGlo5ICU5zQxx6qTgjgpNl1GC1dGjnA1J3xhFALceL5DHxJbSvcRsRVwRjBybMkZurUWhPgzpwVhAhbwrQWJSLLhyXqFcQef_-eKnNE3F5oBq2phORFJ16m3uRU-R-vSoXJlSpyLBZrNGU7gwCHVv0b_e2ZC13MiFR4FnL2lzc3Vlcg"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": {
"id": "https://university.example/issuers/565049",
"name": "Example University",
"description": "A public university focusing on teaching examples."
},
"validFrom": "2015-05-10T12:30:00Z",
"name": "Example University Degree",
"description": "2015 Bachelor of Science and Arts Degree",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"verificationMethod": "did:key:zUC78GzFRA4TWh2mqRiKro1wwRb5KDaMJ3M1AD3qGtgEbFrwWGvWbnCzArkeTZCyzBz4Panr2hLaZxsXHiBQCwBc3fRPH6xY4u5v8ZAd3dPW1aw89Rra86CVwXr3DczANggYbMD",
"cryptosuite": "bbs-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0ChVhQkS0mcHTu9KLuuY8_DlU_2lj8Su_EXxWyY0xMPZuCGQMRzah3DFaerG-CRDFWR1KBWkYUpPizkPDULYOU8XsXoC3a8_00GgHfKuoiNCLnSNBYQGd_DaMQQsoaryttl5TvxnFT-Vm4SkVx03K9qNJ4jhArXFDE8ZX70eeJX1DawHuw0sW9CBV3sa68IaRGcnZiiQpYYJVTGbTfcflzyx41E-f9kSqmf10xYzxJrGfC7b7GPY8X7VjMT__ZKSuwdH-5jak-5gkjocsHI6oxIKlLrhW1Wh5yrDCH-QC823TS8NE9VGBzIFAfUt5qazGEcJ8CxeSPxFggbCn9jbv1yUPTocre_YTgvXiebb8lJMqxhmAnw4MiFbWBZy9pc3N1ZXI"
Protected Headers
"kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
"alg": "ES256"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": {
"id": "https://university.example/issuers/565049",
"name": "Example University",
"description": "A public university focusing on teaching examples."
},
"validFrom": "2015-05-10T12:30:00Z",
"name": "Example University Degree",
"description": "2015 Bachelor of Science and Arts Degree",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+jwt
eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJuYW1lIjoiRXhhbXBsZSBVbml2ZXJzaXR5IiwiZGVzY3JpcHRpb24iOiJBIHB1YmxpYyB1bml2ZXJzaXR5IGZvY3VzaW5nIG9uIHRlYWNoaW5nIGV4YW1wbGVzLiJ9LCJ2YWxpZEZyb20iOiIyMDE1LTA1LTEwVDEyOjMwOjAwWiIsIm5hbWUiOiJFeGFtcGxlIFVuaXZlcnNpdHkgRGVncmVlIiwiZGVzY3JpcHRpb24iOiIyMDE1IEJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMgRGVncmVlIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ
x5OQX2cmaXVU-UxScJ1KlOgR9nwpLvFO4s-fWuHvb58DDEb-xVxS8hqPIpLiNK0F3eedtoHeJ2gJ2RHVnGVSNQ
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": {
"id": "https://university.example/issuers/565049",
"name": "Example University",
"description": "A public university focusing on teaching examples."
},
"validFrom": "2015-05-10T12:30:00Z",
"name": "Example University Degree",
"description": "2015 Bachelor of Science and Arts Degree",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+cose
d28443a10128a05902807b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a7b226964223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f353635303439222c226e616d65223a224578616d706c6520556e6976657273697479222c226465736372697074696f6e223a2241207075626c696320756e697665727369747920666f637573696e67206f6e207465616368696e67206578616d706c65732e227d2c2276616c696446726f6d223a22323031352d30352d31305431323a33303a30305a222c226e616d65223a224578616d706c6520556e697665727369747920446567726565222c226465736372697074696f6e223a22323031352042616368656c6f72206f6620536369656e636520616e64204172747320446567726565222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d5840e49e36b7cb7a12d81900a6ba0bdd26084dcb33baaf759a3a7b3eacff8af566291f6ae573ba6707b231de6f70372e4b8da88e9be12b0f7dd168d5b6f0f0044770
Encoded
Decoded
Issuer Disclosures
eyJpYXQiOjE3NDU3NzY3MTMsImV4cCI6MTc0Njk4NjMxMywiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjp7Im5hbWUiOiJFeGFtcGxlIFVuaXZlcnNpdHkiLCJkZXNjcmlwdGlvbiI6IkEgcHVibGljIHVuaXZlcnNpdHkgZm9jdXNpbmcgb24gdGVhY2hpbmcgZXhhbXBsZXMuIiwiX3NkIjpbIjN5U2k5WkUtdWp0RDQ4NDRacGY4V2NMY3EwQWlyajVqbFJmLTNSQVJPcmsiXX0sInZhbGlkRnJvbSI6IjIwMTUtMDUtMTBUMTI6MzA6MDBaIiwibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSBEZWdyZWUiLCJkZXNjcmlwdGlvbiI6IjIwMTUgQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyBEZWdyZWUiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiZnRIMUtTRTVzNmZKd1cyMWY2STBlUmNtYW9SX2s5YTVBS2lTMnFidFVTNCJdfSwiX3NkIjpbIkNJaDBOYWN4ME5IWUJ5QTFoZ1NlWDdoMXF0amNvUGRIODR1NTN0a2t6R3ciXX0sIl9zZCI6WyI2UFk1X1dKU1pUaWszdG9rOHg0eEF0TWstOGpqWnpzZnV6dXhUX2JvY0wwIiwiVE9XWGhJS1dPeHBZbHgtUmtoal9kVTh3Sml2cmRuOUNrbm9fcXVvNng4YyJdfQ
FzX3Ke7i888rlwj2XY-Xmd73hKH4oGaIp68z2xqPS1Bv17BKSaKQwfxgf22iNAguzVvlIQVXjRqpg0G-S46xDA
WyI5MGlaMEp1a2lCUlpoa0pnajhyRDN3IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
WyJpbU94UllGWWVSM2VHWGdJOTUxcHVnIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
WyJlemF5RzgwVG1hRVhhSjRwNHlpY2xnIiwgImlkIiwgImh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5Il0
WyJXT1lvak0yb2dad3pXQjJOa3FELWNBIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
WyJuUG1kWEk5YWtEakd4Mk0wRTVhWUtBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Claim:
id
SHA-256 Hash:
TOWXhIKWOxpYlx-Rkhj_dU8wJivrdn9Ckno_quo6x8c
Disclosure(s):
WyI5MGlaMEp1a2lCUlpoa0pnajhyRDN3IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
Contents:
"90iZ0JukiBRZhkJgj8rD3w",
"id",
"http://university.example/credentials/3732"
Claim:
type
SHA-256 Hash:
6PY5_WJSZTik3tok8x4xAtMk-8jjZzsfuzuxT_bocL0
Disclosure(s):
WyJpbU94UllGWWVSM2VHWGdJOTUxcHVnIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
Contents:
"imOxRYFYeR3eGXgI951pug",
"type",
"VerifiableCredential",
"ExampleDegreeCredential"
Claim:
id
SHA-256 Hash:
3ySi9ZE-ujtD4844Zpf8WcLcq0Airj5jlRf-3RAROrk
Disclosure(s):
WyJlemF5RzgwVG1hRVhhSjRwNHlpY2xnIiwgImlkIiwgImh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5Il0
Contents:
"ezayG80TmaEXaJ4p4yiclg",
"id",
"https://university.example/issuers/565049"
Claim:
id
SHA-256 Hash:
CIh0Nacx0NHYByA1hgSeX7h1qtjcoPdH84u53tkkzGw
Disclosure(s):
WyJXT1lvak0yb2dad3pXQjJOa3FELWNBIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
Contents:
"WOYojM2ogZwzWB2NkqD-cA",
"id",
"did:example:ebfeb1f712ebc6f1c276e12ec21"
Claim:
type
SHA-256 Hash:
ftH1KSE5s6fJwW21f6I0eRcmaoR_k9a5AKiS2qbtUS4
Disclosure(s):
WyJuUG1kWEk5YWtEakd4Mk0wRTVhWUtBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Contents:
"nPmdXI9akDjGx2M0E5aYKA",
"type",
"ExampleBachelorDegree"
Names and descriptions also support expressing content in different languages.
To express a string with language and
base direction
information,
one can use an object that contains the
@value
@language
, and
@direction
properties to express the text value, language tag, and base direction,
respectively. See
11.1
Language and Base Direction
for further information.
Note
: @direction is not required for single-language strings
The
@direction
property in the examples below is not required
for the associated single-language strings, as their default directions are the
same as those set by the
@direction
value. We include the
@direction
property here for clarity of demonstration and to make copy+paste+edit deliver
functional results. Implementers are encouraged to read the section on
String Internationalization
in the
JSON-LD 1.1
specification.
Example
: Use of the name and description properties
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": ["VerifiableCredential", "ExampleDegreeCredential"],
"issuer": {
"id": "https://university.example/issuers/565049",
"name": [{
"@value": "Example University",
"@language": "en"
}, {
"@value": "Université Exemple",
"@language": "fr"
}, {
"@value": "جامعة المثال",
"@language": "ar",
"@direction": "rtl"
}],
"description": [{
"@value": "A public university focusing on teaching examples.",
"@language": "en"
}, {
"@value": "Une université publique axée sur l'enseignement d'exemples.",
"@language": "fr"
}, {
"@value": ".جامعة عامة تركز على أمثلة التدريس",
"@language": "ar",
"@direction": "rtl"
}]
},
"validFrom": "2015-05-10T12:30:00Z",
"name": [{
"@value": "Example University Degree",
"@language": "en"
}, {
"@value": "Exemple de Diplôme Universitaire",
"@language": "fr"
}, {
"@value": "مثال الشهادة الجامعية",
"@language": "ar",
"@direction": "rtl"
}],
"description": [{
"@value": "2015 Bachelor of Science and Arts Degree",
"@language": "en"
}, {
"@value": "2015 Licence de Sciences et d'Arts",
"@language": "fr"
}, {
"@value": "2015 بكالوريوس العلوم والآداب",
"@language": "ar",
"@direction": "rtl"
}],
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": [{
"@value": "Bachelor of Science and Arts Degree",
"@language": "en"
}, {
"@value": "Licence de Sciences et d'Arts",
"@language": "fr"
}, {
"@value": "بكالوريوس العلوم والآداب",
"@language": "ar",
"@direction": "rtl"
}]
This specification defines a property for expressing the
issuer
of
verifiable credential
verifiable credential
MUST
have an
issuer
property
issuer
The value of the
issuer
property
MUST
be either a
URL
or an object
containing an
id
property
whose value is a
URL
; in either case, the
issuer selects this
URL
to identify itself in a globally unambiguous way. It
is
RECOMMENDED
that the
URL
be one which, if dereferenced, results in a
controlled identifier document, as defined in the
Controlled Identifiers v1.0
specification,
about the
issuer
that can be used to
verify
the information expressed
in the
credential
Credential
ecdsa
ecdsa-sd
bbs
jose
cose
sd-jwt
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": ["VerifiableCredential", "ExampleDegreeCredential"],
"issuer": "https://university.example/issuers/14"
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:33Z",
"verificationMethod": "did:key:zDnaebSRtPnW6YCpxAhR5JPxJqt9UunCsBPhLEtUokUvp87nQ",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z3sXkg3PHbK2YpbhQajunUvReW3Qn66mPsQQKvn4hwEG1DohgUqvXBF2oKT5Qb8tKSKjewNhsJCCcBoY6Rfye4ipw"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:33Z",
"verificationMethod": "did:key:zDnaerJh8WwyBVVGcZKKkqRKK9iezje8ut6t9bnNChtxcWwNv",
"cryptosuite": "ecdsa-sd-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0AhVhA91jcz-MSzf_Z-fw6VM-YN1ijTr26VBTz9H14dMiv6t5vRaGC1IKHvDtY0ZJup1pnliukZBHEXgM46Bf4EjdyIFgjgCQDMIFZRjI7aJUGGsbDYML33eEwJuub6dIF5agqeB4sTdJYIAhgKXoAudJOwmVRpO2Ab5sNIirjQdArIjp8ygMx2S5ihVhASWfZk4fYqoICvoaokYzsABtmDzpgTe8ZkI2z4MDKt1wcp0T9tBx30mk1V20Qhy2PT15nrPygrxpn8_h2Z1Jo7FhAXNmEd28tsb_VkmqckvjVBet7p8Hhq7d8DziDldJRri8-cygIdcaX0MsitDRMsclHCsO25UKSjCX96dSto_Y3FVhAeYhHIz52Lw3Fd8tO7rdPOjILauPLHFkRnmHbd8ixxKwb62gTqchavN3rv8GtKxQL9o-cLCKFm-mpQDUABuYxMVhA-vKFPcx_bNem4ufrFDr-cyjUa3r-zjLJwp9xss7XZikI3PLiiMGIBnhhGs3zCsQXvSZMX6ScPOpog6Kzl-YSj1hA7xtSv3lNDKhPKKQ-7F4WHhmfwj0F1PN_mj5jDkJcdw19eYTux4wRXgehBXRtvkuMw9iG6UFyurMFeyb-EkmQPIFnL2lzc3Vlcg"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"verificationMethod": "did:key:zUC78GzFRA4TWh2mqRiKro1wwRb5KDaMJ3M1AD3qGtgEbFrwWGvWbnCzArkeTZCyzBz4Panr2hLaZxsXHiBQCwBc3fRPH6xY4u5v8ZAd3dPW1aw89Rra86CVwXr3DczANggYbMD",
"cryptosuite": "bbs-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0ChVhQs4LnYe9N1n9fBW8t7tgXy8gZA1WksN76TfdxHLUW0cJlImiaNZZbbNwAaL86-8xnTgMJgpwaMchm_8VepMSYZKjfQReWnOfwRfwz8grbaNNYQGd_DaMQQsoaryttl5TvxnFT-Vm4SkVx03K9qNJ4jhArKnv3N5iX7nvZR0OCXS-uXH4QQ9mW65QM5qlHOfE4GQVYYJVTGbTfcflzyx41E-f9kSqmf10xYzxJrGfC7b7GPY8X7VjMT__ZKSuwdH-5jak-5gkjocsHI6oxIKlLrhW1Wh5yrDCH-QC823TS8NE9VGBzIFAfUt5qazGEcJ8CxeSPxFggO3rpYlZcra0jsUsWXIoCAXrkmj3mb1o1k8CYE2Wx9d6BZy9pc3N1ZXI"
Protected Headers
"kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
"alg": "ES256"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+jwt
eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy8xNCIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ
lTz4nWXqYIiQ0bm_t26FD3GHibp2HVinvyPI6wezRaPURX2KaGSas2v4yaRFhpEyni3hLFc_L2ZhWJXcDWnyUQ
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+cose
d28443a10128a05901ba7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f3134222c2276616c696446726f6d223a22323031302d30312d30315431393a32333a32345a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d58405ecf7be0f23f3ed8bf173e4895c70f7dad9fb36628730d78a37aa499cbf1ef8263a4def9303e5de3783c7ae69884fcdafc924ee676ec232d8f51488fee4cdbc5
Encoded
Decoded
Issuer Disclosures
eyJpYXQiOjE3NDU3NzY3MTMsImV4cCI6MTc0Njk4NjMxMywiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy8xNCIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiZGVncmVlIjp7Im5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIiwiX3NkIjpbImN4X0JsU2pRSVp6bjN5aFRhc0pEeGhLZVlrcndLc25fLXc1RGFKVVdNYmMiXX0sIl9zZCI6WyJOcm96NFFQRHFTOGZkdVI0bDFQaFZwS3l6aFJzN2xha3VlQUZDMmhNa2hzIl19LCJfc2QiOlsiSk84RmdIYmVuLVdlOHJvUDBiM09uV1hrVHZSMlYzOXRTSllzdmpiTy12cyIsImhvckxSUTVqbHpNcFktWDdKMXA1Wmh4UXNNNmMyaHhoZXNjUnF0RnRQSDgiXX0
DVnk8KsBnPp-Z9vnpReTasbST4ENcNjOwn9qxCgDx7H33VsJaFi0DyCa2auVKb1oSL0IilelgxsEVs27fMClSA
WyJoSEtXaHpnQ1k0VUJ0Z1F1V2ZWQjNBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
WyJUeHZFNURzNU5OT190S0VnMUsyZnlBIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
WyJlUkpwYkw3WHZ2SVVwVnVGLWlLUWNnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
WyJwb2o5UDctRG5MYzF3VVBSbHpkXy1nIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Claim:
id
SHA-256 Hash:
JO8FgHben-We8roP0b3OnWXkTvR2V39tSJYsvjbO-vs
Disclosure(s):
WyJoSEtXaHpnQ1k0VUJ0Z1F1V2ZWQjNBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
Contents:
"hHKWhzgCY4UBtgQuWfVB3A",
"id",
"http://university.example/credentials/3732"
Claim:
type
SHA-256 Hash:
horLRQ5jlzMpY-X7J1p5ZhxQsM6c2hxhescRqtFtPH8
Disclosure(s):
WyJUeHZFNURzNU5OT190S0VnMUsyZnlBIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
Contents:
"TxvE5Ds5NNO_tKEg1K2fyA",
"type",
"VerifiableCredential",
"ExampleDegreeCredential"
Claim:
id
SHA-256 Hash:
Nroz4QPDqS8fduR4l1PhVpKyzhRs7lakueAFC2hMkhs
Disclosure(s):
WyJlUkpwYkw3WHZ2SVVwVnVGLWlLUWNnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
Contents:
"eRJpbL7XvvIUpVuF-iKQcg",
"id",
"did:example:ebfeb1f712ebc6f1c276e12ec21"
Claim:
type
SHA-256 Hash:
cx_BlSjQIZzn3yhTasJDxhKeYkrwKsn_-w5DaJUWMbc
Disclosure(s):
WyJwb2o5UDctRG5MYzF3VVBSbHpkXy1nIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Contents:
"poj9P7-DnLc1wUPRlzd_-g",
"type",
"ExampleBachelorDegree"
It is also possible to express additional information about the issuer by
associating an object with the issuer property:
Example
: Expanded use of the issuer property
Credential
ecdsa
ecdsa-sd
bbs
jose
cose
sd-jwt
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": ["VerifiableCredential", "ExampleDegreeCredential"],
"issuer": {
"id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
"name": "Example University"
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": {
"id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
"name": "Example University"
},
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:33Z",
"verificationMethod": "did:key:zDnaebSRtPnW6YCpxAhR5JPxJqt9UunCsBPhLEtUokUvp87nQ",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z35CwmxThsUQ4t79JfacmMcw4y1kCqtD4rKqUooKM2NyKwdF5jmXMRo9oGnzHerf8hfQiWkEReycSXC2NtRrdMZN4"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": {
"id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
"name": "Example University"
},
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:33Z",
"verificationMethod": "did:key:zDnaerJh8WwyBVVGcZKKkqRKK9iezje8ut6t9bnNChtxcWwNv",
"cryptosuite": "ecdsa-sd-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0AhVhA48RQ19Db04U8uJwipJ51iqZLecmjhiPb4k2BXLdHox9KdauSf3Mt6Zhit65HQD3NfKoUBNIhx6u6SkQ_LRN_dlgjgCQCXiUMNh-iT7uOyLhwa_0Ol1mfx4Fhph-wJC4AzOYD8ElYIMaU9eu-pg75GhG_-_CuhoikWj9gtS-qUp4qfdnYI6XAhVhAVag3KzxQuRrStNecEjh3TVoc3hj38x-dqllLiAdbQc_9tlnMJaYIm0HzLXuvqwc7DlSTC7w5D0NX6D2M8NaNqVhAr6tGfnfX0hTJ3a-okEoAyiGTla9x_irE24vYRdi6vlLc-xz5LGVFA5Tyht7GiZaT4kqC3od7Nx57CiHakPBw4VhAGzegEDf5moH7kOGp68C6QQR3TmmVMsFSpU41XLR3-BLBLfuS1gWDQlyAJJDRh_leTFoqkDaxdkcli3NpowghY1hA4WGxUt2yMzqAreubYrAzNKMEQcQts-C0O4y3ErKH9R9UZMnBPY2FslOyagtRB5xE5keh3GGCa9TGNCypiNXVXFhAm-bNAdG37FTLQWR1bVnzRMPaTRr5iWWDMtGoFg78B0v43fkN0r4pPVOj9YcCEFxjS_eCbh9HSnDfHsMRIjnG-oFnL2lzc3Vlcg"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": {
"id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
"name": "Example University"
},
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"verificationMethod": "did:key:zUC78GzFRA4TWh2mqRiKro1wwRb5KDaMJ3M1AD3qGtgEbFrwWGvWbnCzArkeTZCyzBz4Panr2hLaZxsXHiBQCwBc3fRPH6xY4u5v8ZAd3dPW1aw89Rra86CVwXr3DczANggYbMD",
"cryptosuite": "bbs-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0ChVhQswmfQ8aSdnXIildKfGdJUPQ-iT1HwBf8bShxHigrMTIGPA_mbb58NHo_tUU7P6a5AlwACoQDdbgQXIoeIZPmKu7snk3tUbaLIpfacByowWNYQGd_DaMQQsoaryttl5TvxnFT-Vm4SkVx03K9qNJ4jhArQAGpGXTZS6rwOppAPreXlDb3xQb46PJ_xcVri0glVYJYYJVTGbTfcflzyx41E-f9kSqmf10xYzxJrGfC7b7GPY8X7VjMT__ZKSuwdH-5jak-5gkjocsHI6oxIKlLrhW1Wh5yrDCH-QC823TS8NE9VGBzIFAfUt5qazGEcJ8CxeSPxFggxWA747M_eHOtg3OYnWQ7wgc8QZ4KHhjtZYNM8ac6ldiBZy9pc3N1ZXI"
Protected Headers
"kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
"alg": "ES256"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": {
"id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
"name": "Example University"
},
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+jwt
eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiZGlkOmV4YW1wbGU6NzZlMTJlYzcxMmViYzZmMWMyMjFlYmZlYjFmIiwibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSJ9LCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGUiOiJFeGFtcGxlQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX0
iiZQBWDlb2o6AxplaJib4C_XeoftdnSFyrT7X1WBfekQDm1_Vu3JUp1fpQWz4RI7HREkI-4mawO6YUkSG9isHQ
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": {
"id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
"name": "Example University"
},
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+cose
d28443a10128a05901df7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a7b226964223a226469643a6578616d706c653a373665313265633731326562633666316332323165626665623166222c226e616d65223a224578616d706c6520556e6976657273697479227d2c2276616c696446726f6d223a22323031302d30312d30315431393a32333a32345a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d584080831b3012ddc56c1a9d0d8366bb309b8551e8996fdb77ffc08387ef3feba387d0472fdf2805a00aca9ab9dd28958fde6893a024874ff9151f8dacca5595bbed
Encoded
Decoded
Issuer Disclosures
eyJpYXQiOjE3NDU3NzY3MTQsImV4cCI6MTc0Njk4NjMxNCwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjp7Im5hbWUiOiJFeGFtcGxlIFVuaXZlcnNpdHkiLCJfc2QiOlsiYTQ0Y2M5VHU1eGd1N3hCTHlMaTdwVUoxTHFpdHlPVDZqMWxMNF9xZW04SSJdfSwidmFsaWRGcm9tIjoiMjAxMC0wMS0wMVQxOToyMzoyNFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiRHViUDR4bXg4dk5FNFBuYUUzYjlzRGpKWUhIaHpETVFxUVdnUlg2d2ZzWSJdfSwiX3NkIjpbIkJaa0tyVXpjbFhWcHZEUzRFWUh1YkZZa0w3am9lTXlJUFluVlhoS3dBaDQiXX0sIl9zZCI6WyJDT3F6UUNsT2ZTNzc2dXBmaENuVmRyYjdsWWhHY0lBZlRCWDVWeTB3V1E4IiwiS0t0QnoydUxOZzVrd1ZyNHkzWGhHWkhXRXI3aTc3WGFHOVhHbldPV0ZCbyJdfQ
-JMxTewqTy__6Dh_WAXAS6_TqnXHV66JpBSzVZ61NCP6DdYAAIwgGCo5gbF6HyAerxUjSmCfe9vmUTIgtZ_U3g
WyJvX1lOb0F1S0pqNTNFWlg0S1ZzVmV3IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
WyJBVUVzVi1LTnh4eU1WWnBuZWxXT0p3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
WyIwMkdFZW1rVjhzR3hzOWY4b21PbUxBIiwgImlkIiwgImRpZDpleGFtcGxlOjc2ZTEyZWM3MTJlYmM2ZjFjMjIxZWJmZWIxZiJd
WyJPNnpIek5ERjF2ZVFleVpEb1JBR1VRIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
WyIzdm1kU29mcW5MVkprRVozVUZnLWNnIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Claim:
id
SHA-256 Hash:
KKtBz2uLNg5kwVr4y3XhGZHWEr7i77XaG9XGnWOWFBo
Disclosure(s):
WyJvX1lOb0F1S0pqNTNFWlg0S1ZzVmV3IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
Contents:
"o_YNoAuKJj53EZX4KVsVew",
"id",
"http://university.example/credentials/3732"
Claim:
type
SHA-256 Hash:
COqzQClOfS776upfhCnVdrb7lYhGcIAfTBX5Vy0wWQ8
Disclosure(s):
WyJBVUVzVi1LTnh4eU1WWnBuZWxXT0p3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
Contents:
"AUEsV-KNxxyMVZpnelWOJw",
"type",
"VerifiableCredential",
"ExampleDegreeCredential"
Claim:
id
SHA-256 Hash:
a44cc9Tu5xgu7xBLyLi7pUJ1LqityOT6j1lL4_qem8I
Disclosure(s):
WyIwMkdFZW1rVjhzR3hzOWY4b21PbUxBIiwgImlkIiwgImRpZDpleGFtcGxlOjc2ZTEyZWM3MTJlYmM2ZjFjMjIxZWJmZWIxZiJd
Contents:
"02GEemkV8sGxs9f8omOmLA",
"id",
"did:example:76e12ec712ebc6f1c221ebfeb1f"
Claim:
id
SHA-256 Hash:
BZkKrUzclXVpvDS4EYHubFYkL7joeMyIPYnVXhKwAh4
Disclosure(s):
WyJPNnpIek5ERjF2ZVFleVpEb1JBR1VRIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
Contents:
"O6zHzNDF1veQeyZDoRAGUQ",
"id",
"did:example:ebfeb1f712ebc6f1c276e12ec21"
Claim:
type
SHA-256 Hash:
DubP4xmx8vNE4PnaE3b9sDjJYHHhzDMQqQWgRX6wfsY
Disclosure(s):
WyIzdm1kU29mcW5MVkprRVozVUZnLWNnIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Contents:
"3vmdSofqnLVJkEZ3UFg-cg",
"type",
"ExampleBachelorDegree"
Note
: The identifier for an issuer can be any URL
The value of the
issuer
property
can also be a JWK (for
example,
"https://jwk.example/keys/foo.jwk"
) or a
DID
(for
example,
"did:example:abfe13f712120431c276e12ecab"
).
verifiable credential
contains
claims
about one or more
subjects
This specification defines a
credentialSubject
property
for the expression
of
claims
about one or more
subjects
verifiable credential
MUST
contain a
credentialSubject
property
credentialSubject
The value of the
credentialSubject
property
is a set of objects where each
object
MUST
be the
subject
of one or more
claims
, which
MUST
be
serialized inside the
credentialSubject
property
. Each object
MAY
also
contain an
id
property
to identify the
subject
, as described in
Section
4.4
Identifiers
Example
: Use of the credentialSubject property
Credential
ecdsa
ecdsa-sd
bbs
jose
cose
sd-jwt
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": ["VerifiableCredential", "ExampleDegreeCredential"],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject"
: {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:34Z",
"verificationMethod": "did:key:zDnaebSRtPnW6YCpxAhR5JPxJqt9UunCsBPhLEtUokUvp87nQ",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z36CTYymphefPFDdFakYBe7EHHX7Upev5vtRhxG3ZtKiUPXFKknW9ZTds3wxDhTz1WFCGzFUUv6DC5vifg3VCCSFL"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:34Z",
"verificationMethod": "did:key:zDnaerJh8WwyBVVGcZKKkqRKK9iezje8ut6t9bnNChtxcWwNv",
"cryptosuite": "ecdsa-sd-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0AhVhAFPsovbuHDInv8ft0M6jMPGrLrNs9j_sEfn1gdDCxFOmyjYDyblufuagmARZj9RabxfO0SkbpUi_m6dQdXIyoklgjgCQC78Ayc-2ykLAZ_NJzb5-S8dtSenHeKEHHGy469czIbhtYILJ97_OhxkzZccWMaUgCAXRO5ZCyoagriazYdV2ViFsuhVhAvGcG2tqQoB5VaC-x652sos00_94wzBOZg9wGR2mytwn_alXEbksbCMUC2lmiU_FrcFzEEAZrAdcsAfoE0J_KRlhAc71QXbdP2iKlqmgocH4qvDcv_3PT_VmSFGWISFdrQPkmv2lb2r9Mb02yZYilf20oMzCPCRsqYP--0g8ysm9doVhAIqwWkfg1pXXKaxx4_5_QpmoOoXjLPNhJ-14QSHUyxTKKCTarm33OdaIhhCjm5_e7MUCYHvA89vCSvSHMrKvKclhASFp1GivaJXYrbBcM6xNFNsXW7xBg7cZXfBeGOwcXf7fXg1GwMJILZBimOaEM5Eay38F8T6HwbeuMvBQ7b05gbFhAkLeI8-tdeQQzX6ik0xDSM4yLsHPmhG47Tu5Hm25ujoo9iVsLzskiGcIsQLsqvRK5238FvPQAeOpK04R7F2aK9IFnL2lzc3Vlcg"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"verificationMethod": "did:key:zUC78GzFRA4TWh2mqRiKro1wwRb5KDaMJ3M1AD3qGtgEbFrwWGvWbnCzArkeTZCyzBz4Panr2hLaZxsXHiBQCwBc3fRPH6xY4u5v8ZAd3dPW1aw89Rra86CVwXr3DczANggYbMD",
"cryptosuite": "bbs-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0ChVhQkkdBby2GbmvVh66cM6TNzNfh0hR9ePeG7dWYbHfDxK6CcA_rVoxxsRGIoWX5Gs6ZGgQNPTBeehiEHT_cj-5fjZ6ArTluARHPbaXQzWyXKrVYQGd_DaMQQsoaryttl5TvxnFT-Vm4SkVx03K9qNJ4jhArS1r7HKFDPyyrvPGqNF8bjgNELvoomOjpbD9JEvaGI1pYYJVTGbTfcflzyx41E-f9kSqmf10xYzxJrGfC7b7GPY8X7VjMT__ZKSuwdH-5jak-5gkjocsHI6oxIKlLrhW1Wh5yrDCH-QC823TS8NE9VGBzIFAfUt5qazGEcJ8CxeSPxFggUfIz7Xi8QhNU6pC7qIkL0HkvpKYuV2rzBuKizKrBhU6BZy9pc3N1ZXI"
Protected Headers
"kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
"alg": "ES256"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+jwt
eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGUiOiJFeGFtcGxlQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX0
KJnv5DRpXi0xZ6SUSXsu30Xs5OBk8HlunnpkAitIS677TBPhwX1cgbUj9nTuLfNeLlRZnsCyua_yZZ5SooTKSw
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+cose
d28443a10128a05901be7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f353635303439222c2276616c696446726f6d223a22323031302d30312d30315430303a30303a30305a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d5840b1ddb83d2cc91513a6a44ae62b8c622918c9b78d1c6492afcec241b39a23cbd6f1c6efbdeeaa94e0c765b7c8b9284e2c930ae859aa0a2defc8b4d9fba132d23d
Encoded
Decoded
Issuer Disclosures
eyJpYXQiOjE3NDU3NzY3MTQsImV4cCI6MTc0Njk4NjMxNCwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImRlZ3JlZSI6eyJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyIsIl9zZCI6WyJlU3NEMXVhcVNuZUdIVEVjTWxlM1ZzWlJwOHRNbmo1Q0dyN1EzandzdkZrIl19LCJfc2QiOlsiYU5MMTNnNnUtenN2VG1YVkFfOVRYdXlrSVdpRzd0djVvbExzdHNieDlkayJdfSwiX3NkIjpbIkRsMHp6eHZJcXA1TVdBNWEzSTJQRDFNQXJ3NlZBNFFMeWRscVNsSkVCeVkiLCJqVmtSaTdLMGUySTFkbFJURXREdlFVTEIxcWZaZ3NNcGlCdjVQYWsyMXlzIl19
Yh2d9J3y-SKxa16vZzRVQKaya0V66OPIar-C9PGVzOu2Q7_0IbsYqTJxtNYsQ39fk64p1-QEgCmWPWHFRAD_qw
WyIxTGVERC1tNlRQdlFXX1R4MU9MQVVnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
WyJiU1ljSjZNVXdGZlhleWRGSl84dHlnIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
WyJpUGx3eUs1c01BY1BzbzZQbW1DNWl3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
WyJFaEt5VDV6ZjJuSGZUNHFnaWZtczVBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Claim:
id
SHA-256 Hash:
Dl0zzxvIqp5MWA5a3I2PD1MArw6VA4QLydlqSlJEByY
Disclosure(s):
WyIxTGVERC1tNlRQdlFXX1R4MU9MQVVnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
Contents:
"1LeDD-m6TPvQW_Tx1OLAUg",
"id",
"http://university.example/credentials/3732"
Claim:
type
SHA-256 Hash:
jVkRi7K0e2I1dlRTEtDvQULB1qfZgsMpiBv5Pak21ys
Disclosure(s):
WyJiU1ljSjZNVXdGZlhleWRGSl84dHlnIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
Contents:
"bSYcJ6MUwFfXeydFJ_8tyg",
"type",
"VerifiableCredential",
"ExampleDegreeCredential"
Claim:
id
SHA-256 Hash:
aNL13g6u-zsvTmXVA_9TXuykIWiG7tv5olLstsbx9dk
Disclosure(s):
WyJpUGx3eUs1c01BY1BzbzZQbW1DNWl3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
Contents:
"iPlwyK5sMAcPso6PmmC5iw",
"id",
"did:example:ebfeb1f712ebc6f1c276e12ec21"
Claim:
type
SHA-256 Hash:
eSsD1uaqSneGHTEcMle3VsZRp8tMnj5CGr7Q3jwsvFk
Disclosure(s):
WyJFaEt5VDV6ZjJuSGZUNHFnaWZtczVBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Contents:
"EhKyT5zf2nHfT4qgifms5A",
"type",
"ExampleBachelorDegree"
Expressing information related to multiple
subjects
in a
verifiable credential
is possible. The example below specifies two
subjects
who are spouses. Note the use of array notation to associate
multiple
subjects
with the
credentialSubject
property.
Example
10
: Specifying multiple subjects in a verifiable credential
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": ["VerifiableCredential", "RelationshipCredential"],
"issuer": "https://issuer.example/issuer/123",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject":
[{
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"name": "Jayden Doe",
"spouse": "did:example:c276e12ec21ebfeb1f712ebc6f1"
}, {
"id": "https://subject.example/subject/8675",
"name": "Morgan Doe",
"spouse": "https://subject.example/subject/7421"
}]
This specification defines the
validFrom
property
to help an
issuer to express the date and time when a
credential
becomes valid and
the
validUntil
property
to express the date and time
when a
credential
ceases to be valid.
When comparing dates and times, the calculation is done "temporally",
meaning that the string value is converted to a "temporal value" which exists
as a point on a timeline. Temporal comparisons are then performed by checking
to see where the date and time being compared are in relation to
a particular point on the timeline.
validFrom
If present, the value of the
validFrom
property
MUST
be a
XMLSCHEMA11-2
dateTimeStamp
string value representing the date and time the
credential
becomes valid, which could be a date and time in the future or
the past. Note that this value represents the earliest point in time at which
the information associated with the
credentialSubject
property
becomes valid. If a
validUntil
value also exists, the
validFrom
value
MUST
express a point in time that is temporally the same or
earlier than the point in time expressed by the
validUntil
value.
validUntil
If present, the value of the
validUntil
property
MUST
be a
XMLSCHEMA11-2
dateTimeStamp
string value representing the date and time the
credential
ceases to be valid, which could be a date and time in the past
or the future. Note that this value represents the latest point in time at
which the information associated with the
credentialSubject
property
is valid. If a
validFrom
value also exists, the
validUntil
value
MUST
express a point in time that is temporally the same or later than the
point in time expressed by the
validFrom
value.
Example
11
: Use of the validFrom and validUntil properties
Credential
ecdsa
ecdsa-sd
bbs
jose
cose
sd-jwt
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": ["VerifiableCredential", "ExampleDegreeCredential"],
"issuer": "https://university.example/issuers/14",
"validFrom": "2010-01-01T19:23:24Z"
"validUntil": "2020-01-01T19:23:24Z"
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"validUntil": "2020-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:34Z",
"verificationMethod": "did:key:zDnaebSRtPnW6YCpxAhR5JPxJqt9UunCsBPhLEtUokUvp87nQ",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z65sN9W58eruTDUUXYxxwhG4cQ73zQkQuhMYvUVipeM4oEUBPbCxd3oTQTJhnfHN9juyZSzYpERYFjZcfpb2xgeto"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"validUntil": "2020-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:34Z",
"verificationMethod": "did:key:zDnaerJh8WwyBVVGcZKKkqRKK9iezje8ut6t9bnNChtxcWwNv",
"cryptosuite": "ecdsa-sd-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0AhVhAxWvPP0HD9usaRDFthqpz1zXbWtTpNr_1pRFMKY9wbt7RAh0kwkoqR9cFHY0PdBj0cPo9BXd_54Z9iLl7GsmAjlgjgCQCJ0FUx3YRbBxybCrTEtFINFNKD7UC2j8tjmvYa6EQKlNYIL-KVtIrAWQi98Ng86FB4giy2xKCqn_kNOmO75D7AQfEhlhA5pKNMOahYQbk8obEMFyLgAsmd3FGqf3FoDTojybRWUPf7F3A22Kl1822zW093-XtKum7Nfe3q16norHXUnhkWVhAvNR9By8I5ISJtylSp1fkzurbIvSXVhkaj4wsUpbTy1GnYHzeS7qhAyUoO4GkIMUfP3yLS0BIGBbJR7de1s5G4lhATnwFdztYAEXk6z93jJot3TPhlnOYk10G0e7u3uyJJF-ZrAsctOYbjF3ZcNZu3UXJZRe4_ytxr5OqwIVLnUfDqFhAkff2_b4hqpz0uK0kDHjkpMun4mAhuxVCjcmyIlJnaaTdFc2RovLnKiPx4Xnd9P_lOd3ZQoz5ThPWzMS7r_43M1hAmVVtNJ7-lpJdlc9tg5e3GpAhnXzYHpiv3WRRT3F4tH8B_zkHnyeNBT61d16TTnvlFn5mFXJ99FD4abIcQkyP_lhA8IS9pAGKqVgTDzxXSvGcGWMXQ4LEy3jfywyDpdiZodvttNhuZVBMkGKhNBo94oGjIHRfoeAFvQfZQo8_ENtBEYFnL2lzc3Vlcg"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"validUntil": "2020-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"verificationMethod": "did:key:zUC78GzFRA4TWh2mqRiKro1wwRb5KDaMJ3M1AD3qGtgEbFrwWGvWbnCzArkeTZCyzBz4Panr2hLaZxsXHiBQCwBc3fRPH6xY4u5v8ZAd3dPW1aw89Rra86CVwXr3DczANggYbMD",
"cryptosuite": "bbs-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0ChVhQjBPG4AXIRGKu6h5awRiAZHSrx5gfUdbWc2rAxdsfIzSIywzsphRnlb5rPDWwdJlBF5krx4JRYNtT7exHHAw_aZtO6AARXGfbz0eHNrcTKL5YQGd_DaMQQsoaryttl5TvxnFT-Vm4SkVx03K9qNJ4jhArKnv3N5iX7nvZR0OCXS-uXH4QQ9mW65QM5qlHOfE4GQVYYJVTGbTfcflzyx41E-f9kSqmf10xYzxJrGfC7b7GPY8X7VjMT__ZKSuwdH-5jak-5gkjocsHI6oxIKlLrhW1Wh5yrDCH-QC823TS8NE9VGBzIFAfUt5qazGEcJ8CxeSPxFggWjulaLj5whA4VZOvBqHQbwhSW7Ph0eZ2bxz7ota_qnCBZy9pc3N1ZXI"
Protected Headers
"kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
"alg": "ES256"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"validUntil": "2020-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+jwt
eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy8xNCIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwidmFsaWRVbnRpbCI6IjIwMjAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ
UGJHic3E0XIwnJnzsQPF49ZMJsJtVhQSYTk7m8uvpbQWQPIttHiQo8k2qVhNZiRtMDLuIYAdTjim8rhGZbCJ2A
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"validUntil": "2020-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+cose
d28443a10128a05901de7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f3134222c2276616c696446726f6d223a22323031302d30312d30315431393a32333a32345a222c2276616c6964556e74696c223a22323032302d30312d30315431393a32333a32345a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d584076a5f6a774019f85df7b204233f02dcd34fcaa896191e0c41cc6e78f2c4c7d9456daf472970ee8bd3993474bc31f975df3278e844ed6707486b77e928fbd7231
Encoded
Decoded
Issuer Disclosures
eyJpYXQiOjE3NDU3NzY3MTQsImV4cCI6MTc0Njk4NjMxNCwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy8xNCIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwidmFsaWRVbnRpbCI6IjIwMjAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiZGVncmVlIjp7Im5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIiwiX3NkIjpbInRreDZVVzN3VF9OcVRpeHZWR2tzd2RaRi1rQkE0TmhBV1pHSmxhUURpREkiXX0sIl9zZCI6WyJmTmpEU0RIbDNIQkNTQ1hSRzh0OWJud1RIMUpTT0JQOE0wWmFaQlpQTmNJIl19LCJfc2QiOlsiUHhTdmNMelpvam1Lck5qMWVKWDNxVjZKcVoxdFBVV1dYMFo5Q2dLRTlEVSIsInRTSThIellYN2RYdHhpMVc3UHUxckg4S3ZFNUxBRkNEVVNxcHpsbmdzRDgiXX0
4gc3oF3a-OHOSwVC1eiCZP-ureWU-bdPdjBlL-xBjUsE5qL2sBQbg5PP_CO6JgZiBONpr3iU6cL0MF9iPpu9Eg
WyJ3SzVZQTBEZzRoc18wdmtFZk1ENG93IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
WyJ1T0podHZvMEJ0cm1YbWxIeUVKUTdRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
WyJjTzBQZjZxM1MweHp2dmRwS25aWlpnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
WyI0N0FDOWhlLTRCNW4xV1N0dFJRYXRBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Claim:
id
SHA-256 Hash:
PxSvcLzZojmKrNj1eJX3qV6JqZ1tPUWWX0Z9CgKE9DU
Disclosure(s):
WyJ3SzVZQTBEZzRoc18wdmtFZk1ENG93IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd
Contents:
"wK5YA0Dg4hs_0vkEfMD4ow",
"id",
"http://university.example/credentials/3732"
Claim:
type
SHA-256 Hash:
tSI8HzYX7dXtxi1W7Pu1rH8KvE5LAFCDUSqpzlngsD8
Disclosure(s):
WyJ1T0podHZvMEJ0cm1YbWxIeUVKUTdRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
Contents:
"uOJhtvo0BtrmXmlHyEJQ7Q",
"type",
"VerifiableCredential",
"ExampleDegreeCredential"
Claim:
id
SHA-256 Hash:
fNjDSDHl3HBCSCXRG8t9bnwTH1JSOBP8M0ZaZBZPNcI
Disclosure(s):
WyJjTzBQZjZxM1MweHp2dmRwS25aWlpnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd
Contents:
"cO0Pf6q3S0xzvvdpKnZZZg",
"id",
"did:example:ebfeb1f712ebc6f1c276e12ec21"
Claim:
type
SHA-256 Hash:
tkx6UW3wT_NqTixvVGkswdZF-kBA4NhAWZGJlaQDiDI
Disclosure(s):
WyI0N0FDOWhlLTRCNW4xV1N0dFJRYXRBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Contents:
"47AC9he-4B5n1WSttRQatA",
"type",
"ExampleBachelorDegree"
Note
: Validity start period for Verifiable Credentials
If
validFrom
and
validUntil
are not present, the
verifiable credential
validity period is considered valid
indefinitely. In such cases, the
verifiable credential
is assumed to be
valid from the time the
verifiable credential
was created.
This specification defines the
credentialStatus
property
for
discovering information related to the status of a
verifiable credential
, such as whether it is suspended or revoked.
If present, the value associated with the
credentialStatus
property
is a
single object or a set of one or more objects. The following
properties
are defined for every object:
id
The
id
property
is
OPTIONAL
. It
MAY
be used to provide a
unique identifier for the credential status object. If present, the
normative guidance in Section
4.4
Identifiers
MUST
be followed.
type
The
type
property
is
REQUIRED
. It is used to express the
type of status information expressed by the object. The related normative
guidance in Section
4.5
Types
MUST
be followed.
The precise content of the
credential
status information is determined by
the specific
credentialStatus
type
definition and varies
depending on factors such as whether it is simple to implement or if it is
privacy-enhancing. The value will provide enough information to determine the
current status of the
credential
and whether machine-readable information will
be retrievable from the URL. For example, the object could contain a link to an
external document that notes whether the
credential
is suspended or revoked.
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": ["VerifiableCredential", "ExampleDegreeCredential"],
"issuer": "https://university.example/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"credentialStatus": {
"id": "https://university.example/credentials/status/3#94567",
"type": "BitstringStatusListEntry",
"statusPurpose": "revocation",
"statusListIndex": "94567",
"statusListCredential": "https://university.example/credentials/status/3"
credential
can have more than one status associated
with it, such as whether it has been revoked or suspended.
Example
13
: Use of multiple entries for the status property
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://license.example/credentials/9837",
"type": ["VerifiableCredential", "ExampleDrivingLicenseCredential"],
"issuer": "https://license.example/issuers/48",
"validFrom": "2020-03-14T12:10:42Z",
"credentialSubject": {
"id": "did:example:f1c276e12ec21ebfeb1f712ebc6",
"license": {
"type": "ExampleDrivingLicense",
"name": "License to Drive a Car"
},
"credentialStatus": [{
"id": "https://license.example/credentials/status/84#14278",
"type": "BitstringStatusListEntry",
"statusPurpose": "revocation",
"statusListIndex": "14278",
"statusListCredential": "https://license.example/credentials/status/84"
}, {
"id": "https://license.example/credentials/status/84#82938",
"type": "BitstringStatusListEntry",
"statusPurpose": "suspension",
"statusListIndex": "82938",
"statusListCredential": "https://license.example/credentials/status/84"
}]
Implementers are cautioned that
credentials
with multiple status entries
might contain conflicting information. Reconciling such conflicts is a part of
the
validation
process, hence part of the verifier's business logic, and
therefore out of scope for this specification.
Defining the data model, formats, and protocols for status schemes is out of the
scope of this specification. The
Verifiable Credential Extensions
document contains
available status schemes for implementers who want to implement
verifiable credential
status checking.
Credential status specifications
MUST NOT
enable tracking of individuals, such
as an
issuer
being notified (either directly or indirectly) when a
verifier
is interested in a specific
holder
or
subject
. Unacceptable
approaches include "phoning home," such that every use of a credential contacts
the
issuer
of the credential to check the status for a specific individual,
or "pseudonymity reduction," such that every use of the credential causes a
request for information from the
issuer
that the
issuer
can use
to deduce
verifier
interest in a specific individual.
Data schemas are useful when enforcing a specific structure on a given
data collection. There are at least two types of data schemas that this
specification considers:
Data verification schemas, which are used to establish that the structure
and contents of a
credential
or
verifiable credential
conform to a
published schema.
Data encoding schemas, which are used to map the contents of a
verifiable credential
to an alternative representation format, such as a
format used in a zero-knowledge proof.
It is important to understand that data schemas serve a different purpose from
the
@context
property, which neither enforces data structure or
data syntax nor enables the definition of arbitrary encodings to alternate
representation formats.
This specification defines the following
property
for expressing a
data schema, which an
issuer
can include in the
verifiable credentials
that it issues:
credentialSchema
The value of the
credentialSchema
property
MUST
be one or
more data schemas that provide
verifiers
with enough information to
determine whether the provided data conforms to the provided schema(s). Each
credentialSchema
MUST
specify its
type
(for example,
JsonSchema
) and an
id
property
that
MUST
be a
URL
identifying the schema file. The specific type
definition determines the precise contents of each data schema.
If multiple schemas are present, validity is determined according to the
processing rules outlined by each associated
type
property.
Note
: Credential type-specific syntax checking is possible
The
credentialSchema
property
allows one to
annotate type definitions or lock them to specific versions of the vocabulary.
Authors of
verifiable credentials
can include a static version of their
vocabulary using
credentialSchema
that is secured by some content
integrity protection mechanism. The
credentialSchema
property
also makes it possible to perform syntactic checking on the
credential
and to use
verification
mechanisms such as JSON Schema
VC-JSON-SCHEMA
] validation.
Example
14
: Using the credentialSchema property to perform JSON schema validation
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": ["VerifiableCredential", "ExampleDegreeCredential", "ExamplePersonCredential"],
"issuer": "https://university.example/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"alumniOf": {
"name": "Example University"
},
"credentialSchema": [{
"id": "https://example.org/examples/degree.json",
"type": "JsonSchema"
},
"id": "https://example.org/examples/alumni.json",
"type": "JsonSchema"
}]
In the example above, the
issuer
is specifying two
credentialSchema
objects, each of which point to a JSON Schema [
VC-JSON-SCHEMA
] file that a
verifier
can use to determine whether the
verifiable credential
is
well-formed.
This specification recognizes two classes of
securing mechanisms
those that use enveloping proofs and those that use embedded proofs.
An
enveloping proof
wraps a serialization
of this data model. One such
RECOMMENDED
enveloping proof mechanism is defined
in
Securing Verifiable Credentials using JOSE and COSE
VC-JOSE-COSE
].
An
embedded proof
is a mechanism where the proof is
included in the serialization of the data model. One such
RECOMMENDED
embedded
proof mechanism is defined in
Verifiable Credential Data Integrity 1.0
VC-DATA-INTEGRITY
].
These two classes of securing mechanisms are not mutually exclusive. Additional
securing mechanism specifications might also be defined according to the rules
in Section
5.13
Securing Mechanism Specifications
Example
15
: A verifiable credential using an embedded proof
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://example.gov/credentials/3732",
"type": ["VerifiableCredential", "ExampleDegreeCredential"],
"issuer": "did:example:6fb1f712ebe12c27cc26eebfe11",
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "https://subject.example/subject/3921",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"cryptosuite": "eddsa-rdfc-2022",
"created": "2021-11-13T18:19:39Z",
"verificationMethod": "https://university.example/issuers/14#key-1",
"proofPurpose": "assertionMethod",
"proofValue": "z58DAdFfa9SkqZMVPxAQp...jQCrfFPP2oumHKtz"
The
embedded proof
above secures the original
credential
by decorating
the original data with a digital signature via the
proof
property. This
results in a
verifiable credential
that is easy to manage in modern
programming environments and database systems.
Example
16
: A verifiable credential that uses an enveloping proof in SD-JWT format
eyJhbGciOiJFUzM4NCIsImtpZCI6IkdOV2FBTDJQVlVVMkpJVDg5bTZxMGM3U3ZjNDBTLWJ2UjFTT0
Q3REZCb1UiLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ
eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwcz
ovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6
Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLT
AxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIlNFOHp4bmduZTNNbWEwLUNm
S2dlYW1rNUVqU1NfOXRaNlN5NDdBdTdxRWMiLCJjT3lySEVrSlZwdEtSdURtNkNZVTREajJvRkExd0
JQRjFHcTJnWEo1NXpzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJh
Y2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsibVNfSVBMa0JHcTIxbVA3Z0VRaHhOck
E0ZXNMc1ZKQ1E5QUpZNDFLLVRQSSJdfSwiX3NkIjpbIlhTSG9iU05Md01PVl9QNkhQMHNvMnZ1clNy
VXZ3UURYREJHQWtyTXk3TjgiXX0sIl9zZCI6WyJQNE5qWHFXa2JOc1NfRzdvdmlLdm1NOG0yckhDTm
5XVVV2SXZBbW9jb2RZIiwieFNvSHBKUXlCNGV1dmg4SkFJdDFCd1pjNFVEOHY5S3ZOTmVLMk9OSjFC
QSJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2
lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNzAzNjI1OTAxLCJleHAiOjE3MzUyNDgzMDEsImNuZiI6eyJq
d2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6Inl1Zlo1SFUzcU
NfOTRMbkI3Zklzd0hmT0swQlJra0Z5bzVhd1QyX21ld0tJWUpLMVNfR0QySVB3UjRYUTZpdFEiLCJ5
IjoiRmEtV2pOd2NLQ1RWWHVDU2tCY3RkdHJOYzh6bXdBTTZWOWxudmxxd1QyQnRlQ0ZHNmR6ZDJoMF
VjeXluTDg0dCJ9fX0
M7BFJB9LEV_xEylSJpP00fd_4WjrOlXshh0dUv3QgOzw2MEGIfSfi9PoCkHJH7TI0InsqkD6XZVz38
MpeDKekgBW-RoDdJmxnifYOEJhKpJ5EN9PvA007UPi9QCaiEzX
WyJFX3F2V09NWVQ1Z3JNTkprOHNXN3BBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbG
UvY3JlZGVudGlhbHMvMTg3MiJd
WyJTSEc4WnpfRDVRbFMwU0ZrZFUzNXlRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIi
wgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d
WyJqZzJLRno5bTFVaGFiUGtIaHV4cXRRIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbX
BsZXMvZGVncmVlLmpzb24iXQ
WyItQmhzaE10UnlNNUVFbGt4WGVXVm5nIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJ0SEFxMEUwN
nY2ckRuUlNtSjlSUWRBIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd
WyJ1Ynd6bi1kS19tMzRSMGI0SG84QTBBIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ
The
enveloping proof
above secures the original
credential
by
encapsulating the original data in a digital signature envelope, resulting in a
verifiable credential
that can be processed using tooling that understands
the SD-JWT format.
Verifiable presentations
MAY
be used to aggregate information from
multiple
verifiable credentials
Verifiable presentations
SHOULD
be extremely short-lived and bound to a
challenge provided by a
verifier
. Details for accomplishing this depend
on the securing mechanism, the transport protocol, and
verifier
policies.
Unless additional requirements are defined by the particular securing mechanism
or embedding protocol, a
verifier
cannot generally assume that the
verifiable presentation
correlates with the presented
verifiable credentials
The
default graph
of a
verifiable presentation
is also referred to
as the
verifiable presentation graph
The following properties are defined for a
verifiable presentation
id
The
id
property
is optional. It
MAY
be used to provide a
unique identifier for the
verifiable presentation
. If present, the
normative guidance in Section
4.4
Identifiers
MUST
be followed.
type
The
type
property
MUST
be present. It is used to express the
type of
verifiable presentation
. One value of this property
MUST
be
VerifiablePresentation
, but additional types
MAY
be included. The
related normative guidance in Section
4.5
Types
MUST
be followed.
verifiableCredential
The
verifiableCredential
property
MAY
be present. The value
MUST
be one or more
verifiable credential
and/or
enveloped verifiable credential
objects (the values
MUST NOT
be non-object values such as
numbers, strings, or URLs). These objects are called
verifiable credential graphs
and
MUST
express information that is secured using a
securing mechanism
See Section
5.12
Verifiable Credential Graphs
for further details.
holder
The
verifiable presentation
MAY
include a
holder
property
. If present, the value
MUST
be either a
URL
or an object
containing an
id
property
. It is
RECOMMENDED
that the
URL
in the
holder
or its
id
be one which, if
dereferenced, results in a document containing machine-readable information
about the
holder
that can be used to
verify
the information
expressed in the
verifiable presentation
If the
holder
property
is absent, information about the
holder
is obtained either via the securing mechanism or
does not pertain to the
validation
of the
verifiable presentation
The example below shows a
verifiable presentation
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
"type": ["VerifiablePresentation", "ExamplePresentation"],
"verifiableCredential": [{ }]
The contents of the
verifiableCredential
property
shown
above are
verifiable credential
graphs
, as described by this specification.
It is possible for a
verifiable presentation
to include one or more
verifiable credentials
that have been secured using a securing mechanism
that "envelopes" the payload, such as
Securing Verifiable Credentials using JOSE and COSE
VC-JOSE-COSE
].
This can be accomplished by associating the
verifiableCredential
property with
an object that has a
type
of
EnvelopedVerifiableCredential
EnvelopedVerifiableCredential
They are used to associate an object containing an enveloped
verifiable credential
with the
verifiableCredential
property in a
verifiable presentation
. The
@context
property of the object
MUST
be
present and include a context, such as the
base context
for this specification
, that defines at least the
id
type
, and
EnvelopedVerifiableCredential
terms as defined by the base context provided
by this specification. The
id
value of the object
MUST
be a
data:
URL
RFC2397
] that expresses a secured
verifiable credential
using an
enveloping
security scheme, such as
Securing Verifiable Credentials using JOSE and COSE
VC-JOSE-COSE
]. The
type
value of the object
MUST
be
EnvelopedVerifiableCredential
The example below shows a
verifiable presentation
that contains an
enveloped
verifiable credential
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiablePresentation", "ExamplePresentation"],
"verifiableCredential": [{
"@context": "https://www.w3.org/ns/credentials/v2",
"id": "data:application/vc+sd-jwt,QzVjV...RMjU",
"type": "EnvelopedVerifiableCredential"
}]
Note
: Processing enveloped content as RDF
It is possible that an implementer might want to process the object described in
this section and the enveloped presentation expressed by the
id
value in an
RDF environment and create linkages between the objects that are relevant to
RDF. The desire and mechanisms for doing so are use case dependent and will,
thus, be implementation dependent.
holder
MAY
use the
verifiableCredential
property
in
verifiable presentation
to include
verifiable credentials
from
any
issuer
, including themselves. When the
issuer
of a
verifiable credential
is the
holder
, the
claims
in that
verifiable credential
are considered
self-asserted
Such self-asserted claims can be secured by the same mechanism that secures
the
verifiable presentation
in which they are included or by any
mechanism usable for other
verifiable credentials
The
subject(s)
of these self-asserted
claims
are not limited, so these
claims
can include statements about the
holder
, one of the other included
verifiable credentials
or even
the
verifiable presentation
in which the self-asserted
verifiable credential
is included. In each case, the
id
property
is used to identify the specific
subject
, in the object where the
claims
about it are made, just as it is done in
verifiable credentials
that are not self-asserted.
verifiable presentation
that includes a self-asserted
verifiable credential
, which is secured only using the same mechanism as
the
verifiable presentation
MUST
include a
holder
property
All of the normative requirements defined for
verifiable credentials
apply to self-asserted
verifiable credentials
verifiable credential
in a
verifiable presentation
is considered
self-asserted when the value of the
issuer
property
of the
verifiable credential
is identical to the value of the
holder
property
of the
verifiable presentation
The example below shows a
verifiable presentation
that embeds a
self-asserted
verifiable credential
that is secured using the same
mechanism as the
verifiable presentation
Example
20
: A verifiable presentation, secured with an embedded Data Integrity proof, with a self-asserted verifiable credential
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiablePresentation", "ExamplePresentation"],
"holder": "did:example:12345678",
"verifiableCredential": [{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiableCredential", "ExampleFoodPreferenceCredential"],
"issuer": "did:example:12345678",
"credentialSubject": {
"favoriteCheese": "Gouda"
},
{ }
}],
"proof": [{ }]
The example below shows a
verifiable presentation
that embeds a
self-asserted
verifiable credential
holding
claims
about the
verifiable presentation
. It is secured using the same mechanism as the
verifiable presentation
Example
21
: A verifiable presentation, secured with an embedded Data Integrity proof, with a self-asserted verifiable credential about the verifiable presentation
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiablePresentation", "ExamplePresentation"],
"id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b"
"holder": "did:example:12345678",
"verifiableCredential": [{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiableCredential", "ExampleAssertCredential"],
"issuer": "did:example:12345678",
"credentialSubject": {
"id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b"
"assertion": "This VP is submitted by the subject as evidence of a legal right to drive"
},
"proof": { }
}],
"proof": { }
Building on the concepts introduced in Section
4.
Basic Concepts
this section explores more complex topics about
verifiable credentials
This section is non-normative.
The
verifiable credentials
trust model is based on the following
expectations:
The
verifier
expects the
issuer
to verifiably issue the
credential
that it receives. This can be established by satisfying
either of the following:
All
entities
expect the
verifiable data registry
to be tamper-evident
and to be a correct record of which data is controlled by which
entities
This is typically achieved by the method of its publication. This could be via a
peer-to-peer protocol from a trusted publisher, a publicly accessible and well
known web site (with a content hash), a blockchain, etc. When entities publish
metadata about themselves, the publication can be integrity-protected by being
secured using with the entity's private key.
The
holder
and
verifier
expect the
issuer
to stand by
claims
it makes in
credentials
about the
subject
, and to revoke
credentials
quickly if and when they no longer stand by those
claims
The
holder
might trust the
issuer's
claims
because the
holder
has a pre-existing trust relationship with the
issuer
. For example, an
employer might provide an employee with an employment
verifiable credential
or a government might issue an electronic passport to a citizen.
Where no pre-existing trust relationship exists, the
holder
might
have some out-of-band means of determining whether the
issuer
is
qualified to issue the
verifiable credential
being provided.
Note: It is not always necessary for the
holder
to trust the
issuer
since the issued
verifiable credential
might be an assertion about
subject
who is not the
holder
, or about no-one, and the
holder
might be willing to relay this information to a
verifier
without
being held accountable for its veracity.
The
holder
expects the
credential repository
to store
credentials
securely, to not release
credentials
to anyone other than the
holder
(which may subsequently present them to a
verifier
), and to not corrupt nor
lose
credentials
while they are in its care.
This trust model differentiates itself from other trust models by ensuring
the following:
How
verifiers
decide which
issuers
to trust, and for what data or
purposes, is out of scope for this recommendation. Some
issuers
, such as
well-known organizations, might be trusted by many
verifiers
simply because
of their reputation. Some
issuers
and
verifiers
might be members of a
community in which all members trust each other due to the rules of membership.
Some
verifiers
might trust a specific trust-service provider whose
responsibility is to vet
issuers
and list them in a trust list such as those
specified in
Electronic Signatures and Infrastructures (ESI); Trusted Lists
ETSI-TRUST-LISTS
] or the
Adobe
Approved Trust List
By decoupling the expectations between the
issuer
and the
verifier
a more flexible and dynamic trust model is created, such that market
competition and customer choice is increased.
For more information about how this trust model interacts with various threat
models studied by the Working Group, see the
Verifiable Credentials Use Cases
VC-USE-CASES
].
Note
: Trust model differs from the traditional Certificate Authority system
The data model detailed in this specification does not imply a transitive trust
model, such as that provided by more traditional Certificate Authority trust
models. In the Verifiable Credentials Data Model, a
verifier
either
directly trusts or does not trust an
issuer
. While it is possible to
build transitive trust models using the Verifiable Credentials Data Model,
implementers are urged to
learn
about the security weaknesses
introduced by
broadly delegating trust
in the manner adopted by Certificate Authority
systems.
One of the goals of the Verifiable Credentials Data Model is to enable
permissionless innovation. To achieve this, the data model needs to be
extensible in a number of different ways. The data model is required to:
This approach to data modeling is often called an
open world assumption
, meaning that any entity can say anything about
any other entity. While this approach seems to conflict with building simple and
predictable software systems, balancing extensibility with program correctness
is always more challenging with an open world assumption than with closed
software systems.
The rest of this section describes, through a series of examples, how both
extensibility and program correctness are achieved.
Let us assume we start with the
credential
shown below.
Credential
ecdsa
ecdsa-sd
bbs
jose
cose
sd-jwt
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://vc.example/credentials/4643",
"type": ["VerifiableCredential"],
"issuer": "https://issuer.example/issuers/14",
"validFrom": "2018-02-24T05:28:04Z",
"credentialSubject": {
"id": "did:example:abcdef1234567",
"name": "Jane Doe"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://vc.example/credentials/4643",
"type": [
"VerifiableCredential"
],
"issuer": "https://issuer.example/issuers/14",
"validFrom": "2018-02-24T05:28:04Z",
"credentialSubject": {
"id": "did:example:abcdef1234567",
"name": "Jane Doe"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:34Z",
"verificationMethod": "did:key:zDnaebSRtPnW6YCpxAhR5JPxJqt9UunCsBPhLEtUokUvp87nQ",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z3FfiNeGUGhy8ApiRsv42y5VUPFgbieFbUJebkKhkZ6tNASNv6MkiJwNGWczfmrdYdmLZa6r3rtJ4BSF9BjnwrSo8"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://vc.example/credentials/4643",
"type": [
"VerifiableCredential"
],
"issuer": "https://issuer.example/issuers/14",
"validFrom": "2018-02-24T05:28:04Z",
"credentialSubject": {
"id": "did:example:abcdef1234567",
"name": "Jane Doe"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:34Z",
"verificationMethod": "did:key:zDnaerJh8WwyBVVGcZKKkqRKK9iezje8ut6t9bnNChtxcWwNv",
"cryptosuite": "ecdsa-sd-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0AhVhA8DUmqMDGQOAZ8hIuyi_X-LbT_fD_guDAKeRkRbAwk8aXyQeTRQErpRbOMQiYhWHKelW9XSZSIU3_dk8s-SLLIVgjgCQCEJqTiBGYPxkutgRjtMH-_iViqDBvJl4I9XVBXrsRRBhYIC2fjWyVwswq0oXkkyYFTxwdT5k-XZWMJx7JdwFPfALfg1hApuvVmqTlFFKpI79s8M8CND3arkiGE6talSgE8n2iT9NxbWYgiqH0s3Zxo_eXGCbBoxibB3_VMt9huvsz51yhxVhAj55Js6Ka1i7-mfjrszFmD1W0Lc81XKCtAqHvF-qY2XWd6cpHIwWlSvU3NxSoYpcAdxUrgAu17iEmHMLvpdyllFhAo4kADpzjQ_AeB0nvp-IzeawelLeusg8t2M2yZLPzcN3R4alEKnbWofwSflHD2Yx_QQW3U9Ck9YALaKZbO_KIRYFnL2lzc3Vlcg"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://vc.example/credentials/4643",
"type": [
"VerifiableCredential"
],
"issuer": "https://issuer.example/issuers/14",
"validFrom": "2018-02-24T05:28:04Z",
"credentialSubject": {
"id": "did:example:abcdef1234567",
"name": "Jane Doe"
},
"proof": {
"type": "DataIntegrityProof",
"verificationMethod": "did:key:zUC78GzFRA4TWh2mqRiKro1wwRb5KDaMJ3M1AD3qGtgEbFrwWGvWbnCzArkeTZCyzBz4Panr2hLaZxsXHiBQCwBc3fRPH6xY4u5v8ZAd3dPW1aw89Rra86CVwXr3DczANggYbMD",
"cryptosuite": "bbs-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0ChVhQtDW_taTeCBSwoqWX3rzUAFmrR8_TAfE8027nlDX8x4Eiquv_i6S7XU_4mnGV-ODaZYnVuh47RBcLtkevGmEDr_0aXc7ujmM6icKfQgg88cRYQGd_DaMQQsoaryttl5TvxnFT-Vm4SkVx03K9qNJ4jhArvqENcCm8D2khyMGr7-FGFdx818_ufbFmo8hKn_2FgMpYYJVTGbTfcflzyx41E-f9kSqmf10xYzxJrGfC7b7GPY8X7VjMT__ZKSuwdH-5jak-5gkjocsHI6oxIKlLrhW1Wh5yrDCH-QC823TS8NE9VGBzIFAfUt5qazGEcJ8CxeSPxFggPmXI3YCyx-_cwMML4xSJvv9xy0Xvrw9Qb6s21_i5rHiBZy9pc3N1ZXI"
Protected Headers
"kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
"alg": "ES256"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://vc.example/credentials/4643",
"type": [
"VerifiableCredential"
],
"issuer": "https://issuer.example/issuers/14",
"validFrom": "2018-02-24T05:28:04Z",
"credentialSubject": {
"id": "did:example:abcdef1234567",
"name": "Jane Doe"
application/vc+jwt
eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdmMuZXhhbXBsZS9jcmVkZW50aWFscy80NjQzIiwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJodHRwczovL2lzc3Vlci5leGFtcGxlL2lzc3VlcnMvMTQiLCJ2YWxpZEZyb20iOiIyMDE4LTAyLTI0VDA1OjI4OjA0WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6YWJjZGVmMTIzNDU2NyIsIm5hbWUiOiJKYW5lIERvZSJ9fQ
p2BTVD1miV8CyTx1ivkbBmBo_LzoMNyQbDPP1_bxRMov_umGGpsw9ngQ5bF245MAbtH-yJw7L0wx14KKQC1gvw
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://vc.example/credentials/4643",
"type": [
"VerifiableCredential"
],
"issuer": "https://issuer.example/issuers/14",
"validFrom": "2018-02-24T05:28:04Z",
"credentialSubject": {
"id": "did:example:abcdef1234567",
"name": "Jane Doe"
application/vc+cose
d28443a10128a05901487b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f76632e6578616d706c652f63726564656e7469616c732f34363433222c2274797065223a5b2256657269666961626c6543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f6973737565722e6578616d706c652f697373756572732f3134222c2276616c696446726f6d223a22323031382d30322d32345430353a32383a30345a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a61626364656631323334353637222c226e616d65223a224a616e6520446f65227d7d5840eeb9cf85c67689580f3f73aef32e28e495412ab15f694bec8522b52153966a32c16dace5627374f50fef36b7df36415b2a79e652fa87598940e83d0ff972a167
Encoded
Decoded
Issuer Disclosures
eyJpYXQiOjE3NDU3NzY3MTQsImV4cCI6MTc0Njk4NjMxNCwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly9pc3N1ZXIuZXhhbXBsZS9pc3N1ZXJzLzE0IiwidmFsaWRGcm9tIjoiMjAxOC0wMi0yNFQwNToyODowNFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJuYW1lIjoiSmFuZSBEb2UiLCJfc2QiOlsidVE2NkFmZXF3dWY0Y2s5NXI2cTFWZVZEM3FVYjU0VTJtUmdZdGRWQVpkbyJdfSwiX3NkIjpbIktwdURNMGVHaWtoNXBiVjhUR1lrYjZTdDNaLUZadkNtWmxkeGl1NmwydzgiLCJiUzFQMVNOc2tUb2h1QlRCeE8tNHF4bThRT21sQmlDTXhnVXJnYkNpWHM4Il19
NUK9XkgPZ46Zc_3urENrSvkN0RRkNUw31ki9YFAJVhggzxBJhYHNBWK1NtFhu6cQU1o0XqKjaYVMXHsCB4SGGQ
WyJTZDNNNUZ1LTl3dnRaZU85RTE2dEx3IiwgImlkIiwgImh0dHA6Ly92Yy5leGFtcGxlL2NyZWRlbnRpYWxzLzQ2NDMiXQ
WyJKeHpWdGlUWjE3UVBpRDZpdVJIZDh3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIl1d
WyJwUEY1VG95bFhTa19FeU8zUmhJT2RRIiwgImlkIiwgImRpZDpleGFtcGxlOmFiY2RlZjEyMzQ1NjciXQ
Claim:
id
SHA-256 Hash:
KpuDM0eGikh5pbV8TGYkb6St3Z-FZvCmZldxiu6l2w8
Disclosure(s):
WyJTZDNNNUZ1LTl3dnRaZU85RTE2dEx3IiwgImlkIiwgImh0dHA6Ly92Yy5leGFtcGxlL2NyZWRlbnRpYWxzLzQ2NDMiXQ
Contents:
"Sd3M5Fu-9wvtZeO9E16tLw",
"id",
"http://vc.example/credentials/4643"
Claim:
type
SHA-256 Hash:
bS1P1SNskTohuBTBxO-4qxm8QOmlBiCMxgUrgbCiXs8
Disclosure(s):
WyJKeHpWdGlUWjE3UVBpRDZpdVJIZDh3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIl1d
Contents:
"JxzVtiTZ17QPiD6iuRHd8w",
"type",
"VerifiableCredential"
Claim:
id
SHA-256 Hash:
uQ66Afeqwuf4ck95r6q1VeVD3qUb54U2mRgYtdVAZdo
Disclosure(s):
WyJwUEY1VG95bFhTa19FeU8zUmhJT2RRIiwgImlkIiwgImRpZDpleGFtcGxlOmFiY2RlZjEyMzQ1NjciXQ
Contents:
"pPF5ToylXSk_EyO3RhIOdQ",
"id",
"did:example:abcdef1234567"
This
verifiable credential
states that the
entity
associated with
did:example:abcdef1234567
has a
name
with a value of
Jane Doe
Now let us assume a developer wants to extend the
verifiable credential
to store two additional pieces of information: an internal corporate reference
number, and Jane's favorite food.
The first thing to do is to create a JSON-LD context containing two new terms,
as shown below.
"@context": {
"referenceNumber": "https://extension.example/vocab#referenceNumber",
"favoriteFood": "https://extension.example/vocab#favoriteFood"
After this JSON-LD context is created, the developer publishes it somewhere so
it is accessible to
verifiers
who will be processing the
verifiable credential
. Assuming the above JSON-LD context is published at
, we can extend this
example by including the context and adding the new
properties
and
credential
type
to the
verifiable credential
Example
24
: A verifiable credential with a custom extension
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2",
"https://extension.example/my-contexts/v1"
],
"id": "http://vc.example/credentials/4643",
"type": ["VerifiableCredential", "CustomExt12"],
"issuer": "https://issuer.example/issuers/14",
"validFrom": "2018-02-24T05:28:04Z",
"referenceNumber": 83294847,
"credentialSubject": {
"id": "did:example:abcdef1234567",
"name": "Jane Doe",
"favoriteFood": "Papaya"
This example demonstrates extending the Verifiable Credentials Data Model in a
permissionless and decentralized way. The mechanism shown also ensures that
verifiable credentials
created in this way provide a way to prevent
namespace conflicts and semantic ambiguity.
A dynamic extensibility model such as this does increase the implementation
burden. Software written for such a system has to determine whether
verifiable credentials
with extensions are acceptable based on the risk
profile of the application. Some applications might accept only certain
extensions while highly secure environments might not accept any extensions.
These decisions are up to the developers of these applications and are
specifically not the domain of this specification.
Extension specification authors are urged to ensure that their documents, such
as JSON-LD Contexts, are highly available. Developers using these documents
might use software that produces errors when these documents cannot be
retrieved. Strategies for ensuring that extension JSON-LD contexts are always
available include bundling these documents with implementations, content
distribution networks with long caching timeframes, or using
content-addressed URLs for contexts. These approaches are covered in further
detail in Appendix
B.
Contexts, Vocabularies, Types, and Credential Schemas
Implementers are advised to pay close attention to the extension points in this
specification, such as in Sections
4.10
Status
4.11
Data Schemas
4.12
Securing Mechanisms
5.4
Refreshing
5.5
, and
5.6
Evidence
. While this specification does not define concrete
implementations for those extension points, the
Verifiable Credential Extensions
document
provides an unofficial, curated list of extensions that developers can use from
these extension points.
When defining new terms in an application-specific vocabulary, vocabulary
authors
SHOULD
follow the
detailed
checklist
in
Best Practices for Publishing Linked Data
. Specifically, the following guidance is of
particular importance:
Whenever possible, it is
RECOMMENDED
to re-use terms — and their corresponding
URLs — defined by well-known, public vocabularies, such as
Schema.org
New terms
MUST
define
a new URL for each term. When doing so, the
general guidelines for [
LINKED-DATA
] are expected to be followed, in
particular:
Human-readable documentation
MUST
be published, describing the semantics of and
the constraints on the use of each term.
It is
RECOMMENDED
to also publish the collection of all new terms as a
machine-readable vocabulary using
RDF Schema 1.1
It
SHOULD
be possible to dereference the URL of a term, resulting in its
description and/or formal definition.
Furthermore, a machine-readable description (that is, a
JSON-LD Context document
MUST
be
published at the URL specified in the
@context
property
for the
vocabulary. This context
MUST
map each term to its corresponding URL, possibly
accompanied by further constraints like the type of the property value. A
human-readable document describing the expected order of values for the
@context
property
is also expected to be published by any implementer
seeking interoperability.
Note
: Term redefinition is not allowed
When processing the
active
context
defined by the base JSON-LD Context document
defined in this specification
, compliant JSON-LD-based
processors produce an error when a JSON-LD context
redefines
any term.
The only way to change the definition of existing terms is to introduce a new
term that clears the active context within the scope of that new term. Authors
that are interested in this feature should read about the
@protected
keyword
in the JSON-LD 1.1 specification.
conforming document
SHOULD NOT
use the
@vocab
feature in production
as it can lead to JSON term clashes, resulting in semantic ambiguities with
other applications. Instead, to achieve proper interoperability, a
conforming document
SHOULD
use JSON-LD Contexts that define all terms used by their
applications, as described earlier in Section
5.2
Extensibility
. If a
conforming document
does not use JSON-LD Contexts that define all terms
used, it
MUST
include the
as the last value in the
@context
property.
It is useful for systems to enable the manual or automatic refresh of an expired
verifiable credential
. For more information about validity periods for
verifiable credentials
, see Section
A.7
Validity Periods
This specification defines a
refreshService
property
, which
enables an
issuer
to include a link to a refresh service.
The
issuer
can include the refresh service as an element inside the
verifiable credential
if it is intended for either the
verifier
or
the
holder
(or both), or inside the
verifiable presentation
if it
is intended for the
holder
only. In the latter case, this enables the
holder
to refresh the
verifiable credential
before creating a
verifiable presentation
to share with a
verifier
. In the former
case, including the refresh service inside the
verifiable credential
enables either the
holder
or the
verifier
to perform future
updates of the
credential
The refresh service is only expected to be used when either the
credential
has expired or the
issuer
does not publish
credential
status information.
Issuers
are advised not to put the
refreshService
property
in a
verifiable credential
that does not contain public information or whose refresh service is not
protected in some way.
refreshService
The value of the
refreshService
property
MUST
be one or more
refresh services that provides enough information to the recipient's software
such that the recipient can refresh the
verifiable credential
. Each
refreshService
value
MUST
specify its
type
. The precise content of each
refresh service is determined by the specific
refreshService
type
definition.
Example
27
: Use of the refreshService property by an issuer
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/age/v1"
],
"type": ["VerifiableCredential", "AgeVerificationCredential"],
"issuer": "did:key:z6MksFxi8wnHkNq4zgEskSZF45SuWQ4HndWSAVYRRGe9qDks",
"validFrom": "2024-04-03T00:00:00.000Z",
"validUntil": "2024-12-15T00:00:00.000Z",
"name": "Age Verification Credential",
"credentialSubject": {
"overAge": 21
},
"refreshService": {
"type": "VerifiableCredentialRefreshService2021",
"url": "https://registration.provider.example/flows/reissue-age-token",
"refreshToken": "z2BJYfNtmWRiouWhDrbDQmC2zicUPBxsPg"
In the example above, the
issuer
specifies an automatic
refreshService
that can be used by POSTing the
verifiable credential
to
the refresh service
url
. Note that this particular verifiable credential is
not intended to be shared with anyone except for the original issuer.
Terms of use can be used by an
issuer
or a
holder
to
communicate the terms under which a
verifiable credential
or
verifiable presentation
was issued. The
issuer
places their terms
of use inside the
verifiable credential
. The
holder
places their
terms of use inside a
verifiable presentation
. This specification defines
property
for expressing terms of use
information.
The value of the
property
might be used
to tell the
verifier
any or all of the following, among other things:
the procedures or policies that were used in issuing the
verifiable credential
, by providing, for example, a pointer to a public location
(to avoid "phone home" privacy issues) where these procedures or policies
can be found, or the name of the standard that defines them
the rules and policies of the
issuer
that apply to the presentation
of this
verifiable credential
to a
verifier
, by providing,
for example, a pointer to a public location (to avoid "phone home" privacy
issues) where these rules or policies can be found
the identity of the entity under whose authority the
issuer
issued
this particular
verifiable credential
The value of the
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
value
MUST
specify
its
type
, for example,
TrustFrameworkPolicy
, and
MAY
specify its
instance
id
. The precise contents of each term of use is determined
by the specific
type
definition.
Example
28
: Use of the termsOfUse property by an issuer
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/undefined-terms/v2"
],
"id": "urn:uuid:08e26d22-8dca-4558-9c14-6e7aa7275b9b",
"type": [
"VerifiableCredential",
"VerifiableAttestation",
"VerifiableTrustModel",
"VerifiableAuthorisationForTrustChain"
],
"issuer": "did:ebsi:zZeKyEJfUTGwajhNyNX928z",
"validFrom": "2021-11-01T00:00:00Z",
"validUntil": "2024-06-22T14:11:44Z",
"credentialSubject": {
"id": "did:ebsi:zvHWX359A3CvfJnCYaAiAde",
"reservedAttributeId": "60ae46e4fe9adffe0bc83c5e5be825aafe6b5246676398cd1ac36b8999e088a8",
"permissionFor": [{
"schemaId": "https://api-test.ebsi.eu/trusted-schemas-registry/v3/schemas/zHgbyz9ajVuSProgyMhsiwpcp8g8aVLFRNARm51yyYZp6",
"types": [
"VerifiableCredential",
"VerifiableAttestation",
"WorkCertificate"
],
"jurisdiction": "https://publications.europa.eu/resource/authority/atu/EUR"
}]
},
"termsOfUse": {
"type": "TrustFrameworkPolicy",
"trustFramework": "Employment&Life",
"policyId": "https://policy.example/policies/125",
"legalBasis": "professional qualifications directive"
"credentialStatus": {
"id": "https://api-test.ebsi.eu/trusted-issuers-registry/v5/issuers/did:ebsi:zvHWX359A3CvfJnCYaAiAde/attributes/60ae46e4fe9adffe0bc83c5e5be825aafe6b5246676398cd1ac36b8999e088a8",
"type": "EbsiAccreditationEntry"
},
"credentialSchema": {
"id": "https://api-test.ebsi.eu/trusted-schemas-registry/v3/schemas/zCSHSDwrkkd32eNjQsMCc1h8cnFaxyTXP5ByozyVQXZoH",
"type": "JsonSchema"
In the example above, the
issuer
is asserting that the legal basis
under which the
verifiable credential
has been issued is the
"professional qualifications directive" using the "Employment&Life" trust
framework, with a specific link to the policy.
This feature is expected to be used by government-issued
verifiable credentials
to instruct digital wallets to limit their use to similar
government organizations in an attempt to protect citizens from unexpected use
of sensitive data. Similarly, some
verifiable credentials
issued by private
industry are expected to limit use to within departments inside the
organization, or during business hours. Implementers are urged to read more
about this evolving feature in the appropriate section of the Verifiable
Credentials Implementation Guidelines [
VC-IMP-GUIDE
] document.
Evidence can be included by an
issuer
to provide the
verifier
with
additional supporting information in a
verifiable credential
. This could be
used by the
verifier
to establish the confidence with which it relies on the
claims in the
verifiable credential
. For example, an
issuer
could check
physical documentation provided by the
subject
or perform a set of
background checks before issuing the
credential
. In certain scenarios, this
information is useful to the
verifier
when determining the risk associated
with relying on a given
credential
This specification defines the
evidence
property
for expressing evidence
information.
evidence
If present, the value of the
evidence
property
MUST
be either a single
object or a set of one or more objects. The following
properties
are defined
for every evidence object:
id
The
id
property
is
OPTIONAL
. It
MAY
be used to provide a unique identifier
for the evidence object. If present, the normative guidance in Section
4.4
Identifiers
MUST
be followed.
type
The
type
property
is
REQUIRED
. It is used to express the type of evidence
information expressed by the object. The related normative guidance in Section
4.5
Types
MUST
be followed.
Note
: See Implementation Guide for strategies for providing evidence
For information about how attachments and references to
credentials
and
non-credential data might be supported by the specification, see Section
5.3
Integrity of Related Resources
Example
29
: Example of evidence supporting a skill achievement credential
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
],
"id": "http://1edtech.edu/credentials/3732",
"type": [
"VerifiableCredential",
"OpenBadgeCredential"
],
"issuer": {
"id": "https://1edtech.edu/issuers/565049",
"type": "Profile"
},
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "AchievementSubject",
"name": "Alice Smith",
"activityEndDate": "2023-12-02T00:00:00Z",
"activityStartDate": "2023-12-01T00:00:00Z",
"awardedDate": "2024-01-01T00:00:00Z",
"achievement": [{
"id": "urn:uuid:d46e8ef1-c647-419b-be18-5e045d1c4e64",
"type": ["Achievement"],
"name": "Basic Barista Training",
"criteria": {
"narrative": "Team members are nominated for this badge by their supervisors, after passing the Basic Barista Training course."
},
"description": "This achievement certifies that the bearer is proficient in basic barista skills."
}]
},
"evidence": [{

"id": "https://videos.example/training/alice-espresso.mp4",
"type": ["Evidence"],
"name": "Talk-aloud video of double espresso preparation",
"description": "This is a talk-aloud video of Alice demonstrating preparation of a double espresso drink.",

"digestMultibase": "uELq9FnJ5YLa5iAszyJ518bXcnlc5P7xp1u-5uJRDYKvc"
In the
evidence
example above, the
issuer
is asserting that they have
video of the
subject
of the
credential
demonstrating the achievement.
Note
: Evidence has a different purpose from securing mechanisms
The
evidence
property
provides information that is different from and
information to the securing mechanism used. The
evidence
property
is
used to express supporting information, such as documentary evidence, related to
the
verifiable credential
. In contrast, the securing mechanism is used to
express machine-verifiable mathematical proofs related to the authenticity of
the
issuer
and integrity of the
verifiable credential
. For more
information about securing mechanisms, see Section
4.12
Securing Mechanisms
Zero-knowledge proofs are
securing mechanisms
which enable a
holder
to prove that they hold a
verifiable credential
containing a value without disclosing the actual value such as being able to
prove that an individual is over the age of 25 without revealing their birthday.
This data model supports being secured using zero-knowledge proofs.
Some capabilities that are compatible with
verifiable credentials
which are
made possible by zero-knowledge proof mechanisms include:
Specification authors that create
securing mechanisms
MUST NOT
design them in
such a way that they leak information that would enable the
verifier
to
correlate a
holder
across multiple
verifiable presentations
to different
verifiers
Not all capabilities are supported in all zero-knowledge proof mechanisms.
Specific details about the capabilities and techniques provided by a particular
zero knowledge proof mechanism, along with any normative requirements for using
them with
verifiable credentials
, would be found in a specification for
securing
verifiable credentials
with that zero-knowledge proof mechanism.
For an example of such a specification, refer to the
Data Integrity BBS Cryptosuites v1.0
We note that in most instances, for the
holder
to make use of zero knowledge
mechanisms with
verifiable credentials
, the
issuer
is required to secure
the
verifiable credential
in a manner that supports these capabilities.
The diagram below highlights how the data model might be used to issue and
present
verifiable credentials
in zero-knowledge.
Figure
12
A visual example of the relationship between credentials and derived
credentials in a ZKP
presentation
An example of a
verifiable credential
and a
verifiable presentation
using the
Data Integrity BBS Cryptosuites v1.0
unlinkable selective disclosure securing mechanism is
shown below.
Example
30
: Verifiable credential using the Data Integrity BBS Cryptosuite with a Base Proof
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/citizenship/v3"
],
"type": ["VerifiableCredential", "PermanentResidentCard"],
"issuer": {
"id": "did:web:credentials.utopia.example",
"image": "data:image/png;base64,iVBORw0KGgo...YII="
},
"identifier": "83627465",
"name": "Permanent Resident Card",
"description": "Government of Utopia Permanent Resident Card.",
"validFrom": "2024-08-01T00:00:00Z",
"validUntil": "2029-12-01T00:00:00Z",
"credentialSubject": {
"type": ["PermanentResident", "Person"],
"givenName": "JANE",
"familyName": "SMITH",
"gender": "Female",
"image": "data:image/png;base64,iVBORw0KGgoAA...Jggg==",
"residentSince": "2015-01-01",
"lprCategory": "C09",
"lprNumber": "999-999-999",
"commuterClassification": "C1",
"birthCountry": "Arcadia",
"birthDate": "1978-07-17"
},
"proof":
"type": "DataIntegrityProof",
"verificationMethod": "did:web:playground.alpha.chapi.io#zUC75LjjCLGKRxSissX1nAebRDmY4Bv4T6MAbzgaap9Q8rAGf6SEjc2Hf4nH6bUPDwky3GWoYcUjMCcEqRRQfXEiNwfeDwNYLoeqk1J1W2Ye8vCdwv4fSd8AZ1yS6UoNzcsQoPS",
"cryptosuite": "bbs-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0ChVhQjYs9O7wUb3KRSMaIRX7jmafVHYDPYBLD4ta85_qmuXTBU_t2Ir7pNujwRE6fERsBUEZRSjJjtI-hqOqDs3VvBvH6gd3o2KeUS2V_zpuphPpYQEkapOeQgRTak9lHKSTqEQqa4j2lyHqekEeGvzPlqcHQGFccGifvLUXtP59jCuGJ86HDA9HL5kDzUT6n4Gi50HlYYIzNqhbjIxlqOuxO2IgIppSTWjQGeer34-PmKnOzKX8m_9DHPhif7TUf5uTV4OQWdhb0SxHnJ-CPu_z9FJ5ACekBQhz6YWS0_CY6j_ibucXzeVfZwLv1W47pjbt-l1Vl5VggSn2xVt69Q0GD9mPKpOhkKV_hyOL7i6haf7bq-gOKAwWDZy9pc3N1ZXJtL2lzc3VhbmNlRGF0ZW8vZXhwaXJhdGlvbkRhdGU"
The example above is a
verifiable credential
where the
issuer
has
enabled a BBS-based unlinkable disclosure scheme to create a base proof that
can then be used by the
holder
to create a derived proof that reveals only
particular pieces of information from the original
verifiable credential
Example
31
: Verifiable presentation using the Data Integrity BBS Cryptosuite with a derived credential and proof
@context: "https://www.w3.org/ns/credentials/v2"
type: "VerifiablePresentation",
verifiableCredential: {
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/citizenship/v3"
],
"type": ["VerifiableCredential", "PermanentResidentCard"],
"issuer": {
"id": "did:web:issuer.utopia.example",
"image": "data:image/png;base64,iVBORw0KGgo...YII="
},
"name": "Permanent Resident Card",
"description": "Government of Utopia Permanent Resident Card.",
"validFrom": "2024-08-01T00:00:00Z",
"validUntil": "2029-12-01T00:00:00Z",
"credentialSubject": {
"type": ["PermanentResident", "Person"],
"birthCountry": "Arcadia"
},
"proof":
type: "DataIntegrityProof",
verificationMethod: "did:web:issuer.utopia.example#zUC75LjjCLGKRxSissX1nAebRDmY4Bv4T6MAbzgaap9Q8rAGf6SEjc2Hf4nH6bUPDwky3GWoYcUjMCcEqRRQfXEiNwfeDwNYLoeqk1J1W2Ye8vCdwv4fSd8AZ1yS6UoNzcsQoPS",
cryptosuite: "bbs-2023",
proofPurpose: "assertionMethod",
proofValue: "u2V0DhVkCkLdnshxHtgeHJBBUGPBqcEooPp9ahgqs08RsoqW5EJFmsi70jqf2X368VcmfdJdYcYJwObPIg5dlyaoBm34N9BqcZ4RlTZvgwX79ivGnqLALC0EqKn2wOj5hRO76xUakfLGIcT4mE-G7CxA1FTs8sRCWy5p6FozelBYiZU2YlhUpJ7pBwelZ9wnlcbj4q-KyxAj5GU2iWp7-FxU-E624DmdT-yvCkAGRRrYej6lMwg7jB9uCHypOXXH2dVZ-jpf74YBaE4rMTxPFh60GN4o3S65F1fMsJbEMLdrXa8Vs6ZSlmveUcY1X7oPr1UIxo17ehVTCjOxWunYqrtLi9cVkYOD2s9XMk1oFVWBB3UY29axXQQXlZVfvTIUsfVc667mnlYbF7a-ko_SUfeY2n3s1DOAap5keeNU0v2KVPCbxA2WGz7UJy4xJv2a8olMOWPKjAEUruCx_dsbyicd-9KGwhYoUEO3HoAzmtI6qXVhMbJKxPrhtcp8hOdD9izVS5ed4CxHNaDGPSopF_MBwjxwPcpUufNNNdQwesrbtFJo0-P-1CrX_jSxKFMle2b3t24UbHRbZw7QnX4OG-SSVucem5jpMXTDFZ8PLFCqXX0zncJ_MQ-_u-liE-MwJu3ZemsXBp1JoB2twS0TqDVzSWR7bpFZKI9_07fKUAmQNSV_no9iAgYRLuPrnnsW1gQgCV-nNqzbcCOpzkHdCqro6nPSATq5Od3Einfc683gm5VGWxIldM0aBPytOymNz7PIZ6wkgcMABMe5Vw46B54ftW-TN5YZPDmCJ_kt7Mturn0OeQr9KJCu7S0I-SN14mL9KtGE1XDnIeR-C_YZhSA3vX4923v1l3vNFsKasqy9iEPHKM0hcogABAQCGAAECBAUGhAMJCgtYUnsiY2hhbGxlbmdlIjoiNGd2OFJyaERPdi1OSHByYlZNQlM1IiwiZG9tYWluIjoiaHR0cHM6Ly9wbGF5Z3JvdW5kLmFscGhhLmNoYXBpLmlvIn0"
The
verifiable presentation
above includes a
verifiable credential
that
contains an unlinkable subset of the information from the previous example and a
derived proof that the
verifier
can use to verify that the information
originated from the expected
issuer
and is bound to this particular
exchange of information.
Implementers are urged to understand that representing and processing time
values is not as straight-forward as it might seem and have a variety of
idiosyncrasies that are not immediately obvious nor uniformly observed in
different regions of the world. For example:
Calendaring systems other than the Gregorian calendar are actively used by
various regions.
When processing Daylight Saving/Summer Time, it is important to understand that
1) it is not observed in all regions, 2) it does not necessarily begin or end on
the same day or at the same time of day, and 3) the amount or direction of the
adjustment does not always match other similar regions.
Leap seconds might not be taken into account in all software systems, especially
for dates and times that precede the introduction of the leap second. Leap
seconds can affect highly sensitive systems that depend on the exact
millisecond offset from the epoch. However, note that for most applications the
only moment in time that is affected is the one second period of the leap second
itself. That is, the moment after the most recent leap second can always be
represented as the first moment of the next day (for example,
2023-01-01T00:00:00Z
), regardless of whether the system in question
understands leap seconds.
These are just a few examples that illustrate that the actual time of day, as
would be seen on a clock on the wall, can exist in one region but not exist in
another region. For this reason, implementers are urged to use time values
that are more universal, such as values anchored to the
time zone over
values that are affected by Daylight Saving/Summer Time.
This specification attempts to increase the number of universally recognized
combinations of dates and times, and reduce the potential for
misinterpretation of time values, by using the
dateTimeStamp
construction first established by the [
XMLSCHEMA11-2
] specification. In
order to reduce misinterpretations between different time zones, all time values
expressed in
conforming documents
SHOULD
be specified in
dateTimeStamp
format, either in Universal Coordinated Time (UTC), denoted by a
at the end
of the value, or with a time zone offset relative to UTC. Time values that are
incorrectly serialized without an offset
MUST
be interpreted as UTC. Examples of
valid time zone offsets relative to UTC include
+01:00
-08:00
, and
+14:00
. See the regular expression at the end of this section for a formal
definition of all acceptable values.
Time zone definitions are occasionally changed by their governing body. When
replacing or issuing new
verifiable credentials
, implementers are advised
to ensure that changes to local time zone rules do not result in unexpected gaps
in validity. For example, consider the zone
America/Los_Angeles
, which has
a raw offset of UTC-8 and had voted to stop observing daylight savings time in
the year 2024. A given
verifiable credential
that had a
validUtil
value of
2024-07-12T12:00:00-07:00
, might be re-issued to have a
validFrom
value of
2024-07-12T12:00:00-08:00
, which would create a gap of
an hour where the
verifiable credential
would not be valid.
Implementers that desire to check
dateTimeStamp
values for validity
can use the regular expression provided below, which is reproduced from the [
XMLSCHEMA11-2
] specification for
convenience. To avoid doubt, the regular expression in [
XMLSCHEMA11-2
] is the
normative definition. Implementers are advised that not all
dateTimeStamp
values that pass the regular expression below are
valid moments in time. For example, the regular expression below allows for 31
days in every month, which allows for leap years, and leap seconds, as well as
days in places where they do not exist. That said, modern system libraries that
generate
dateTimeStamp
values are often error-free in their
generation of valid
dateTimeStamp
values. The regular
expression shown below (minus the whitespace included here for readability),
is often adequate when processing library-generated dates and times on
modern systems.
Example
32
: Regular expression to detect a valid XML Schema 1.1: Part 2 dateTimeStamp
-?([1-9][0-9]{3,}|0[0-9]{3})
-(0[1-9]|1[0-2])
-(0[1-9]|[12][0-9]|3[01])
T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?|(24:00:00(\.0+)?))
(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))
This section is non-normative.
Verifiable credentials
are intended as a means of reliably identifying
subjects
. While it is recognized that Role Based Access Controls (RBACs)
and Attribute Based Access Controls (ABACs) rely on this identification as a
means of authorizing
subjects
to access resources, this specification
does not provide a complete solution for RBAC or ABAC. Authorization is not an
appropriate use for this specification without an accompanying authorization
framework.
The Working Group did consider authorization use cases during the creation of
this specification and is pursuing that work as an architectural layer built
on top of this specification.
This specification reserves a number of
properties
to serve as possible
extension points. While some implementers signaled interest in these properties,
their inclusion in this specification was considered to be premature. It is
important to note that none of these properties are defined by this
specification. Consequently, implementers are cautioned that use of these
properties is considered experimental.
Implementers
MAY
use these properties, but
SHOULD
expect them and/or
their meanings to change during the process of normatively specifying them.
Implementers
SHOULD NOT
use these properties without a publicly disclosed
specification describing their implementation.
In order to avoid collisions regarding how the following properties are used,
implementations
MUST
specify a
type
property in the value associated with the
reserved property. For more information related to adding
type
information,
see Section
4.5
Types
Reserved Property
Description
confidenceMethod
A property used for specifying one or more methods that a verifier might use to
increase their confidence that the value of a property in or of a verifiable
credential or verifiable presentation is accurate. The associated vocabulary
URL
MUST
be
renderMethod
A property used for specifying one or more methods to render a credential into a
visual, auditory, haptic, or other format. The associated vocabulary URL
MUST
be
An unofficial list of specifications that are associated with the extension
points defined in this specification, as well as the reserved extension points
defined in this section, can be found in the
Verifiable Credential Extensions
. Items in the
directory that refer to reserved extension points
SHOULD
be treated as
experimental.
There are a number of digital credential formats that do not natively use the
data model provided in this document, but are aligned with a number of concepts
in this specification. At the time of publication, examples of these digital
credential formats include
JSON Web Tokens
(JWTs),
CBOR Web Tokens
(CWTs),
JSON Advanced Electronic Signature
(JAdES),
ISO-18013-5:2021
(mDLs),
AnonCreds
Gordian Envelopes
, and
Authentic Chained Data Containers
(ACDCs).
If conceptually aligned digital credential formats can be transformed into a
conforming document
according to the rules provided in this section, they
are considered
"compatible with the
W3C
Verifiable Credentials
ecosystem"
. Specification authors are advised to adhere to the following
rules when documenting transformations that enable compatibility with the
Verifiable Credentials ecosystem. The transformation specification —
MUST
identify whether the transformation to this data model is one-way-only or
round-trippable.
MUST
preserve the
@context
values when performing round-trippable
transformation.
MUST
result in a
conforming document
when transforming to the data
model described by this specification.
MUST
specify a registered media type for the input document.
SHOULD
provide a test suite that demonstrates that the specified transformation
algorithm to the data model in this specification results in
conforming document
SHOULD
ensure that all semantics used in the transformed
conforming document
follow best practices for Linked Data. See
Section
4.1
Getting Started
, Section
5.2
Extensibility
, and Linked Data Best Practices [
LD-BP
for additional guidance.
Note
: What constitutes a verifiable credential?
Readers are advised that a digital credential is only considered compatible with
the
W3C
Verifiable Credentials ecosystem if it is a
conforming document
and it uses at least one securing mechanism, as described by their
respective requirements in this specification. While some communities might call
some digital credential formats that are not
conforming documents
"verifiable credentials", doing so does NOT make that digital credential
compliant to this specification.
When expressing
verifiable credentials
(for example in a
presentation
), it is important to ensure that data in one
verifiable credential
is not mistaken to be the same data in another
verifiable credential
. For example, if one has two
verifiable credentials
, each
containing an object of the following form:
{"type": "Person", "name": "Jane
Doe"}
, it is not possible to tell if one object is describing the same person
as the other object. In other words, merging data between two
verifiable credentials
without confirming that they are discussing the same entities
and/or properties, can lead to a corrupted data set.
To ensure that data from different
verifiable credentials
are not
accidentally co-mingled, the concept of a
verifiable
credential graph
is used to encapsulate each
verifiable credential
For simple
verifiable credentials
, that is, when the JSON-LD document
contains a single credential with, possibly, associated proofs, this graph is
the
default graph
. For
presentations
, each value associated with
the
verifiableCredential
property of the
presentation
is a separate
named graph
of type
VerifiableCredentialGraph
which contains a single
verifiable credential
or an
enveloped verifiable credential
Using these
graphs
has a concrete effect when performing JSON-LD
processing, which properly separates graph node identifiers in one graph from
those in another graph. Implementers that limit their inputs to
application-specific JSON-LD documents will also need to keep this in mind if
they merge data from one
verifiable credential
with data from another,
such as when the
credentialSubject.id
is the same in both
verifiable credentials
, but the object might contain objects of the "Jane Doe" form
described in the previous paragraph. It is important to not merge objects that
seem to have similar properties but do not contain an
id
property that uses a
global identifier, such as a URL.
As described in Section
4.12
Securing Mechanisms
, there are
multiple strategies that an implementer can use when securing a
conforming document
. In order to maximize utility and interoperability,
specification authors that desire to author new ways of securing
conforming documents
are provided with the guidance in this section.
Securing mechanism specifications
MUST
document normative algorithms that
provide content integrity protection for
conforming documents
. The
algorithms
MAY
be general in nature and
MAY
be used to secure data other than
conforming documents
Securing mechanism specifications
MUST
provide a verification algorithm that
returns the information in the
conforming document
that has been secured, in
isolation, without including any securing mechanism information, such as
proof
or
JOSE/COSE header parameters and signatures. Verification algorithms
MAY
return
additional information that might be helpful (for example, during validation or
for debugging purposes), such as details of the securing mechanism. A verification
algorithm
MUST
provide an interface that receives a media type (
string
inputMediaType
) and input data (
byte sequence
or
map
inputData
).
Securing mechanism specifications
MAY
provide algorithms and interfaces in
addition to the ones specified in this document. The verification algorithm
returns a verification result with at least the following
items
boolean
verified
A verification status whose value is
true
if the verification succeeded and
false
if it did not.
map
verifiedDocument
A document that only contains information that was successfully secured.
string
mediaType
A media type as defined in [
RFC6838
].
Securing mechanism specifications
SHOULD
provide integrity protection for any
information referenced by a URL that is critical to validation. Mechanisms that
can achieve this protection are discussed in Section
5.3
Integrity of Related Resources
and Section
B.1
Base Context
A securing mechanism specification that creates a new type of
embedded proof
MUST
specify a
property
that relates the
verifiable credential
or
verifiable presentation
to a
proof graph
The requirements on the securing mechanism are as follow:
The
proof
property as defined in [
VC-DATA-INTEGRITY
MAY
be used by the
embedded securing mechanism.
Securing mechanism specifications
SHOULD
register the securing mechanism in the
Securing Mechanisms
section of the
Verifiable Credential Extensions
document.
The data model as described in Sections
3.
Core Data Model
4.
Basic Concepts
, and
5.
Advanced Concepts
is the canonical structural
representation of a
verifiable credential
or
verifiable presentation
All syntaxes are representations of that data model in a specific format. This
section specifies how the data model is serialized in JSON-LD for
application/vc
and
application/vp
, the base media types for
verifiable credentials
and
verifiable presentations
, respectively. Although syntactic
mappings are only provided for JSON-LD, applications and services can use any
other data representation syntax (such as XML, YAML, or CBOR) that is capable of
being mapped back to
application/vc
or
application/vp
. As the
verification
and
validation
requirements are defined in terms of the
data model, all serialization syntaxes have to be deterministically translated
to the data model for processing,
validation
, or comparison.
The expected arity of the property values in this specification, and the
resulting datatype which holds those values, can vary depending on the property.
If present, the following properties are represented as a single value:
id
(Section
4.4
Identifiers
),
issuer
(Section
4.7
Issuer
), and
validFrom
validUntil
(Section
4.9
Validity Period
). All other properties,
if present, are represented as either a single value or an array of values.
This specification uses
JSON-LD 1.1
to serialize the data model described in
this specification. JSON-LD is useful because it enables the expression of the
graph-based data model
on which
verifiable credentials
are based,
machine-readable
semantics
, and is also useful when extending the data model (see Sections
3.
Core Data Model
and
5.2
Extensibility
).
JSON-LD is a JSON-based format used to serialize
Linked Data
. Linked
Data is modeled using Resource Description Framework (RDF) [
RDF11-CONCEPTS
].
RDF is a technology for modeling graphs of statements. Each statement is a
single
subject→property→value
(also known as
entity→attribute→value
) relationship, which is referred to as a
claim
in this specification. JSON-LD is a technology that enables the
expression of RDF using idiomatic JSON, enabling developers familiar with JSON
to write applications that consume RDF as JSON. See
Relationship of JSON-LD to RDF
for more details.
In general, the data model and syntax described in this document enables
developers to largely treat
verifiable credentials
as JSON documents,
allowing them to copy and paste examples, with minor modification, into their
software systems. The design goal of this approach is to provide a low barrier
to entry while still ensuring global interoperability between a heterogeneous
set of software systems. This section describes some of the JSON-LD features
that are used to make this possible, which will likely go unnoticed by most
developers, but whose details might be of interest to implementers. The most
noteworthy features in
JSON-LD 1.1
used by this specification include:
The
@id
and
@type
keywords are aliased to
id
and
type
respectively, enabling developers to use
this specification as idiomatic JSON.
Data types, such as integers, dates, units of measure, and URLs, are
automatically typed to provide stronger type guarantees for use cases that
require them.
The
verifiableCredential
property
is defined as a
JSON-LD 1.1 graph
container
. This requires the creation of
named graphs
, used to isolate
sets of data asserted by different entities. This ensures, for example, proper
cryptographic separation between the data graph provided by each
issuer
and the one provided by the
holder
presenting the
verifiable credential
to ensure the provenance of the information for each graph is
preserved.
The
@protected
properties feature of
JSON-LD 1.1
is used to ensure that
terms defined by this specification cannot be overridden. This means that as
long as the same
@context
declaration is made at the top of a
verifiable credential
or
verifiable presentation
, interoperability is guaranteed for
all terms understood by users of the data model whether or not they use a
JSON-LD 1.1
processor.
In order to increase interoperability, this specification restricts the use of
JSON-LD representations of the data model. JSON-LD
compacted document
form
MUST
be used for all representations of the data model using the
application/vc
or
application/vp
media type.
As elaborated upon in Section
6.3
Type-Specific Credential Processing
, some software applications
might not perform generalized JSON-LD processing. Authors of
conforming documents
are advised that interoperability might be reduced if JSON-LD
keywords in the
@context
value are used to globally affect values in a
verifiable credential
or
verifiable presentation
, such as by
setting either or both of the
@base
or
@vocab
keywords. For example, setting
these values might trigger a failure in a mis-implemented JSON Schema test of
the
@context
value in an implementation that is performing
type-specific credential processing
and not expecting the
@base
and/or
@vocab
value to
be expressed in the
@context
value.
In order to increase interoperability,
conforming document
authors are
urged to not use JSON-LD features that are not easily detected when performing
type-specific credential processing
. These features include:
In-line declaration of JSON-LD keywords in the
@context
value that globally
modify document term and value processing, such as setting
@base
or
@vocab
Use of JSON-LD contexts that override declarations in previous contexts, such as
resetting
@vocab
In-line declaration of JSON-LD contexts in the
@context
property
Use of full URLs for JSON-LD terms and types (for example,
or
) instead of the short forms of
any such values (for example,
VerifiableCredential
or
SomeNewType
) that are
explicitly defined in JSON-LD
@context
mappings (for example, in
While this specification cautions against the use of
@vocab
, there are
legitimate uses of the feature, such as to ease experimentation, development,
and localized deployment. If an application developer wants to use
@vocab
in
production, which is advised against to reduce term collisions and leverage the
benefits of semantic interoperability, they are urged to understand that any use
of
@vocab
will disable reporting of "undefined term" errors, and
later use(s) will override any previous
@vocab
declaration(s). Different values
of
@vocab
can change the semantics of the information contained in the document,
so it is important to understand whether and how these changes will affect the
application being developed.
Lists, arrays, and even lists of lists, are possible when using
JSON-LD 1.1
We encourage those who want RDF semantics in use cases requiring lists and
arrays to follow the guidance on
lists in JSON-LD 1.1
In general, a JSON array is ordered, while a JSON-LD array is not ordered unless
that array uses the
@list
keyword.
Note
: Array order might not matter
While it is possible to use this data model by performing
type-specific credential processing
, those who do so and make use of arrays need to be aware
that unless the above guidance is followed, the order of items in an array
are not guaranteed in JSON-LD. This might lead to unexpected behavior.
If JSON structure or ordering is important to your application, we recommend you
mark such elements as
@json
via an
@context
that is specific to your
use case. An example of such a declaration is shown below.
Example
33
: A @context file that defines a matrix as an embedded JSON data structure
"@context"
"matrix"
"@id"
"https://website.example/vocabulary#matrix"
"@type"
"@json"
When the context shown above is used in the example below, by including the
context in the
@context
property, the
value in
credentialSubject.matrix
retains its JSON semantics; the exact order
of all elements in the two dimensional matrix is preserved.
Example
34
: A verifiable credential with an embedded JSON data structure
"@context"
"https://www.w3.org/ns/credentials/v2"
"https://www.w3.org/ns/credentials/examples/v2"
"https://website.example/matrix/v1"
"id"
"http://university.example/credentials/1872"
"type"
"VerifiableCredential"
"ExampleMatrixCredential"
"issuer"
"https://university.example/issuers/565049"
"validFrom"
"2010-01-01T19:23:24Z"
"credentialSubject"
"id"
"did:example:ebfeb1f712ebc6f1c276e12ec21"
"matrix"
10
11
12
This section is non-normative.
As JSON can be used to express different kinds of information, a consumer of
a particular JSON document can only properly interpret the author's intent if they
possess information that contextualizes and disambiguates it from other possible
expressions. Information to assist with this interpretation can either be wholly
external to the JSON document or linked from within it. Compacted JSON-LD documents
include a
@context
property that internally expresses or links to
contextual information to express
claims
. These features
enable generalized processors to be written to convert JSON-LD documents from one
context to another, but this is not needed when consumers receive JSON-LD documents
that already use the context and shape that they expect. Authors of JSON-LD
documents, such as
issuers
of
verifiable credentials
, are required
to provide proper JSON-LD contexts and follow these rules in order to facilitate
interoperability.
The text below helps consumers understand how to ensure a JSON-LD document is
expressed in a context and shape that their application already understands
such that they do not need to transform it in order to consume its contents.
Notably, this does not mean that consumers do not need to understand any
context at all; rather, consuming applications only need to understand a chosen
set of contexts and document shapes to work with and not others. Issuers can
publish contexts and information about their
verifiable credentials
to
aid consumers who do not use generalized processors, just as can be done
with any other JSON-formatted data.
General JSON-LD processing
is defined as a mechanism that uses a
JSON-LD software library to process a
conforming document
by performing
various
transformations
Type-specific credential processing
is defined as a lighter-weight
mechanism for processing
conforming documents
, that doesn't require
a JSON-LD software library. Some consumers of
verifiable credentials
only need to consume credentials with specific types. These consumers can use
type-specific credential processing instead of generalized processing. Scenarios
where type-specific credential processing can be desirable include, but are not
limited to, the following:
That is,
type-specific credential processing
is allowed as long as the
document being consumed or produced is a
conforming document
If
type-specific credential processing
is desired, an implementer is advised
to follow this rule:
Ensure that all values associated with a
@context
property are in the expected
order, the contents of the context files match known good cryptographic hashes
for each file, and domain experts have deemed that the contents are appropriate
for the intended use case.
Using static context files with a JSON Schema is one acceptable approach to
implementing the rule above. This can ensure proper term identification,
typing, and order, when performing
type-specific credential processing
The rule above guarantees semantic interoperability between the two processing
mechanisms for mapping literal JSON keys to URIs via the
@context
mechanism.
While
general JSON-LD processing
can use previously unseen
@context
values provided in its algorithms to verify that all terms are correctly
specified, implementations that perform
type-specific credential processing
only accept specific
@context
values which the implementation
is engineered ahead of time to understand, resulting in the same semantics
without invoking any JSON-LD APIs. In other words, the context in which the data
exchange happens is explicitly stated for both processing mechanisms by using
@context
in a way that leads to the same
conforming document
semantics.
This section is non-normative.
This section details the general privacy considerations and specific privacy
implications of deploying the Verifiable Credentials Data Model into production
environments.
This section is non-normative.
It is important to recognize there is a spectrum of privacy ranging from
pseudonymous to strongly identified. Depending on the use case, people have
different comfort levels about the information they are willing to provide
and the information that can be derived from it.
Figure
13
Privacy spectrum ranging from pseudonymous to fully identified.
Privacy solutions are use case specific.
For example, many people would prefer to remain anonymous when purchasing
alcohol because the regulation is only to verify whether a purchaser is
above a specific age. In contrast, when filling prescriptions written by
a medical professional for a patient, the pharmacy is legally required
to more strongly identify both the prescriber and the patient. No single
approach to privacy works for all use cases.
Note
: Proof of age might be insufficient for some use cases
Even those who want to remain anonymous when purchasing alcohol might need
to provide photo identification to appropriately assure the merchant. The
merchant might not need to know your name or any details other than that
you are over a specific age, but in many cases, simple proof of age might
be insufficient to meet regulations.
The Verifiable Credentials Data Model strives to support the full privacy
spectrum and does not take philosophical positions on the correct level of
anonymity for any specific transaction. The following sections will guide
implementers who want to avoid specific scenarios that are hostile to
privacy.
This section is non-normative.
A variety of trust relationships exist in the
ecosystem described by this specification
. An
individual using a web browser trusts the web browser, also known as a
user agent
, to preserve
that trust by not uploading their personal information to a data broker;
similarly, entities filling the roles in the ecosystem described by this
specification trust the software that operates on behalf of each of those roles.
Examples include the following:
The examples above are not exhaustive, and the users in these roles can also
expect various other things from the software they use to achieve their
goals. In short, the user expects the software to operate in the user's best
interests; any violations of this expectation breach trust and can lead to the
software's replacement with a more trustworthy alternative. Implementers are
strongly encouraged to create software that preserves user trust. Additionally,
they are encouraged to include auditing features that enable users or trusted
third parties to verify that the software is operating in alignment with their
best interests.
Readers are advised that some software, like a website providing services
to a single
verifier
and multiple
holders
, might operate as a
user agent
to both
roles but might not always be able to operate simultaneously in the best
interests of all parties. For example, suppose a website detects an attempt at
fraudulent
verifiable credential
use among multiple
holders
. In that
case, it might report such an anomaly to the
verifier
, which might be
considered not to be in all
holders'
best interest, but would be in the
best interest of the
verifier
and any
holders
not
committing
such a violation. It is imperative that when software operates in this manner,
it is made clear in whose best interest(s) the software is operating, through
mechanisms such as a website use policy.
This section is non-normative.
Data associated with
verifiable credentials
stored in the
credential.credentialSubject
property is susceptible to privacy violations
when shared with
verifiers
. Personally identifying data, such as a
government-issued identifier, shipping address, or full name, can be easily
used to determine, track, and correlate an
entity
. Even information that
does not seem personally identifiable, such as the combination of a
birthdate and a postal code, has powerful correlation and de-anonymization
capabilities.
Implementers of software used by
holders
are strongly advised to warn
holders
when they share data with these kinds of characteristics.
Issuers
are strongly advised to provide privacy-protecting
verifiable credentials
when possible — for example, by issuing
ageOver
verifiable credentials
instead of
dateOfBirth
verifiable credentials
for use when a
verifier
wants to determine whether an
entity
is at least 18 years of age.
Because a
verifiable credential
often contains personally identifiable
information (PII), implementers are strongly advised to use mechanisms while
storing and transporting
verifiable credentials
that protect the data from
those who ought not have access to it. Mechanisms that could be considered include
Transport Layer Security (TLS) or other means of encrypting the data while in
transit, as well as encryption or access control mechanisms to protect
the data in a
verifiable credential
when at rest.
Generally, individuals are advised to assume that a
verifiable credential
like most physical credentials, will leak personally identifiable information
when shared. To combat such leakage,
verifiable credentials
and their
securing mechanisms need to be carefully designed to prevent correlation.
Verifiable credentials
specifically designed to protect against leakage
of personally identifiable information are available. Individuals and
implementers are encouraged to choose these credential types over those not
designed to protect personally identifiable information.
This section is non-normative.
Verifiable credentials
might contain long-lived identifiers that could be
used to correlate individuals. These identifiers include
subject
identifiers, email addresses, government-issued identifiers, organization-issued
identifiers, addresses, healthcare vitals, and many other long-lived
identifiers. Implementers of software for
holders
are encouraged to
detect identifiers in
verifiable credentials
that could be used
to correlate individuals and to warn
holders
before they share this
information. The rest of this section elaborates on guidance related to
using long-lived identifiers.
Subjects
of
verifiable credentials
are identified using the
id
property, as defined in Section
4.4
Identifiers
and used in places such
as the
credentialSubject.id
property. The identifiers used to identify a
subject
create a greater correlation risk when the identifiers are
long-lived or used across more than one web domain. Other types of identifiers
that fall into this category are email addresses, government-issued identifiers,
and organization-issued identifiers.
Similarly, disclosing the
credential
identifier (as in
Example
) can lead to situations where multiple
verifiers
, or an
issuer
and a
verifier
, can collude to correlate the
holder
Holders
aiming to reduce correlation are encouraged to use
verifiable credentials
from
issuers
that support selectively disclosing correlating
identifiers in a
verifiable presentation
. Such approaches expect the
holder
to generate the identifier and might even allow hiding the identifier
from the
issuer
through techniques like
blind signatures
while still keeping the identifier embedded and signed in the
verifiable credential
Securing mechanism
specification authors are advised to avoid enabling
identifier-based correlation by designing their technologies to avoid the use
of correlating identifiers that cannot be selectively disclosed.
If strong anti-correlation properties are required in a
verifiable credentials
system, it is essential that identifiers meet one or more
of the following criteria:
Selectively disclosable
Bound to a single origin
Single-use
Not used and instead replaced by short-lived, single-use bearer tokens.
This section is non-normative.
The contents of a
verifiable credential
are secured using a
securing mechanism
. Values representing the securing mechanism pose a greater
risk of correlation when they remain the same across multiple sessions
or domains. Examples of these include the following values:
the binary value of the digital signature
timestamp information associated with the creation of the digital signature
cryptographic material associated with the digital signature, such as
a public key identifier
When strong anti-correlation properties are required,
issuers
are encouraged
to produce
verifiable credentials
where signature values and metadata can
be regenerated for each
verifiable presentation
. This can be achieved using
technologies that support unlinkable disclosure, such as the
Data Integrity BBS Cryptosuites v1.0
specification. When possible,
verifiers
are encouraged to prefer
verifiable presentations
that use this technology in order to enhance
privacy for
holders
and
subjects
This section is non-normative.
There are mechanisms external to
verifiable credentials
that
track and correlate individuals on the Internet and the Web. These
mechanisms include Internet protocol (IP) address tracking, web browser
fingerprinting, evercookies, advertising network trackers, mobile network
position information, and in-application Global Positioning System (GPS) APIs.
Using
verifiable credentials
cannot prevent the use of these other
tracking technologies; rather, using these technologies alongside
verifiable credentials
can reveal new correlatable information. For
instance, a birthdate combined with a GPS position can strongly correlate
an individual across multiple websites.
Privacy-respecting systems ought to aim to prevent the combination of other
tracking technologies with
verifiable credentials
. In some instances,
tracking technologies might need to be disabled on devices that
transmit
verifiable credentials
on behalf of a
holder
The Oblivious HTTP protocol [
RFC9458
] is one mechanism implementers
might consider using when fetching external resources associated with a
verifiable credential
or a
verifiable presentation
Oblivious HTTP allows a client to make multiple requests to an origin server
without that server being able to link those requests to that client or even to
identify those requests as having come from a single client, while placing only
limited trust in the nodes used to forward the messages. Oblivious HTTP
is one privacy-preserving mechanism that can reduce the possibility
of device tracking and fingerprinting. Below are some concrete examples of
ways that Oblivious HTTP can benefit ecosystem participants.
holder
using a digital wallet can reduce the chances that they
will be tracked by a 3rd party when accessing external links within a
verifiable credential
stored in their digital wallet.
For example, a digital wallet might fetch and render linked images, or
it might check the validity of a
verifiable credential
by fetching
an externally linked revocation list.
verifier
can reduce its likelihood of signaling to an
issuer
that the
verifier
has received a specific
verifiable credential
For example, a
verifier
might fetch an externally linked revocation
list while performing status checks on a
verifiable credential
This section is non-normative.
Issuers
are encouraged to limit the information included in a
verifiable credential
to the smallest set required for the intended purposes, so as to
allow recipients to use them in various situations without disclosing more
personally identifiable information (PII) than necessary. One way to avoid
placing PII in a
verifiable credential
is to use an abstract
property
that meets the needs of
verifiers
without providing overly specific
information about a
subject
For example, this document uses the
ageOver
property
instead of a specific birthdate, which would represent more sensitive PII. If
retailers in a particular market commonly require purchasers to be older than
a certain age, an
issuer
trusted in that market might choose to offer
verifiable credentials
that claim that
subjects
have met that
requirement rather than offering
verifiable credentials
that contain
claims
about the customers' birthdays. This practice enables individual
customers to make purchases without disclosing more PII than necessary.
This section is non-normative.
Privacy violations occur when information divulged in one context leaks into
another. One accepted best practice for preventing such a violation is for
verifiers
to limit the information requested and received, to the absolute
minimum necessary for a particular transaction. Regulations in multiple
jurisdictions, including the Health Insurance Portability and Accountability
Act (HIPAA) in the United States and the General Data Protection Regulation
(GDPR) in the European Union, mandate this data minimization approach.
With
verifiable credentials
, data minimization for
issuers
means
limiting the content of a
verifiable credential
to the minimum required by
potential
verifiers
for expected use. For
verifiers
, data minimization
means restricting the scope of information requested or required for
accessing services.
For example, a driver's license containing a driver's ID number, height, weight,
birthday, and home address expressed as a
verifiable credential
contains
more information than is necessary to establish that the person is above a
certain age.
It is considered best practice for
issuers
to atomize information or use a
securing mechanism that allows for
selective disclosure
. For example, an
issuer
of driver's licenses could issue a
verifiable credential
containing every property that appears on a driver's license, and allow the
holder
to disclose each property selectively. It could also issue more
abstract
verifiable credentials
(for example, a
verifiable credential
containing only an
ageOver
property). One possible adaptation would be for
issuers
to provide secure HTTP endpoints for retrieving single-use
bearer credentials
that promote the pseudonymous use of
verifiable credentials
Implementers that find this impractical or unsafe might consider using
selective disclosure
schemes that eliminate dependence on
issuers
at
proving time and reduce the risk of temporal correlation by
issuers
Verifiers
are urged to only request information that is strictly necessary
for a specific transaction to occur. This is important for at least
two reasons:
It reduces the liability on the
verifier
for handling highly sensitive
information that it does not need to handle.
It enhances the
subject's
and/or
holder's
privacy by only asking for
information that is necessary for a specific transaction.
Implementers of software used by
holders
are encouraged to disclose the
information being requested by a
verifier
, allowing the
holder
to
decline to share specific information that is unnecessary for the
transaction. Implementers of software used by
holders
are also advised
to give
holders
access to logs of information shared with
verifiers
enabling the
holders
to provide this information to authorities if they
believe that they have been subjected to information overreach or coerced to
share more information than necessary for a particular transaction.
Note
: Minimum disclosure can still lead to unique identification
While it is possible to practice the principle of minimum disclosure, it might
be impossible to avoid the strong identification of an individual for
specific use cases during a single session or over multiple sessions. The
authors of this document cannot stress how difficult it is to meet this
principle in real-world scenarios.
This section is non-normative.
bearer credential
is a
privacy-enhancing piece of information, such as a concert ticket, that entitles
its
holder
to a specific resource without requiring the
holder
to
divulge sensitive information. In low-risk scenarios, entities often use bearer
credentials where multiple
holders
presenting the same
verifiable credential
is not a concern or would not result in large economic or reputational losses.
Verifiable credentials
that are
bearer credentials
are made
possible by not specifying the
subject
identifier, expressed using the
id
property
, which is nested in the
credentialSubject
property
. For example, the following
verifiable credential
is a
bearer credential
Credential
ecdsa
ecdsa-sd
bbs
jose
cose
sd-jwt
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/temporary/28934792387492384",
"type": ["VerifiableCredential", "ExampleDegreeCredential"],
"issuer": "https://university.example/issuers/14",
"validFrom": "2017-10-22T12:23:48Z",
"credentialSubject": {

"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/temporary/28934792387492384",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2017-10-22T12:23:48Z",
"credentialSubject": {
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:34Z",
"verificationMethod": "did:key:zDnaebSRtPnW6YCpxAhR5JPxJqt9UunCsBPhLEtUokUvp87nQ",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z5gCBzvpHbsJoeuuy5Z54rKQwkGzBZkmapRZZAKKW4ervhBGGTaygnh4sBG6vV8MHGD8eKhXEmkXr487JwVhZ2WHQ"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/temporary/28934792387492384",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2017-10-22T12:23:48Z",
"credentialSubject": {
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2025-04-27T17:58:34Z",
"verificationMethod": "did:key:zDnaerJh8WwyBVVGcZKKkqRKK9iezje8ut6t9bnNChtxcWwNv",
"cryptosuite": "ecdsa-sd-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0AhVhAOEMucTcwHIY19VxghifeZjhZGFI9buw5OmEiWzSpbStoG5arWcYX6NB2-ftSiNc_CMh-CemG3peCu8ZOrSCHVFgjgCQC1zlBPjThDb-LSIbpc3uzcrjmKdC3xyuQAM8DoT5zv3FYIP13m1SOplZJx47EsonA19WEGnwABCA4hlMlQS96LIQMhVhADxlyJM3iqf_jn__vvJ0KgjL5uKLmVSsOxTFUsIHJ82mS8DAo_WZUmDxMnCAjrrxPQXLaNdfcmqehQOLT4_oiiVhA74UxSBi3EedkNnN5F2WV_Hd1Pr1vPWA_Qx52meKAa0_FhKu-Gm8uk2fFxK28flIbUv5HVQgGT0nrSuSprE4JslhAGl8hwCBGr5KxrUVAcMZE3vW26KrrI6jMTDLPGb81b9-ILrXLIJKb_ZOcmLggwzgbyxE_hUDLL9b88aZ7tE4dOVhACerSusVIq25s-hjms5Ws4Uw3wmgRQp1lp228deojpcavN-n3FNe3AIBgHFbpK2SzdOzvraj-HVkMpQptXrGEhVhAujmfdq6faQbfYn4LUQCy_sDUr1WNbklcyg2XTDQKscMF0VAUU38d50UrmprSKbhrnZpgWMBFg4ibUco_HO4UToFnL2lzc3Vlcg"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/temporary/28934792387492384",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2017-10-22T12:23:48Z",
"credentialSubject": {
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
},
"proof": {
"type": "DataIntegrityProof",
"verificationMethod": "did:key:zUC78GzFRA4TWh2mqRiKro1wwRb5KDaMJ3M1AD3qGtgEbFrwWGvWbnCzArkeTZCyzBz4Panr2hLaZxsXHiBQCwBc3fRPH6xY4u5v8ZAd3dPW1aw89Rra86CVwXr3DczANggYbMD",
"cryptosuite": "bbs-2023",
"proofPurpose": "assertionMethod",
"proofValue": "u2V0ChVhQhlm-IXSzQAaXH0xW-NU1t3ikH2xt--sFY-DtoL44DiWf3qv-nuhCc36deovk3t1GLy9JeN-vdeth8XWKMGUcyA4eWD21lxYdvK5Qdzw07ytYQGd_DaMQQsoaryttl5TvxnFT-Vm4SkVx03K9qNJ4jhArdrHmhnEXifHmmlKM3zCnc0pq4l3ZkBkIESZ4DrQomVNYYJVTGbTfcflzyx41E-f9kSqmf10xYzxJrGfC7b7GPY8X7VjMT__ZKSuwdH-5jak-5gkjocsHI6oxIKlLrhW1Wh5yrDCH-QC823TS8NE9VGBzIFAfUt5qazGEcJ8CxeSPxFggOkuR5x7VvZAB-RbcqkcwxkQ7or0tsVOUTPlebfxRUQCBZy9pc3N1ZXI"
Protected Headers
"kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
"alg": "ES256"
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/temporary/28934792387492384",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2017-10-22T12:23:48Z",
"credentialSubject": {
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+jwt
eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzL3RlbXBvcmFyeS8yODkzNDc5MjM4NzQ5MjM4NCIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJFeGFtcGxlRGVncmVlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzE0IiwidmFsaWRGcm9tIjoiMjAxNy0xMC0yMlQxMjoyMzo0OFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ
6xC1cZL-ht0EvN7nz2Zs81htECRBp_87csS2IRyRG41wp-4zW0US8rth2KZjQMhsuPy7s0yjVIRWFGb6TQRCdg
application/vc
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/temporary/28934792387492384",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/14",
"validFrom": "2017-10-22T12:23:48Z",
"credentialSubject": {
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
application/vc+cose
d28443a10128a05901a27b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f74656d706f726172792f3238393334373932333837343932333834222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f3134222c2276616c696446726f6d223a22323031372d31302d32325431323a32333a34385a222c2263726564656e7469616c5375626a656374223a7b22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d58409ec236d42a81339288605ac9a750f8632dadc2d44bcaae49b2d1431f9d98fded1c01772494c84a0aab75b9ec527ce6dc3fbd4d7f913f6963549cb19c091be521
Encoded
Decoded
Issuer Disclosures
eyJpYXQiOjE3NDU3NzY3MTQsImV4cCI6MTc0Njk4NjMxNCwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy8xNCIsInZhbGlkRnJvbSI6IjIwMTctMTAtMjJUMTI6MjM6NDhaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiZGVncmVlIjp7Im5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIiwiX3NkIjpbIl9BT1Y2UkQwSmFobzVaaUgxSUxNd0pXSlE3cS1ueWVveVhIQWoyeVdtUlkiXX19LCJfc2QiOlsiUG9aeVBTUGtzd1AyODdsRU5ZMDJHdzg1Q2NzMjYyWU5fVkZLSEFpOGZ3byIsIlY0Y0k4aDQ5VUt6em5UdGpMQV9NZ3hBblFoeWR0ME45OWVVdjBTZXJibDQiXX0
71495BlH0xrBlHTp-Y2JqwvTx1u3nu8dS8eiXwxSF-TukGYmbZ0y74RxVQCZ046h7YK2OZ-FZjlVUAcTN0vLvQ
WyJqVThiaS1zWHk1dzVKNUYtdlhNaUZ3IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvdGVtcG9yYXJ5LzI4OTM0NzkyMzg3NDkyMzg0Il0
WyJlbXBLOFdGNDhHcW56ekVudTJNblV3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
WyJnTnRsVmhfeVZyWm5aeEVXQUpyaFhRIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Claim:
id
SHA-256 Hash:
PoZyPSPkswP287lENY02Gw85Ccs262YN_VFKHAi8fwo
Disclosure(s):
WyJqVThiaS1zWHk1dzVKNUYtdlhNaUZ3IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvdGVtcG9yYXJ5LzI4OTM0NzkyMzg3NDkyMzg0Il0
Contents:
"jU8bi-sXy5w5J5F-vXMiFw",
"id",
"http://university.example/credentials/temporary/28934792387492384"
Claim:
type
SHA-256 Hash:
V4cI8h49UKzznTtjLA_MgxAnQhydt0N99eUv0Serbl4
Disclosure(s):
WyJlbXBLOFdGNDhHcW56ekVudTJNblV3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d
Contents:
"empK8WF48GqnzzEnu2MnUw",
"type",
"VerifiableCredential",
"ExampleDegreeCredential"
Claim:
type
SHA-256 Hash:
_AOV6RD0Jaho5ZiH1ILMwJWJQ7q-nyeoyXHAj2yWmRY
Disclosure(s):
WyJnTnRsVmhfeVZyWm5aeEVXQUpyaFhRIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0
Contents:
"gNtlVh_yVrZnZxEWAJrhXQ",
"type",
"ExampleBachelorDegree"
While
bearer credentials
are privacy-enhancing,
issuers
still need to
take care in their design to avoid unintentionally divulging more information
than the
holder
of the
bearer credential
expects. For example,
repeated use of the same
bearer credential
across multiple sites can
enable these sites to collude in illicitly tracking or correlating the
holder
. Similarly, information that might seem non-identifying, such as
a birthdate and postal code, can be used together to statistically identify
an individual when used in
the same
bearer credential
or session.
Issuers
of
bearer credentials
should ensure that the
bearer credentials
provide privacy-enhancing benefits that:
Are single-use, where possible.
Do not contain personally identifying information.
Are not unduly correlatable.
Holders
ought to be warned by their software if it detects that
bearer credentials
containing sensitive information have been issued or requested, or that a
correlation risk is posed by the combination of two or more
bearer credentials
across one
or more sessions. While detecting all correlation risks might be impossible,
some might certainly be detectable.
Verifiers
ought not request
bearer credentials
known to carry
information which can be used to illicitly correlate the
holder
This section is non-normative.
When processing
verifiable credentials
verifiers
evaluate relevant
claims
before relying upon them. This
evaluation might be done in any manner desired as long as it satisfies
the requirements of the
verifier
doing the validation.
Many verifiers will perform the checks listed in Appendix
A.
Validation
as
well as a variety of specific business process checks such as:
The professional licensure status of the
holder
A date of license renewal or revocation.
The sub-qualifications of an individual.
If a relationship exists between the
holder
and the
entity
with whom the
holder
is attempting to interact.
The geolocation information associated with the
holder
The process of performing these checks might result in information leakage that
leads to a privacy violation of the
holder
. For example, a simple
operation, such as checking an improperly configured revocation list, can
notify the
issuer
that a specific business is likely interacting
with the
holder
. This could
enable
issuers
to collude to correlate individuals without their
knowledge.
Issuers
are urged to not use mechanisms, such as
credential
revocation lists that are unique per
credential
, during the
verification
process, which could lead to privacy violations. Organizations
providing software to
holders
ought to warn when
credentials
include
information that could lead to privacy violations during the verification
process.
Verifiers
are urged to consider rejecting
credentials
that
produce privacy violations or that enable substandard privacy practices.
This section is non-normative.
When a
holder
receives a
verifiable credential
from an
issuer
, the
verifiable credential
needs to be stored somewhere
(for example, in a
credential repository
).
Holders
need to be aware
that the information in a
verifiable credential
can be sensitive and highly
individualized, making it a prime target for data mining. Services offering
"free of charge" storage of
verifiable credentials
might mine personal data
and sell it to organizations interesting in building individualized profiles
on people and organizations.
Holders
need to be aware of the terms of service for their
credential repository
, specifically the correlation and data mining
protections in place for those who store their
verifiable credentials
with the service provider.
Some effective mitigations for data mining and profiling include using:
Service providers that do not sell your information to third parties.
Software that encrypts
verifiable credentials
such that a service
provider cannot view the contents of the
credential
Software that stores
verifiable credentials
locally on a device that you
control and that does not upload or analyze your information beyond your
expectations.
In addition to the mitigations above, civil society and regulatory
participation in vendor analysis and auditing can help ensure that legal
protections are enacted and enforced for individuals affected by practices
that are not aligned with their best interests.
This section is non-normative.
Having two pieces of information about the same
subject
often reveals
more about the
subject
than the combination of those two pieces, even
when the pieces are delivered through different channels. Aggregating
verifiable credentials
poses a privacy risk, and all participants in
the ecosystem need to be aware of the risks of data aggregation.
For example, suppose two
bearer credentials
, one for an email address and
one stating the
holder
is over 21, are provided to the same
verifier
across multiple sessions. The
verifier
of the information now has a unique
identifier (the email address) along with age-related ("over 21") information
for that individual. It is now easy to create a profile for the
holder
building it by adding more and more information as it leaks over time.
Aggregation of such
credentials
can also be performed by multiple sites
in collusion with each other, leading to privacy violations.
From a technological perspective, preventing information aggregation is a
challenging privacy problem. While new cryptographic techniques, such as
zero-knowledge proofs, are being proposed as solutions to aggregation and
correlation issues, the existence of long-lived identifiers and
browser-tracking techniques defeats even the most modern cryptographic
techniques.
The solution to the privacy implications of correlation or aggregation tends
not to be technological in nature, but policy-driven instead. Therefore, if a
holder
wishes to avoid the aggregation of their information, they need to
express this in the
verifiable presentations
they transmit, and
by the
holders
and
verifiers
to whom they transmit their
verifiable presentations
This section is non-normative.
Despite best efforts by all involved to assure privacy, using
verifiable credentials
can potentially lead to de-anonymization and a
loss of privacy. This correlation can occur when any of the following occurs:
The same
verifiable credential
is presented to the same
verifier
more than once. The
verifier
could infer that the
holder
is the
same individual.
The same
verifiable credential
is presented to different
verifiers
, and either those
verifiers
collude, or a third party
has access to transaction records from both
verifiers
. An observant
party could infer that the individual presenting the
verifiable credential
is the same person at both services. That is, the
same person controls both accounts.
subject
identifier of a
credential
refers to the same
subject
across multiple
presentations
or
verifiers
. Even
when different
credentials
are presented, if the
subject
identifier is the same,
verifiers
(and those with access to
verifier
logs) could infer that the
credentials
subjects
are the same entity.
The underlying information in a
credential
can be used to identify an
individual across services. In this case, using information from other sources
(including information provided directly by the
holder
),
verifiers
can use information inside the
credential
to correlate the individual
with an existing profile. For example, if a
holder
presents
credentials
that include postal code, age, and gender, a
verifier
can potentially correlate the
subject
of that
credential
with an
established profile. For more information, see [
DEMOGRAPHICS
].
Passing the identifier of a
credential
to a centralized revocation server.
The centralized server can correlate uses of the
credential
across
interactions. For example, if a
credential
is used to prove age in this
manner, the centralized service could know everywhere that
credential
was
presented (all liquor stores, bars, adult stores, lottery sellers, and so on).
In part, it is possible to mitigate this de-anonymization and loss of privacy
by:
The
holder
software providing a globally-unique identifier as the
subject
for any given
verifiable credential
and never reusing that
verifiable credential
The
issuer
using a globally-distributed service for revocation such that
it is not contacted when revocation checks are performed.
Specification authors designing revocation mechanisms that do not depend on
submitting a unique identifier for a
verifiable credential
to a query API,
and instead use, for example, a privacy-preserving revocation list.
Issuers
avoiding the association of personally identifiable information
with any specific long-lived
subject
identifier.
Unfortunately, these mitigation techniques are only sometimes practical or
even compatible with necessary use. Sometimes, correlation is a requirement.
For example, in some prescription drug monitoring programs, monitoring prescription
use 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 prescription
use overrides individual privacy concerns.
Verifiable credentials
will also be used to intentionally correlate
individuals across services. For example, when using a common persona to log in
to multiple services, 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 violations related to the use of
verifiable credentials
occur when
unintended or unexpected correlation arises from the presentation of those
verifiable credentials
This section is non-normative.
Legal processes can compel
issuers
holders
, and
verifiers
to
disclose private information to authorities, such as law enforcement. It is
also possible for the same private information to be accidentally disclosed
to an unauthorized party through a software bug or security failure. Authors
of legal processes and compliance regimes are advised to draft guidelines that
require notifying the
subjects
involved when their private information is
intentionally or accidentally disclosed to a third party. Providers of software
services are advised to be transparent about known circumstances that might
cause such private information to be shared with a third party, as well as the
identity of any such third party.
This section is non-normative.
When a
holder
chooses to share information with a
verifier
, it
might be the case that the
verifier
is acting in bad faith and requests
information that could harm the
holder
. For example, a
verifier
might ask for a bank account number, which could then be used
with other information to defraud the
holder
or the bank.
Issuers
ought to strive to tokenize as much information as possible so
that if a
holder
accidentally transmits
credentials
to the wrong
verifier
, the situation is not catastrophic.
For example, instead of including a bank account number to check
an individual's bank balance, provide a token that enables the
verifier
to check if the balance is above a certain amount. In this
case, the bank could issue a
verifiable credential
containing a balance
checking token to a
holder
. The
holder
would then include the
verifiable credential
in a
verifiable presentation
and bind the
token to a credit checking agency using a digital signature. The
verifier
could then wrap the
verifiable presentation
in their
digital signature and hand it back to the issuer to check the
account balance dynamically.
Using this approach, even if a
holder
shares the account balance token
with the wrong party, an attacker cannot discover the bank account number or
the exact value of the account. Also, given the validity period of the
counter-signature, the attacker gains access to the token for only a
few minutes.
This section is non-normative.
The data expressed in
verifiable credentials
and
verifiable presentations
are valuable since they contain authentic
statements made by trusted third parties (such as
issuers
) or
individuals (such as
holders
or
subjects
). The storage and
accessibility of this data can inadvertently create honeypots of
sensitive data for malicious actors. These adversaries often seek to
exploit such reservoirs of sensitive information, aiming to
acquire and exchange that data for financial gain.
Issuers
are advised to retain the minimum amount of data
necessary to issue
verifiable credentials
to
holders
and
to manage the status and revocation of those credentials. Similarly,
issuers
are advised to avoid creating publicly
accessible credentials that include personally identifiable information
(PII) or other sensitive data. Software implementers are advised
to safeguard
verifiable credentials
using robust consent
and access control measures, ensuring that they remain
inaccessible to unauthorized entities.
Holders
are advised to use implementations that appropriately
encrypt their data in transit and at rest and protect sensitive
material (such as cryptographic secrets) in ways that cannot be easily
extracted from hardware or other devices. It is further suggested that
holders
store and manipulate their data only on devices they
control, away from centralized systems, to reduce the likelihood of
an attack on their data or inclusion in a large-scale theft if an attack is
successful. Furthermore,
holders
are encouraged to rigorously control
access to their credentials and presentations, allowing access only to those
with explicit authorization.
Verifiers
are advised to ask only for data necessary for a particular
transaction and to retain no data beyond the needs of any particular
transaction.
Regulators are advised to reconsider existing audit requirements such that
mechanisms that better preserve privacy can be used to achieve similar
enforcement and audit capabilities. For example, audit-focused regulations
that insist on the collection and long-term retention of personally
identifiable information can cause harm to individuals and organizations
if that same information is later compromised and accessed by an attacker.
The technologies described by this specification enable
holders
to
prove properties about themselves and others more readily, reducing the
need for long-term data retention by
verifiers
. Alternatives include
keeping logs that the information was collected and checked, as well as
random tests to ensure that compliance regimes are operating as expected.
This section is non-normative.
As detailed in Section
8.14
Patterns of Use
, patterns of use can be
correlated with certain types of behavior. This correlation is partially
mitigated when a
holder
uses a
verifiable credential
without the
knowledge of the
issuer
Issuers
can defeat this protection
however, by making their
verifiable credentials
short lived and renewal
automatic.
For example, an
ageOver
verifiable credential
is helpful in
gaining access to a bar. If an
issuer
issues such a
verifiable credential
with a very short validity period and an automatic
renewal mechanism, then the
issuer
could correlate the
holder's
behavior in a way that negatively impacts the
holder
Organizations providing software to
holders
ought to warn them if they
repeatedly use
credentials
with short lifespans, which could result in
behavior correlation.
Issuers
ought to avoid issuing
credentials
that
enable them to correlate patterns of use.
This section is non-normative.
An ideal privacy-respecting system would require only the information necessary
for interaction with the
verifier
to be disclosed by the
holder
The
verifier
then records that the disclosure requirement has been met
and discards any sensitive information disclosed. In many cases,
competing priorities, such as regulatory burden, prevent this ideal system from
being employed. In other instances, long-lived identifiers prevent single use.
The designer of any
verifiable credentials
ecosystem ought to strive
to make it as privacy-respecting as possible by preferring single-use
verifiable credentials
whenever possible.
Using single-use
verifiable credentials
provides several benefits. The
first benefit is to
verifiers
who can be sure that the data in a
verifiable credential
is fresh. The second benefit is to
holders
who know that if there are no long-lived identifiers in the
verifiable credential
, the
verifiable credential
itself cannot be
used to track or correlate them online. Finally, there is nothing for attackers
to steal, making the entire ecosystem safer to operate within.
This section is non-normative.
In an ideal private browsing scenario, no PII will be revealed. Because many
credentials
include PII, organizations providing software to
holders
ought to warn them about the possibility of this information
being revealed if they use
credentials
and
presentations
while in
private browsing mode. As each browser vendor handles private browsing
differently, and some browsers might not have this feature, it is
important that implementers not depend on private browsing mode to provide
any privacy protections. Instead, implementers are advised to rely on
tooling that directly usable by their software to provide privacy guarantees.
This section is non-normative.
Verifiable credentials
rely on a high degree of trust in
issuers
The degree to which a
holder
might take advantage of possible privacy
protections often depends strongly on the support an
issuer
provides for
such features. In many cases, privacy protections which make use of
zero-knowledge proofs, data minimization techniques, bearer credentials,
abstract claims, and protections against signature-based correlation require
active support by the
issuer
, who need to incorporate those capabilities
into the
verifiable credentials
they issue.
It is crucial to note that
holders
not only depend on
issuer
participation to provide
verifiable credential
capabilities that help
preserve
holder
and
subject
privacy, but also rely on
issuers
to
not deliberately subvert these privacy protections. For example, an
issuer
might sign
verifiable credentials
using a signature scheme
that protects against signature-based correlation. This would protect the
holder
from being correlated by the signature value as it is shared among
verifiers
. However, if the
issuer
creates a unique key for each
issued
credential
, it might be possible for the
issuer
to track
presentations
of the
credential
, regardless of a
verifier's
inability to do so.
In addition to previously described privacy protections an
issuer
might
offer,
issuers
need to be aware of data they leak that is associated with
identifiers and claim types they use when issuing
credentials
. One
example of this would be an
issuer
issuing driver's licenses which reveal
both the location(s) in which they have jurisdiction and the location of the
subject's
residence.
Verifiers
might take advantage of this by
requesting a
credential
to check that the
subject
is licensed to
drive when, in fact, they are interested in metadata
about
the
credential, such as which
issuer
issued the credential, and tangential
information that might have been leaked by the
issuer
, such as the
subject's
home address. To mitigate such leakage,
issuers
might
use common identifiers to mask specific location information or other sensitive
metadata; for example, a shared
issuer
identifier at a state or national
level instead of at the level of a county, city, town, or other smaller
municipality. Further,
verifiers
can use
holder
attestation mechanisms
to preserve privacy, by providing proof that an
issuer
exists in a set of
trusted entities without needing to disclose the exact
issuer
This section is non-normative.
Issuers
holders
, and
verifiers
should be aware of a number of
security considerations when processing data described by this specification.
Ignoring or not understanding the implications of this section can result in
security vulnerabilities.
While this section highlights a broad set of security considerations, it is a
partial list. Implementers of mission-critical systems using the technology
described in this specification are strongly encouraged to consult security and
cryptography professionals for comprehensive guidance.
This section is non-normative.
Cryptography can protect some aspects of the data model described in this
specification. It is important for implementers to understand the cryptography
suites and libraries used to create and process
credentials
and
presentations
. Implementing and auditing cryptography systems generally
requires substantial experience. Effective
red teaming
can also
help remove bias from security reviews.
Cryptography suites and libraries have a shelf life and eventually succumb to
new attacks and technological advances. Production quality systems need to take
this into account and ensure mechanisms exist to easily and proactively upgrade
expired or broken cryptography suites and libraries, and to invalidate and
replace existing
credentials
. Regular monitoring is important to
ensure the long term viability of systems processing
credentials
This section is non-normative.
The security of most digital signature algorithms, used to secure
verifiable credentials
and
verifiable presentations
, depends on the quality and
protection of their
private signing keys
. The management of
cryptographic keys encompasses a vast and complex field. For comprehensive
recommendations and in-depth discussion, readers are directed to
NIST-SP-800-57-Part-1
]. As strongly recommended in both [
FIPS-186-5
] and
NIST-SP-800-57-Part-1
], a private signing key is not to be used for multiple
purposes; for example, a private signing key is not to be used for encryption
as well as signing.
NIST-SP-800-57-Part-1
] strongly advises that private signing keys and
public verification keys
have limited
cryptoperiods
, where
cryptoperiod
is "the time span during which a specific key is
authorized for use by legitimate entities or the keys for a given system will
remain in effect." [
NIST-SP-800-57-Part-1
] gives extensive
guidance on cryptoperiods for different key types under various conditions
and recommends a one to three year cryptoperiod for a private signing key.
To deal with potential private key compromises, [
NIST-SP-800-57-Part-1
provides recommendations for protective measures, harm reduction, and
revocation. Although this section focuses primarily on the security of the
private signing key, [
NIST-SP-800-57-Part-1
] also highly recommends
confirmation of the validity of all
verification material
before using it.
This section is non-normative.
Verifiable credentials
often contain URLs to data that resides outside
the
verifiable credential
. Linked content that exists outside a
verifiable credential
— such as images, JSON-LD extension contexts,
JSON Schemas, and other machine-readable data — is not protected
against tampering because the data resides outside of the protection of the
securing mechanism
on the
verifiable credential
Section
5.3
Integrity of Related Resources
of this specification provides an
optional mechanism for ensuring the integrity of the content of external
resources. This mechanism is not necessary for external resources that do not
impact the
verifiable credential
's security. However, its implementation
is crucial for external resources where content changes could potentially
introduce security vulnerabilities.
Implementers need to recognize the potential security risks associated with
unprotected URLs of external machine-readable content. Such vulnerabilities
could lead to successful attacks on their applications. Where changes to
external resources might compromise security, implementers will benefit by
employing the content integrity protection mechanism outlined in this
specification.
This section is non-normative.
This specification enables the creation of
credentials
without signatures
or proofs. These
credential
classes are often useful for intermediate
storage or self-asserted information, analogous to filling out a form on a web
page. Implementers ought to be aware that these
credential
types are not
verifiable
because the authorship either is unknown or cannot be trusted.
This section is non-normative.
The data model does not inherently prevent
Man-in-the-Middle (MITM)
replay
, and
spoofing
attacks.
Both online and offline use cases might be susceptible to these attacks, where
an adversary intercepts, modifies, re-uses, and/or replicates the
verifiable credential
data during transmission or storage.
This section is non-normative.
It is considered best practice for
issuers
to atomize information in a
credential
or use a signature scheme that allows for selective
disclosure. When atomizing information, if it is not done securely by the
issuers
, the
holders
might bundle together
claims
from different
credentials
in ways that the
issuers
did not intend.
Consider a university issuing two
verifiable credentials
to an individual.
Each
credential
contains two properties that, when combined, indicate the
person's "role" in a specific "department." For instance, one
credential
pair might designate "Staff Member" in the "Department of Computing," while
another could signify "Post Graduate Student" in the "Department of Economics."
Atomizing these
verifiable credentials
results in the university issuing
four separate
credentials
to the individual. Each
credential
contains
a single designation: "Staff Member", "Post Graduate Student", "Department of
Computing", or "Department of Economics". The
holder
might then present
the "Staff Member" and "Department of Economics"
verifiable credentials
to
verifier
, which, together, would comprise a false
claim
This section is non-normative.
When
verifiable credentials
contain highly dynamic information, careful
consideration of validity periods becomes crucial. Issuing
verifiable credentials
with validity periods that extend beyond their intended use creates
potential security vulnerabilities that malicious actors could exploit. Validity
periods shorter than the timeframe where the information expressed by the
verifiable credential
is expected to be used creates a burden on
holders
and
verifiers
. It is, therefore, important to set validity
periods for
verifiable credentials
appropriate to the use case and the
expected lifetime of the information contained in the
verifiable credential
This section is non-normative.
Storing
verifiable credentials
on a device poses risks if the device is
lost or stolen. An attacker gaining possession of such a device potentially
acquires unauthorized access to systems using the victim's
verifiable credentials
. Ways to mitigate this type of attack include:
Enabling password, pin, pattern, or biometric screen unlock protection on the
device.
Enabling password, biometric, or multi-factor authentication for the
credential repository
Enabling password, biometric, or multi-factor authentication when accessing
cryptographic keys.
Using a separate hardware-based signature device.
All or any combination of the above.
Furthermore, instances of impersonation can manifest in various forms,
including situations where an
entity
attempts to disavow its actions.
Elevating trust and security within the realm of
verifiable credentials
entails more than averting impersonation; it also involves implementing
non-repudiation mechanisms. These mechanisms solidify an
entity's
responsibility for its actions or transactions, reinforcing accountability and
deterring malicious behavior. Attainment of non-repudiation is a
multifaceted endeavor, encompassing an array of techniques including
securing mechanisms
, proofs of possession,
and authentication schemes in various protocols designed to foster trust and
reliability.
This section is non-normative.
Ensuring alignment between an
entity's
actions — such as
presentation
and the intended purpose of those actions — is essential. It involves having the
authorization to use
verifiable credentials
and using
credentials
in a
manner that adheres to their designated scope(s) and objective(s). Two critical
aspects in this context are
Unauthorized Use
and
Inappropriate Use
Entities using
verifiable credentials
and
verifiable presentations
beyond their intended purpose are engaging in unauthorized activity. One class
of unauthorized use is a
confidentiality violation
. Consider a
holder
that shares a
verifiable presentation
with a
verifier
to establish their age and residency status. If the
verifier
then proceeds
to employ the
holder's
data without proper consent, such as by selling the
data to a data broker, that would constitute an unauthorized use of the data,
violating an expectation of privacy that the
holder
might have in the
transaction.
Similarly, an
issuer
can employ a
property to specify how and when a
holder
might be permitted and expected
to use a
credential
. A
holder
using
credentials
outside of the
scope(s) defined in the
would be considered to be unauthorized.
Note
: Digital Rights Management is out of scope
Further study is required to determine how a
holder
can assert and
enforce authorized use of their data after
presentation
While valid cryptographic signatures and successful status checks signify the
reliability of
credentials
, they do not signify that all
credentials
are interchangeable for all contexts. It is crucial that
verifiers
also
validate
any relevant
claims
considering the source and nature of the
claim
alongside the purpose
for which the
holder
presents the
credential
For instance, in scenarios where a certified medical diagnosis is required, a
self-asserted
credential
carrying the necessary data might not suffice
because it lacks validity from an authoritative medical source. To ensure proper
credential
use, stakeholders need to assess the
credential's
relevance and authority within the
specific context of their intended application.
This section is non-normative.
Data in
verifiable credentials
can include injectable code or code from
scripting languages. Authors of
verifiable credentials
benefit from avoiding
such inclusions unless necessary and only after mitigating associated risks to
the fullest extent possible.
For example, a single natural language string containing multiple languages or
annotations often requires additional structure or markup for correct
presentation. Markup languages, such as HTML, can label text spans in different
languages or supply string-internal markup needed to display
bidirectional text
properly. It is also possible to use the
rdf:HTML
datatype to encode
such values accurately in JSON-LD.
Despite the ability to encode information as HTML, implementers are strongly
discouraged from doing so for the following reasons:
It requires some version of an HTML processor, which increases the burden of
processing language and base direction information.
It increases the security attack surface when using this data model,
because naively processing HTML could result in the execution of a
script
tag that an attacker injected at some point during the data production process.
If implementers feel they need to use HTML, or other markup languages capable of
containing executable scripts, to address a specific use case, they are advised
to analyze how an attacker could use the markup to mount injection attacks
against a consumer of the markup. This analysis should be followed by the
proactive deployment of mitigations against the identified attacks, such as
running the HTML rendering engine in a sandbox with no ability to access the
network.
This section is non-normative.
While this specification does not provide conformance criteria for the process
of the
validation
of
verifiable credentials
or
verifiable presentations
, readers might be curious about how the
information in this data model is expected to be used by
verifiers
during the process of
validation
. This section captures a selection of
conversations held by the Working Group related to the expected use of the
properties in this specification by
verifiers
This section is non-normative.
The value associated with the
issuer
property
identifies an
issuer
to the
verifier
Metadata related to the
issuer
property
is available to the
verifier
through the
verification
algorithm
as defined in Section
7.1
Verification
This metadata includes identification of the verified controller of the
verification method used by the securing mechanism to secure each
verifiable credential
or
verifiable presentation
, of which the controller is
typically the respective
issuer
or
holder
Some ecosystems might have more complex relationships between
issuers
and controllers of verification methods and might use lists of verified
issuers in addition to, or instead of, the mapping described above.
This section is non-normative.
The value associated with the
holder
property
is used to identify the
holder
to the
verifier
Often relevant metadata about the
holder
, as identified by the value of
the
holder
property
, is available to, or retrievable by, the
verifier
. For example, a
holder
can publish information containing
the
verification material
used to secure
verifiable presentations
. This
metadata is used when checking proofs on
verifiable presentations
Some cryptographic identifiers contain all necessary metadata in the identifier
itself. In those cases, no additional metadata is required. Other identifiers
use verifiable data registries where such metadata is automatically published
for use by
verifiers
, without any additional action by the
holder
See the
Verifiable Credentials Implementation Guidelines 1.0
and
Verifiable Credentials Use Cases
for additional examples related to
subject
and
holder
Note
: Validation is the process of applying business rules
Validation is the process by which verifiers apply business rules to
evaluate the propriety of a particular use of a
verifiable credential
verifier
might need to validate a given
verifiable presentation
against complex business rules; for example, the verifier might need confidence
that the
holder
is the same entity as a
subject
of a
verifiable credential
. In such a situation, the following factors can provide a
verifier
with reasonable confidence that the claims expressed regarding
that identifier, in included
verifiable credentials
, are, in fact, about
the current presenter:
This section is non-normative.
The
validFrom
is expected to be within an expected range for the
verifier
. For example, a
verifier
can check that the start of
the validity period for a
verifiable credential
is not in the future.
This section is non-normative.
The securing mechanism used to prove that the information in a
verifiable credential
or
verifiable presentation
was not tampered with is called a
cryptographic proof
. There are many types of cryptographic proofs
including, but not limited to, digital signatures and zero-knowledge proofs. In
general, when verifying cryptographic proofs, implementations are expected to
ensure:
The cryptographic proof is available in a form defined by a known cryptographic
suite.
All required cryptographic proof
properties
are present.
The cryptographic proof
verification
algorithm, when applied to the data,
results in an accepted cryptographic proof.
In general, when verifying digital signatures, implementations are expected to
ensure:
Acceptably recent metadata regarding the
verification material
associated
with the signature is available. For example, if the
verification material
is a cryptographic public key, the metadata might include
properties
related
to the validity period, the controller, or the authorized purpose, such as
authentication or encryption, of the cryptographic public key.
The public key is not suspended, revoked, or expired.
The digital signature verifies.
Any additional requirements defined by the securing mechanism are satisfied.
This section is non-normative.
The
verifier
expects that the
validFrom
and
validUntil
properties will be within a certain range. For example,
verifier
can check that the end of the validity period of a
verifiable credential
is not in the past. Because some credentials can be
useful for secondary purposes even if their original validity period has
expired, validity period, as expressed using the
validFrom
and
validUntil
properties, is always considered a component of
validation, which is performed
after
verification.
This section is non-normative.
If the
credentialSchema
property is available, the schema of a
verifiable credential
is expected to be evaluated by the
verifier
according to the
credentialSchema
type
definition for the
verifiable credential
and the
verifier's
own schema evaluation
criteria. For example, if the
credentialSchema
's
type
value is [
VC-JSON-SCHEMA
], then a
verifier
can ensure a credential's
data is valid against the given JSON Schema.
This section is non-normative.
Fitness for purpose is about whether the custom
properties
in the
verifiable credential
are appropriate for the
verifier's
purpose.
For example, if a
verifier
needs to determine whether a
subject
is
older than 21 years of age, they might rely on a specific
birthdate
property
, or on more abstract
properties
, such as
ageOver
The
issuer
is trusted by the
verifier
to make the
claims
at
hand. For example, a franchised fast food restaurant location trusts the
discount coupon
claims
made by the corporate headquarters of the
franchise. Policy information expressed by the
issuer
in the
verifiable credential
should be respected by
holders
and
verifiers
unless they accept the liability of ignoring the policy.
This section is non-normative.
Systems using what is today commonly referred to as "artificial intelligence"
and/or "machine learning" might be capable of performing complex tasks at a
level that meets or exceeds human performance. This might include tasks such as
the acquisition and use of
verifiable credentials
. Using such tasks to
distinguish between human and automated "bot" activity, as is commonly done
today with a
CAPTCHA
for instance, might thereby cease to provide adequate or acceptable protection.
Implementers of security architectures that use
verifiable credentials
and/or perform validation on their content are urged to consider the existence
of machine-based actors, such as those which are today commonly referred to as
"artificial intelligence", that might legitimately hold
verifiable credentials
for use in interactions with other systems. Implementers might
also consider how threat actors could couple such "artificial intelligence"
systems with
verifiable credentials
to pose as humans when interacting with
their systems. Such systems might include, but not be limited to, global
infrastructure such as social media, election, energy distribution, supply
chain, and autonomous vehicle systems.
Implementations
MUST
treat the base context value, located at
, as already retrieved;
the following value is the hexadecimal encoded SHA2-256 digest value of the base
context file:
59955ced6697d61e03f2b2556febe5308ab16842846f5b586d7f1f7adec92734
. It is possible to confirm
the cryptographic digest above by running the following command from a modern
Unix command interface line:
curl -s https://www.w3.org/ns/credentials/v2 | openssl dgst -sha256
It is strongly advised that all JSON-LD Context URLs used by an
application use the same mechanism, or a functionally equivalent mechanism,
to ensure end-to-end security. Implementations are expected to throw errors
if a cryptographic hash value for a resource does not match the expected hash
value.
Implementations that apply the base context above, as well as other contexts
and values in any
@context
property, during operations such as
JSON-LD Expansion
or
transformation to RDF
, are expected to do so without experiencing any
errors. If such operations are performed and result in an error,
the
verifiable credential
or
verifiable presentation
MUST
result
in a verification failure.
Note
: See errata if hash value changes are detected
It is extremely unlikely that the files that have associated cryptographic hash
values in this specification will change. However, if critical errata are
found in the specification and corrections are required to ensure
ecosystem stability, the cryptographic hash values might change. As such, the
HTTP cache times for the files are not set to infinity and implementers are
advised to check for errata if a cryptographic hash value change is detected.
This section serves as a reminder of the importance of ensuring that, when
verifying
verifiable credentials
and
verifiable presentations
, the
verifier
has information that is consistent with what the
issuer
or
holder
had when securing the
credential
or
presentation
This information might include at least:
The contents of the credential itself, which are secured in
verifiable credentials
and
verifiable presentations
by using
securing mechanisms. See Section
4.12
Securing Mechanisms
for further
information.
The content in a credential whose meaning depends on a link to an external URL,
such as a JSON-LD Context, which can be secured by using a local static copy
or a cryptographic digest of the file. See Section
5.3
Integrity of Related Resources
for more details.
Verifiers
are warned that other data that is referenced from within a
credential
, such as resources that are linked to via URLs, are not
cryptographically protected by default. It is considered a best practice to
ensure that the same sorts of protections are provided for any URL that is
critical to the security of the
verifiable credential
through the use of
permanently cached files and/or cryptographic hashes. Ultimately, knowing the
cryptographic digest of any linked external content enables a
verifier
to
confirm that the content is the same as what the
issuer
or
holder
intended.
Implementations that depend on RDF vocabulary processing
MUST
ensure that the
following vocabulary URLs used in the base context ultimately resolve to the
following files when loading the JSON-LD serializations, which are normative.
Other semantically equivalent serializations of the vocabulary files
MAY
be used
by implementations. A cryptographic hash is provided for each JSON-LD document
to ensure that developers can verify that the content of each file is correct.
JSON-LD Documents and Hashes
URL:
Resolved Document:
SHA2-256 Digest:
9db03c54d69a8ec3944f10770e342b33e58a79045c957c35d51285976fc467c4
URL:
Resolved Document:
SHA2-256 Digest:
689af6f393b55c9b35c37cfad59d13cc421e0c89ce97cf0e8234f9b4a3074104
It is possible to confirm the cryptographic digests listed above by running
a command like the following, replacing

with the appropriate value, through a modern UNIX-like OS command line interface:
curl -sL -H "Accept: application/ld+json" | openssl dgst -sha256
Note
: schema.org changes regularly, but is considered stable
Implementers and document authors might note that cryptographic digests for
schema.org
are not provided. This is because the
schema.org
vocabulary
undergoes regular changes; any digest provided would be out of date within
weeks of publication. The Working Group discussed this concern and concluded
that the vocabulary terms from
schema.org
, that are used by this
specification, have been stable for years and are highly unlikely to change in
their semantic meaning.
The following base classes are defined in this specification for processors
and other specifications that benefit from such definitions:
Base Class
Purpose
CredentialEvidence
Serves as a superclass for specific evidence types that are placed into the
evidence
property.
CredentialSchema
Serves as a superclass for specific schema types that are placed into the
credentialSchema
property.
CredentialStatus
Serves as a superclass for specific credential status types that are placed into
the
credentialStatus
property.
ConfidenceMethod
Serves as a superclass for specific confidence method types that are placed into
the
confidenceMethod
property.
RefreshService
Serves as a superclass for specific refresh service types that are placed into
the
credentialRefresh
property.
RenderMethod
Serves as a superclass for specific render method types that are placed into
the
renderMethod
property.
Serves as a superclass for specific terms of use types that are placed into
the
property.
This section defines datatypes that are used by this specification.
The
sriString
datatype is associated with a value to provide the integrity
information for a resource using the method specified in the
Subresource Integrity
specification. The
sriString
datatype is defined as follows:
The URL denoting this datatype
The lexical space
See the
ABNF
grammar
, defining the
integrity
attribute in the [
SRI
] specification,
for the restrictions on the string format.
The value space
A (possibly empty) list of
(alg,val)
pairs, where
alg
identifies a
hash function, and
val
is an integer as a standard mathematical concept.
The lexical-to-value mapping
Any element of the lexical space is mapped to the value space by following the
parse metadata algorithm
based on the
ABNF
grammar
in the [
SRI
] specification.
The canonical mapping
The canonical mapping consists of the lexical-to-value mapping.
This section is non-normative.
The
verifiable credential
and
verifiable presentation
data models
leverage a variety of underlying technologies including [
JSON-LD11
] and
VC-JSON-SCHEMA
]. This section will provide a comparison of the
@context
type
, and
credentialSchema
properties, and cover some of the more specific use cases where it is possible
to use these features of the data model.
The
type
property is used to uniquely identify the type of the
verifiable credential
in which it appears, that is, to indicate which set of
claims the
verifiable credential
contains. This property, and the value
VerifiableCredential
within the set of its values, are mandatory.
Whilst it is good practice to include one additional value depicting the unique
subtype of this
verifiable credential
, it is permitted to either omit or
include additional type values in the array. Many verifiers will request a
verifiable credential
of a specific subtype, then omitting the subtype
value could make it more difficult for verifiers to inform the holder which
verifiable credential
they require. When a
verifiable credential
has multiple subtypes, listing all of them in the
type
property is sensible. The use of the
type
property in a
JSON-LD11
] representation of a
verifiable credential
enables to enforce
the semantics of the
verifiable credential
because the machine is able to
check the semantics. With [
JSON-LD11
], the technology is not only describing the
categorization of the set of claims, the technology is also conveying the
structure and semantics of the sub-graph of the properties in the graph. In
JSON-LD11
], this represents the type of the node in the graph which is why some
JSON-LD11
] representations of a
verifiable credential
will use the
type
property on many objects in the
verifiable credential
The primary purpose of the
@context
property, from a [
JSON-LD11
perspective, is to convey the meaning of the data and term definitions of the
data in a
verifiable credential
, in a machine-readable way. The
@context
property is used to map the globally unique URLs for
properties in
verifiable credentials
and
verifiable presentations
into short-form alias names, making [
JSON-LD11
] representations more
human-friendly to read. From a [
JSON-LD11
] perspective, this mapping also allows
the data in a
credential
to be modeled in a network of machine-readable
data, by enhancing how the data in the
verifiable credential
or
verifiable presentation
relates to a larger machine-readable data graph.
This is useful for telling machines how to relate the meaning of data to other
data in an ecosystem where parties are unable to coordinate. This property, with
the first value in the set being
, is mandatory.
Since the
@context
property is used to map data to a graph
data model, and the
type
property in [
JSON-LD11
] is used to
describe nodes within the graph, the
type
property becomes
even more important when using the two properties in combination. For example,
if the
type
property is not included within the resolved
@context
resource using [
JSON-LD11
], it could lead to claims being
dropped and/or their integrity no longer being protected during production and
consumption of the
verifiable credential
. Alternatively, it could lead to
errors being raised during production or consumption of a
verifiable credential
. This will depend on the design choices of the implementation and
both paths are used in implementations today, so it's important to pay attention
to these properties when using a [
JSON-LD11
] representation of a
verifiable credential
or
verifiable presentation
The primary purpose of the
credentialSchema
property is to define
the structure of the
verifiable credential
, and the datatypes for the
values of each property that appears. A
credentialSchema
is useful
for defining the contents and structure of a set of claims in a
verifiable credential
, whereas [
JSON-LD11
] and a
@context
in a
verifiable credential
are best used only for conveying the semantics and
term definitions of the data, and can be used to define the structure of the
verifiable credential
as well.
While it is possible to use some [
JSON-LD11
] features to allude to the
contents of the
verifiable credential
, it's not generally suggested to use
@context
to constrain the data types of the data model. For example,
"@type": "@json"
is useful for leaving the semantics open-ended and not
strictly defined. This can be dangerous if the implementer is looking to
constrain the data type of the claims in the
credential
, and is expected
not to be used.
When the
credentialSchema
and
@context
properties
are used in combination, both producers and consumers can be more confident
about the expected contents and data types of the
verifiable credential
and
verifiable presentation
This section is non-normative.
The Working Group thanks the following individuals not only for their
contributions toward the content of this document, but also for yeoman's work
in this standards community that drove changes, discussion, and consensus among
a sea of varied opinions: David Chadwick, Dave Longley, Ted Thibodeau Jr.,
Brent Zundel, Ivan Herman, Joe Andrieu, and Gabe Cohen.
Work on this specification has been supported by the Rebooting the Web of Trust
community facilitated by Christopher Allen, Shannon Appelcline, Kiara Robles,
Brian Weller, Betty Dhamers, Kaliya Young, Manu Sporny, Drummond Reed, Joe
Andrieu, Heather Vescent, Kim Hamilton Duffy, Samantha Chase, Andrew Hughes,
Will Abramson, Erica Connell, Eric Schuh, Zaïda Rivai, and Shigeya Suzuki.
The participants in the Internet Identity Workshop, facilitated by Phil Windley,
Kaliya Young, Doc Searls, and Heidi Nobantu Saul, also supported the refinement
of this work through numerous working sessions designed to educate about,
debate on, and improve this specification.
The Working Group also thanks our Working Group Chairs, Dan Burnett, Matt Stone,
Brent Zundel, Wayne Chang, and Kristina Yasuda, as well as our
W3C
Staff
Contacts, Kazuyuki Ashimura and Ivan Herman, for their expert management and
steady guidance of the group through multiple
W3C
standardization cycles. We
also thank the Chairs of the
W3C
Credentials Community Group, Christopher Allen,
Joe Andrieu, Kim Hamilton Duffy, Heather Vescent, Wayne Chang, Mike Prorock,
Harrison Tang, Kimberly Wilson Linson, and Will Abramson, who oversaw the
incubation of a number of work items that were incorporated into this
specification.
Portions of the work on this specification have been funded by the United States
Department of Homeland Security's Science and Technology Directorate under
contracts HSHQDC-17-C-00019, 70RSAT20T00000010/P00001, 70RSAT20T00000029,
70RSAT21T00000016/P00001, 70RSAT23T00000005, 70RSAT23C00000030,
70RSAT23R00000006, 70RSAT24T00000014, 70RSAT22T00000001, and the National
Science Foundation under NSF 22-572. The content of this specification does not
necessarily reflect the position or the policy of the U.S. Government and no
official endorsement should be inferred.
The Working Group would like to thank the following individuals for reviewing
and providing feedback on the specification (in alphabetical order by first
name or their Github handle if a name was not provided):
Abhishek Mahadevan Raju,
Adam C. Migus,
Addison Phillips,
Adrian Gropper,
Aisp-GitHub
Alen Horvat,
Alexander Mühle,
AlexAndrei98
Allen Brown,
Amy Guy,
Andor Kesselman,
Andres Paglayan,
Andres Uribe,
Andrew Hughes,
Andrew Jones,
Andrew Whitehead,
Andy Miller,
Anil John,
Anthony Camilleri,
Anthony Nadalin,
Benjamin Collins,
Benjamin Goering,
Benjamin Young,
Bert Van Nuffelen,
Bohdan Andriyiv,
Brent Zundel,
Brian Richter,
Bruno Zimmermann,
caribouW3
cdr
Chaoxinhu
Charles "Chaals" McCathieNevile,
Charles E. Lehner,
Chris Abernethy,
Chris Buchanan,
Christian Lundkvist,
Christine Lemmer-Webber,
Christoph Lange,
Christopher Allen,
Christopher Lemmer Webber,
ckennedy422
Clare Nelson,
confiks
Dan Brickley,
Daniel Buchner,
Daniel Burnett,
Daniel Hardman,
Darrell O'Donnell,
Dave Longley,
David Ammouial,
David Chadwick,
David Ezell,
David Hyland-Wood,
David I. Lehn,
David Janes,
David Waite,
Denis Ah-Kang,
Denisthemalice
Devin Rousso,
Dmitri Zagidulin,
Dominique Hazael-Massieux,
Drummond Reed,
Emmanuel
enuoCM
Eric Elliott,
Eric Korb,
Eric Prud'hommeaux,
etaleo
Evstifeev Roman,
Fabricio Gregorio,
Filip Kolarik,
Gabe Cohen,
Ganesh Annan,
George Aristy,
glauserr
Golda Velez,
Grace Huang,
Grant Noble,
Greg Bernstein,
Gregg Kellogg,
Heather Vescent,
Henry Andrews,
Henry Story,
Ian B. Jacobs,
Ilan
Isaac Henderson,
isaackps
Iso5786
Ivan Herman,
Jace Hensley,
Jack Tanner,
James Schoening,
Janina Sajka,
Jan Forster Cognizone,
Jeff Burdges,
Jeffrey Yasskin,
Jim Masloski,
Jim St.Clair,
Joe Andrieu,
Joel Gustafson,
Joel Thorstensson,
John Tibbetts,
Jonathan Holt,
José San Juan,
Juan Caballero,
Julien Fraichot,
Justin Richer,
Kaan Uzdoğan,
Kaliya Young,
Kazuyuki Ashimura,
Ken Ebert,
Kendall Weihe,
Kerri Lemoie,
Kevin Dean,
Kevin Griffin,
Kim Hamilton Duffy,
Konstantin Tsabolov,
Kristijan Sedlak,
Kristina Yasuda,
Kyle Den Hartog,
Lal Chandran,
Lance
Lautaro Dragan,
Leonard Rosenthol,
Liam Missin,
Liam Quin,
Line Kofoed,
Lionel Wolberger,
Logan Porter,
Lovesh Harchandani,
Lukas J. Han,
Mahmoud Alkhraishi,
Maik Riechert,
Manu Sporny,
Marcel Jackisch,
Mark Foster,
Mark Harrison,
Mark Moir,
Markus Sabadello,
Martin Thomson,
Marty Reed,
Matt Peterson,
Matt Stone,
Matthew Peterson,
Matthieu Bosquet,
Matti Taimela,
Melvin Carvalho,
Michael B. Jones,
Michael Herman,
Michael Lodder,
Michael Richardson,
Mike Prorock,
Mike Varley,
Mircea Nistor,
MIZUKI Sonoko / Igarashi,
nage
Nate Otto,
Nathan George,
Niclas Mietz,
Niko Lockenvitz,
Nikos Fotiou,
Nis Jespersen,
Oliver Terbu,
Pat McBennett,
Patrick St-Louis,
Paul Bastian,
Paul F. Dietrich,
Paulo Jorge Q. Ferreira,
Pelle Braendgaard,
Pete Rowley,
Phil Archer,
Phillip Long,
Pierre-Antoine Champin,
Rajesh Rathnam,
Ralph Swick,
Renato Iannella,
Reto Gmür,
Reza Soltani,
Richard Bergquist,
Richard Ishida,
Richard Varn,
Rieks Joosten,
RorschachRev
Ryan Grant,
Samuel Müller,
Samuel Smith,
Sarven Capadisli,
Sebastian Crane,
Sebastian Elfors,
Shawn Butterfield,
Shigeya Suzuki,
Sho Nakatani,
Shuji Kamitsuna,
Snorre Lothar von Gohren Edwin,
Sten Reijers,
Stephen Curran,
Steve Huguenin,
Steve McCown,
Steven Rowat,
Taro
tcibm
Ted Thibodeau Jr.,
Tim Bouma,
Timo Glastra,
Tobias Käfer,
Tobias Looker,
Tom Jones,
Torsten Lodderstedt,
Tzviya Siegman,
Victor Dods,
Vincent Kelleher,
Vladimir Alexiev,
Víctor Herraiz Posada,
Wayne Chang,
whatisthejava
Will Abramson,
William Entriken, and
Yancy Ribbens.