This
specification
defines
how
to
secure
credentials
and
presentations
conforming
to
the
[
VC-DATA-MODEL
],
with
JSON
Object
Signing
and
Encryption
(
JOSE
),
and
CBOR
Object
Signing
and
Encryption
(COSE)
[
RFC9052
].
This
enables
the
Verifiable
Credential
data
model
[
VC-DATA-MODEL
]to
be
implemented
with
standards
for
signing
and
encryption
that
are
widely
adopted.
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-jose-cose/
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/.
Publication
as
a
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
describes
how
to
secure
media
types
expressing
Verifiable
Credentials
and
Verifiable
Presentations
as
described
in
the
[
VC-DATA-MODEL
],
using
approaches
described
by
the
OAUTH,
JOSE,
and
COSE
working
groups
at
IETF.
This
includes
JWTs
[
RFC7519
],
JWS
[
RFC7515
],
SD-JWT
[
SD-JWT
],
and
COSE
[
RFC9052
],
and
provides
an
approach
using
well-defined
content
types
[
RFC6838
]
and
structured
suffixes
[
MULTIPLE-SUFFIXES
]
to
distinguish
the
data
types
of
documents
conforming
to
[
VC-DATA-MODEL
]
from
the
data
types
of
secured
documents
conforming
to
[
VC-DATA-MODEL
],
defined
in
this
specification.
JSON
Web
Signatures
(JWS)
Selective
Disclosure
JWT
(SD-JWT)
[
RFC7515
SD-JWT
]
provide
provides
a
standardized
mechanism
for
digitally
signing
JSON
documents.
It
provides
a
means
to
ensure
the
integrity,
authenticity,
selective
disclosure
and
non-repudiation
of
the
information
contained
in
a
JSON
document.
JWS
enables
secure
communication
and
trust
between
parties
by
adding
a
cryptographic
signature
to
a
payload.
This
signature
is
generated
using
a
private
key
and
can
be
verified
using
the
corresponding
public
key.
JWS
enables
content
integrity,
authentication
and
non
repudiation,
protecting
data
from
unauthorized
modifications.
The
versatility
and
wide
adoption
of
JWS
make
it
an
essential
component
for
verifying
the
authenticity
and
integrity
of
various
application
media
types,
including
authentication,
authorization,
and
secure
data
exchange.
These
properties
make
JWS
SD-JWT
especially
well
suited
to
securing
the
JSON-LD
[
VC-DATA-MODEL
]
and
through
this
to
provide
a
means
of
supporting
the
three
party
model
(issuer,
holder,
verifier)
for
exchange
of
verifiable
credentials
and
verifiable
presentations.
JSON
Web
Token
(JWT)
[
RFC7519
]
is
a
widely-used
means
of
expressing
claims
,
represented
in
JSON,
to
be
transferred
between
two
parties.
Providing
a
representation
of
the
[
VC-DATA-MODEL
]
for
JWT
allows
existing
systems
and
libraries
to
participate
in
the
ecosystem
described
in
Section
ecosystem
overview
.
A
JWT
encodes
a
set
of
claims
as
a
JSON
object
that
is
secured
via
a
JSON
Web
Signature
(JWS)
[
RFC7515
]
and/or
JSON
Web
Encryption
(JWE)
[
RFC7516
].
For
this
specification,
the
use
of
JWE
is
out
of
scope.
CBOR
Object
Signing
and
Encryption
(COSE)
[
RFC9052
]
is
a
specification
that
defines
a
framework
for
representing
signed
and
encrypted
data
using
(Concise
Binary
Object
Representation)
[RFC8949]
data
structures.
COSE
provides
a
standardized
way
to
secure
the
integrity,
authenticity,
and
confidentiality
of
CBOR-encoded
information.
It
offers
a
flexible
and
extensible
set
of
cryptographic
options,
allowing
for
a
wide
range
of
algorithms
to
be
used
for
signing
and
encryption.
COSE
supports
two
main
operations:
signing
and
encryption.
For
signing,
COSE
allows
the
creation
of
digital
signatures
over
CBOR
data
using
various
algorithms
such
as
HMAC,
RSA,
ECDSA,
or
EdDSA.
These
signatures
provide
assurance
of
data
integrity
and
authenticity.
COSE
also
supports
encryption,
enabling
the
confidentiality
of
CBOR
data
by
encrypting
it
with
symmetric
or
asymmetric
encryption
algorithms.
2.
Securing
the
VC
Data
Model
This
section
outlines
how
to
secure
documents
conforming
to
the
[
VC-DATA-MODEL
]
using
JOSE
and
COSE.
Documents
conforming
to
the
[
VC-DATA-MODEL
],
and
their
associated
media
types,
rely
on
JSON-LD,
which
is
a
flexible
and
extensible
format
for
describing
linked
data,
see
JSON-LD
Relationship
to
RDF
.
A
benefit
to
this
approach
is
that
payloads
can
be
made
to
conform
directly
to
the
[
VC-DATA-MODEL
]
without
any
mappings
or
transformation,
while
at
the
same
time
supporting
registered
claims
that
are
understood
in
the
context
of
JOSE
and
COSE.
The
most
specific
media
type
(or
subtype)
available
SHOULD
be
used,
instead
of
more
generic
media
types
(or
supertypes).
For
example,
rather
than
the
general
application/sd-jwt
,
application/vc+ld+json+sd-jwt
ought
to
be
used,
unless
there
is
a
more
specific
media
type
that
would
even
better
identify
the
secured
envelope
format.
If
implementations
do
not
know
which
media
type
to
use,
media
types
defined
in
this
specification
MUST
be
used.
2.1
With
JOSE
2.1.1
Securing
JSON-LD
Verifiable
Credentials
with
JOSE
This
section
details
how
to
secure
data
payloads
with
the
type
application/vc+ld+json
with
JOSE.
[
rfc7515
]
MAY
be
used
to
secure
this
media
type.
COSE
[
rfc9052
]
is
a
common
approach
to
encoding
and
securing
information
using
CBOR
[
rfc8949
].
Verifiable
credentials
MAY
be
secured
using
COSE
[
rfc9052
]
and
SHOULD
be
identified
through
use
of
content
types
as
outlined
in
this
section.
2.2.1
Securing
JSON-LD
VCs
with
COSE
This
section
details
how
to
secure
data
with
the
type
application/vc+ld+json
with
COSE.
[
rfc9052
]
MAY
be
used
to
secure
this
media
type.
When
using
this
approach,
the
type
(TBD)
SHOULD
be
vc+ld+json+cose
This
prevents
following
the
guidance
from
the
JWT
BCP
3.
Wallets
This
section
is
non-normative.
Issuers
,
holders
and
verifiers
might
rely
on
clients,
as
defined
in
RFC4949
.
Such
clients
are
often
referred
to
as
wallets
or
digital
credential
wallets
,
when
they
support
storing
and
presenting
digital
credentials.
In
order
to
meet
verifier
requirements,
some
issuers
might
need
to
assess
the
quality
of
a
wallet
used
by
a
holder
,
prior
to
issuing
and
delivering
credentials
to
a
holder
.
If
<code>kid</code>
is
also
present,
it
is
expected
to
be
useful
to
distinguish
the
specific
key
used.
--
in
response
to
which
I
ask
--
how
is
kid
to
be
useful
to
distinguish
the
specific
key
used
?
This
cries
out
for
an
example,
or
a
fair
amount
of
additional
prose.
Issue 106: Explain relationship between controller documents and JOSE headers
Just read that section, and I have to say that it's not intuitive at all. I think it would be worth either: adding an example that refers to this controller document, pointing to the spec you mentioned, or explicitly stating the relationship between controller docs and `iss` & `kid`.
kid
MAY
be
used
if
there
are
multiple
keys
associated
with
the
issuer
of
the
JWT.
The
key
discovery
is
out
of
the
scope
of
this
specification.
For
example,
the
kid
can
refer
to
a
key
in
a
DID
document
,
or
can
be
the
identifier
of
a
key
inside
a
JWKS.
I'd
like
some
clarification
on
the
optionality
of
the
"kid"
field.
My
guess
is
that
VCs/VPs
are
trying
to
be
generic
regarding
issuers/holders,
allowing
for
URIs,
which
precludes
the
possibility
of
giving
any
more
details
about
how
the
"kid"
field
should
be
used.
Is
that
right?
I'm
coming
from
a
DID-centric
ecosystem,
and
in
that
scenario
it
seems
that
there's
no
reason
not
to
set
the
"kid"
field
on
a
JWT-formatted
VC/VP
to
the
DID
fragment
URL
of
the
specific
key
used
to
sign.
From
w3c/vc-data-model#914
I
understand
that
it
would
still
be
necessary
to
tie
the
"kid"
to
the
"iss"
field,
but
that
seems
fine.
As
far
as
I
can
tell,
if
the
"kid"
field
is
missing,
and
assuming
we're
working
with
DIDs
here,
the
process
to
resolve
the
signing
key
has
to
be:
Identify
the
VC
issuer
/
holder
--
the
"iss"
field
of
the
JWT.
This
should
be
a
DID.
(Question:
Could
this
validly
include
query
params
such
as
versionTime?)
Resolve
the
DID
document
for
that
DID.
For
each
key
with
purpose
"authentication",
attempt
to
verify
the
VC/VP's
signature
using
that
key.
If
one
of
the
keys
verifies
the
signature,
accept
the
VP/VC's
signature
as
valid.
Otherwise
reject
it
as
invalid.
To
me,
this
seems
sloppy,
involving
unnecessary
complexity
and
computation,
and
making
detecting
errors
in
implementations
harder.
It
also
wouldn't
scale
if
for
whatever
reason
a
DID
had
very
many
keys
(inefficient
at
best,
possible
DoS
at
worst).
Maybe
I'm
missing
something
here.
Can
anyone
comment
on
this?
Thanks.
Issue
30
:
Accept
or
Dismiss
the
guidance
provided
by
DIF
on
`kid`
/
`iss`
discuss
Can
we
add
an
explanation
why
do
these
members
need
to
be
translated
to
the
equivalents
of
the
JWT
claims?
iss,
nbf,
all
of
them
are
optional
in
RFC
7519
itself.
They
only
become
required
when
the
JWT
is
used
for
a
specific
purpose,
and
the
only
place
I
can
think
of
right
now
is
an
ID
Token.
The
OIDC
Configuration
Endpoint
URL
is
dereferenced
to
a
JSON
document
which
contains
issuer
configuration
details,
one
of
which
is
the
jwks_uri
.
This
URL
might
also
be
well-known,
for
example:
The
verifier
(or
relying
party)
uses
kid
from
the
protected
header
of
the
JWT
to
identify
the
public
key,
controlled
by
the
issuer,
and
uses
it
to
verify
the
token.
The
verifier
(or
relying
party)
verifies
the
signature
on
the
JWT.
After
verification,
the
claims
the
issuer
has
made
about
the
subject
can
be
reviewed
or
processed,
because
the
integrity
of
the
claims
has
been
protected
by
a
digital
signature
verification.
Additional
members
may
be
present,
if
they
are
not
understood,
they
MUST
be
ignored.
6.
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
,
MUST
NOT
,
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.
The
normative
statements
in
Securing
Verifiable
Credentials
apply
to
securing
application/vc+ld+json
and
application/vp+ld+json
as
application/vc+ld+json+jwt
application/vc+ld+json+sd-jwt
and
application/vp+ld+json+jwt
application/vp+ld+json+sd-jwt
.
For
clarity,
these
requirements
are
repeated
here:
At
least
one
securing
mechanism,
and
the
details
necessary
to
evaluate
it,
MUST
be
expressed
for
a
credential
or
presentation
to
be
a
verifiable
credential
or
verifiable
presentation;
that
is,
to
be
verifiable.
Methods
of
securing
credentials
or
presentations
that
embed
a
proof
in
the
data
model
MUST
use
the
proof
property.
Methods
of
securing
credentials
or
presentations
that
use
an
external
proof
MAY
use
the
proof
property.
One
or
more
cryptographic
proofs
that
can
be
used
to
detect
tampering
and
verify
the
authorship
of
a
credential
or
presentation.
The
specific
method
used
for
an
embedded
proof
MUST
be
included
using
the
type
property.
The
type
VerifiableCredential
and
VerifiablePresentation
are
RDF
Classes.
The
presence
of
the
word
"Verifiable"
does
not
convey
a
cryptographic
verification
capability
exists.
The
presence
of
the
JSON
proof
member
does
not
convey
a
cryptographic
verification
capability
exists.
The
presence
of
the
JSON
proof
member
is
optional
in
both
VerifiableCredential
and
VerifiablePresentation
.
The
presence
of
the
JSON
proof
member
is
optional
in
both
application/vc+ld+json
and
application/vp+ld+json
.
Accordingly,
Issuers,
Holders
and
Verifiers
MUST
understand
the
JSON
Web
Token
header
parameter
"alg":
"none"
when
securing
the
[
VC-DATA-MODEL
]
with
JSON
Web
Tokens.
When
content
types
from
the
[
VC-DATA-MODEL
]
are
secured
using
JSON
Web
Tokens,
the
header
parameter
"alg":
"none"
,
MUST
be
used
to
communicate
that
a
claimset
(a
Verifiable
Credential
or
a
Verifiable
Presentation)
has
no
integrity
protection.
When
a
JSON
Web
Token
claimset
(a
Verifiable
Credential
or
a
Verifiable
Presentation)
contains
proof
,
and
the
JSON
Web
Token
header
contains
"alg":
"none"
,
the
claimset
MUST
be
considered
to
have
no
integrity
protection.
Verifiable
Credentials
and
Verifiable
Presenatations
are
not
required
to
be
secured
or
integrity
protected
or
to
contain
a
proof
member.
Issuers,
Holders
and
Verifiers
MUST
ignore
all
claimsets
that
have
no
integrity
protection.
This
specification
registers
the
application/vc+ld+json+jwt
application/vc+ld+json+sd-jwt
Media
Type
specifically
for
identifying
a
Verifiable
Credential
that
has
been
secured
using
a
JWT
.
Type
name:
application
Subtype
name:
vc+ld+json+jwt
Required
parameters:
None
Encoding
considerations:
application/vc+ld+json+jwt
values
are
encoded
as
a
series
of
base64url
encoded
values
(some
of
which
may
be
the
empty
string)
each
separated
from
the
next
by
a
single
period
('.')
character.
Security
considerations:
As
defined
in
this
specification.
See
also
the
security
considerations
in
[
RFC7519
Selective
Disclosure
for
JWTs
(SD-JWT)
].
Contact:
W3C
Verifiable
Credentials
Working
Group
public-vc-wg@w3.org
7.1.2
application/vp+ld+json+jwt
This
specification
registers
conforming
to
the
application/vp+ld+json+jwt
Media
Type
for
identifying
a
Verifiable
Presentation
that
has
been
secured
using
a
JWT
.
Credentials.
Type
name:
application
Subtype
name:
vp+ld+json+jwt
vc+ld+json+sd-jwt
Required
parameters:
None
Encoding
considerations:
application/vp+ld+json+jwt
binary;
application/sd-jwt
values
are
encoded
as
a
series
of
base64url
encoded
base64url-encoded
values
(some
of
which
may
be
the
empty
string)
each
separated
from
the
next
by
a
single
period
('.')
character.
or
tilde
('~')
characters.
Security
considerations:
As
defined
in
this
specification.
See
also
the
security
considerations
in
[
RFC7519
].
Be
advised,
per
the
[
VC-DATA-MODEL
Selective
Disclosure
for
JWTs
(SD-JWT)
],
verifiable
presentations
are
not
required
to
be
secured.
This
"typ"
value
might
be
paired
with
"alg:
none",
in
headers.
.
This
specification
registers
the
application/vc+ld+json+sd-jwt
application/vp+ld+json+sd-jwt
Media
Type
specifically
for
identifying
a
Selective
Disclosure
for
JWTs
(SD-JWT)
conforming
to
the
Verifiable
Credentials.
Presentations.
Type
name:
application
Subtype
name:
vc+ld+json+sd-jwt
vp+ld+json+sd-jwt
Required
parameters:
None
Encoding
considerations:
binary;
application/sd-jwt
values
are
a
series
of
base64url-encoded
values
(some
of
which
may
be
the
empty
string)
separated
by
period
('.')
or
tilde
('~')
characters.
This
section
retains
deprecated
registered
claim
names
that
were
previously
submitted
to
the
Internet
Engineering
Steering
Group
(IESG)
for
review,
approval,
and
registration
with
IANA
in
the
"JSON
Web
Token
Claims
Registry".
Verifiable
Credentials
often
contain
sensitive
information
that
needs
to
be
protected
to
ensure
the
privacy
and
security
of
organizations
and
individuals.
This
section
outlines
some
privacy
considerations
relevant
to
implementers
and
users.
Implementers
are
advised
to
note
and
abide
by
all
privacy
considerations
called
out
in
the
[
VC-DATA-MODEL
].
Implementers
are
additionally
advised
to
reference
the
Privacy
Consideration
section
of
the
JWT
specification
for
privacy
guidance.
In
addition
to
the
privacy
recommendations
in
the
[
VC-DATA-MODEL
],
the
following
considerations
are
given:
Minimization
of
data:
It
is
considered
best
practice
for
Verifiable
Credentials
to
only
contain
the
minimum
amount
of
data
necessary
to
achieve
their
intended
purpose.
This
helps
to
limit
the
amount
of
sensitive
information
that
is
shared
or
stored
unnecessarily.
Informed
consent:
It
is
considered
best
practice
that
individuals
be
fully
informed
about
how
their
data
will
be
used
and
provide
the
ability
to
consent
to
or
decline
the
use
of
their
data.
This
helps
to
ensure
that
individuals
maintain
control
over
their
own
personal
information.
Data
protection:
It
is
considered
best
practice
to
protect
Verifiable
Credentials
using
strong
encryption
and
other
security
measures
to
prevent
unauthorized
access,
modification,
or
disclosure.
These
considerations
are
not
exhaustive,
and
implementers
and
users
are
advised
to
consult
additional
privacy
resources
and
best
practices
to
ensure
the
privacy
and
security
of
Verifiable
Credentials
implemented
using
VC-JWT.
8.2
Security
Considerations
This
section
outlines
security
considerations
for
implementers
and
users
of
this
specification.
It
is
important
to
carefully
consider
these
factors
to
ensure
the
security
and
integrity
of
Verifiable
Credentials
when
implemented
using
JWTs.
When
implementing
VC-JWTs,
it
is
essential
to
address
all
security
issues
relevant
to
broad
cryptographic
applications.
This
especially
includes
protecting
the
user's
asymmetric
private
and
symmetric
secret
keys,
as
well
as
employing
countermeasures
against
various
attacks.
Failure
to
adequately
address
these
issues
could
compromise
the
security
and
integrity
of
Verifiable
Credentials,
potentially
leading
to
unauthorized
access,
modification,
or
disclosure
of
sensitive
information.
Implementers
are
advised
to
follow
best
practices
and
established
cryptographic
standards
to
ensure
the
secure
handling
of
keys
and
other
sensitive
data.
Additionally,
conduct
regular
security
assessments
and
audits
to
identify
and
address
any
vulnerabilities
or
threats.
Follow
all
security
considerations
outlined
in
[
rfc7515
]
and
[
rfc7519
].
When
utilizing
JSON-LD,
take
special
care
around
remote
retrieval
of
contexts
and
follow
the
additional
security
considerations
noted
in
[
json-ld11
].
As
noted
in
[
rfc7515
]
when
utilizing
JSON
[
rfc7159
],
strict
validation
is
a
security
requirement.
If
malformed
JSON
is
received,
it
may
be
impossible
to
reliably
interpret
the
producer's
intent,
potentially
leading
to
ambiguous
or
exploitable
situations.
To
prevent
these
risks,
it
is
essential
to
use
a
JSON
parser
that
strictly
validates
the
syntax
of
all
input
data.
It
is
essential
that
any
JSON
inputs
that
do
not
conform
to
the
JSON-text
syntax
defined
in
[
rfc7159
]
be
rejected
in
their
entirety
by
JSON
parsers.
Failure
to
reject
invalid
input
could
compromise
the
security
and
integrity
of
Verifiable
Credentials.
8.3
Accessibility
This
section
is
non-normative.
When
implementing
the
VC-JWT
this
specification,
it
is
crucial
for
technical
implementers
to
consider
various
accessibility
factors.
Ignoring
accessibility
concerns
renders
the
information
unusable
for
a
significant
portion
of
the
population.
To
ensure
equal
access
for
all
individuals,
regardless
of
their
abilities,
it
is
vital
to
adhere
to
accessibility
guidelines
and
standards,
such
as
the
Web
Content
Accessibility
Guidelines
(WCAG
2.1)
[
WCAG21
].
This
becomes
even
more
critical
when
establishing
systems
that
involve
cryptography,
as
they
have
historically
posed
challenges
for
assistive
technologies.
Implementers
are
advised
to
note
and
abide
by
all
accessibility
considerations
called
out
in
the
[
VC-DATA-MODEL
].
8.4
Internationalization
This
section
is
non-normative.
Implementers
should
take
into
account
several
internationalization
considerations
when
publishing
data
described
in
this
specification.
Disregarding
internationalization
hampers
the
production
and
consumption
of
data
across
diverse
languages
and
societies,
thereby
restricting
the
applicability
and
significantly
reducing
the
value
of
the
specification
as
a
standard.
Implementers
are
advised
to
note
and
abide
by
all
internationalization
considerations
called
out
in
the
[
VC-DATA-MODEL
],
see
also
i18n
,
URL
Standard
9.
Appendix
This
section
is
non-normative.
9.1
Controllers
Example
9
:
A
verifiable
credential
controller
document
9.6
Selective
Disclosure
The
following
examples
are
taken
from
Selective
Disclosure
for
JWTs
(SD-JWT)
.
Issue
These
example
are
from
a
work
in
progress
draft.
An
issuer
might
start
with
a
vc+ld+json
claimset,
for
example:
Example
23
{
: [
,
],
: [
,
],
,
,
,
,
,
: {
: {
,
,
,
},
,
,
,
,
: {
,
,
,
,
},
,
,
,
}
}
The
issuer
converts
this
claimset
into
the
SD-JWT
payload,
and
encodes
the
token,
for
example:
Example
24
eyJhbGciOiAiRVMyNTYifQ.eyJpc3MiOiAiaHR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1Z
XIiLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6IDE4ODMwMDAwMDAsICJAY29udGV4d
CI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0c
HM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJsZ
UNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjogI
mh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIzL
TAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDExO
jAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRlI
iwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRlI
iwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhiW
lk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3N
GdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5e
DFYc3RJaVM2QjFZYmwySlo0IiwgIlRDbXpybDdLMmdldl9kdTdwY01JeXpSTEhwLVllZ
y1GbF9jeHRyVXZQeGciLCAiVjdrSkJMSzc4VG1WRE9tcmZKN1p1VVBIdUtfMmNjN3laU
mE0cVYxdHh3TSIsICJiMGVVc3ZHUC1PRERkRm9ZNE5semxYYzN0RHNsV0p0Q0pGNzVOd
zhPal9nIiwgInpKS19lU01YandNOGRYbU1aTG5JOEZHTTA4ekozX3ViR2VFTUotNVRCe
TAiXSwgInZhY2NpbmUiOiB7Il9zZCI6IFsiMWNGNWhMd2toTU5JYXFmV0pyWEk3Tk1XZ
WRMLTlmNlkyUEE1MnlQalNaSSIsICJIaXk2V1d1ZUxENWJuMTYyOTh0UHY3R1hobWxkT
URPVG5CaS1DWmJwaE5vIiwgIkxiMDI3cTY5MWpYWGwtakM3M3ZpOGViT2o5c214M0MtX
29nN2dBNFRCUUUiXSwgInR5cGUiOiAiVmFjY2luZSJ9LCAicmVjaXBpZW50IjogeyJfc
2QiOiBbIjFsU1FCTlkyNHEwVGg2T0d6dGhxLTctNGw2Y0FheHJZWE9HWnBlV19sbkEiL
CAiM256THE4MU0yb04wNndkdjFzaEh2T0VKVnhaNUtMbWREa0hFREpBQldFSSIsICJQb
jFzV2kwNkc0TEpybm4tX1JUMFJiTV9IVGR4blBKUXVYMmZ6V3ZfSk9VIiwgImxGOXV6Z
HN3N0hwbEdMYzcxNFRyNFdPN01HSnphN3R0N1FGbGVDWDRJdHciXSwgInR5cGUiOiAiV
mFjY2luZVJlY2lwaWVudCJ9LCAidHlwZSI6ICJWYWNjaW5hdGlvbkV2ZW50In0sICJfc
2RfYWxnIjogInNoYS0yNTYifQ.5jJEqiRViN_DJ4VMxHQIN4KK-Cdfn30nY3nRe5jGxS
5Pths5G7mF1GWy9TawYuyFwCze7qiCIx_MhJ68Uu5zeQ~WyIyR0xDNDJzS1F2ZUNmR2Z
yeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9nM2dTTklJOEVZbn
N4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW
9kZXJuYSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvc
ml6YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0~WyJlSThaV205UW5LUHBOU
GVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRhdGUiLCAiMjAyMS0wOC0xNlQxMzo0M
DoxMloiXQ~WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2Npbm
F0aW9uIiwgIkdFIl0~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2
NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyJQYzMzSk0yTGNoY1VfbE
hnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBI
iwgImdlbmRlciIsICJGZW1hbGUiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm
JpcnRoRGF0ZSIsICIxOTYxLTA4LTE3Il0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIi
wgImdpdmVuTmFtZSIsICJNYXJpb24iXQ~WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53Iiw
gImZhbWlseU5hbWUiLCAiTXVzdGVybWFubiJd~WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS
13IiwgImFkbWluaXN0ZXJpbmdDZW50cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd~W
yJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjYzODI3M
zYiXQ~WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbC
IsICI4ODMxMTAwMDAwMTUzNzYiXQ~
Notice
that,
in
the
case
of
sd-jwt,
the
decoded
payload
is
different
from
the
input
claimset:
Example
25
{
,
,
,
: [
,
],
: [
,
],
,
,
,
,
,
: {
: [
,
,
,
,
,
,
],
: {
: [
,
,
],
},
: {
: [
,
,
,
],
},
},
}
{
: [
,
],
: [
,
],
,
,
,
,
,
: {
: {
,
,
},
: {
},
,
,
},
,
: {
: {
,
,
,
}
}
}
See
Selective
Disclosure
for
JWTs
(SD-JWT)
for
a
detailed
explanation
of
each
disclosable
claim,
and
the
mandatory
to
disclose
claims.
The
holder,
converts
the
issued
sd-jwt
to
its
presentation
form,
redacting
any
fields
they
don't
wish
to
disclose
to
the
verifier,
for
example:
Example
26
eyJhbGciOiAiRVMyNTYifQ.eyJpc3MiOiAiaHR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1Z
XIiLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6IDE4ODMwMDAwMDAsICJAY29udGV4d
CI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0c
HM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJsZ
UNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjogI
mh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIzL
TAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDExO
jAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRlI
iwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRlI
iwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhiW
lk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3N
GdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5e
DFYc3RJaVM2QjFZYmwySlo0IiwgIlRDbXpybDdLMmdldl9kdTdwY01JeXpSTEhwLVllZ
y1GbF9jeHRyVXZQeGciLCAiVjdrSkJMSzc4VG1WRE9tcmZKN1p1VVBIdUtfMmNjN3laU
mE0cVYxdHh3TSIsICJiMGVVc3ZHUC1PRERkRm9ZNE5semxYYzN0RHNsV0p0Q0pGNzVOd
zhPal9nIiwgInpKS19lU01YandNOGRYbU1aTG5JOEZHTTA4ekozX3ViR2VFTUotNVRCe
TAiXSwgInZhY2NpbmUiOiB7Il9zZCI6IFsiMWNGNWhMd2toTU5JYXFmV0pyWEk3Tk1XZ
WRMLTlmNlkyUEE1MnlQalNaSSIsICJIaXk2V1d1ZUxENWJuMTYyOTh0UHY3R1hobWxkT
URPVG5CaS1DWmJwaE5vIiwgIkxiMDI3cTY5MWpYWGwtakM3M3ZpOGViT2o5c214M0MtX
29nN2dBNFRCUUUiXSwgInR5cGUiOiAiVmFjY2luZSJ9LCAicmVjaXBpZW50IjogeyJfc
2QiOiBbIjFsU1FCTlkyNHEwVGg2T0d6dGhxLTctNGw2Y0FheHJZWE9HWnBlV19sbkEiL
CAiM256THE4MU0yb04wNndkdjFzaEh2T0VKVnhaNUtMbWREa0hFREpBQldFSSIsICJQb
jFzV2kwNkc0TEpybm4tX1JUMFJiTV9IVGR4blBKUXVYMmZ6V3ZfSk9VIiwgImxGOXV6Z
HN3N0hwbEdMYzcxNFRyNFdPN01HSnphN3R0N1FGbGVDWDRJdHciXSwgInR5cGUiOiAiV
mFjY2luZVJlY2lwaWVudCJ9LCAidHlwZSI6ICJWYWNjaW5hdGlvbkV2ZW50In0sICJfc
2RfYWxnIjogInNoYS0yNTYifQ.5jJEqiRViN_DJ4VMxHQIN4KK-Cdfn30nY3nRe5jGxS
5Pths5G7mF1GWy9TawYuyFwCze7qiCIx_MhJ68Uu5zeQ~WyJQYzMzSk0yTGNoY1VfbEh
nZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIi
wgImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyIyR0
xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWN
U9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklEL
TE5IFZhY2NpbmUgTW9kZXJuYSJd~
After
validation,
the
Verifier
will
have
the
following
data
for
further
processing:
Note
One
benefit
of
using
vc+ld+json+jwt
and
vc+ld+json+sd-jwt
is
that
they
both
produce
vc+ld+json
which
can
be
further
processed
as
RDF
by
a
verifier.
Issue
The
working
group
is
still
discussing
the
relevance
of
the
JWT
BCP,
and
distinguishing
vc+ld+json+sd-jwt
from
vc+sd-jwt
via
type
.
Example
27
{
,
,
,
: [
,
],
: [
,
],
,
,
,
,
,
: {
: {
,
,
},
: {
},
,
,
},
}