Among
other
things,
the
[
VC-DATA-MODEL-2
]
specifies
the
models
used
for
Verifiable
Credentials,
Verifiable
Presentations,
and
explains
the
relationships
between
three
parties:
issuers
,
holders
,
and
verifiers
.
Verifiability,
extensibility,
and
semantic
interoperability
are
critical
pieces
of
functionality
referenced
throughout
the
[
VC-DATA-MODEL-2
].
This
specification
provides
a
mechanism
to
make
use
of
a
Credential
Schema
in
Verifiable
Credential
,
leveraging
the
existing
Data
Schemas
concept.
Status
of
This
Document
This
is
a
preview
Do
not
attempt
to
implement
this
version
of
the
specification.
Do
not
reference
this
version
as
authoritative
in
any
way.
Instead,
see
https://w3c.github.io/vc-json-schema/
for
the
Editor's
draft.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
https://www.w3.org/TR/.
Status
of
This
Document
This
document
is
experimental
and
is
undergoing
heavy
development.
It
is
inadvisable
to
implement
the
specification
in
its
current
form.
An
experimental
implementation
is
available.
Publication
as
a
First
Public
Working
Draft
does
not
imply
endorsement
by
W3C
and
its
Members.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
This
specification
provides
a
mechanism
for
the
use
of
JSON
Schemas
with
Verifiable
Credentials
.
A
significant
part
of
the
integrity
of
a
Verifiable
Credential
comes
from
the
ability
to
structure
its
contents
so
that
all
three
parties
—
issuer,
holder,
verifier
—
may
have
a
consistent
mechanism
of
trust
in
interpreting
the
data
that
they
are
provided
with.
We
introducing
a
new
data
model
for
an
object
to
facilitate
backing
Credentials
with
JSON
Schemas
that
we
call
a
Credential
Schema
.
This
specification
provides
a
standardized
way
of
creating
Credential
Schemas
to
be
used
in
credentialing
systems.
Credential
Schemas
may
apply
to
any
portion
of
a
Verifiable
Credential.
Multiple
JSON
Schemas
may
back
a
single
Verifiable
Credential,
e.g.
a
schema
for
the
credentialSubject
and
another
for
other
credential
properties.
1.1
Terminology
This
section
is
non-normative.
Error
Cannot
GET
/uploads/zWvDUU/terms.html
/uploads/gNPLq4/terms.html
1.2
Conformance
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
,
RECOMMENDED
,
and
SHOULD
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.
2.
Data
Model
The
following
sections
outline
the
data
models
for
this
document,
of
which
there
are
two:
JsonSchema2023
for
usage
of
a
[
JSON-Schema
]
directly
in
a
credentialSchema
property,
and
VerifiableCredentialSchema2023
for
usage
of
a
[
JSON-Schema
]
represented
as
a
verifiable
credential
.
2.1
JsonSchema2023
This
term
definition
is
https://www.w3.org/ns/credentials#JsonSchema2023
.
JsonSchema2023
is
for
the
validation
of
W3C
Verifiable
Credentials,
based
on
JSON
Schema.
The
version
of
[
JSON-Schema
]
can
be
any
version
noted
in
the
section
on
JSON
Schema
Specifications
.
Property
Description
id
The
constraints
on
the
id
property
are
listed
in
the
Verifiable
Credentials
Data
Model
specification
[
VC-DATA-MODEL-2
].
The
value
MUST
be
a
URL
that
identifies
the
schema
associated
with
the
verifiable
credential
.
type
The
type
property
MUST
be
JsonSchema2023.
An
example
of
utilizing
the
VC
Data
Model's
credentialSchema
is
provided
below:
The
constraints
on
the
id
property
are
listed
in
the
Verifiable
Credentials
Data
Model
specification
[
VC-DATA-MODEL-2
].
The
value
MUST
be
a
URL
that
identifies
the
verifiable
credential
which
contains
a
credential
schema.
type
The
type
property
MUST
be
VerifiableCredentialSchema2023
An
example
of
utilizing
the
VC
Data
Model's
credentialSchema
is
provided
below:
Example
3
:
Example
VerifiableCredentialSchema2023
JSON
Schema
specifications
reserve
certain
keywords
that
hold
specific
meanings
and
functions
during
the
processing
of
JSON
Schemas.
It
is
crucial
to
avoid
using
conflicting
keys
when
creating
JSON
Schemas.
The
specification
document
for
each
version
of
JSON
Schema
lists
these
reserved
keywords,
which
can
be
found
in
the
table
provided
above.
In
the
upcoming
sections
we
list
some
keywords
that
possess
unique
significance
and
should
not
be
used
in
conflicting
ways.
Furthermore,
we
identify
specific
keywords,
that
are
not
explicitly
defined
by
JSON
Schema,
but
are
emphasized
in
this
specification
to
support
widespread
usage.
3.1.1
$id
Across
JSON
Schema
specifications,
the
$id
keyword
identifies
a
schema
resource
with
its
canonical
[
RFC-6596
]
URI.
The
$id
MUST
be
present
and
its
value
MUST
represent
a
valid
URI-reference
[
RFC-3986
].
It
is
RECOMMENDED
that
the
value
of
the
$id
property
match
the
id
value
in
the
credentialSchema
object
of
a
verifiable
credential
,
and
that
the
value
of
the
$id
is
a
dereferenceable
IRI.
3.1.2
$schema
Across
JSON
Schema
specifications,
the
$schema
keyword
identifies
a
JSON
Schema
providing
the
feature
set
for
a
given
JSON
Schema
specification.
This
property
MUST
be
present
in
each
schema.
For
example,
when
constructing
a
schema
for
Draft
2020-12
the
value
of
the
$schema
identifier
MUST
be
https://json-schema.org/draft/2020-12/schema
.
3.1.3
name
It
is
RECOMMENDED
that
all
JSON
Schemas
include
a
name
property
which
provides
a
human-readable
name
that
describes
the
schema.
3.1.4
description
JSON
Schemas
MAY
choose
to
include
an
optional
description
property
which
provides
a
human-readable
sentence
describing
the
schema.
A
common
feature
of
a
JSON
schema
validator
is
the
ability
to
detect
the
version
of
a
JSON
schema
document
and
select
the
validator
for
that
specific
version
of
[
JSON-SCHEMA
].
This
is
done
by
switching
on
the
schema's
$schema
and
picking
the
corresponding
validator.
Schemas
without
a
$schema
property
are
not
considered
valid
and
MUST
not
be
processed.
It
is
RECOMMENDED
that
implementers
choose
validators
which
possess
this
capability
and
are
able
to
limit
validation
to
the
JSON
schema
specifications
supported
by
this
document.
Secured
credentials
representing
credential
schemas
SHOULD
first
be
validated
according
to
the
rules
set
out
in
the
aforementioned
securing
specifications
before
proceeding
with
additional
processing.
Issue
143
:
Add
examples
of
validating
VC-JWT
and
Linked
Data
Proof
credentials
Provide
examples
for
Data
Integrity
and
VC-JWT
Credential
Schemas
Credential
Schemas
of
type
JsonSchema2023
MAY
be
annotated
with
integrity
information
by
adding
the
digestSRI
property
to
the
credentialSchema
value
in
the
Verifiable
Credential
which
contains
the
schema,
as
described
in
Integrity
of
Related
Resources
.
Validation
of
the
integrity
of
the
schema
MUST
be
done
before
evaluation.
An
example
of
such
usage
is
provided
below:
Example
5
:
Example
Verifiable
Credential
JsonSchema2023
with
Integrity
Information
Validation
of
a
given
Credential
against
its
schema
is
to
be
performed
according
to
its
associated
[
JSON-SCHEMA
]
specification.
If
validation
succeeds
the
credential
is
considered
to
be
valid
against
its
credential
schema
.
5.
Implementation
Considerations
This
section
is
non-normative.
This
section
details
some
issues
implementers
of
the
specification
may
consider.
5.1
Validation
of
Specific
Properties
in
a
Credential
This
section
is
non-normative.
Implementers
may
wish
to
validate
certain
sections
of
a
verifiable
credential
.
To
do
this,
credential
schemas
can
be
constructed
to
specify
application
to
subsets
of
a
given
credential.
One
example
of
such
a
construction
would
be
to
validate
the
presence
of
certain
top-level
properties
in
a
verifiable
credential
.
The
following
example
demonstrates
a
schema
which
enforces
that
a
credential
issued
against
it
has
an
validUntil
property
and
includes
evidence
.
Example
6
:
ValidUntil
and
Evidence
Credential
Schema
In
using
[
JSON-Schema
]
it
is
advised
that
implementers
avoid
setting
the
additionalProperties
to
false
.
Doing
so
could
inadvertently
exclude
properties
in
a
credential
from
passing
validation.
As
an
example,
consider
a
credential
schema
that
is
intended
to
validate
the
credentialSubject
property
of
a
credential.
It
is
common
for
the
credentialSubject
property
to
include
an
id
,
denoting
the
identifier
the
subject.
Not
including
this
id
property
in
a
given
schema
would
result
in
validation
failure.
The
simple
alternative
is
to
avoid
setting
additionalProperties
to
false
.
Versioning
is
not
provided
as
an
explicit
feature
of
this
specification.
It
is
advised
to
make
backwards
compatabile
changes
to
schemas,
should
they
be
adjusted.
Otherwise,
it
is
advised
that
a
new
credential
schema
is
created
with
a
unique
identifier.
Issue
120
:
Consider
adding
language
on
schema
immutability
v2
Add
language
on
enabling
schema
immutability/versioning,
such
as
making
use
of
hashlinks.
5.4
Storage
This
section
is
non-normative.
Credential
schemas
MAY
be
created
and
made
available
as
immutable
objects.
They
can
be
stored
on
any
number
of
storage
mediums
such
as
a
distributed
ledger,
traditional
database,
or
decentralized
file
storage.
The
same
schema
could
be
replicated
across
multiple
file
stores
with
the
same
identifier.
Immutability
is
key
to
enabling
a
consistent
source
of
truth
for
usage
with
verifiable
credentials
which
are
tamper-evident
by
design.
5.5
Resolution
This
section
is
non-normative.
Issue
19
:
Example
of
the
credentialSchema.id
resolution
to
schema
v2
Add
section
on
schema
resolution.
5.6
5.5
Multiple
Schemas
This
section
is
non-normative.
A
common
use
case
is
to
include
multiple
schemas
to
validate
against
which
a
single
verifiable
Credential
.
One
such
use
case
is
to
utilize
the
JSON
Schema
defined
by
the
[
VC-DATA-MODEL-2
]
in
addition
to
a
schema
to
validate
a
specific
property
in
the
credential,
such
as
the
credentialSubject
.
Multiple
schemas
MAY
be
combined
using
native
constructs
from
the
[
JSON-SCHEMA
]
specification,
through
utilizing
properties
such
as
oneOf
,
anyOf
,
or
allOf
.
An
example
of
how
to
construct
such
a
schema
using
the
[
JSON-SCHEMA
]
property
allOf
is
provided
below,
combining
schemas
for
a
verifiable
credential
,
name,
and
email
address:
Example
8
:
Multiple
Schema
Credential
Schema
Example
Add
warning
for
improperly
formed
schemas
and
risks
associated
with
using
multiple
schemas.
5.7
5.6
Validity
of
a
Verifiable
Credential
This
section
is
non-normative.
Validation
against
a
[
JSON-SCHEMA
]
may
be
confused
with
validation
or
verification
of
a
Verifiable
Credential.
A
valid
credential
according
to
a
[
JSON-SCHEMA
]
refers
only
to
the
structure
of
the
claims
comprising
a
Verifiable
Credential.
This
idea
of
validity
does
not
imply
anything
about
the
validity
of
the
Verifiable
Credential
itself.
It's
possible
for
a
Verifiable
Credential
to
be
considered
valid
by
one
verifier,
while
another
verifier
would
not
consider
it
valid.
5.8
5.7
Relationship
to
Verifiable
Credential
Type
Property
This
section
is
non-normative.
It
is
common
to
define
a
credential
schema
that
will
be
set
for
Verifiable
Credentials
whose
type
property
contains
a
specific
type
.
In
this
scenario,
it
is
advised
to
use
the
value
of
the
specific
type
in
the
id
or
in
a
name
or
description
property.
of
a
[
JSON-Schema
].
The
example
below
illustrates
this
for
EmailCredential
:
Example
10
:
Verifiable
Credential
with
Schema
Type
It
is
important
to
note
that
a
credential
schema
enables
issuers
to
communicate
how
to
process
the
structure
of
data
inside
a
verifiable
credential,
whereas
the
type
property
of
a
verifiable
credential
lets
issuers
communicate
the
semantics
of
the
data.
It
is
advised
to
associate
all
properties
that
have
a
semantic
mapping
with
a
property
in
a
credential
schema
.
6.
Privacy
Considerations
This
section
is
non-normative.
This
section
details
the
general
privacy
considerations
and
specific
privacy
implications
of
deploying
this
specification
into
production
environments.
6.1
Personally
Identifiable
Information
Data
associated
with
schemas
and
verifiable
credentials
are
susceptible
to
privacy
violations
when
shared.
Personally
identifying
data,
such
as
a
government-issued
identifier,
address,
or
name,
can
be
used
to
track
and
correlate
entities.
Even
less
overt
personal
data
such
as
a
birthdate
or
postal
code
has
the
ability
to
result
in
correlation
and
de-anonymization.
Implementers
are
strongly
advised
to
avoid
constructing
schemas
with
any
personally
identifiable
information
(PII).
If
such
personally
identifiable
information
is
necessary
in
a
schema,
or
a
credential
schema,
implementers
are
strongly
advised
to
use
mechanisms
while
storing
and
transporting
verifiable
credentials
that
protect
the
data
from
those
who
should
not
access
it
such
as
Transportation
Layer
Security
(TLS)
or
other
means
of
encrypting
the
data
whether
in
transit
or
at
rest.
6.2
Verifier
Caching
Since
schemas
are
immutable,
they
are
highly
cachable.
It
is
possible
for
verifiers
to
increase
the
privacy
of
the
holder
whose
verifiable
credential
is
being
checked
by
caching
schemas
that
have
been
fetched
from
remote
servers.
By
caching
the
content
locally,
less
correlatable
information
can
be
inferred
from
verifier
-based
access
patterns
on
the
schema.
6.3
Content
Distribution
Networks
The
use
of
content
distribution
networks
by
issuers
can
increase
the
privacy
of
holders
by
reducing
or
eliminating
requests
for
the
schemas
lists
from
the
issuer
.
Often,
a
request
for
a
schema
list
will
be
served
by
an
edge
device
and
thus
be
faster
and
reduce
the
load
on
the
server
as
well
as
cloaking
verifiers
and
holders
from
issuers
.
7.
Security
Considerations
This
section
is
non-normative.
There
are
a
number
of
security
considerations
that
implementers
should
be
aware
of
when
processing
data
described
by
this
specification.
Ignoring
or
not
understanding
the
implications
of
this
section
can
result
in
security
vulnerabilities.
7.1
Issuer
Impersonation
It
is
possible
for
a
schema
to
become
authoritative,
such
as
schemas
provided
by
a
recognized
industry
group
like
a
consoritum
of
financial
companies.
To
avoid
confusion
as
to
the
authorship
of
credential
schemas
it
is
advised
that
they
are
packaged
as
secured
verifiable
credentials
.
8.
Accessibility
Considerations
This
section
is
non-normative.
There
are
a
number
of
accessibility
considerations
implementers
should
be
aware
of
when
processing
data
described
in
this
specification.
As
with
any
web
standards
or
protocols
implementation,
ignoring
accessibility
issues
makes
this
information
unusable
to
a
large
subset
of
the
population.
It
is
important
to
follow
accessibility
guidelines
and
standards,
such
as
[
WCAG21
],
to
ensure
all
people,
regardless
of
ability,
can
make
use
of
this
data.
This
is
especially
important
when
establishing
systems
utilizing
cryptography,
which
have
historically
created
problems
for
assistive
technologies.
JSON
Schemas
are
designed
to
be
a
machine-readable
format
which
provides
static
validation.
As
such,
human
readability
is
a
secondary
concern.
When
using
a
verifiable
credential
to
represent
a
schema,
we
recommend
following
the
guidance
in
the
VC
Data
Model
.
9.
Internationalization
Considerations
This
section
is
non-normative.
There
are
a
number
of
internationalization
considerations
implementers
should
be
aware
of
when
publishing
data
described
in
this
specification.
As
with
any
web
standards
or
protocols
implementation,
ignoring
internationalization
makes
it
difficult
for
data
to
be
produced
and
consumed
across
a
disparate
set
of
languages
and
societies,
which
would
limit
the
applicability
of
the
specification
and
significantly
diminish
its
value
as
a
standard.
JSON
Schemas
are
JSON
text
intended
primarily
for
machines
to
read,
since
they
are
used
for
strict
static
validation
of
data.
Language
and
text
direction
concerns
are
addressed
by
the
noted
specification
documents
for
JSON
Schema
itself.