This document describes a threat model for the Verifiable Credentials Render Method specification. It identifies and analyzes security and privacy threats specific to the publication, retrieval, and processing of render methods used to produce a human-readable rendering of a [=verifiable credential=].

This threat model is a work in progress. It is published alongside the Verifiable Credentials Render Method specification to inform implementers and ecosystem designers of the security and privacy considerations relevant to deployments of the specification. Feedback and proposed additions are welcome via the issue tracker.

Introduction

Threat modeling is a vital part of specification development. This document provides a threat model for the Verifiable Credentials Render Method specification, which defines how an [=issuer=] can associate one or more render templates with a [=verifiable credential=] so that a [=holder=] or [=verifier=] can produce a consistent, human-readable rendering of that credential.

This threat model follows the methodology described in the W3C Threat Modeling Guide and classifies threats using the STRIDE taxonomy. Threats are grouped into five categories:

Description

The Verifiable Credentials Render Method specification builds on the Verifiable Credentials Data Model. For this threat model, we consider a minimal instantiation focused on the render method lifecycle, consisting of three roles: the [=E1|Issuer=] (E1), who publishes and maintains the render templates associated with a [=verifiable credential=]; the [=E2|Holder=] (E2), who renders a credential to review it; and the [=E3|Verifier=] (E3), who renders a credential as part of evaluating it. The elements and flows introduced by the Render Method specification are shown in full color in the data flow diagram below; elements reused from the Verifiable Credentials Data Model threat model are shown grayed as context.

Note: We do NOT model potential attackers as first-class elements, as over-characterizing attackers can lead to analysis bias that is better avoided.

Data Flow Diagram for the Render Method Ecosystem

The data flow diagram below illustrates the key elements and data flows introduced by the Render Method specification. Within the [=C1|Issuer System=] (C1), the issuer runs the [=P1|Publish Render Template=] (P1) and [=P2|Update Render Template=] (P2) processes, which write to [=S1|Render Template Storage=] (S1). Within the [=C2|Holder System=] (C2) and the [=C3|Verifier System=] (C3), the [=P3|Render=] (P3) process retrieves a render template ([=F1|F1=]) and produces a rendering that the holder or verifier observes ([=F2|F2=]). Elements drawn from the Verifiable Credentials Data Model threat model are shown grayed for context and are not re-numbered here.

Data flow diagram showing three dashed system boundaries. The Issuer System (C1) contains the new Publish Render Template (P1) and Update Render Template (P2) processes, which write to the new Render Template Storage (S1); grayed context elements from the Verifiable Credentials Data Model threat model are also shown. The Holder System (C2) and Verifier System (C3) each contain the Render (P3) process. The Render process retrieves a render template from Render Template Storage via flow F1, and the Holder and Verifier observe the resulting rendering via flow F2.

The following notation is used in the diagram description and dictionary:

Dictionary

The dictionary defines the data flow diagram elements introduced by the Render Method specification. Elements reused from the Verifiable Credentials Data Model threat model appear grayed in the diagram for context and are defined in that document rather than repeated here.

E1 Issuer An entity that issues a [=verifiable credential=] and, using the Render Method specification, associates one or more render methods with it so that consumers have an issuer-intended way to present the credential. The issuer runs [=P1|Publish Render Template=] and [=P2|Update Render Template=] and operates [=S1|Render Template Storage=].
E2 Holder A person or organization that holds a [=verifiable credential=] and renders it, by way of the [=P3|Render=] process, in order to view or review it. The holder is the person who observes the rendering ([=F2|Observe Rendering=]) within the [=C2|holder system=].
E3 Verifier An entity that receives and evaluates a [=verifiable credential=] and renders it, by way of the [=P3|Render=] process, as part of reviewing it. The verifier is the person or operator who observes the rendering ([=F2|Observe Rendering=]) within the [=C3|verifier system=].
P1 Publish Render Template The process by which an [=issuer=] creates a [=O1|render template=] and makes it available in [=S1|Render Template Storage=], whether by hosting it for later retrieval or by embedding it so that it travels inside the credential.
P2 Update Render Template The process by which an [=issuer=] changes a previously published [=O1|render template=] in [=S1|Render Template Storage=], for example to update branding or layout over the lifetime of a long-lived credential. Updating a template that is not bound to the credential by a digest changes how previously issued credentials render.
P3 Render The process that combines a [=O1|render template=] retrieved via [=F1|Retrieve Render Template=] with claim values from a [=verifiable credential=] and produces output a person perceives, which can be visual, auditory, tactile, or textual. This is the same logical process whether it runs within the [=C2|holder system=] or the [=C3|verifier system=]. For the `html` render suite it executes template-supplied code inside a confined rendering environment; for the `card` and `nfc` render suites it produces a standardized output or emits a static payload without executing template-supplied code. The specification defines the confinement for the `html` suite in terms of required security outcomes rather than a specific mechanism. A sandboxed browser iframe with a Content Security Policy is one common way to achieve those outcomes, but it is an implementation detail, and equivalent isolation can be provided by other means.
F1 Retrieve Render Template The data flow by which the [=P3|Render=] process obtains the [=O1|render template=] from [=S1|Render Template Storage=]. When the template is referenced by location, this flow is a network request that reveals to the [=issuer=] or template host that a credential is being rendered; when the template is embedded, the template travels inside the credential and no such request is made.
F2 Observe Rendering The data flow by which the output of the [=P3|Render=] process reaches the [=holder=] or [=verifier=] who observes it. This flow represents the rendered presentation as it is perceived by a person.
O1 Render Template The self-contained, transferable artifact that determines how a [=verifiable credential=] is presented. Depending on the render suite it is a JSON template producing a standardized card output (`card`), an HTML fragment carrying its own CSS and JavaScript (`html`), or a static binary payload (`nfc`). A render template is produced by [=P1|Publish Render Template=], optionally changed by [=P2|Update Render Template=], held in [=S1|Render Template Storage=], carried by [=F1|Retrieve Render Template=], and consumed by [=P3|Render=]. It can be referenced by location or embedded in the credential, and it can be bound to the credential by a cryptographic digest.
S1 Render Template Storage The storage, within or operated by the [=C1|issuer system=], that holds published [=O1|render templates=] for retrieval by consumers. When a template is embedded in the credential rather than hosted, this storage is effectively the credential itself as it resides in the holder's possession.
C1 Issuer System The system boundary, typically a server or service operated by or for the [=issuer=], within which [=P1|Publish Render Template=] and [=P2|Update Render Template=] run and [=S1|Render Template Storage=] resides.
C2 Holder System The system boundary, typically a mobile or desktop digital wallet application, within which the holder's instance of the [=P3|Render=] process runs and where the holder observes the rendering.
C3 Verifier System The system boundary, typically a verification application or service, within which the verifier's instance of the [=P3|Render=] process runs and where the verifier observes the rendering.

Stakeholders

E1 Issuer

An issuer is an entity that issues [=verifiable credentials=] and, using the Render Method specification, associates render templates with them.

The issuer's primary goal is that its credentials are presented to people in the way it intends, so that an observer forms an accurate understanding of what the issuer attested. The issuer also has an interest in controlling how that intended presentation evolves: some issuers want the presentation fixed at issuance and protected against modification, while others want to update branding or layout over the lifetime of a long-lived credential. Issuers that host their templates have a further interest in not turning template retrieval into a means of tracking where and when their credentials are displayed.

E2 Holder

A holder is a person or organization that holds [=verifiable credentials=] and renders them to view or review them, typically within a digital wallet.

The holder's primary goal is to see a faithful, usable rendering of a credential. Holders have a strong interest in privacy, in that rendering a credential does not reveal to the issuer or a third party that, when, or where the credential is being displayed. Holders also have an interest in safety and availability: rendering untrusted template content does not compromise their device or expose their data, and rendering works within the constraints of their device, including when offline.

E3 Verifier

A verifier is an entity that evaluates [=verifiable credentials=] and renders them as part of reviewing them, for example to let a person confirm a credential against the issuer's intended presentation.

The verifier's primary goal is that the rendering it shows accurately reflects the issuer's intent and the credential's actual claims, so that a person is not misled into accepting a credential that does not meet the verifier's purpose. Like the holder, the verifier has an interest in rendering untrusted content safely, without compromising the verifier system.

Threats

Contributing

This threat model is maintained alongside the Verifiable Credentials Render Method specification. Feedback, bug reports, and proposed additions are welcome via the issue tracker.

Adding a Threat

To add a new threat to the model, provide the following components:

  1. A short, descriptive name
  2. A unique ID (letter T followed by an integer, e.g., T1)
  3. A description of the threat with enough detail for readers to understand its scope
  4. One or more responses, each with a name, unique ID (letter R followed by an integer), response type (Eliminate, Reduce, Transfer, or Accept), and description
  5. A list of affected DFD elements drawn from the dictionary above
  6. The threat taxonomy used (e.g., STRIDE) and the threat class within that taxonomy

Create a YAML file following the pattern of the Data Integrity threat model's threat files, then register it in threats/outline.yaml by adding its filename to the files list and its threat ID to the appropriate category in the categories list. No changes to index.html are required.