This
specification
describes
a
data
model
with
which
one
or
more
recognized
entities,
such
as
one
or
more
persons
and/or
organizations,
can
be
described
as
known
to
perform
specific
actions,
such
as
issuing
or
verifying
a
verifiable
credential
.
The
data
model
enables
the
publication
or
direct
sharing
of
such
information,
providing
a
cryptographically-verifiable
and
privacy-preserving
mechanism
through
which
a
holder
can
demonstrate
that
an
entity
whose
credential
they
are
using
is
recognized
within
a
particular
ecosystem.
The
specification
is
designed
to
interoperate
with
existing
"trust
infrastructures",
such
as
X.509
certificate
authority
lists
and
ETSI
Trust
Service
Lists,
while
enabling
new
decentralized
ecosystems
to
be
built
using
verifiable
credentials
.
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-recognition/
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
standards
and
drafts
index
.
This
is
an
experimental
specification
and
is
undergoing
regular
revisions.
It
is
not
fit
for
production
deployment.
Publication
as
an
Editor's
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
a
work
in
progress.
The
verifiable
credential
ecosystem
relies
on
the
ability
of
verifiers
to
determine
whether
a
particular
issuer
is
recognized
to
perform
a
particular
action,
such
as
issuing
a
certain
type
of
verifiable
credential
.
Historically,
this
determination
has
often
been
made
through
out-of-band
processes,
bilateral
agreements,
or
proprietary
registries
that
are
difficult
to
discover,
query,
or
reason
about
in
an
automated
way.
As
verifiable
credentials
are
increasingly
deployed
across
sectors
such
as
education,
healthcare,
financial
services,
and
government,
the
need
for
a
standardized,
interoperable
mechanism
to
express
and
communicate
recognition
of
entities
that
perform
known
actions
has
become
critical.
Without
such
a
mechanism,
ecosystem
participants
are
forced
to
build
bespoke
"trust
infrastructure",
leading
to
fragmentation,
increased
integration
costs,
and
barriers
to
cross-border
and
cross-sector
interoperability.
This
specification
addresses
the
challenge
of
expressing
recognized
entities,
such
as
people
and
organizations,
and
the
actions
they
perform,
such
as
issuing
and
verifying,
in
a
decentralized
manner
by
defining
a
data
model
that
any
entity
can
use
to
publish
or
share
recognition
information
as
a
verifiable
credential
.
Rather
than
mandating
a
single
central
registry,
the
model
allows
any
entity
—
a
government
body,
an
industry
consortium,
a
standards
organization,
or
even
a
single
individual
—
to
issue
a
VerifiableRecognitionCredential
asserting
that
they
know
of
one
or
more
entities
that
are
recognized
to
perform
specific
actions.
This
design
enables
a
web
of
overlapping,
competing,
and
complementary
"trust
registries"
to
coexist,
allowing
ecosystem
participants
to
choose
the
entities
they
trust
and
to
reason
across
multiple
registries.
The
specification
also
supports
interoperability
with
existing
"trust
infrastructure",
such
as
X.509
certificate
authority
lists
and
ETSI
Trust
Service
Lists,
allowing
existing
recognized
entity
information
to
be
referenced
and
composed
into
new
decentralized
ecosystems.
Readers
who
are
interested
in
the
variety
of
use
cases
supported
by
this
specification
are
urged
to
read
the
use
cases
document
.
The
remainder
of
this
document
is
organized
into
the
following
sections:
Section
2.
Data
Model
defines
the
core
data
model,
including
the
RecognizedEntity
,
RecognizedAction
,
and
VerifiableRecognitionCredential
types
along
with
their
properties
and
worked
examples.
Section
4.
Security
Considerations
discusses
security
considerations
relevant
to
implementers
of
this
specification.
Section
3.
Privacy
Considerations
discusses
privacy
considerations
relevant
to
implementers
of
this
specification.
1.1
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
,
OPTIONAL
,
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.
A
conforming
document
is
any
concrete
expression
of
the
data
model
that
complies
with
the
normative
statements
in
this
specification.
Specifically,
all
relevant
normative
statements
in
Section
2.
Data
Model
of
this
document
MUST
be
enforced.
A
conforming
processor
is
any
algorithm
realized
as
software
and/or
hardware
that
generates
or
consumes
a
conforming
document
.
Conforming
processors
MUST
produce
errors
when
non-conforming
documents
are
consumed.
This
document
also
contains
examples
that
contain
JSON
and
JSON-LD
content.
Some
of
these
examples
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
valid
JSON
or
JSON-LD.
2.
Data
Model
The
following
sections
outline
the
data
model
that
is
used
by
this
specification
for
Verifiable
Issuer
and
Verifier
Lists.
The
data
model
described
in
this
section
has
been
built
using
input
from
a
variety
of
the
prior
art
evaluated
for
this
paper
including
input
from
the
EBSI
Trusted
Issuer
Registry,
ETSI
TS
119
612,
eSSIF-Lab
TRAIN,
the
Trust
over
IP
Foundation
Trust
Registry
Protocol,
and
Rebooting
the
Web
of
Trust
input
documents.
The
data
model
described
in
this
section
is
capable
of
expressing
many,
but
not
all,
of
the
concepts
described
in
those
other
specifications.
The
unified
data
model
for
this
work
can
be
represented
as
a
list
of
service
providers
that
represent
entities
or
organizations
that
provide
services
such
as
credential
issuance
or
validation.
The
data
model
also
includes
the
details
of
the
list
operator
description.
2.1
General
Properties
The
properties
in
this
section
can
be
added
to
objects
found
in
a
VerifiableRecognitionCredential
as
defined
in
Section
2.4
VerifiableRecognitionCredential
.
Each
general
property
listed
in
this
section
is
OPTIONAL
;
none
of
the
values
are
required
to
be
provided
by
an
issuer
.
The
official
legal
name
of
an
organization
or
entity,
as
registered
with
legal
authorities,
which
can
differ
from
the
commonly
used
name.
The
value
MUST
be
a
string
.
image
A
URL
or
image
data
representing
a
visual
identifier
for
the
entity,
such
as
a
logo,
photograph,
or
icon.
The
value
MUST
be
a
URL
.
url
A
URL
pointing
to
the
primary
website
or
web
resource
associated
with
the
entity.
The
value
MUST
be
a
URL
.
sameAs
One
or
more
URLs
that
refer
to
the
same
entity
in
other
contexts
or
systems,
enabling
cross-reference
and
verification
across
different
platforms.
Each
value
MUST
be
a
URL
.
An
object
that
contains
a
reference
to
a
document
of
recognized
entities
that
contains
this
particular
recognized
entity
as
well
as
the
actions
it
is
known
to
perform.
The
id
value
of
the
object
MUST
be
a
URL
.
The
type
value
of
the
object
MUST
conform
to
the
type
value
space
defined
in
the
Verifiable
Credentials
Data
Model
v2.0
specification
and
SHOULD
be
EtsiTrustServiceList
,
x509CertificateAuthorityList
,
or
VerifiableRecognitionCredential
.
Properties
from
Section
2.1
General
Properties
can
be
included
in
addition
to
the
properties
above.
A
recognized
action
is
an
action
that
a
recognized
entity
is
expected
to
perform.
Property
Description
type
The
type
property
MUST
be
RecognizedAction
.
action
A
string
that
specifies
the
name
of
the
action
to
be
performed
such
as
issue
or
verify
.
recognizedBy
A
URL
,
or
object
containing
properties
from
Section
2.1
General
Properties
,
of
the
entity
that
performed
the
task
of
recognizing.
outputValidation
The
value
of
the
outputValidation
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
validator
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.
A
verifiable
credential
that
contains
a
set
of
recognized
entities
MAY
express
an
id
property
to
make
its
retrieval
easier
for
other
systems.
type
A
verifiable
credential
that
contains
a
set
of
recognized
entities
MUST
express
a
type
property
that
includes
the
VerifiableRecognitionCredential
value.
The
earliest
point
in
time
at
which
the
credential
is
valid.
This
property
is
defined
in
the
Verifiable
Credentials
Data
Model
specification
in
Section
4.6:
Validity
Period
.
validUntil
The
latest
point
in
time
at
which
the
credential
is
valid.
This
property
is
defined
in
the
Verifiable
Credentials
Data
Model
specification
in
Section
4.6:
Validity
Period
.
credentialSubject
A
set
of
one
or
more
RecognizedEntity
objects
as
defined
in
Section
2.2
RecognizedEntity
.
The
following
examples
demonstrate
how
verifiable
recognition
credentials
can
be
employed
in
a
variety
of
use
cases.
The
first
example
below
is
used
to
publish
information
about
a
set
of
known
universities
in
a
particular
nation.
Example
1
:
A
set
of
known
universities
in
a
particular
nation
{"@context":["https://www.w3.org/ns/credentials/v2","https://www.w3.org/ns/credentials/examples/v2"],"type":["VerifiableCredential","VerifiableRecognitionCredential"],"issuer":{"id":"did:web:learning-commission.example","type":"RecognizedIssuer"},"validFrom":"2025-01-01T00:00:00Z","validUntil":"2030-01-01T00:00:00Z","credentialSubject":[{"id":"did:web:university.example","type":"RecognizedEntity","name":"Example Tech","legalName":"Example Polytechnic University","image":"https://university.example/logo.png","url":"https://www.university.example/","description":"A university providing a great education in Utopia Valley.",},{"id":"did:web:college.example","type":"RecognizedEntity","name":"Exemplar Community College","legalName":"Community College of Examples and ","image":"https://college.example/graphics/ecc.png","url":"https://college.example/","description":"The backbone of learning in the Utopia community.",}],"proof":{"type":"DataIntegrityProof","created":"2026-04-10T20:08:22Z","verificationMethod":"did:web:accreditor.example#issuance-key-1","cryptosuite":"ecdsa-rdfc-2019","proofPurpose":"assertionMethod","proofValue":"z36XPGByaH3rvtKfwoEQXsnUXUAjwd2Ceiqke1GPfjAPAFYoXKo5ftPdwE7QZ8Mw22SC5LSRQg1d8bhe3252hYJoH"}
}
The
next
example
is
used
to
publish
information
about
a
set
of
known
issuers
for
a
particular
type
of
verifiable
credential
.
Example
2
:
A
set
of
known
issuers
for
a
particular
type
of
credential
{"@context":["https://www.w3.org/ns/credentials/v2","https://www.w3.org/ns/credentials/examples/v2"],"type":["VerifiableCredential","VerifiableRecognitionCredential"],"issuer":{"id":"did:web:learning-commission.example","type":"RecognizedIssuer"},"validFrom":"2025-01-01T00:00:00Z","validUntil":"2030-01-01T00:00:00Z","credentialSubject":[{"id":"did:web:university.example","type":"RecognizedEntity","name":"Example Tech","legalName":"Example Polytechnic University","image":"https://university.example/logo.png","url":"https://www.university.example/","description":"A university providing a great education in Utopia Valley.","recognizedTo":{"type":"RecognizedAction","action":"issue","recognizedBy":"did:web:learning-commission.example","outputValidation":{"id":"https://learning-commission.example/credentials/bachelors.json","type":"JsonSchema","digestMultibase":"uEiBZl963sknNAHgPyslVv6VztZpfWQoRvW1htfx-UwirFo",}}},{"id":"did:web:college.example","type":"RecognizedEntity","name":"Exemplar Community College","legalName":"Community College of Examples and ","image":"https://college.example/graphics/ecc.png","url":"https://college.example/","description":"The backbone of learning in the Utopia community.","recognizedTo":{"type":"RecognizedAction","action":"issue","recognizedBy":"did:web:learning-commission.example","outputValidation":{"id":"https://learning-commission.example/credentials/associates.json","type":"JsonSchema","digestMultibase":"uEiWQoRvpfWW1htfsknNAHgPyslVv6VztZpfwirFoBZl963",}}}],"proof":{"type":"DataIntegrityProof","created":"2026-04-10T20:08:22Z","verificationMethod":"did:web:accreditor.example#issuance-key-1","cryptosuite":"ecdsa-rdfc-2019","proofPurpose":"assertionMethod","proofValue":"z36XPGByaH3rvtKfwoEQXsnUXUAjwd2Ceiqke1GPfjAPAFYoXKo5ftPdwE7QZ8Mw22SC5LSRQg1d8bhe3252hYJoH"}
}
The
final
example
below
is
used
to
publish
information
about
an
entity
that
publishes
an
European
Union
ETSI
Trust
Services
list
[
ETSI-TRUST-LISTS
].
Example
3
:
An
entity
that
publishes
information
conforming
to
an
EU
ETSI
Trust
Service
list
{"@context":["https://www.w3.org/ns/credentials/v2","https://www.w3.org/ns/credentials/examples/v2"],"type":["VerifiableCredential","VerifiableRecognitionCredential"],"issuer":"did:web:ec.europa.example","validFrom":"2025-01-01T00:00:00Z","validUntil":"2030-01-01T00:00:00Z","credentialSubject":[{"id":"did:web:ec.europa.example","type":"RecognizedEntity","name":"Utopian Commission","legalName":"The Utopian Commission","image":"https://ec.europa.example/logo.png","url":"https://ec.europa.example/","recognizedIn":{"id":"https://ec.europa.example/tsl/lotl.xml","type":"EtsiTrustServiceList","name":"Utopian Commission List of the Lists"}}],"proof":{"type":"DataIntegrityProof","created":"2026-04-10T20:08:22Z","verificationMethod":"did:web:ec.europa.example#issuance-key-1","cryptosuite":"ecdsa-rdfc-2019","proofPurpose":"assertionMethod","proofValue":"z36XPGByaH3rvtKfwoEQXsnUXUAjwd2Ceiqke1GPfjAPAFYoXKo5ftPdwE7QZ8Mw22SC5LSRQg1d8bhe3252hYJoH"}
}
3.
Privacy
Considerations
This
section
details
the
general
privacy
considerations
and
specific
privacy
implications
of
deploying
this
specification
into
production
environments.
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.
While
this
section
attempts
to
highlight
a
broad
set
of
security
considerations,
it
is
not
a
complete
list.
Implementers
are
urged
to
seek
the
advice
of
security
and
cryptography
professionals
when
implementing
mission
critical
systems
using
the
technology
outlined
in
this
specification.
4.1
Validate
Before
Sharing
When
a
holder
receives
a
VerifiableRecognitionCredential
and
shares
it
with
others,
there
is
a
risk
that
the
credential
has
not
been
properly
vetted.
A
malicious
or
negligent
actor
could
craft
a
VerifiableRecognitionCredential
that
lists
fraudulent
or
compromised
entities
as
recognized
issuers
or
verifiers,
and
propagate
it
peer-to-peer
across
an
ecosystem.
Recipients
who
accept
and
act
upon
such
a
credential
without
independent
verification
might
unknowingly
accept
verifiable
credentials
from
untrustworthy
sources,
exposing
themselves
and
others
to
fraud,
data
breaches,
or
credential
forgery.
The
decentralized
nature
of
this
specification,
while
a
strength,
amplifies
this
risk:
a
single
unvetted
credential
shared
widely
can
rapidly
corrupt
the
trust
assumptions
of
many
parties
in
an
ecosystem.
To
mitigate
these
dangers,
deployments
are
expected
to
independently
verify
the
cryptographic
integrity
and
provenance
of
any
VerifiableRecognitionCredential
before
acting
upon
it
or
sharing
it
further.
This
includes
confirming
that
the
issuer
of
the
credential
is
a
party
the
implementer
has
an
established
reason
to
trust
for
the
given
recognition
domain,
and
that
the
credential
has
not
expired
or
been
revoked.
Implementers
cannot
rely
solely
on
the
fact
that
a
peer
has
already
accepted
a
credential
as
evidence
of
its
validity.
Instead,
a
verifier
needs
to
vet
the
issuer
of
the
recognition
credential
as
well
as
the
recognized
action
independently
of
receiving
the
VerifiableRecognitionCredential
and
can
only
depend
on
information
from
the
credential
once
trust
has
been
established
on
the
issuing
entity.
A.
Acknowledgements
This
section
is
non-normative.
The
Working
Group
thanks
the
following
individuals
for
significant
contributions
to
the
community:
TBD
Work
on
this
specification
has
been
supported
by
the
Rebooting
the
Web
of
Trust
community
facilitated
by
Christopher
Allen,
Joe
Andrieu,
and
Erica
Connell.
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
would
like
to
thank
the
following
individuals
for
reviewing
and
providing
feedback
on
the
specification
(in
alphabetical
order):