Specification

https://w3c.github.io/vc-render-method/

Explainer

https://w3c.github.io/vc-render-method/#introduction

Links

• The WG's request for this TAG review: Link to the VCWG minutes to be added after the group confirms the request at TPAC 2026 (the TAG offered on the 14 Oct 2026 VCWG call to join a meeting if a task force has questions: https://w3c.github.io/vc-wg/minutes/2026-10-14.html)
• Previous early design review, if any: None
• An introduction to the feature, aimed at unfamiliar audiences: https://w3c.github.io/vc-render-method/#introduction
• A description of the problems that end-users were facing before this proposal: https://w3c.github.io/vc-render-method/#introduction (issuer-controlled visual, audio, and haptic presentation of a credential; today each wallet invents its own display, so the same credential looks different everywhere and issuers cannot convey branding, layout, or accessible alternatives)
• Alternatives considered: https://w3c.github.io/vc-render-method/#relationship-to-other-technologies (client-determined rendering, credential-type-specific display registries, standalone PDF/SVG/HTML presentation formats, SD-JWT VC type metadata rendering)
• Examples of how to use the proposal to solve the end-users' problems: https://w3c.github.io/vc-render-method/#data-model (the static, summary, and html render suites, each with examples)
• What do the end-users experience with this proposal: https://w3c.github.io/vc-render-method/#the-summary-render-suite and https://w3c.github.io/vc-render-method/#the-html-render-suite (a holder sees the issuer's intended card, summary view, or interactive HTML view inside the wallet; a verifier can read a static payload such as an NFC binary payload)
• User research you did to validate the problem and/or design, if any: Feedback from wallet and issuer deployments during the Credentials Community Group incubation (2023 to 2025) and from VCWG task force participants; specific deployments to be added
• Test Suite: N/A, will be created when transitioning into CR, following the existing pattern for VC test suites at https://w3c.github.io/vc-data-integrity/implementations/#test-suite-reports, with results added to the VC ecosystem conformance dashboard: https://canivc.com/

The specification

• Follows the Web Platform Design Principles.
• Includes Security and Privacy Considerations sections based on answers to the Security/Privacy Questionnaire.
  • NOTE: The VCWG has volunteered to follow the new Threat Modelling approach championed by the Security IG, which largely replaces the traditional Security/Privacy Considerations section with a Threat Model section: https://w3c.github.io/vc-render-method/#threat-model and a more comprehensive Threat Model document: https://w3c.github.io/vc-render-method/threat-model/

Where and by whom is the work is being done?

• GitHub repo: https://github.com/w3c/vc-render-method/
• Primary contacts:
  • Dmitri Zagidulin (@dmitrizagidulin), Interop Alliance, Editor
  • Manu Sporny (@msporny), Digital Bazaar, Editor
  • Patrick St. Louis (@PatStLouis), Open Security and Identity, Editor
  • Hendry Poh (@pohhendry), Infocomm Media Development Authority of Singapore, Editor
  • Isaac Koh (@isaackps), Infocomm Media Development Authority of Singapore, Editor
  • Phil Archer (@philarcher), GS1, VCWG Chair
  • Brent Zundel (@brentzundel), Mesur.io, VCWG Chair
  • Ivan Herman (@iherman), W3C, Staff Contact
• Organization/project driving the specification: VCWG Render Method Task Force; MIT Digital Credentials Consortium, Digital Bazaar, Infocomm Media Development Authority of Singapore, Government Technology Agency of Singapore
• This work is being funded by: To be added
• Primary standards group developing this feature: W3C VCWG
• Incubation and standards groups that have discussed the design:
  • Credentials CG incubation (2023 to 2025): https://github.com/w3c-ccg/vc-render-method (archived on adoption by the VCWG, October 2025)
  • VCWG Render Method Task Force meetings (2025 to present): https://w3c.github.io/vc-wg/minutes/#rem
  • VCWG plenary discussions, including the June 2026 face-to-face: https://w3c.github.io/vc-wg/minutes/2026-06-03-f2f.html#3c9e

Feedback so far

• Active horizontal reviews: https://github.com/w3c/vc-render-method/issues/66
  • Internationalization (in progress, seven issues filed in October 2026): https://github.com/w3c/i18n-request/issues/325
  • Privacy (closed, no concerns): https://github.com/w3cping/privacy-request/issues/225
  • Security (awaiting review): https://github.com/w3c/security-request/issues/147
  • Accessibility (awaiting review): https://github.com/w3c/a11y-request/issues/176
• Multi-stakeholder feedback: See "Incubation and standards groups that have discussed the design" above and the task force minutes at https://w3c.github.io/vc-wg/minutes/#rem
• Major unresolved issues with or opposition to this specification: No formal opposition. Open design questions the WG is actively working on:
  • How a wallet communicates the holder's preferred languages when fetching a linked render payload, which has been raised to the VC Data Model as a general question: https://github.com/w3c/vc-data-model/issues/1653 (see also https://github.com/w3c/vc-render-method/issues/92 and https://github.com/w3c/vc-render-method/pull/89)
  • Linked versus embedded payloads as a general pattern for externally fetched resources, including the tracking and exfiltration considerations in the threat model: https://github.com/w3c/vc-render-method/issues/99
  • How the sandboxed html render suite should handle navigation to and from other credentials: https://github.com/w3c/vc-render-method/issues/99
• Status/issue trackers for implementations: To be added

You should also know that...

The specification is an extension to the Verifiable Credentials Data Model v2.1 via its reserved renderMethod extension point. It defines a single SuiteRenderMethod type that dispatches on a renderSuite value, with three render suites in scope for v1.0: static (an opaque, pre-rendered payload such as an image or an NFC binary payload), summary (a structured, localizable JSON summary the wallet renders natively), and html (an HTML, CSS, and JavaScript payload booted in a sandboxed iframe with the credential supplied as a data block). The html suite is the part most likely to interest the TAG: it runs issuer-supplied code inside the wallet and relies on the sandbox, a restricted set of capabilities, and host-mediated navigation to contain it. The threat model document was written with this in mind.

We are planning to enter Candidate Recommendation as soon as we have received horizontal reviews and responded to requests for changes. This is one of the reviews that is gating our entrance into Candidate Recommendation. Our goal is to enter Candidate Recommendation in Q1 2027.

<!-- Content below this is maintained by @w3c-tag-bot -->

---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1297