This
specification
defines
how
to
secure
credentials
and
presentations
conforming
to
the
Verifiable
Credential
data
model
[
VC-DATA-MODEL-2.0
]
with
JSON
Object
Signing
and
Encryption
(
JOSE
),
Selective
Disclosure
for
JWTs
[
SD-JWT
],
and
CBOR
Object
Signing
and
Encryption
(COSE)
[
RFC9052
].
This
enables
the
Verifiable
Credential
data
model
[
VC-DATA-MODEL-2.0
]
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
defines
how
to
secure
media
types
expressing
Verifiable
Credentials
and
Verifiable
Presentations
as
described
in
[
VC-DATA-MODEL-2.0
]
using
approaches
defined
by
the
JOSE,
OAuth,
and
COSE
working
groups
at
the
IETF.
This
includes
JSON
Web
Signature
(JWS)
[
RFC7515
],
Selective
Disclosure
for
JWTs
[
SD-JWT
],
and
CBOR
Object
Signing
and
Encryption
(COSE)
[
RFC9052
].
It
uses
content
types
[
RFC6838
]
and
structured
suffixes
[
MULTIPLE-SUFFIXES
]
to
distinguish
between
the
data
types
of
unsecured
documents
conforming
to
[
VC-DATA-MODEL-2.0
]
and
the
data
types
of
secured
documents
conforming
to
[
VC-DATA-MODEL-2.0
].
JSON
Web
Signature
(JWS)
[
RFC7515
]
defines
a
standard
means
of
digitally
signing
documents,
including
JSON
documents,
using
JSON-based
data
structures.
It
provides
a
means
to
ensure
the
integrity,
authenticity,
and
non-repudiation
of
the
information
contained
in
the
document.
Selective
Disclosure
for
JWTs
(SD-JWT)
[
SD-JWT
]
builds
on
JWS
by
also
providing
a
mechanism
enabling
selective
disclosure
of
document
elements.
These
properties
make
JWS
and
SD-JWT
especially
well
suited
to
securing
documents
conforming
to
[
VC-DATA-MODEL-2.0
].
CBOR
Object
Signing
and
Encryption
(COSE)
[
RFC9052
]
defines
a
standard
means
of
representing
digitally
signed
data
structures
using
Concise
Binary
Object
Representation
(CBOR)
[
RFC8949
].
Like
JWS,
COSE
provides
a
standardized
way
to
secure
the
integrity,
authenticity,
and
confidentiality
of
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
RSA,
ECDSA,
and
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.
Terminology
Error
Cannot
GET
/uploads/WjV5RL/terms.html
/uploads/qGfPrC/terms.html
3.
Securing
the
VC
Data
Model
This
section
outlines
how
to
secure
documents
conforming
to
[
VC-DATA-MODEL-2.0
]
using
JOSE,
SD-JWT,
and
COSE.
A
benefit
to
this
approach
is
that
payloads
can
be
made
to
conform
directly
to
[
VC-DATA-MODEL-2.0
]
without
any
mappings
or
transformation,
while
at
the
same
time
supporting
registered
header
parameters
and
claims
that
are
understood
in
the
context
of
JOSE,
SD-JWT,
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
SHOULD
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.
3.1
With
JOSE
3.1.1
Securing
JSON-LD
Verifiable
Credentials
with
JOSE
This
section
details
how
to
use
JOSE
to
secure
verifiable
credentials
conforming
to
[
VC-DATA-MODEL-2.0
].
The
typ
header
parameter
SHOULD
be
vc+ld+json+jwt
.
When
present,
the
cty
header
parameter
SHOULD
be
vc+ld+json
.
See
Registered
Header
Parameter
Names
for
additional
details
regarding
usage
of
typ
and
cty
.
The
typ
header
parameter
SHOULD
be
vp+ld+json+jwt
.
When
present,
the
cty
header
parameter
SHOULD
be
vp+ld+json
.
See
Registered
Header
Parameter
Names
for
additional
details
regarding
usage
of
typ
and
cty
.
The
typ
header
parameter
SHOULD
be
vc+ld+json+sd-jwt
.
When
present,
the
cty
header
parameter
SHOULD
be
vc+ld+json
.
See
Registered
Header
Parameter
Names
for
additional
details
regarding
usage
of
typ
and
cty
.
The
typ
header
parameter
SHOULD
be
vp+ld+json+sd-jwt
.
When
present,
the
cty
header
parameter
SHOULD
be
vp+ld+json
.
See
Registered
Header
Parameter
Names
for
additional
details
regarding
usage
of
typ
and
cty
.
Implementations
MUST
support
the
compact
serialization
(
application/sd-jwt
)
and
MAY
support
the
JSON
serialization
(
application/sd-jwt+json
).
If
the
JSON
serialization
is
used,
it
is
RECOMMENDED
that
a
profile
be
defined
to
ensure
any
additional
JSON
members
are
understood
consistently.
3.3
With
COSE
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.
3.3.1
Securing
JSON-LD
Verifiable
Credentials
with
COSE
This
section
details
how
to
secure
data
with
the
type
application/vc+ld+json
with
COSE.
The
typ
header
parameter
SHOULD
be
application/vc+ld+json+cose
.
See
I-D.ietf-cose-typ-header-parameter
for
the
COSE
"
typ
"
(type)
header
parameter.
When
present,
the
content
type
(3)
header
parameter
SHOULD
be
application/vc+ld+json
.
See
Common
COSE
Header
Parameters
for
additional
details.
The
typ
header
parameter
SHOULD
be
application/vp+ld+json+cose
.
When
present,
the
cty
header
parameter
SHOULD
be
application/vp+ld+json
.
See
Common
COSE
Header
Parameters
for
additional
details.
When
the
iat
and/or
exp
JWT
claims
are
present,
they
represent
the
issuance
and
expiration
time
of
the
signature,
respectively.
Note
that
these
are
different
from
the
validFrom
and
validUntil
properties
defined
in
Validity
Period
,
which
represent
the
validity
of
the
data
that
is
being
secured.
The
claims
and
security
provided
by
this
specification
are
independent
of
the
data
secured
and
semantics
provided
by
the
[
VC-DATA-MODEL-2.0
].
This
means
that
while
the
security
features
of
this
specification
ensure
data
integrity
and
authenticity,
they
do
not
dictate
the
interpretation
of
claim
data.
Implementers
SHOULD
avoid
setting
JWT
claims
to
values
that
conflict
with
the
values
of
verifiable
credential
properties
when
a
claim
and
property
pair
refer
to
the
same
conceptual
entity,
especially
with
pairs
such
as
iss
and
issuer
,
jti
and
id
,
and
sub
and
credentialSubject.id
.
For
example,
JWK
claim
iss
should
not
be
set
to
a
value
which
conflicts
with
the
value
of
verifiable
credential
property
issuer
.
The
JWT
Claim
Names
vc
and
vp
MUST
NOT
be
present.
Additional
members
may
be
present
as
header
parameters
and
claims.
If
they
are
not
understood,
they
MUST
be
ignored.
It
is
RECOMMENDED
to
use
the
IANA
CBOR
Web
Token
Claims
registry
and
the
IANA
COSE
Header
Parameters
registry
to
identify
any
claims
and
header
parameters
that
might
be
confused
with
members
defined
by
[
VC-DATA-MODEL-2.0
].
These
include
but
are
not
limited
to:
iss
,
kid
,
alg
,
iat
,
exp
,
and
cnf
.
When
the
iat
and/or
exp
CWT
claims
are
present,
they
represent
the
issuance
and
expiration
time
of
the
signature,
respectively.
Note
that
these
are
different
from
the
validFrom
and
validUntil
properties
defined
in
Validity
Period
,
which
represent
the
validity
of
the
data
that
is
being
secured.
Additional
members
may
be
present
as
header
parameters
and
claims.
If
they
are
not
understood,
they
MUST
be
ignored.
When
iss
is
absent,
and
the
issuer
is
identified
as
a
[
URL
],
the
kid
MUST
be
an
absolute
[
URL
]
to
a
verification
method
listed
in
a
controller
document.
Example
11
:
An
issuer
identified
by
a
controller
document
identifier
When
the
holder
is
identified
as
a
[
URL
],
and
iss
is
absent,
the
kid
MUST
be
an
absolute
[
URL
]
to
a
verification
method
listed
in
a
controller
document.
Example
13
:
A
holder
identified
by
a
controller
document
identifier
When
iss
is
present
and
is
a
[
URL
],
the
kid
MUST
match
a
key
discovered
via
a
JWT
Issuer
Metadata
Request,
as
described
in
[
SD-JWT-VC
].
Issue
:
(AT
RISK)
Feature
depends
on
demonstration
of
independent
implementations
This
normative
statement
depends
on
the
IETF
OAuth
working
group
draft
[
SD-JWT-VC
].
This
feature
is
at
risk
and
will
be
removed
from
the
specification
if
at
least
two
independent,
interoperable
implementations
are
not
demonstrated.
The
value
of
the
issuer
property
can
be
either
a
string
or
an
object.
When
issuer
value
is
a
string,
iss
value,
if
present,
MUST
match
issuer
value.
When
issuer
value
is
an
object
with
an
id
value,
iss
value,
if
present,
MUST
match
issuer.id
value.
If
kid
is
also
present
in
the
JOSE
Header
,
it
is
used
to
distinguish
the
specific
key
used.
Use
of
a
proof-of-posssion
proof-of-possession
key
provided
by
the
Holder
to
the
Issuer
to
establish
a
cryptographic
binding
to
the
Holder
in
the
Verifiable
Credential
that
is
verifiable
by
the
Verifier
in
the
Verifiable
Presentation
is
RECOMMENDED
.
When
the
issuer
value
is
a
URL
using
the
HTTPS
scheme,
issuer
metadata
including
the
issuer's
public
keys
can
be
retrieved
using
the
mechanism
defined
in
[
SD-JWT-VC
].
Issue
:
(AT
RISK)
Feature
depends
on
demonstration
of
independent
implementations
This
normative
statement
depends
on
the
IETF
OAuth
working
group
draft
[
SD-JWT-VC
].
This
feature
is
at
risk
and
will
be
removed
from
the
specification
if
at
least
two
independent,
interoperable
implementations
are
not
demonstrated.
A
controller
document
can
express
verification
methods
,
such
as
cryptographic
public
keys
,
which
can
be
used
to
authenticate
or
authorize
interactions
with
the
controller
or
associated
parties.
For
example,
a
cryptographic
public
key
can
be
used
as
a
verification
method
with
respect
to
a
digital
signature;
in
such
usage,
it
verifies
that
the
signer
could
use
the
associated
cryptographic
private
key.
Verification
methods
might
take
many
parameters.
An
example
of
this
is
a
set
of
five
cryptographic
keys
from
which
any
three
are
required
to
contribute
to
a
cryptographic
threshold
signature.
The
value
of
the
controller
property
MUST
be
a
string
that
conforms
to
the
[
URL
]
syntax.
revoked
The
revoked
property
is
OPTIONAL
.
If
present,
its
value
MUST
be
an
[
XMLSCHEMA11-2
]
combined
date
and
time
string
specifying
when
the
verification
method
SHOULD
cease
to
be
used.
Once
the
value
is
set,
it
is
not
expected
to
be
updated,
and
systems
depending
on
the
value
are
expected
to
not
verify
any
proofs
associated
with
the
verification
method
at
or
after
the
time
of
revocation.
Example
15
:
Example
verification
method
structure
Note
:
Verification
method
controller(s)
and
controller(s)
The
semantics
of
the
controller
property
are
the
same
when
the
subject
of
the
relationship
is
the
controller
document
as
when
the
subject
of
the
relationship
is
a
verification
method
,
such
as
a
cryptographic
public
key.
Since
a
key
can't
control
itself,
and
the
key
controller
cannot
be
inferred
from
the
controller
document
,
it
is
necessary
to
explicitly
express
the
identity
of
the
controller
of
the
key.
The
difference
is
that
the
value
of
controller
for
a
verification
method
is
not
necessarily
a
controller
.
Controllers
are
expressed
using
the
`
controller
`
property
at
the
highest
level
of
the
controller
document
.
6.3.1.1
Verification
Material
Verification
material
MUST
be
expressed
in
the
publicKeyJwk
property
of
a
JsonWebKey
.
This
key
material
is
retrieved
based
on
hints
in
the
JOSE
or
COSE
message
envelopes,
such
as
kid
or
iss
.
At
the
time
of
writing,
there
is
no
standard
way
to
retrieve
a
public
key
in
JWK
format
from
a
DID
URL
or
controller
document.
A
verification
method
MUST
NOT
contain
multiple
verification
material
properties
for
the
same
material.
For
example,
expressing
key
material
in
a
verification
method
using
both
publicKeyJwk
and
another
representtion
representation
is
prohibited.
Implementations
MAY
convert
keys
between
formats
as
desired
for
operational
purposes
or
to
interface
with
cryptographic
libraries.
As
an
internal
implementation
detail,
such
conversion
MUST
NOT
affect
the
external
representation
of
key
material.
The
JSON
Web
Key
(JWK)
is
a
specific
type
of
verification
method
that
uses
the
JWK
specification
[
RFC7517
]
to
encode
key
types
into
a
set
of
parameters.
When
specifying
a
JsonWebKey
,
the
object
takes
the
following
form:
type
The
value
of
the
type
property
MUST
contain
the
string
JsonWebKey
.
publicKeyJwk
The
publicKeyJwk
property
is
REQUIRED
,
and
its
value
MUST
be
a
JSON
Web
Key
that
conforms
to
[
RFC7517
].
It
is
RECOMMENDED
that
verification
methods
that
use
JWKs
[
RFC7517
]
to
represent
their
public
keys
use
the
value
of
kid
as
their
fragment
identifier.
It
is
RECOMMENDED
that
JWK
kid
values
be
set
to
the
public
key
fingerprint
[
RFC7638
].
See
the
first
key
in
the
example
below
for
an
instance
of
a
public
key
with
a
compound
key
identifier.
As
specified
in
Section
4.4
of
the
JWK
specification
,
the
OPTIONAL
alg
property
identifies
the
algorithm
intended
for
use
with
the
public
key,
and
SHOULD
be
included
to
prevent
security
issues
that
can
arise
when
using
the
same
key
with
multiple
algorithms.
As
specified
in
Section
6.2.1.1
of
the
JWA
specification
,
describing
a
key
using
an
elliptic
curve,
the
REQUIRED
crv
property
is
used
to
identify
the
particular
curve
type
of
the
public
key.
As
specified
in
Section
4.1.4
of
the
JWS
specification
,
the
OPTIONAL
kid
property
is
a
hint
used
to
help
discover
the
key;
if
present,
the
kid
value
SHOULD
match,
or
be
included
in,
the
id
property
of
the
encapsulating
JsonWebKey
object,
as
part
of
the
path,
query,
or
fragment
of
the
URL.
secretKeyJwk
The
secretKeyJwk
property
is
OPTIONAL
.
If
present,
its
value
MUST
be
a
map
representing
a
JSON
Web
Key
that
conforms
to
[
RFC7517
].
It
MUST
NOT
be
used
if
the
data
structure
containing
it
is
public
or
may
be
revealed
to
parties
other
than
the
legitimate
holders
of
the
secret
key.
An
example
of
an
object
that
conforms
to
JsonWebKey
is
provided
below:
Example
17
:
JSON
Web
Key
encoding
of
a
secp384r1
(P-384)
public
key
In
the
example
above,
the
publicKeyJwk
value
contains
the
JSON
Web
Key.
The
kty
property
encodes
the
key
type
of
"OKP",
which
means
"Octet
string
key
pairs".
The
alg
property
identifies
the
algorithm
intended
for
use
with
the
public
key,
which
in
this
case
is
ES384
.
The
crv
property
identifies
the
particular
curve
type
of
the
public
key,
P-384
.
The
x
property
specifies
the
point
on
the
P-384
curve
that
is
associated
with
the
public
key.
The
publicKeyJwk
property
MUST
NOT
contain
any
property
marked
as
"Private"
or
"Secret"
in
any
registry
contained
in
the
JOSE
Registries
[
JOSE-REGISTRIES
],
including
"d".
JSON
Web
Key
is
also
capable
of
encoding
secret
keys
,
sometimes
referred
to
as
private
keys
.
Example
18
:
JSON
Web
Key
encoding
of
a
secp384r1
(P-384)
secret
key
The
private
key
example
above
is
almost
identical
to
the
previous
example
of
the
public
key,
except
that
the
information
is
stored
in
the
secretKeyJwk
property
(rather
than
the
publicKeyJwk
),
and
the
private
key
value
is
encoded
in
the
d
property
thereof
(alongside
the
x
property,
which
still
specifies
the
point
on
the
secp384r1
curve
that
is
associated
with
the
public
key).
{
...
"authentication": [
// this key is referenced and might be used by// more than one verification relationship
"did:example:123456789abcdefghi#keys-1",
],
...
}
The
authentication
verification
relationship
is
used
to
specify
how
the
controller
is
expected
to
be
authenticated
,
for
purposes
such
as
logging
into
a
website
or
engaging
in
any
sort
of
challenge-response
protocol.
Example
20
:
Authentication
property
containing
three
verification
methods
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://www.w3.org/ns/credentials/v2"
],
"id": "did:example:123456789abcdefghi",
...
"authentication": [
// this method can be used to authenticate as did:...fghi
"did:example:123456789abcdefghi#keys-1",
...
}
If
authentication
is
established,
it
is
up
to
the
application
to
decide
what
to
do
with
that
information.
This
is
useful
to
any
authentication
verifier
that
needs
to
check
to
see
whether
an
entity
that
is
attempting
to
authenticate
is,
in
fact,
presenting
a
valid
proof
of
authentication.
When
a
verifier
receives
some
data
(in
some
protocol-specific
format)
that
contains
a
proof
that
was
made
for
the
purpose
of
"authentication",
and
that
says
that
an
entity
is
identified
by
the
id
,
then
that
verifier
checks
to
ensure
that
the
proof
can
be
verified
using
a
verification
method
(e.g.,
public
key
)
listed
under
`
authentication
`
in
the
controller
document
.
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://www.w3.org/ns/credentials/v2"
],
"id": "did:example:123456789abcdefghi",
...
"assertionMethod": [
// this method can be used to assert statements as did:...fghi
"did:example:123456789abcdefghi#keys-1",
...
}
7.
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
,
NOT
RECOMMENDED
,
OPTIONAL
,
RECOMMENDED
,
REQUIRED
,
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.
7.1
Conformance
Classes
A
conforming
JWS
document
is
one
that
conforms
to
all
of
the
"
MUST
"
statements
in
Section
.
A
conforming
JWS
issuer
implementation
produces
conforming
JWS
documents
and
MUST
secure
them
as
described
in
Section
.
The
normative
statements
in
Securing
Verifiable
Credentials
apply
to
securing
application/vc+ld+json
and
application/vp+ld+json
as
application/vc+ld+json+sd-jwt
and
application/vp+ld+json+sd-jwt
.
Accordingly,
Issuers,
Holders,
and
Verifiers
MUST
understand
the
JSON
Web
Token
header
parameter
"alg":
"none"
when
securing
[
VC-DATA-MODEL-2.0
]
with
JSON
Web
Tokens.
When
content
types
from
[
VC-DATA-MODEL-2.0
]
are
secured
using
JSON
Web
Tokens,
the
header
parameter
"alg":
"none"
,
MUST
be
used
to
communicate
that
a
JWT
Claims
Set
(a
Verifiable
Credential
or
a
Verifiable
Presentation)
has
no
integrity
protection.
When
a
JWT
Claims
Set
(a
Verifiable
Credential
or
a
Verifiable
Presentation)
contains
proof
,
and
the
JSON
Web
Token
header
contains
"alg":
"none"
,
the
JWT
Claims
Set
MUST
be
considered
to
have
no
integrity
protection.
Verifiable
Credentials
and
Verifiable
Presentations
are
not
required
to
be
secured
or
integrity
protected
or
to
contain
a
proof
member.
Issuers,
Holders,
and
Verifiers
MUST
ignore
all
JWT
Claims
Sets
that
have
no
integrity
protection.
The
JWT
Claim
Names
vc
and
vp
MUST
NOT
be
present
in
any
JWT
Claims
Set.
8.
IANA
Considerations
8.1
Media
Types
8.1.1
application/vc+ld+json+jwt
This
specification
registers
the
application/vc+ld+json+jwt
Media
Type
specifically
for
identifying
a
JSON
Web
Token
(JWT)
with
a
payload
conforming
to
the
Verifiable
Credential
Data
Model.
Type
name:
application
Subtype
name:
vc+ld+json+jwt
Required
parameters:
None
Encoding
considerations:
binary;
application/jwt
values
are
a
series
of
base64url-encoded
values
(some
of
which
may
be
the
empty
string)
separated
by
period
('.').
Security
considerations:
As
defined
in
this
specification.
See
also
the
security
considerations
in
JSON
Web
Token
(JWT)
.
This
specification
registers
the
application/vp+ld+json+jwt
Media
Type
specifically
for
identifying
a
JSON
Web
Token
(JWT)
with
a
payload
conforming
to
Verifiable
Presentations.
Type
name:
application
Subtype
name:
vp+ld+json+jwt
Required
parameters:
None
Encoding
considerations:
binary;
application/jwt
values
are
a
series
of
base64url-encoded
values
(some
of
which
may
be
the
empty
string)
separated
by
period
('.').
Security
considerations:
As
defined
in
this
specification.
See
also
the
security
considerations
in
JSON
Web
Token
(JWT)
.
This
specification
registers
the
application/vc+ld+json+sd-jwt
Media
Type
specifically
for
identifying
a
Selective
Disclosure
for
JWTs
(SD-JWT)
with
a
payload
conforming
to
the
Verifiable
Credential
Data
Model.
Type
name:
application
Subtype
name:
vc+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
specification
registers
the
application/vp+ld+json+sd-jwt
Media
Type
specifically
for
identifying
a
Selective
Disclosure
for
JWTs
(SD-JWT)
with
a
payload
conforming
to
Verifiable
Presentations.
Type
name:
application
Subtype
name:
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
specification
registers
the
application/vc+ld+json+cose
Media
Type
specifically
for
identifying
a
COSE
object
[
RFC9052
]
with
a
payload
conforming
to
the
Verifiable
Credential
Data
Model.
Type
name:
application
Subtype
name:
vc+ld+json+cose
Required
parameters:
None
Encoding
considerations:
binary
(CBOR)
Security
considerations:
As
defined
in
this
specification.
See
also
the
security
considerations
in
[
RFC9052
].
This
specification
registers
the
application/vp+ld+json+cose
Media
Type
specifically
for
identifying
a
COSE
object
[
RFC9052
]
with
a
payload
conforming
to
Verifiable
Presentations.
Type
name:
application
Subtype
name:
vp+ld+json+cose
Required
parameters:
None
Encoding
considerations:
binary
(CBOR)
Security
considerations:
As
defined
in
this
specification.
See
also
the
security
considerations
in
[
RFC9052
].
This
specification
registers
the
+ld+json+jwt
Structured
Suffix
in
the
IANA
"Structured
Syntax
Suffixes"
registry
[
IANA-STRUCTURED-SUFFIX
]
for
indicating
that
the
media
type
is
encoded
as
a
JSON
Web
Token
(JWT)
with
a
JSON-LD
payload.
Name:
ld+json+jwt
+suffix:
+ld+json+jwt
References:
this
specification
Encoding
considerations:
binary;
jwt
values
are
a
series
of
base64url-encoded
values
(some
of
which
may
be
the
empty
string)
separated
by
period
('.').
This
specification
registers
the
+json+jwt
Structured
Suffix
in
the
IANA
"Structured
Syntax
Suffixes"
registry
[
IANA-STRUCTURED-SUFFIX
]
for
indicating
that
the
media
type
is
encoded
as
a
JSON
Web
Token
(JWT)
with
a
JSON
payload.
Name:
json+jwt
+suffix:
+json+jwt
References:
this
specification
Encoding
considerations:
binary;
jwt
values
are
a
series
of
base64url-encoded
values
(some
of
which
may
be
the
empty
string)
separated
by
period
('.').
Security
considerations:
As
defined
in
this
specification.
See
also
the
security
considerations
in
JSON
Web
Token
(JWT)
.
This
specification
registers
the
+ld+json+sd-jwt
Structured
Suffix
in
the
IANA
"Structured
Syntax
Suffixes"
registry
[
IANA-STRUCTURED-SUFFIX
]
for
indicating
that
the
media
type
is
encoded
as
an
Selective
Disclosure
for
JWTs
(SD-JWT)
with
a
JSON-LD
payload.
Name:
ld+json+sd-jwt
+suffix:
+ld+json+sd-jwt
References:
this
specification
Encoding
considerations:
binary;
sd-jwt
values
are
a
series
of
base64url-encoded
values
(some
of
which
may
be
the
empty
string)
separated
by
period
('.')
or
tilde
('~')
characters.
binary;
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
specification
registers
the
+ld+json+cose
Structured
Suffix
in
the
IANA
"Structured
Syntax
Suffixes"
registry
[
IANA-STRUCTURED-SUFFIX
]
for
indicating
that
the
media
type
is
encoded
as
a
COSE
object
[
RFC9052
]
with
a
JSON-LD
payload.
Name:
ld+json+cose
+suffix:
+ld+json+cose
References:
this
specification
Encoding
considerations:
binary
(CBOR)
Security
considerations:
As
defined
in
this
specification.
See
also
the
security
considerations
in
[
RFC9052
]
and
[
json-ld11
].
This
specification
registers
the
+json+cose
Structured
Suffix
in
the
IANA
"Structured
Syntax
Suffixes"
registry
[
IANA-STRUCTURED-SUFFIX
]
for
indicating
that
the
media
type
is
encoded
as
a
COSE
object
[
RFC9052
]
with
a
JSON
payload.
Name:
json+cose
+suffix:
+json+cose
References:
this
specification
Encoding
considerations:
binary
(CBOR)
Security
considerations:
As
defined
in
this
specification.
See
also
the
security
considerations
in
[
RFC9052
].
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
[
VC-DATA-MODEL-2.0
].
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-2.0
],
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
this
specification.
9.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
JOSE
or
COSE.
When
implementing
this
specification,
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.
9.3
Accessibility
This
section
is
non-normative.
When
implementing
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
[
VC-DATA-MODEL-2.0
].
This
specification
might
be
used
with
many
different
key
discovery
protocols.
Therefore,
discovery
of
verification
keys
is
described
in
6.
Key
Discovery
,
and
is
assumed
to
have
succeeded
prior
to
beginning
the
verification
process.
As
a
general
rule,
verifiers
SHOULD
strive
to
minimize
the
processing
of
untrusted
data.
This
includes
minimizing
any
processing
of
the
protected
header,
unprotected
header,
or
payload
as
part
of
the
key
discovery
procedures.
When
verifying
a
credential
or
presentation
secured
with
SD-JWT,
the
algorithm
defined
in
[
SD-JWT
]
for
Verification
of
the
SD-JWT
MUST
be
followed.
When
verifying
a
credential
or
presentation
secured
with
COSE_Sign1,
the
algorithm
defined
in
Signing
and
Verification
Process
MUST
be
followed.
After
verification
has
succeeded,
additional
validation
checks
SHOULD
be
performed.
12.
Validation
Algorithm
All
claims
expected
for
the
typ
MUST
be
present.
All
claims
that
are
understood
MUST
be
evaluated
according
the
verifier's
validation
policies.
All
claims
that
are
not
understood
MUST
be
ignored.
Schema
extension
mechanisms
such
as
credentialSchema
SHOULD
be
checked.
If
the
extension
mechanism
type
is
not
understood,
this
property
MUST
be
ignored.
Status
extension
mechanisms
such
as
credentialStatus
SHOULD
be
checked.
If
the
extension
mechanism
type
is
not
understood,
this
property
MUST
be
ignored.
Based
on
the
validation
policy
of
the
verifier
and
the
type
of
credentials
and
type
of
securing
mechanism,
additional
validation
checks
might
be
applied.
For
example,
dependencies
between
multiple
credentials,
ordering
or
timing
information
associated
with
multiple
credentials,
and/or
multiple
presentations
could
cause
an
otherwise
valid
credential
or
presentation
to
be
considered
invalid.