This
work
focuses
on
how
a
party
or
its
agent
can
decide
whether
or
not
to
engage
with
a
counterparty
in
a
transaction.
The
purpose
of
this
work
is
to
enable
a
party
to
share
a
list
of
Verifiable
Issuers
Issuers,
Verifiers,
and
Verifiers
Wallet
Providers
in
a
way
that
is
useful
to
a
particular
transaction.
There
was
extensive
analysis
of
existing
initiatives
performed
at
the
Rebooting
the
Web
of
Trust
11
conference
in
The
Hague
as
well
as
a
number
of
follow
on
meetings
to
coordinate
activity
across
various
communities.
The
paper
analyzing
the
existing
state
of
the
art
is
available
from
the
Rebooting
The
Web
of
Trust
paper
archive
.
This
specification
is
intended
to
align
with
work
happening
in
other
venues
such
as
the
Trust
Over
IP
Foundation,
ESSIF-Lab,
The
European
Digital
Identity
Initiative
and
other
European
Trust
Frameworks,
Canadian
Trust
Framework
activities,
as
well
as
commercial
ventures
that
are
exploring
Trust
Frameworks.
Effort
will
continue
to
be
expended
to
align
this
specification
with
work
happening
in
other
related
venues.
The
authors
and
editors
of
this
specification
invite
commentary
on
this
specification
through
the
Github
issue
tracker
listed
at
the
top
of
this
document.
This
is
an
experimental
specification
and
is
undergoing
regular
revisions.
It
is
not
fit
for
production
deployment.
The
maintenance
of
lists
of
Verifiable
Issuers,
sometimes
referred
to
as
Trusted
Registries,
are
is
a
well-known
concept
from
the
pre-internet
age.
Whenever
there
is
a
diploma
signed
by
a
university,
there
are
people
and
organizations
that
keep
track
of
what
universities
exist
and
what
methods
there
are
to
confirm
the
authenticity
of
that
diploma.
A
list
could
be
maintained
by
HR
staff
for
the
purpose
of
hiring
personnel
based
on
qualifications
asserted
by
particular
Verifiable
Issuers,
and
the
governance
of
that
list
would
be
minimal.
Another
list
could
be
maintained
by
a
government,
associated
with
well-governed
accreditation
procedures,
for
the
purpose
of
assuring
that
a
diploma
represents
a
proper
education.
Lists
of
Verifiable
Issuers
support
Verifiers
in
their
decision
to
trust
the
Issuer
of
a
Verifiable
Credential
that
is
presented
by
a
Holder.
Digitally
Digital
sharing
of
lists
of
Verifiable
Issuers
Issuers,
Verifiers,
and
Verifiers
Wallet
Providers
is
a
relatively
new
concept.
Examples
are
the
list
of
parties
that
are
allowed
to
use
the
digital
fingerprint
information
on
the
chip
of
RFID-based
digital
passports.
This
is
cryptographically
enforced:
“chip-says-no”
when
an
unauthorized
party
attempts
to
access
this
information
on
the
chip.
Also
eIDAS
v2
will
have
a
Verifiable-Verifiers
List
that
limits
the
access
of
Verifiers
to
credentials
in
a
EUDI
(EUropean
Digital
Identity)
wallet.
Verifiable-Verifiers
Lists
support
Holders
and
holder
implementations
in
their
decision
to
trust
a
Verifier
to
share
a
Verifiable
Presentation
to
that
Verifier.
A
Verifiable
Wallet
Provider's
list
may
be
used
by
Issuers
when
deciding
whether
or
not
to
issue
a
credential
to
a
holder's
wallet.
Lists
of
Verifiable
Issuers
Issuers,
Verifiers,
and
Verifiers
Wallet
Providers
help
to
automate
the
decision
process
of
whether
to
engage
with
a
counterparty
in
a
transaction
and
make
it
more
auditable
by
ensuring
that
software
can
note
that
a
party
was
on
a
list
before
engaging
with
them.
it.
This
paper
contains
the
following
sections
that
provide
background
on
the
problem
space
as
well
as
a
proposed
set
of
solutions
given
the
current
state
of
the
market:
Section
2
presents
a
set
of
use
cases
in
the
digital
age
that
explain
the
use
of
lists
of
Verifiable
Issuers
Issuers,
Verifiers,
and
Verifiers.
Wallet
Providers.
Section
3
analyses
prior
art
such
as
lists
of
Verifiable
Issuers
and
Verifiers
that
have
already
been
deployed,
or
that
are
being
developed,
as
well
as
a
gap
analysis
of
the
current
solutions
and
desired
outcomes.
Section
4
highlights
the
unified
requirements
derived
from
the
analysis
of
prior
art
and
a
conceptual
model
for
sharing
lists
of
Verifiable
Issuers
and
Verifiers
and
the
format
of
the
entries
in
the
list.
Section
5
4
provides
a
concrete
data
model
and
possible
serializations,
which
could
serve
as
a
starting
point
for
future
standardization.
Section
6
discusses
possible
next
steps
towards
future
standardization.
5
provides
a
non-normative
example
of
a
verifiable
list
published
as
a
verifiable
credential.
Section
7
concludes
the
paper
and
proposes
future
work.
6
discusses
possible
approaches
to
securing
verifiable
lists.
The
target
audience
of
this
paper
are
people
that
know
the
basics
of
Self-Sovereign
Identity
(SSI)
such
as
the
concepts
of
Issuer,
Holder,
Verifier,
and
Verifiable
Credential.
SSI
developers
may
use
this
document
as
input
and
inspiration
for
their
code
and
other
products.
Deployers
of
SSI
use
cases
may
use
this
document
in
the
specification
process
of
their
deployment.
1.1
Terminology
The
following
terms
are
used
to
describe
concepts
in
this
document.
Credential
A
set
of
one
or
more
claims
made
by
an
issuer
.
A
verifiable
credential
is
a
tamper-evident
credential
that
has
authorship
that
can
be
cryptographically
verified.
Verifiable
credentials
can
be
used
to
build
verifiable
presentations
,
which
can
also
be
cryptographically
verified.
The
claims
in
a
credential
can
be
about
different
subjects.
Electronic
Identification,
Authentication
and
Trust
Services
(eIDAS)
eIDAS
(
e
lectronic
ID
entification,
A
uthentication
and
trust
S
ervices)
is
an
EU
regulation
on
electronic
identification
and
trust
services
for
electronic
transactions
in
the
European
Single
Market
.
It
was
established
in
EU
Regulation
910/2014
of
23
July
2014.
All
organizations
delivering
public
digital
services
in
an
EU
member
state
must
recognize
electronic
identification
from
all
EU
member
states
from
September
29,
2018.
European
Digital
Identity
(EUDI)
The
European
Digital
Identity
is
based
on
a
European
Commission
document
called
“European
Digital
Identity
Architecture
and
Reference
Framework”
that
has
established
the
functional
and
architectural
requirements
for
an
upcoming
European
Digital
Identity
Wallet.
The
degree
of
certainty
that
a
relying
party
can
have
about
the
true
identity
of
someone
presenting
an
identity
credential.
Four
levels
of
assurance
were
outlined
by
a
2006
document
from
the
US
National
Institute
of
Standards
and
Technology
(NIST
800-63).
The
level
of
assurance
is
measured
by
the
strength
and
rigor
of
the
identity
proofing
process,
the
strength
of
the
token
used
to
authenticate
the
identity
claim,
and
the
management
processes
the
identity
provider
applies
to
it.
Sharing
The
act
of
transferring
information
from
one
party
to
another.
This
paper
uses
the
word
"sharing"
instead
of
"publishing"
as
the
latter
presumes
a
one-way
and
public
transfer
of
information.
The
Verifiable
Issuer/Verifier
lists
described
in
this
paper
are
made
available
in
some
form
or
other.
They
might
be
pushed
to
a
party
or
pulled
from
a
party
and
might
use
a
public
communication
channel
or
a
private
one.
Verifiable
Issuer
/
Verifiable
Verifier
A
party
that
is
verifiable
might
have
different
levels
of
trustworthiness
associated
with
it
by
different
parties.
Note
that
“trusted”
or
“authorized”
are
sometimes
used
as
synonyms
for
“verifiable”,
as
the
purpose
of
some
lists
is
to
assure
trust
or
authority.
This
paper
uses
the
word
“verifiable”
as
no
presumption
should
be
made
about
the
application
of
the
lists,
or
the
trust/authority
that
they
assure.
Verifiable
Issuer/Verifier
List
A
container
that
consists
of
a
set
of
Verifiable
Issuers
or
Verifiers
.
The
word
“list”
can
be
considered
synonymous
to
“register”,
depending
on
the
amount
of
governance,
assurances
and
authority
associated
with
it.
This
paper
uses
the
word
“list”
and
presumes
there
will
always
be
some
form
of
governance,
if
only
the
establishment
of
its
purpose
and
the
format
of
its
entries.
This
section
contains
criteria
that
can
be
used
to
determine
whether
something
does
or
does
not
fit
a
particular
terminological
definition
in
the
previous
section.
sharing
Enables
other
parties
to
obtain
a
copy
of
a
list
entry
about
an
Issuer
or
Verifier
from
the
list
,
e.g.
in
VC
format,
through
DNS
query,
or
other
mechanism.
May
or
may
not
enable
others
to
obtain
a
copy
of
the
full
contents
of
a
list
.
Those
others
may
be
anyone
in
the
world,
or
they
may
be
only
those
who
have
access
to
the
list
or
to
a
specific
entry
about
an
Issuer
or
Verifier
.
list
Contains
zero-or-more
entries
about
any
party
.
A
list
entry
contains
data
about
one
specific
party.
The
data
is
specified
by
the
party
that
governs
the
list
.
A
list
is
associated
with
a
policy
containing
one
or
more
criteria
that
are
used
to
determine
whether
or
not
a
party
qualifies
for
being
registered
in
the
list
.
Criterion
may
distinguish
between
parties
,
e.g.,
between
parties
that
are
trusted
to
issue
or
verify
VCs
of
a
specific
kind.
Other
parties
may
use
the
data
in
a
list
entry
as
the
basis
for
a
decision,
e.g.,
to
share
further
information,
or
to
engage
in
a
transaction.
The
perceived
use
of
list
entries
by
other
parties
should
guide
the
party
that
governs
the
list
as
it
specifies
the
structure
of
list
entries
.
parties
Are
expected
to
perform
the
roles
of
issuer
,
holder
,
and
verifier
as
well
as
other
verifiable-credential-related
roles
(e.g.,
revocator).
May
or
may
not
be
a
legal
authority.
The
party
that
manages
the
list
has
to
be
able
to
precisely
describe
the
thing
that
the
list
entry
enables
because
software
will
act
upon
that
machine-readable
description.
For
example,
"Issues
Student
ID
cards
for
University
X".
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
word
MUST
in
this
document
is
to
be
interpreted
as
described
in
BCP
14
[
RFC2119
]
[
RFC8174
]
when,
and
only
when,
it
appears
in
all
capitals,
as
shown
here.
A
conforming
list
is
any
concrete
expression
of
the
data
model
that
complies
with
the
normative
statements
in
this
specification.
Specifically,
all
relevant
normative
statements
in
Sections
4.
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
list
.
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.
Use
Cases
This
section
outlines
use
cases
that
highlight
the
need
for
the
technology
described
in
this
paper
by
discussing
the
use
cases
in
two
three
categories:
Verifiable
Issuers
Verifiable
Verifiers
Verifiable
Wallet
Providers
A
final
use
case
section
then
checks
for
commonalities
and
differences
between
the
two
categories
three
categories.
There
are
a
number
of
other
locations
that
have
published
use
cases
that
are
related
to
this
paper.
Rather
than
include
those
use
cases
in
this
document,
they
are
included
by
reference:
Acme
Inc.
is
a
producer
of
medical
equipment.
Twin
Mountains
Hospital
decided
to
buy
equipment
from
Acme
Inc.
The
law
says
that
medical
equipment
should
be
certified
by
a
3rd
party
certification
body.
Twin
Mountains
Hospital
requests
a
certification
from
Acme,
Inc.;
Twin
Mountains
Hospital
Acme
Inc.
Acme
Inc.
delivers
it
the
certificate
to
them.
The
hospital
then
checks
if
whether
Acme
Inc.
is
in
the
Verifiable
Issuer
List
of
licensed
3rd
party
certification
bodies
to
see
if
whether
the
Issuer
of
Acme
Inc.'s
certification
is
an
approved
certification
body.
Note:
The
solution
might
need
to
convey
a
single
item
in
a
List
vs.
the
entire
List.
Note:
Many
similar
certification/license
use
cases
are
out
there.
Walmay,
Inc.
is
a
wholesaler
of
drugs.
John
&
Jane
is
a
manufacturer
of
drugs.
Walmay,
Inc.
finds
out
that
a
lot
of
Adenosine
Triphosphate
drugs
has
have
broken
packaging
and
decides
to
return
the
lot
to
the
manufacturer.
It
is
required
that
all
interactions
in
the
drug
market
must
be
done
only
between
authorized
trading
partners.
John
&
Jane
requests
an
authorized
trading
partner
certificate
from
Walmay
Inc.
The
certificate
credential
contains
a
link
to
the
Issuer.
John
&
Jane
then
verifies
that
the
Issuer
is
a
member
of
the
Verifiable-Issuer
List
of
Issuers
authorized
to
issue
ATP
(Authorized
Trading
Partner)
credentials.
Elena
is
an
IT
Administrator
in
the
hiring
department
of
a
mid-size
company
that
would
like
to
vet
job
applicants
as
having
received
their
degrees
from
an
accredited
college
or
university.
Elena
configures
their
hiring
software
to
refer
to
multiple
lists
(Verifiable-Issuer
Lists)
containing
several
hundred
organizations
that
are
curated
by
the
various
accreditation
bodies
that
they
trust.
Line
is
elected
treasurer
of
a
Dutch
church.
In
her
role
as
treasurer,
she
goes
online
to
open
a
bank
account
for
the
church.
To
comply
with
certain
laws
and
adhere
to
internal
risk
mitigating
policies,
the
bank
needs
to
verify
that
Line
has
been
authorized
by
the
church
to
sign
on
its
behalf.
For
companies,
personal
information
about
executive
board
members
is
registered
by
the
Chamber
of
Commerce
alongside
the
registration
of
the
legal
entity.
However,
due
to
the
special
sensitive
nature
of
data
regarding
religious
affiliations,
the
Chamber
of
Commerce
in
the
case
of
religious
institutions
(mosque/synagogue/church)
is
prohibited
from
registering
any
data
that
can
be
correlated
with
a
natural
person.
Instead
of
checking
the
Chamber
of
Commerce
public
register,
the
bank
requests
a
credential
from
Line
stating
her
mandate
to
sign,
which
she
received
from
the
church.
The
bank
checks
whether
the
church
is
on
the
Verifiable
Issuer-List
of
Churches,
which
is
maintained
by
the
Chamber
of
Commerce.
Finding
the
church
on
the
list,
the
bank
is
now
able
to
open
a
bank
account
for
the
church,
which
Line
can
administer.
Figure
1:
A
Verifiable-Issuer
List
helps
verifying
whether
a
diploma
is
genuine.
Yuri
has
a
digital
driver's
license
and
is
attempting
to
rent
a
car
from
CarMart.
CarMart
requests
to
see
Yuri's
age,
motor
vehicle
class,
and
driver's
license
number.
Yuri's
software
checks
against
a
Verifiable-Verifier
List
to
make
sure
that
CarMart
is
a
Verifiable
authority
for
information
of
that
type,
so
it
can
warn
Yuri
if
CarMart
isn't
trusted
to
request
that
information
from
Yuri.
Oskar
joins
a
tennis
club.
The
tennis
club
requests
a
government-issued
proof
of
birth
date.
However,
the
tennis
club
does
not
have
authorization
to
ask
for
this
personal
information.
As
a
consequence,
Oskar’s
certified
EUDI
wallet
refuses
to
present
the
information,
based
on
the
absence
of
the
tennis
club
in
the
relevant
Verifiable-Verifier
List.
The
tennis
club
realizes
that
they
cannot
obtain
this
high-LoA
information
from
the
EUDI
wallet
and
instead
accepts
a
self-asserted
date-of-birth
by
Oskar.
Oskar
was
invited
by
the
European
Commission
to
become
an
evaluator.
Even
though
Oskar
would
be
paid
only
the
equivalent
of
a
book
voucher,
the
EC
requires
a
full
contracting
process,
which
includes
an
eIDAS
LoA
high
identification
and
a
recent
authentic
bank
statement.
Even
though
Oskar
considers
these
requirements
unreasonable,
Oskar’s
certified
EUDI
wallet
accepts
the
request,
as
the
EC
is
registered
in
the
relevant
Verifiable-Verifier
List.
This
way,
Oskar
knows
at
least
that
the
request
is
genuine,
and
that
there
exists
a
sufficiently-well-governed
policy
associated
with
the
request.
Oskar
crosses
the
border
to
Dystopia.
Immigration
requests
that
Oskar
surrender
all
Verifiable
Credentials
in
his
SSI
wallet,
including
identification,
driver’s
license,
diplomas,
certifications
and
other
records.
Immigration
of
this
country
is
not
authorized
to
make
such
a
wide
request,
as
it
is
not
included
in
the
relevant
Verifiable-Verifier
List.
As
a
consequence,
Oskar’s
certified
EUDI
wallet
refuses
to
present
this
information.
Even
the
threat
of
denial-of-entry
or
worse
cannot
change
the
situation,
as
neither
immigration
nor
Oskar
himself
is
physically
able
to
compromise
Oskar’s
EUDI
wallet
to
surrender
the
information.
Figure
2:
A
properly-implemented
wallet
with
Verifiable-Verifier
List
protects
citizens
against
overzealous
law
enforcement.
2.3
Verifiable
Wallet
Provider
Use
Cases
David
requests
a
driving
license
from
his
national
driving
license
authority
(DLA).
The
DLA
interrogates
David's
wallet,
and
finds
out
that
the
software
was
not
written
by
a
trusted
software
supplier,
so
it
refuses
to
issue
the
driving
license
to
this
wallet.
David
then
installs
a
certified
EUDI
wallet
on
his
device,
and
repeats
the
request
to
the
DLA.
This
time
the
DLA
is
able
to
obtain
the
certificate
issued
to
the
wallet,
and
it
duly
issues
the
driving
license
to
David's
EUDI
wallet.
2.4
Commonalities
and
Differences
Conceptually
and
technically,
the
two
three
types
of
lists
(Verifiable
Issuer,
Verifiable
Verifier)
Verifier,
and
Verifiable
Wallet
Provider)
are
fairly
similar.
Each
type
is
a
governed
list
of
parties
with
a
role
in
SSI
exchanges.
Each
type
needs
to
provide
some
form
of
sharing
(publication/access),
so
that
the
list
is
available
to
its
users.
This
paper
will
presume
specification
presumes
that
the
types
of
lists
themselves,
as
well
as
their
sharing
methods,
can
be
technically
identical.
The
only
distinction
is
that
a
list
could
might
contain
only
Verifiable
Issuers,
only
Verifiable
Verifiers,
only
Verifiable
Wallet
Providers,
or
a
mixture
2
some
combination
of
both,
so
these.
Consequently,
the
data
model
should
accommodate
this.
Major
differences
arise
in
the
applications
surrounding
the
lists.
Verifiable
Issuer
lists
target
Verifier
and
Wallet
implementations,
whereas
Verifiable
Verifier
lists
target
Holder
(digital
wallet)
implementations.
Also
there
may
Holder/Wallet
implementations,
and
Verifiable
Wallet
Provider
lists
target
Issuers.
There
might
also
be
major
differences
in
the
governance
between
the
two
types
of
lists,
or
whether/how
each
type
of
list,
and/or
whether
and/or
how
the
consulting
of
these
lists
is
implemented
and
enforced.
All
of
these
differences
are
out
of
outside
the
scope
of
this
paper.
specification.
3.
Requirements
3.1
Conceptual
Model
An
Assurance
Community
is
what
governs
a
list
of
Verifiable
Issuers
and/or
Verifiers.
The
community
can
consist
of
a
single
person,
a
group
of
people,
an
organization,
a
group
of
organizations,
or
any
other
relevant
structure.
The
governing
can
be
purely
manual,
partially
automated,
or
completely
automated
through
the
use
of
APIs
or
smart
contracts.
A
list
of
Verifiable
Issuers
and/or
Verifiable
Verifiers
contains
entries
with
information
about
the
Issuers
and/or
Verifiers
that
it
verifies.This
information
can
be
as
minimal
as
a
single
DID
or
public
key
per
Verifiable
Issuer
or
Verifiable
Verifier,
or
it
can
also
include
metadata
about
each
entity
and
the
services
that
each
entity
performs.
An
Interested
Party
is
an
entity
that
uses
one
or
more
entries
from
the
List
of
Verifiable
Issuers
and/or
Verifiable
Verifiers
in
a
decision
making
process.
An
interested
party
is
typically
software
that
is
acting
on
behalf
of
an
Issuer,
Holder,
or
Verifier.
The
party
might
request
the
entire
List,
or
portions
of
the
List
over
either
a
public
channel,
or
a
private
channel.
3.2
Requirements
The
following
requirements
have
been
specified
by
the
authors.
It
includes
both
requirements
on
a
Verifiable-Issuers/Verifiers
List
(“a
list”
in
short)
as
a
whole
and
its
individual
entries.
These
requirements
may
be
updated
in
the
future.
A
list
may
be
created
and
governed
by
any
individual,
group
of
individuals,
organization,
group
of
organizations,
or
other.
A
list
and/or
its
entries
shall
be
made
available
to
subscribers.
A
list
and/or
its
individual
entries
shall
be
serializable
in
one
or
more
formats
such
as
a
Verifiable
Credential.
Entries
may
be
made
available
via
a
Wallet,
a
Website,
a
URI,
a
QR
code,
a
DNS
Resource
Records,
DNSSEC,
on-chain
Ethereum
transactions,
or
other
methods.
A
list
and
its
entries
shall
be
cryptographically
verifiable.
A
list
shall
accommodate
Different
cryptographic
mechanisms
(X.509,
JWK
etc.).
There
shall
be
an
ability
to
authenticate
the
list
or
an
individual
entry.
A
list
and
its
entries
shall
have
associated
Governance
Metadata
Format,
including:
Policies;
and
Qualifier
details.
A
list
and
its
entries
shall
be
publicly
resolvable.
A
list
and
its
entries
shall
be
privately
transmittable/retrievable.
A
list
may
have
metadata
associated
with
it,
e.g.,
metadata
that
is
applicable
to
all
of
its
entries.
A
list
may
have
different
levels
of
privacy/confidentiality,
ranging
from
fully
public
to
for-authorized-yes-only.
Entries
shall
be
able
to
be
created,
read,
and
deleted.
Entries
may
be
updated,
suspended
and/or
revoked.
Entries
may
have
an
individual
level
of
assurance
associated
with
it.
Entries
may
have
an
associated
level
of
assurance.
Issue
1
The
only
technology
approach
that
we
were
not
able
to
analyze
deeply
is
Trinsic's
approach.
We
need
to
make
sure
their
approach
is
integrated
into
and
aligned
with
the
documented
use
cases,
requirements,
and
the
rest
of
the
document.
4.
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
orgnaizations
that
provides
services
such
as
credential
issuance
or
validation.
The
Data
Model
also
contains
the
details
of
the
list
operator
informations.
4.1
Overview
of
List
Operator
The
List
Operator
provides
a
framework
for
managing
a
trusted
list,
which
includes
essential
information
about
the
entity
responsible
for
the
list's
maintenance
and
its
associated
attributes.
4.1.1
Attributes
of
List
Operator
ListOperatorInformation:
Provides
a
set
of
information
about
the
owner
of
the
trusted
list.
TSLVersionIdentifier:
Specifies
the
version
of
the
TL
format.
TSLSequenceNumber:
Sequence
number
of
the
TL,
starting
at
1,
incremented
at
each
release.
TSLType:
Specifies
the
type
of
the
trusted
list,
set
to
"https://w3c.org/ccg/TSLv1".
ListOperatorName:
Name
of
the
entity
responsible
for
establishing,
publishing,
signing,
and
maintaining
the
trusted
list.
ListOperatorAddress:
Postal
address
of
the
legal
entity
or
mandated
organization
identified
by
the
list
operator
name.
ElectronicAddress:
Email
address
of
the
list
operator.
WebSite:
Website
URI
of
the
list
operator.
ListName:
Name
under
which
the
list
operates.
ListInformationURIs:
Set
of
URIs
for
obtaining
list-specific
information.
ListTerritory:
Country
or
territory
where
the
scheme
is
established,
preferably
as
ISO
country
codes.
PolicyOrLegalNotice:
Policy
or
legal
notice
concerning
the
list's
status
or
legal
requirements.
IssuedAt:
UTC
date/time
when
the
list
was
issued.
NextUpdate:
UTC
date/time
by
which
an
update
of
the
TL
will
be
available,
or
null
for
a
closed
TL.
DistributionPoints:
Locations
where
the
current
TL
is
published
and
updates
can
be
found.
4.2
Overview
of
Trust
Service
Provider
Each
list
entry,
representing
a
service
provider,
contains
the
following
mandatory
information:
An
identifier
The
type,
such
as
a
"VerifiableIssuer"
or
"VerifiableVerifier"
A
human-readable
name
Each
list
entry,
representing
a
party,
might
contain
the
following
optional
information:
A
legal
name
An
associated
website
An
email
address
A
set
of
identifiers
that
specify
a
human
readable
name
for
the
property
and
its
corresponding
value
A
set
of
operational
schemes,
such
as
a
trust
scheme,
under
which
it
operates,
stored
as
tuples
of
a
URL
to
the
operational
scheme
and
a
human-readable
name.
A
set
of
accreditations
that
are
identified
by
URL
A
set
of
credentials
that
the
party
is
authorized
to
issue,
verify,
or
otherwise
process
where
each
credential
description
MUST
contain:
A
type
A
credential
schema
that
can
be
used
to
match
against
a
Verifiable
Credential
4.2.1
Attributes
of
Trust
Service
Provider
TrustServiceProviderList:
Set
containing
the
list
of
TSPs
and
their
approved
trust
services.
TrustServiceProvider:
Object
containing
information
about
one
TSP
and
its
trust
services.
TSPInfo:
Object
containing
information
about
the
TSP.
UUID:
UUID
of
the
TSP.
TSPName:
Legal
name
of
the
TSP.
TSPTradeName:
Trade
name
of
the
TSP.
TSPAddress:
Postal
address
of
the
TSP.
TSPEmail:
Email
address
of
the
TSP.
TSPCertifications:
Set
of
certifications
of
the
TSP,
e.g.,
ISO
27001.
Each
certification
comprises
a
type
and
a
value.
TSPIdentifiers:
Set
of
identifiers
of
the
TSP,
e.g.,
LEI,
company
registration
numbers.
Each
identifier
comprises
a
type
and
a
value.
TSPURIs:
URI(s)
where
users
can
obtain
TSP-specific
information.
TSPServices:
Set
of
services
provided
by
the
TSP.
TSPService:
Object
detailing
one
service
provided
by
the
TSP.
ServiceTypeIdentifier:
URI
indicating
the
type
of
service
provided
by
the
TSP,
such
as:
https://w3c.org/ccg/st/trusted_issuer
-
TSP
that
issues
certificates
to
users.
https://w3c.org/ccg/st/trusted_verifier
-
TSP
that
requests
certificates
from
users.
ServiceName:
Name
under
which
the
TSP
provides
the
service.
ServiceCurrentStatus:
Current
status
of
the
service
("Active"
or
"Withdrawn").
StatusStartingTime:
UTC
date
and
time
when
the
current
status
became
effective.
ServiceDigitalIdentity:
Digital
identifier(s)
that
unambiguously
identify
the
service
with
the
name
and
type
associated.
ServiceDefinitionURIs:
Set
of
URI(s)
for
obtaining
service-specific
information
from
the
TL
operator.
ServiceSupplyPoints:
URIs
where
relying
parties
can
access
the
service.
AdditionalServiceInformation:
Object
specifying
additional
information
about
the
service,
such
as:
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):
Some
of
the
imagery
in
this
specification
was
provided
by
Ron
Lach
and
Kindel
Media
under
the
Pexel's
license
.
We
are
thankful
to
those
individuals
and
Pexels
for
providing
imagery
that
this
community
could
use
and
have
made
donations
to
each
of
those
contributors.
