Copyright © 2026 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply.
This specification describes an extension mechanism for the Verifiable Credential Data Model, that can be used to represent a Verifiable Credential through a visual, auditory, or haptic medium. It covers rendering a Verifiable Credential to a physical document, digital image, screen reader, or braille output.
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.
This document was published by the Verifiable Credentials Working Group as an Editor's Draft.
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.
This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This document is governed by the 18 August 2025 W3C Process Document .
Rendering methods can be used when the issuer has a specific way that they want to express a verifiable credential to an observer through a visual, auditory, or haptic mechanism. For example, an issuer of an employee badge credential might want to include rich imagery of their corporate logo and specific placement of employee information in specific areas of the badge. They might also want to provide an audio read out of the important aspects of the badge for individuals that have accessibility needs related to their eyesight.
Some terminology used throughout this document is defined in the Terminology section of the Verifiable Credentials Data Model v2.1 specification.
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 , 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.
A conforming render method is any concrete expression of the data model that complies with the normative statements in this specification. Specifically, all relevant normative statements in Sections 2. Data Model and 3. Algorithms of this document MUST be enforced.
A conforming processor is any algorithm realized as software and/or hardware that generates or consumes a conforming render method . 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.
The following sections outline the data model that is used by this specification for rendering methods
The
renderMethod
property
is
a
reserved
extension
point
in
the
Verifiable
Credentials
Data
Model
v2.1
specification
.
An
issuer
can
utilize
this
property
in
a
verifiable
credential
to
express
one
or
more
preferred
render
methods.
renderMethod
property
MUST
specify
one
or
more
rendering
methods
that
can
be
used
by
software
to
express
the
verifiable
credential
using
a
visual,
auditory,
or
haptic
mechanism.
Each
renderMethod
value
MUST
specify
its
type
,
for
example,
SuiteRenderMethod
.
The
precise
contents
of
each
rendering
hint
is
determined
by
the
render
suite
specified
by
the
renderSuite
property.
When
an
issuer
desires
to
specify
rendering
instructions
for
a
verifiable
credential
,
they
MAY
add
a
renderMethod
property
that
uses
the
data
model
described
below.
The
concrete
rendering
behavior
is
determined
by
the
render
suite
named
in
the
renderSuite
property.
Each
render
suite
defines
which
of
the
properties
below
it
uses;
see
the
individual
render
suite
sections.
| Property | Description | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| id | An OPTIONAL string that follows the URL Standard and, when fetched, dereferences to a render template. | ||||||||
| type |
A
REQUIRED
string
that
MUST
be
the
value
SuiteRenderMethod
.
|
||||||||
| renderSuite |
A
REQUIRED
string
that
identifies
the
render
suite,
that
is,
the
set
of
algorithms
used
for
generating
the
concrete
rendering.
The
value
is
a
plain
JSON
string
and
is
compared
using
exact,
case-sensitive
matching.
This
specification
defines
the
values
,
,
and
.
Implementations
MUST
ignore
any
renderMethod
entry
whose
renderSuite
value
they
do
not
recognize
or
support.
|
||||||||
| name | An OPTIONAL human-readable string that can be displayed to provide a hint to the type of rendering that will be performed. This property might be used in a graphical interface that enables an individual to select between multiple presentation modes. | ||||||||
| description |
An
OPTIONAL
human-readable
string
that
provides
a
more
involved
description
than
name
of
when
the
particular
rendering
might
be
useful.
|
||||||||
| renderProperty |
An
OPTIONAL
list
of
string
values
that
each
conform
to
the
JavaScript
Object
Notation
(JSON)
Pointer
syntax
that
specifies
which
properties
from
the
verifiable
credential
are
exposed
when
using
this
specific
render
method.
If
renderProperty
is
not
provided,
the
entire
verifiable
credential
is
presumed
to
be
shared
when
the
render
method
is
used.
|
||||||||
| template |
An
OPTIONAL
URL
or
map
that
provides
or
refers
to
the
template
that
will
be
used
to
perform
the
rendering.
If
the
value
is
a
URL
,
it
MAY
be
a
data:
URL
[
RFC2397
]
containing
the
template
code.
If
the
value
is
a
map
,
it
MUST
conform
to
the
following
rules:
|
||||||||
| digestMultibase |
An
OPTIONAL
multibase-encoded
Multihash
of
the
render
method
referenced
if
id
is
specified.
The
multibase
value
MUST
be
u
(base64url-nopad)
and
the
multihash
value
MUST
be
SHA-2
with
256-bits
of
output
(
0x12
).
|
Where render suite values are registered (a registry section in this specification, the VC Specs Directory, or both), and whether extension suite values are plain strings or URLs, is still under discussion.
The
summary
render
suite
uses
JSON
templates
to
transform
a
verifiable
credential
into
a
standardized
data
display
format.
This
format
enables
wallets
to
display
credentials
in
a
responsive
layout
with
key
data
highlighted
and
configurable
additional
fields.
Wallets
that
implement
this
method
can
render
the
standardized
JSON
output
in
their
own
UI
designs,
allowing
credentials
to
be
displayed
even
when
a
wallet
doesn't
natively
support
a
specific
credential
type.
The template and the rendered output are both JSON objects that share a single definition, the summary object, given below. String values in the template can be JSON pointer strings (as specified in JavaScript Object Notation (JSON) Pointer ) that reference values in the verifiable credential . When processing the template, JSON pointer strings are evaluated against the credential data and replaced with the resolved values. Both the template and the resulting output MUST conform to the summary object definition. Compound data across multiple fields is not supported; each field references a single JSON pointer.
The
summary
render
suite
uses
the
common
render
method
properties
as
follows:
| Property | Use in this suite |
|---|---|
| template |
Provides
the
summary
template,
either
embedded
as
a
data:
URL
or
referenced
as
a
map.
The
value
MUST
be,
or
dereference
to,
a
JSON
document
that
conforms
to
the
summary
object
definition
in
2.2.1.2
The
Summary
Object
.
|
| renderProperty | Not used by this suite. The JSON pointer strings in the summary template determine which properties of the verifiable credential are exposed. |
| outputPreference |
MAY
be
provided.
The
accessMode
and
style
preferences
apply
to
the
display
of
the
rendered
summary.
|
A
summary
object
is
a
JSON
object
[
RFC8259
]
with
the
members
defined
below.
The
same
definition
applies
to
the
template
and
to
the
rendered
output.
In
a
template,
the
value
of
any
member
defined
as
a
string
MAY
instead
be
a
JSON
pointer
string
(starting
with
/
,
as
specified
in
JavaScript
Object
Notation
(JSON)
Pointer
)
that
references
a
value
in
the
verifiable
credential
,
except
where
noted
for
the
label
and
value
members
of
field
objects.
In
the
rendered
output,
every
JSON
pointer
has
been
replaced
by
its
resolved
value.
name
description
icon
data:
URL
[
RFC2397
]
for
an
icon
or
image
to
display
on
the
summary.
theme
primaryColor
accentColor
fields
label
value
"/issuer"
).
language
direction
validFrom
validUntil
A template SHOULD be validated against the summary object definition above before processing. A non-normative JSON Schema for summary templates is provided in C. Summary Template JSON Schema .
The following example shows a valid summary template with JSON pointer strings:
{
"name": "/credentialSubject/degree/name",
"description": "University Degree Credential",
"icon": "/credentialSubject/icon",
"theme": {
"primaryColor": "#1a5490",
"accentColor": "/credentialSubject/theme/accentColor"
},
"fields": [
{
"label": "Institution",
"value": "/issuer"
},
{
"label": "Degree Type",
"value": "/credentialSubject/degree/type"
},
{
"label": "Issue Date",
"value": "/validFrom"
}
],
"validFrom": "/validFrom",
"validUntil": "/validUntil"
}
The following example shows a valid summary output:
{
"name": "Bachelor of Science and Arts",
"description": "University Degree Credential",
"icon": "https://example.edu/icons/degree.svg",
"theme": {
"primaryColor": "#1a5490",
"accentColor": "#4a90e2"
},
"fields": [
{
"label": "Institution",
"value": "Example University"
},
{
"label": "Degree Type",
"value": "BachelorDegree"
},
{
"label": "Graduation Date",
"value": "2010-05-15"
}
],
"validFrom": "2010-01-01T19:23:24Z",
"validUntil": null
}
In
the
example
below,
the
JSON
template
is
embedded
directly
in
the
verifiable
credential
as
a
data:
URL
[
RFC2397
].
{
...
"renderMethod": {
"type": "SuiteRenderMethod",
"renderSuite": "summary",
// the JSON template is embedded in the VC
"template": "data:application/json;base64,eyJuYW1lIjogIi9jcmVkZW50aWFsU3ViamVjdC9kZWdyZWUvbmFtZSIsICJkZXNjcmlwdGlvbiI6ICJVbml2ZXJzaXR5IERlZ3JlZSBDcmVkZW50aWFsIiwgImZpZWxkcyI6IFt7ImxhYmVsIjogIkluc3RpdHV0aW9uIiwgInZhbHVlIjogIi9pc3N1ZXIifV19"
}
}
The
next
example
links
to
the
JSON
template
on
the
Web
and
secures
it
against
modification
by
using
the
digestMultibase
property.
{
...
"renderMethod": {
"type": "SuiteRenderMethod",
"renderSuite": "summary",
"template": {
// this JSON template is fetched from the Web
"id": "https://degree.example/credential-templates/bachelors.json",
"mediaType": "application/json",
"digestMultibase": "zQmerWC85Wg6wFl9znFCwYxApG270iEu5h6JqWAPdhyxz2dR"
}
}
The
next
example
links
to
the
rendering
template
on
the
Web
and
secures
it
using
the
digestMultibase
property:
{
...
"renderMethod": {
// this render method is fetched from the Web
"id": "https://degrees.example/bachelors-card.jsonld",
"mediaType": "application/ld+json",
"type": "SuiteRenderMethod",
"renderSuite": "summary",
"digestMultibase": "zQmG270iEu5h6JqWAPdhyxz2dRerWC85Wg6wFl9znFCwYxAp"
}
The
html
render
suite
allows
template
authors
to
provide
an
HTML
template
to
render
a
verifiable
credential
.
The
HTML
can
be
referenced
remotely
or
via
a
data:
URL
as
the
value
of
either
template
or
template.id
(when
the
value
of
template
is
an
object).
JavaScript
within
the
HTML
fragment
is
responsible
for
rendering
the
filtered
verifiable
credential
data
provided
via
an
HTML
data
block
(i.e.
<script
type="application/vc"></script>
)
hosted
in
a
sandboxed
iframe
alongside
the
HTML
template.
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": [
"VerifiableCredential",
"NameCredential"
],
"issuer": {
"id": "did:example:1234",
"name": "The Issuer"
},
"credentialSubject": {
"name": "Example Name",
"notRendered": "should not appear"
},
"renderMethod": {
"type": "SuiteRenderMethod",
"renderSuite": "html",
"renderProperty": [
"/issuer/name",
"/credentialSubject/name"
],
"template": {
"id": "https://test.example/credential-templates/NameCredential.html",
"mediaType": "text/html",
"digestMultibase": "zQmerWC85Wg6wFl9znFCwYxApG270iEu5h6JqWAPdhyxz2dR"
},
"outputPreference": {
"accessMode": [
"visual"
],
"mediaType": "application/html",
"style": {
"width": "800px",
"height": "800px"
}
}
}
}
The
html
render
suite
uses
the
common
render
method
properties
as
follows:
| Property | Use in this suite |
|---|---|
| template |
Provides
the
HTML
fragment,
either
embedded
as
a
data:
URL
or
referenced
as
a
map
whose
id
dereferences
to
the
fragment.
|
| renderProperty | MAY be provided to limit the verifiable credential data passed to the template. If absent, the entire verifiable credential is provided. |
| outputPreference |
MAY
be
provided.
The
style
width
and
height
preferences
apply
to
the
iframe
hosting
the
template.
|
Implementations
MUST
provide
an
environment
that
allows
for
JavaScript
to
safely
render
the
HTML
template
using
the
filtered
verifiable
credential
data.
Additionally,
a
host
page
SHOULD
protect
the
privacy
of
any
request
made
(for
example,
dereferencing
template.id
)
by
using
Oblivious
HTTP
[
RFC9458
]
or
other
means
of
disassociating
the
requesting
client
from
the
requested
origin
by
using
a
protecting
relay.
The following terminology is used to describe this environment:
At minimum, the environment MUST prevent navigation, loading of external content, and access to the host page in order to prevent tracking and other privacy harms.
The
environment
MUST
also
expose
to
the
template
code
all
internationalization
and
accessibility
settings
that
are
available
in
the
user's
environment.
This
allows
a
template
to
honor
the
language,
text
size,
contrast,
and
motion
preferences
that
an
individual
has
already
expressed
to
their
user
agent
or
operating
system.
Examples
of
such
settings
include
those
reflected
in
CSS,
such
as
the
rem
unit
and
media
queries
like
prefers-contrast
,
prefers-reduced-motion
,
and
forced-colors
,
as
well
as
those
available
to
JavaScript,
such
as
the
locale
information
provided
by
Intl
and
Navigator.language
.
Browser
based
implementations,
for
example,
can
provide
such
an
environment
using
a
combination
of
Content
Security
Policy
[
CSP3
]
restrictions
on
a
host
page
,
sandboxing
of
an
iframe
hosting
the
HTML
template,
and
wrapper
code
that
wraps
the
HTML
template
to
add
additional
CSP
restrictions
and
provides
ready
and
error
event
communication
with
the
host
page
.
A
sandboxed
iframe
meets
the
internationalization
and
accessibility
requirements
above
by
default.
The
sandbox
and
CSP
restrictions
described
in
this
section
do
not
interfere
with
CSS
media
queries
or
with
JavaScript
APIs
such
as
Intl
and
Navigator.language
.
Alternate
rendering
environments
for
the
html
render
suite
are
possible,
such
as
a
WebView
on
a
mobile
platform.
The host page (typically a Wallet or verifiable credential renderer) MUST prevent the HTML template from navigating the top-level browsing context, accessing external content, accessing the host page , and loading any remote content.
If a host page is used, the following rules apply:
frame-src
'none'
.
This
forces
the
use
of
srcdoc
instead
of
src
for
iframes,
which
prevents
the
browser
from
loading
the
HTML
template.
In
turn,
this
forces
the
host
page
code
to
preload
remotely
referenced
template
code
and
check
the
response
against
the
related
digestMultibase
value
prior
to
injecting
the
template
into
the
wrapper
code
.
sandbox="allow-scripts"
MUST
be
set
on
the
iframe
hosting
the
HTML
template
to
prevent
navigation
and
top-level
access.
<html>
<head>
<meta http-equiv="content-security-policy" content="frame-src 'none'">
</head>
<body>
<iframe id="renderer" sandbox="allow-scripts allow-modals" srcdoc=""></iframe>
</body>
</
html
>
The
HTML
template
code
referenced
by
the
template
property
in
the
renderMethod
MUST
be
an
HTML
fragment
that
contains
the
HTML,
CSS,
and
JavaScript
necessary
to
render
the
verifiable
credential
.
The
template
code
MUST
NOT
include
any
<html>
,
<head>
,
or
<body>
tags,
as
these
will
be
provided
by
the
wrapper
code
.
<div>
<script>
document.addEventListener('DOMContentLoaded', (event) => {
console.log('running template render script');
// display credential as JSON as an example renderer; anything
// could be done here instead, including mustache/other-style
// template processing to generate the HTML for display
// FIXME: determine best name/location for the datablock/script tag
const credential = JSON.parse(document.querySelector(
'head > script[name="credential"]').innerHTML);
document.querySelector('#credentialSubject-name').innerText =
credential.credentialSubject.name;
document.querySelector('#issuer-name').innerText =
credential.issuer.name;
// TBD: signal to host that rendering is complete
window.renderMethodReady();
});
</script>
<style>
h1 {
color: blue;
}
</style>
<h1 id="credentialSubject-name"></h1>
<p>Issued by: <span id="issuer-name"></span></p>
</
div
>
The
template
HTML
fragment
MUST
be
wrapped
in
wrapper
code
that
provides
the
data
block
containing
the
partial
verifiable
credential
and
adds
an
additional
CSP
policies
to
prevent
navigation
and
external
content
loading.
Specifically,
the
wrapper
code
MUST
add
the
following
CSP
restrictions
of
default-src
data:
'unsafe-inline'
to
prevent
any
network
requests
from
being
made
by
the
template
code
.
<html>
<head>
<meta http-equiv="content-security-policy" content="default-src data: 'unsafe-inline'">
<script name="credential" type="application/vc">${JSON.stringify(credential)}</script>
</head>
<body>${template}</body>
</
html
>
To
complete
the
setup,
the
host
page
MUST
inject
the
wrapper
code
(once
populated
with
the
verifiable
credential
and
the
template
code
)
into
the
iframe's
srcdoc
attribute
which
will
run
any
JavaScript
contained
in
the
wrapper
code
and
template
code
.
<html>
<head>
<meta http-equiv="content-security-policy" content="default-src 'none' data: 'unsafe-inline'">
<!-- The credential data block injected into the Wrapper Code. -->
<script name="credential" type="application/vc">{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": [
"VerifiableCredential",
"NameCredential"
],
"issuer": {
"id": "did:example:1234",
"name": "The Issuer"
},
"credentialSubject": {
"name": "Example Name"
}
}</script>
<!-- End credential data block -->
</head>
<body>
<!-- The template HTML injected into the Wrapper Code. -->
<div>
<script>
console.log('running template render script');
// display credential as JSON as an example renderer; anything
// could be done here instead, including mustache/other-style
// template processing to generate the HTML for display
// FIXME: determine best name/location for the datablock/script tag
const credential = JSON.parse(document.querySelector(
'head > script[name="credential"]').innerHTML);
document.querySelector('#credentialSubject-name').innerText =
credential.credentialSubject.name;
document.querySelector('#issuer-name').innerText =
credential.issuer.name;
// TBD: signal to host that rendering is complete
window.renderMethodReady()
</script>
<style>
h1 {
color: blue;
}
</style>
<h1 id="credentialSubject-name"></h1>
<p>Issued by: <span id="issuer-name"></span></p>
</div>
<!-- End template HTML -->
</body>
</
html
>
The
iframe
created
in
the
wrapper
code
MUST
provide
a
communication
channel
to
allow
the
template
to
notify
the
host
page
when
rendering
is
complete
or
if
there
was
an
error
during
rendering.
This
can
be
accomplished
using
the
postMessage
API
with
a
MessageChannel
setup
by
the
wrapper
code
.
The
JavaScript
shown
below
would
be
added
to
the
above
host
page
to
add
an
onload
event
to
the
iframe
which
sets
up
the
MessageChannel
.
The
host
page
also
creates
a
Promise
that
resolves
when
a
ready
message
is
received
from
the
wrapper
code
or
rejects
when
an
error
message
is
received.
The
wrapper
code
also
provides
a
window.renderMethodReady
method
for
use
by
the
template
to
notify
the
host
page
that
rendering
is
complete
or
send
back
an
error
message.
// a promise that resolves when the rendering is ready (or rejects if it
// fails); can be used to show the display or an error instead
let resolveRender;
let rejectRender;
const readyPromise = new Promise((resolve, reject) => {
resolveRender = resolve;
rejectRender = reject;
});
// Setup communication channel for use by the template code in the iframe
renderer.onload = () => {
// create a MessageChannel; transfer one port to the iframe
const channel = new MessageChannel();
// start message queue so messages won't be lost while iframe loads
channel.port1.start();
// handle `ready` message
channel.port1.onmessage = function ready(event) {
if(event.data === 'ready') {
// unhide the iframe because it's ready
resolveRender();
} else {
rejectRender(new Error(event.data?.error?.message));
}
channel.port1.onmessage = undefined;
};
// send "start" message; send `port2` to iframe for return communication
renderer.contentWindow.postMessage('start', '*', [channel.port2]);
};
// setup event responses to ready or error
// NOTE: this section is idiosyncratic to the Wallet/Renderer's UX needs
readyPromise.then(() => {
console.log('rendering ready');
const renderer = document.getElementById('renderer');
renderer.hidden = false;
}).catch(err => {
const errorMessage = document.getElementById('error-message');
errorMessage.style.display = 'block';
errorMessage.innerText = 'Rendering failed: ' + err.message;
console.error('rendering failed', err);
});
// add promise that will resolve to the communication port from
// the parent window
const portPromise = new Promise(resolve => {
window.addEventListener('message', function start(event) {
if(event.data === 'start' && event.ports?.[0]) {
window.removeEventListener('message', start);
resolve(event.ports[0]);
}
});
});
// attach a function to the window for the template to call when
// it's "ready" (or that an error occurred) that will send a message
// to the parent so the parent can decide whether to show the iframe
window.renderMethodReady = function(err) {
portPromise.then(port => port.postMessage(
!err ? 'ready' : {error: {message: err.message}}));
};
With
this
setup,
the
template
JavaScript
can
call
window.renderMethodReady()
to
notify
the
host
page
that
rendering
is
complete
or
call
window.renderMethodReady(new
Error("error
message"))
to
notify
the
host
page
of
an
error.
Rendering environment preferences MAY be provided within the Render Method. The purpose of this object is to provide suggested use, display, and intended access mode when rendering the provided template. An implementation SHOULD follow these preferences when provided.
| Property | Description |
|---|---|
| outputPreference | An OPTIONAL map that expresses the preferred rendering environment for the provided template. |
The
outputPreference
object
MAY
contain
any
of
the
following
properties:
| Property | Description |
|---|---|
| accessMode |
An
OPTIONAL
list
of
one
or
more
string
values
of
auditory
,
tactile
,
textual
,
or
visual
as
defined
in
https://w3c.github.io/cg-reports/a11y-discov-vocab/CG-FINAL-vocabulary-20260128/#accessMode-vocabulary
|
| mediaType | An OPTIONAL string stating a valid media type listed in the IANA Media Types preferred for rendering. This value MAY be used when suggesting addtional processing prior to rendering. Examples include converting an SVG template into a static image or an HTML document into a PDF. |
| style | An OPTIONAL map which defines style properties to potentially be used by the rendering environment. |
The
style
object
MAY
contain
any
of
the
following
properties:
| Property | Description |
|---|---|
| width |
An
OPTIONAL
string
containing
a
CSS
compatible
width
preference
to
be
set
on
the
iframe
.
|
| height |
An
OPTIONAL
string
containing
a
CSS
compatible
height
preference
to
be
set
on
the
iframe
.
|
The
render
suite
nfc
static
transmits
a
is
used
to
delivery
binary
payload
payloads
representing
the
verifiable
credential
over
a
wireless
in
various
static
or
pre-rendered
binary
formats,
such
as
images,
PDFs,
or
embedded
NFC
connection.
payloads.
In the example below, a fully embedded NFC payload is used as the rendering template, which only discloses the barcode identifier associated with the credential.
{
...
"renderMethod": {
"type": "SuiteRenderMethod",
"renderSuite": "nfc",
"renderSuite": "static",
"deliveryMode": "nfc",
"name": "Tap to send",
// the NFC payload is embedded
"template": "data:application/octet-stream;base64,2QZkpQGDG...G8XJWnROcY4Biw",
// only the barcode is transmitted over NFC
"renderProperty": ["/credentialSubject/barcode"]
}
...
}
The
render
suite
uses
the
common
render
method
properties
as
follows:
nfc
static
| Property | Use in this suite |
|---|---|
| template |
Provides
the
static
binary
data:
URL.
|
| deliveryMode |
Designates
the
intended
delivery
method
for
the
rendered
template,
such
as
nfc
for
transmission
over
a
wireless
NFC
channel.
|
| renderProperty |
MAY
be
provided
to
limit
which
verifiable
credential
data
is
|
| outputPreference | Not generally used by this suite. |
The following sections outline the algorithms that is used by this specification for rendering methods.
When processing a summary template, the following steps MUST be performed:
/
(indicating
it
is
a
JSON
pointer),
evaluate
it
using
the
JSON
Pointer
algorithm
JavaScript
Object
Notation
(JSON)
Pointer
against
the
verifiable
credential
as
the
target
document.
null
,
the
behavior
is
implementation-specific.
Implementations
MAY
use
an
empty
string,
leave
the
value
as
null
,
or
signal
an
error.
/
,
treat
it
as
a
literal
string
and
leave
it
unchanged.
Note that compound data across multiple fields is not supported. Each field in the template references a single JSON pointer that resolves to a single value from the credential.
The
following
sections
outline
the
algorithms
that
are
used
by
the
html
render
suite
to
safely
render
the
HTML
template.
Alternative
algorithms
MAY
be
used
as
long
as
the
security
and
privacy
outcomes
as
well
as
the
output
is
the
same.
The
host
page
MUST
create
an
iframe
element
to
host
the
HTML
template.
The
host
page
MUST
set
the
sandbox
attribute
on
the
iframe
to
allow-scripts
to
prevent
navigation
and
top-level
access.
vc
be
the
verifiable
credential
to
be
rendered.
renderMethod
be
the
chosen
renderMethod
property
in
vc
where
renderMethod.type
is
SuiteRenderMethod
and
renderMethod.renderSuite
is
html
.
renderMethod.template
is
a
string
,
then
let
template
be
the
value
of
renderMethod.template
.
renderMethod.template
is
a
map
,
then
let
template
be
the
result
of
fetching
the
URL
in
renderMethod.template.id
.
The
host
page
MUST
filter
the
verifiable
credential
vc
to
only
include
the
properties
specified
in
renderMethod.renderProperty
,
if
it
is
present.
If
renderMethod.renderProperty
is
not
present,
the
entire
verifiable
credential
is
used.
This
filtering
MUST
be
done
by
applying
the
selectJsonLd
algorithm
defined
in
Section
3.4.13
selectJsonLd
of
the
Data
Integrity
ECDSA
Cryptosuites
v1.0
specification
[
VC-DI-ECDSA
]
to
the
JSON
Pointer
[
RFC6901
]
values
present
in
renderMethod.renderProperty
.
The host page MUST create the wrapper code by embedding the filtered verifiable credential and the HTML template into the wrapper code template defined above.
wrapperCode
be
an
HTML
Document
with
<meta
http-equiv="Content-Security-Policy"
content="default-src
data:
'unsafe-inline'">
in
the
<head>
.
datablock
be
an
HTML
Data
Block
with
a
type
of
application/vc
.
datablock
to
be
the
filtered
verifiable
credential
in
stringified
JSON
format.
datablock
into
the
<head>
of
wrapperCode
.
template
into
the
<body>
of
wrapperCode
.
The
host
page
MUST
set
the
srcdoc
attribute
of
the
iframe
to
the
resulting
wrapper
code
.
srcdoc
attribute
of
the
iframe
to
the
stringified
HTML
of
wrapperCode
.
The
host
page
MUST
setup
a
communication
channel
with
the
wrapper
code
to
receive
ready
and
error
messages
as
described
above.
renderPromise
be
a
new
Promise
that:
resolve
,
can
be
used
to
display
the
iframe
to
the
user.
reject
,
display
the
error
message
to
the
user.
onload
event
of
the
iframe
:
channel
be
a
new
MessageChannel
.
port1
listener
on
channel
that
listens
for
a
ready
message
from
the
code
in
template
now
injected
into
the
iframe
via
wrapperCode
.
port1
listener,
if
a
ready
message
is
received,
resolve
renderPromise
.
If
an
error
message
is
received,
reject
renderPromise
with
the
error
message.
postMessage
to
send
port2
of
channel
to
the
iframe
content
window.
The
host
page
SHOULD
use
the
renderPromise
to
determine
when
rendering
is
complete
or
if
there
was
an
error
during
rendering.
The
wrapper
code
MUST
setup
to
receive
communication
from
the
host
page
via
the
MessageChannel
and
provide
the
window.renderMethodReady
method
for
use
by
the
template
code
.
window.onload
event...
port
be
the
MessagePort
received
from
the
host
page
via
the
message
event.
window.renderMethodReady
function
that...
This section is non-normative.
This section summarizes the threat model for this specification, covering the security and privacy considerations relevant to the publication, retrieval, and processing of render methods. The full analysis, including responses and the data flow diagram, is provided in the Verifiable Credentials Render Method Threat Model .
Readers are urged to familiarize themselves with the general threat model provided in the Threat Model section of the Verifiable Credentials Data Model v2.1 specification before reading this section. Implementers are expected to apply the general analysis provided in that specification to each specific feature provided by this specification.
html
render
suite
executes
template-supplied
code
and
consumes
credential
values
that
are
untrusted
input,
so
hostile
content
arriving
inside
a
well-formed,
verified
credential
can
attempt
to
reach
the
surrounding
host
page
,
navigate
away,
or
contact
external
locations
during
rendering.
html
render
suite
relies
on
the
confinement
provided
by
the
chosen
rendering
environment,
so
a
defect
that
lets
the
sandbox
be
escaped,
a
policy
be
bypassed,
or
the
isolation
between
template
and
host
be
broken
becomes
a
defect
in
the
render
process
even
when
the
render
method
is
used
exactly
as
specified.
W3C is migrating to a holistic threat modelling approach and is in the process of deprecating the Security Considerations sections in new specifications. Please refer to Appendix A. Threat Model for documentation related to security considerations.
W3C is migrating to a holistic threat modelling approach and is in the process of deprecating the Privacy Considerations sections in new specifications. Please refer to Appendix A. Threat Model for documentation related to privacy considerations.
This section is non-normative.
Several existing approaches and technologies were considered for conveying an issuer-preferred, human-perceivable presentation of a verifiable credential . This section summarizes those alternatives and why the render method approach described in this specification was chosen.
Defining no mechanism and leaving presentation to the holder or verifier software requires no extra data, but gives the issuer no way to convey intended presentation, so credentials render inconsistently and claims or branding can be misrepresented, as described in Uncontrolled Credential Presentation . Credential formats such as ISO/IEC 18013-5 mobile driving licence (mDL) and the JSON Web Tokens ( RFC 7519 ) take this approach, defining the claims a credential carries but leaving their presentation to the consuming software. Microsoft's Information Card (CardSpace), now discontinued, took a limited variant of this, letting an issuer supply only a card name and logo that the identity selector rendered in a uniform card chrome. This specification adds an issuer-asserted alternative rather than prohibiting client-determined rendering.
Standardizing presentation per credential type via a registry gives consistent renderings for well-known types but requires prior knowledge of each type, does not scale to custom credentials, and cannot express issuer-specific branding. Platform wallets such as Apple Wallet (PassKit) , Google Wallet , and Samsung Wallet take this approach, rendering a fixed set of predefined pass or object types in fixed, platform-controlled layouts where an issuer can fill in field values and assets but cannot express layout or branding outside the platform's catalog. The render method strategy defined by this specification instead travels with or is referenced from the credential, so even an unfamiliar type can be rendered as intended by its issuer.
Such a centralized, controlled, registry-focused solution also works against the distributed, decentralized, and permissionless patterns otherwise specified to be part of the ecosystem of Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) .
Distributing a fully-rendered PDF, static SVG, or HTML document is self-contained and widely supported, but such snapshots do not adapt to selective disclosure, cannot be re-rendered from the verified data, and are not bound to what was secured. This specification reuses these formats as templates combined with claim values at render time rather than as finished documents.
Rather than defining a new integrity mechanism, this specification relies on existing securing mechanisms such as Verifiable Credential Data Integrity 1.0 and the digestMultibase property to bind a referenced template to the credential. Readers can learn about these general protection mechanisms by reading about the Tampering with Unprotected External Resources threat in the Verifiable Credential Threat Model .
SD-JWT
VC
defines
a
rendering
property
to
choose
between
a
simple
method
that
supports
a
fixed
set
of
styling
attributes,
and
an
svg_templates
method
that
forbids
any
code
execution
and
substitutes
claim
values
into
text
placeholders
in
an
SVG.
The
group
explored
this
approach
and
found
it
too
limited
for
real-world
use
cases:
because
placeholders
appear
only
in
text
nodes
and
no
code
can
run,
data-driven
presentation
tools
such
as
conditional
fields,
variable-length
lists,
value
formatting,
and
responsive
layout
cannot
be
expressed.
These
features
are
requirements
in
sectors
such
as
healthcare,
retail,
and
banking/finance.
In
contrast,
this
specification
is
not
tied
to
a
single
credential
serialization,
and
instead
defines
render
suites
that
span
a
code-free
declarative
summary
suite,
a
data-driven
html
suite
executed
in
a
confined,
"sandboxed"
environment,
and
a
static
or
the
suite.
nfc
static
This section is non-normative.
The following JSON Schema implements the summary object rules defined in 2.2.1.2 The Summary Object , as they apply to summary templates. This schema is non-normative.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"required": ["name", "description", "fields"],
"properties": {
"name": {
"type": "string",
"description": "Display name as a literal string or JSON pointer (e.g., \"/credentialSubject/degree/name\")"
},
"description": {
"type": "string",
"description": "Description as a literal string or JSON pointer"
},
"icon": {
"type": "string",
"description": "Icon URL or data: URL as a literal string or JSON pointer"
},
"theme": {
"type": "object",
"properties": {
"primaryColor": {
"type": "string",
"description": "Primary color as a literal string or JSON pointer"
},
"accentColor": {
"type": "string",
"description": "Accent color as a literal string or JSON pointer"
}
},
"additionalProperties": false
},
"fields": {
"type": "array",
"minItems": 1,
"items": {
"type": "object",
"required": ["label", "value"],
"properties": {
"label": {
"type": "string",
"description": "Field label (a literal string; a JSON pointer is not allowed)"
},
"value": {
"type": "string",
"pattern": "^/",
"description": "Field value as a JSON pointer string (starts with \"/\")"
},
"language": {
"type": "string",
"description": "Optional BCP 47 language tag for the field"
},
"direction": {
"type": "string",
"description": "Optional text direction tag for the field"
}
},
"additionalProperties": false
}
},
"validFrom": {
"type": "string",
"description": "Validity start date as a literal ISO 8601 date string or JSON pointer"
},
"validUntil": {
"type": "string",
"description": "Validity end date as a literal ISO 8601 date string or JSON pointer"
}
},
"additionalProperties": false
}
Referenced in:
Referenced in: