Security and Privacy Self-Review Questionnaire for VC Rendering Methods v1.0

Security and Privacy Self-Review Questionnaire

This document provides the responses of the Verifiable Credential Rendering Methods v1.0 specification to the questions in the W3C Security and Privacy Self-Review Questionnaire.

Answers reference the specification and the threat model.

The specification defines an extension mechanism for the Verifiable Credential Data Model that lets an issuer associate render templates with a verifiable credential, so a holder or verifier can produce a consistent, issuer-intended visual, auditory (and eventually) haptic rendering. It defines no Web platform API, so several questions below do not apply in the browser/origin sense in which they are framed. Unlike a purely declarative data model, however, it defines a render suite (html) whose templates carry executable JavaScript, and specifies the confinement in which that code runs; where a question touches script execution, sandboxing, or network activity, the answer attempts to address the specific concern.

2.1. What information does this feature expose, and for what purposes?

A renderMethod exposes the issuer's intended presentation of a credential: the render suite (card, html, or nfc), optional name and description, the properties the rendering discloses (renderProperty), rendering preferences (outputPreference), and either an embedded template or a URL to fetch one. The purpose is to let consumers display the credential as its issuer intended rather than inventing a presentation that omits, reorders, relabels, or misbrands its claims. This is the target threat, T1: Uncontrolled Credential Presentation.

Separately, retrieving a template referenced by location reveals to the issuer or host that a credential is being rendered, with the requester's address and timing (T3: Tracking via Template and Resource Fetches).

2.2. Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?

Yes, with an explicit control. renderProperty is a list of JSON Pointers naming exactly which properties reach a rendering; the html suite requires the host page to filter the credential accordingly, using selectJsonLd from VC-DI-ECDSA, before the template sees it. The nfc example transmits only a static byte string.

The default when renderProperty is absent is that the entire credential is shared with the template. Reviewers may wish to consider whether a non-minimizing default is right for a mechanism that hands credential data to issuer-supplied code, even if it is entirely sandboxed, or even if the property
is useful at all given that it is an "attacker controlled" property... there
were previous iterations of render methods that would allow upload of content
to a remote server, but those mechanisms have been removed from the
specification due to obvious "data leakage to remote system" security and privacy concerns.

Template retrieval is minimized by embedding, or where unavoidable by caching and Oblivious HTTP (RFC 9458) or a similar relay (T3 R2).

2.3. Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?

Every property the specification defines is presentation metadata, but the purpose of a render method is to display a credential, which frequently contains PII, and the html suite places the filtered credential in a data block that issuer-authored JavaScript reads. The specification constrains what that code can do with it: the environment MUST prevent navigation, external content loading, and host-page access, closing the obvious exfiltration paths (T2 R1, T3 R1).

2.4. How do the features in your specification deal with sensitive information?

There are four mechanisms that are used to protect sensitive information: (1) renderProperty limits which properties reach the template, applied before template code runs; (2) the html suite confines that code, and a browser realization combines frame-src 'none' on the host page, sandbox="allow-scripts" on the iframe, and a default-src data: 'unsafe-inline' CSP added by the wrapper code, denying network egress; (3) digestMultibase binds a referenced template to the credential so the presentation cannot be silently substituted (T1 R2), and frame-src 'none' exists precisely to force the host page to preload and digest-check remote template code before injecting it; (4) a host page SHOULD protect retrieval metadata using Oblivious HTTP or another relay.

2.5. Does data exposed by your specification carry related but distinct information that may not be obvious to users?

Yes. A distinct template URL per credential is an identifier, so an issuer assigning per-credential locations turns each render into a correlation signal (T3). And outputPreference.accessMode states the issuer's intent, not a fact about the viewer, but an application that selects a render method based on the user's assistive technology and then fetches it leaks that selection to the template host (see 2.21). There is other information that is related to the VC Data Model and data integrity that is also carried in the VC, but not exposed to the outside world.

2.6. Do the features in your specification introduce state that persists across browsing sessions?

Not in the browser-storage sense; no client-side storage is defined. Two forms of persistence are contemplated. Templates referenced by URL are expected to be aggressively cached so each is fetched at most once (T3 R2), a privacy improvement, but still state derived from which credentials a person holds. And a mutable, non-digest-bound hosted template is long-lived issuer-side state: updating it changes how already-issued credentials render (P2 Update Render Template). Note that a VC is state that persists across browsing sessions, but is not something that is introduced by this specification.

2.7. Do the features in your specification expose information about the underlying platform to origins?

The specification exposes no device, OS, or user-agent information and does not operate in terms of origins. However, the html suite runs issuer-supplied JavaScript, and such code can observe local characteristics (viewport, fonts, timing). The required outcomes prevent it from transmitting them: the wrapper CSP blocks network requests and the sandbox blocks host access. Fingerprinting is confined to what can be inferred without egress; only a defect in the environment changes that, which is covered in (T5).

2.8. Does this specification allow an origin to send data to the underlying platform?

No origin-scoped API is defined. The adjacent case is the nfc suite, which transmits a binary payload over NFC. That is a deliberate, holder-consented and initiated transmission to a nearby reader, bounded by renderProperty.

2.9. Do features in this specification enable access to device sensors?

No. The nfc suite emits a payload but defines no sensor read.

2.10. Do features in this specification enable new script execution/loading mechanisms?

Yes. The html render suite is explicitly a mechanism for executing issuer-supplied JavaScript: the template is an HTML fragment carrying its own CSS and JavaScript, embedded as a data: URL or fetched from the Web.

The execution environment is not left open. Implementations MUST provide an environment that prevents navigation, external content loading, and host-page access. For a browser realization the specification requires: frame-src 'none' in the host page CSP (forcing srcdoc over src, and hence forcing the host page to preload remote template code and check it against digestMultibase before injection); sandbox="allow-scripts" on the iframe; a default-src data: 'unsafe-inline' CSP added by the wrapper code, blocking all network requests; template code with no <html>, <head>, or <body> tags; and host communication limited to a MessageChannel carrying ready/error, exposed as window.renderMethodReady(). Alternative algorithms MAY be used if the security and privacy outcomes and output are the same.

Residual risks are T2: Unsafe Rendering of Untrusted Data, where verification confirms authenticity but not safety, so hostile content can arrive inside a well-formed verifiable credential, and T5: Inherited Rendering Environment Attack Surface.

The card and nfc suites execute no template code (card is declarative JSON with JSON Pointer substitution; nfc is a static payload), and deployers who do not need data-driven presentation are advised to prefer them (T4 R2, T5 R2). This is the area where the group would most value reviewer scrutiny.

2.11. Do features in this specification allow an origin to access other devices?

There are two cases where this might happen under controlled conditions. The host page MAY fetch a template or render method by URL, an ordinary retrieval whose tracking implications are T3; the template code itself is denied network access once running. Locally, the nfc suite transmits to a nearby reader, initiated by the person presenting the credential and limited by renderProperty.

2.12. Do features in this specification allow an origin some measure of control over a user agent's native UI?

No. However, an issuer can influence application UI within a bounded region: outputPreference.style.width/height are CSS-compatible preferences set on the iframe, and mediaType/accessMode suggest how output is produced. These are preferences an implementation SHOULD follow, and the rendering is confined to a sandboxed iframe that cannot navigate the top-level context or reach the host page. The risk that a rendering misrepresents an issuer is T1.

2.13. What temporary identifiers do the features in this specification create or expose to the web?

There are no temporary identifiers created by the specification. A template.id or render method id is a stable identifier, and an issuer assigning one per credential issued can create a per-credential correlator exposed on every render that fetches it (T3). A data: URL template exposes no identifier to the network.

2.14. How does this specification distinguish between behavior in first-party and third-party contexts?

The origin distinction does not map directly, but the specification is explicit about an analogous boundary: the template is third-party content relative to the first-party application rendering it. It names the parties (host page, template code, wrapper code) and requires the host/template boundary be enforced, the only permitted crossing being the ready/error MessageChannel. The threat model draws the same boundaries as C1 (issuer), C2 (holder), and C3 (verifier) systems in its data flow diagram. Trust in a template author is not established by the specification (T2).

2.15. How do the features in this specification work in the context of a browser's Private Browsing or Incognito mode?

No browser feature is defined and no behavior varies by mode. One implementer note: a template fetch is a network request attributable to the person rendering, and the advice to cache aggressively and relay retrieval applies with more force where a cache may be discarded and the fetch repeated. Embedding avoids this issue.

2.16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

Both are consolidated into an integrated Threat Model appendix, supported by a companion Threat Model document following the W3C Threat Modeling Guide and the STRIDE taxonomy. The Security and Privacy Considerations sections are retained as pointers to that appendix, per W3C's migration to holistic threat modelling.

Readers are also directed to the VCDM Threat Model, which this model builds on rather than repeats, in particular Code Injection via Credential Content, Device Tracking and Fingerprinting, and Tampering with Unprotected External Resources.

2.17. Do features in your specification enable origins to downgrade default security protections?

No, the follow restrictions are added on top of basic origin security protections: frame-src 'none' on the host page, sandbox="allow-scripts" on the iframe, and a further default-src data: 'unsafe-inline' policy from the wrapper code. Conforming processors MUST error on non-conforming documents.

'unsafe-inline' appears by necessity, because the suite's purpose is to run the template's inline script, and its safety rests on the accompanying default-src data: restriction and the sandbox rather than on script restriction.

frame-src 'none' is a MUST specifically so that the unsafe construction (using src, skipping the digest check) fails rather than silently working.

The specification's normative prose requires sandbox="allow-scripts", while the minimal host page example uses sandbox="allow-scripts allow-modals"; allow-modals permits a template to raise alert, confirm, and prompt dialogs, which is a wider grant than the prose describes and a disruption vector related to T4. The working group will reconcile the two, and reviewers may wish to advise on which is the right path.

2.18. What happens when a document that uses your feature is kept alive in BFCache after navigation, and potentially gets reused on future navigations back to the document?

The only BFCache contemplated is a cache used by the observer for the template. In that case, the danger is a stale rendering: a URL-referenced template not bound by digestMultibase is mutable, so a cached copy may render presentation the issuer has since replaced. The specification treats this as a deliberate issuer choice, either addressing the concern with digestMultibase, or leaving the template mutable and accepting that previously issued credentials render using the update (T1 R2).

2.19. What happens when a document that uses your feature gets disconnected?

No browser document lifecycle applies. A credential with an embedded template (data: URL, embedded card JSON, or nfc payload) renders with no network access at all, the recommended configuration for offline use and unlinkability, at the cost of credential size (T3 R2). A remote template renders only if cached or reachable; the host page's renderPromise rejects on failure and the error is displayed, so a failed retrieval with no cache backup is surfaced as an error rather than a silently degraded rendering.

2.20. Does your spec define when and how new kinds of errors should be raised?

Yes. Conformance requires conforming processors to error on non-conforming documents. Card template processing MUST stop and error if the template fails schema validation or if the resulting output fails the card output schema; an unresolvable JSON Pointer is explicitly implementation-specific (empty string, null, or error). HTML template processing defines a structured error channel: renderPromise resolves on ready and rejects on error, with the message displayed to the user; the template signals via window.renderMethodReady() or window.renderMethodReady(new Error(...)). A digestMultibase mismatch on preloaded template code is a security-relevant failure.

Reviewers may wish to consider whether implementation-defined behavior for unresolvable JSON Pointers is too permissive, since two conforming implementations can render the same credential differently, arguably a variant of T1. We have attempted to provide a mechanism that degrades gracefully instead of not rendering something partially useful.

2.21. Does your feature allow sites to learn about the user's use of assistive technology?

In general, no. outputPreference.accessMode states the issuer's intent for a rendering (auditory, tactile, textual, visual, per the Accessibility Discoverability Vocabulary); it is not a user signal, and no mechanism lets a template learn what assistive technology a person uses. Once running, template code cannot report observations, because the wrapper CSP denies network access.

The privacy risk is indirect, in that an application that selects among render methods based on the user's accessibility configuration and then fetches the chosen template discloses that choice to the host, turning an accessibility preference into an observable signal. This is an instance of T3, with the same mitigations, and implies such an application should prefer an embedded template where available.

2.22. What should this questionnaire have asked?

Several browser-centric questions did not apply, but, unusually for a data-model specification, the script-execution questions applied. A better-suited questionnaire might also ask:

(a) What is the security relationship between the party supplying executable content and the party executing it? A verifiable credential proves a template is authentic, not safe to run (T2).

(b) When a specification delegates security to a platform mechanism, what happens when that mechanism fails? A sandbox escape or CSP bypass becomes a defect in the render process even when the specification is adhered to (T5).

(c) Can the feature harm the person physically or perceptually, as distinct from harming them via data exposure? A template controls visual, auditory, and tactile output, so it can drive a strobing pattern capable of triggering a photosensitive seizure or emit a sudden loud sound (T4).

(d) Does the feature give one party control over how another party's information is presented, and can that be used to mislead? Rendering integrity (T1) is a harm to interpretation by a person even if the integrity of the data is sound. This is a user-agent attack, and if that is the scope of the threat, then nothing can be trusted, really.

(e) Does retrieving a resource needed to use the feature constitute a tracking signal? Template retrieval is a property of using the feature rather than of the data it exposes (T3).

Start with the questionnaire text and compare its claims against the linked Verifiable Credential Rendering Methods specification and threat model. Check the repository’s documentation structure to determine where this review belongs; done means the questionnaire is placed in the expected location and its answers remain consistent with the specification and threat model.