From 75013b3ec9dba902bfe0dbf1dfa51cd3141cd8cc Mon Sep 17 00:00:00 2001 From: Dmitri Zagidulin Date: Thu, 1 Oct 2026 16:58:11 -0400 Subject: [PATCH 1/3] Prep threat model for DNOTE publication. Signed-off-by: Dmitri Zagidulin --- threat-model/index.html | 17 +- threat-model/threats/threat-model.css | 12 +- transitions/2026/DNOTE/diagrams/dfd.svg | 1 + transitions/2026/DNOTE/index.html | 1597 +++++++++++++++++ .../2026/DNOTE/threats/threat-model.css | 168 ++ 5 files changed, 1780 insertions(+), 15 deletions(-) create mode 100644 transitions/2026/DNOTE/diagrams/dfd.svg create mode 100644 transitions/2026/DNOTE/index.html create mode 100644 transitions/2026/DNOTE/threats/threat-model.css diff --git a/threat-model/index.html b/threat-model/index.html index b0d549a..4c03366 100644 --- a/threat-model/index.html +++ b/threat-model/index.html @@ -12,9 +12,10 @@ + + + +
+

+

Verifiable Credentials Render Method Threat Model

+

W3C Group Note Draft

+
+ More details about this document +
+
This version:
+ https://www.w3.org/TR/2026/DNOTE-vc-render-method-threat-model-1.0-20261008/threat-model/ +
+
Latest published version:
+ https://www.w3.org/TR/vc-render-method/threat-model/ +
+
Latest editor's draft:
https://w3c.github.io/vc-render-method/threat-model/
+
History:
+ https://www.w3.org/standards/history/vc-render-method-threat-model-1.0/ +
+ Commit history +
+ + + + + +
+ Editor: +
+ Manu Sporny (Digital Bazaar) +
+ + +
Feedback:
+ GitHub w3c/vc-render-method + (pull requests, + new issue, + open issues) +
+ + +
+
+ + +

+ Copyright + © + 2026 + + World Wide Web Consortium. + W3C® + liability, + trademark and + permissive document license rules apply. +

+
+
+

Abstract

+

+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. +

+
+

Status of This Document

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 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. +

+

+ This document was published by the Verifiable Credentials Working Group as + a Group Note Draft using the + Note + track. +

Group Note Drafts are not endorsed by + W3C nor 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. + +

+ + The + W3C Patent + Policy + does not carry any licensing requirements or commitments on this + document. + + +

+ This document is governed by the + 18 August 2025 W3C Process Document. +

+

1. 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: +

+
    +
  • +Target Threats are threats the specification was designed +to address. +
    • +
  • +Implementation Threats are threats that implementers must +handle; the specification leaves the choice of mitigation open. +
    • +
  • +Deployment Threats are threats that arise from how systems +are configured and operated. +
    • +
  • +External Threats are real-world risks acknowledged as out +of scope for this version of the specification. +
    • +
  • +Dependency Threats are threats inherited from technologies +the specification depends upon. +
    • +
+ +

1.1 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 Issuer (E1), who publishes and +maintains the render templates associated with a verifiable credential; +the Holder (E2), who renders a credential to review +it; and the 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

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

+
+ +

1.2 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 +Issuer System (C1), the issuer runs the Publish Render Template +(P1) and Update Render Template (P2) processes, which write to +Render Template Storage (S1). Within the Holder System (C2) +and the Verifier System (C3), the Render (P3) process +retrieves a render template (F1) and produces a rendering that the +holder or verifier observes (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: +

+
    +
  • +E denotes an External Entity (a human or legal person +outside the system boundary) +
    • +
  • +P denotes a Process (a running algorithm that transforms +data) +
    • +
  • +F denotes a Data Flow (movement of data between elements) +
    • +
  • +S denotes a Data Store (persistent or ephemeral storage) +
    • +
  • +O denotes a Data Object (a self-contained, transferable +artifact) +
    • +
  • +C denotes a Contained System Boundary (a collection of +elements under a single authority) +
    • +
+
+ +

1.3 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 Publish Render Template and Update Render Template and +operates Render Template Storage. +
+ E2 Holder + +A person or organization that holds a verifiable credential and renders +it, by way of the Render process, in order to view or review it. The +holder is the person who observes the rendering (Observe Rendering) +within the holder system. +
+ E3 Verifier + +An entity that receives and evaluates a verifiable credential and renders +it, by way of the Render process, as part of reviewing it. The +verifier is the person or operator who observes the rendering +(Observe Rendering) within the verifier system. +
+ P1 Publish Render +Template + +The process by which an issuer creates a render template and makes +it available in 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 +render template in 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 render template retrieved via +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 holder system or the 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 Render process obtains the +render template from 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 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 Publish Render Template, +optionally changed by Update Render Template, held in +Render Template Storage, carried by Retrieve Render Template, +and consumed by 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 issuer system, that holds +published 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 Publish Render Template and +Update Render Template run and 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 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 Render process runs and where the +verifier observes the rendering. +
+
+
+ +

2. Stakeholders

+ + +

2.1 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. +

+ +

2.2 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. +

+ +

2.3 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. +

+
+ +

3. Threats

+ +

3.1 Threat List

+ + +

Target Threats

+
    +
  1. Uncontrolled Credential Presentation + security + +
    2. +
+ +

Implementation Threats

+
    +
  1. Unsafe Rendering of Untrusted Data + security + +
    2. +
+ +

Deployment Threats

+
    +
  1. Tracking via Template and Resource Fetches + privacy + +
    2. +
+ +

External Threats

+
    +
  1. Harmful Rendering Output + security + +
    2. +
+ +

Dependency Threats

+
    +
  1. Inherited Rendering Environment Attack Surface + security + +
    2. +
+ +
+

3.2 Threat Details

+ + +

Target Threats

+ +

3.2.1 T1. Uncontrolled Credential Presentation

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+

T1. Uncontrolled Credential Presentation + + security + +

+ [Threat List] +
+
+ An issuer generally has a strong interest in how the verifiable credentials it issues are presented to people. Without a render method asserted by the issuer, the choice of how to display a credential falls entirely to the holder or verifier software that performs the Render process. That software can introduce data integrity risks, either intentionally or unintentionally by altering the presentation layer of a credential. If the client application modifies the layout, it may violate the issuer's security or schema requirements. Specifically, it can cause payload omission by omitting or de-emphasizing important claims, schema mutation by reordering or relabeling fields, metadata deletion by dropping disclaimers or validity information, or UI spoofing by applying branding that misrepresents the issuer. The person viewing the credential then forms an incorrect understanding of what the issuer actually attested, even though the underlying credential is authentic and unmodified. This is the primary threat the Render Method specification is designed to address: it gives the issuer a way to assert, within the credential itself, a correct and intended presentation, published during Publish Render Template to Render Template Storage and retrieved by consumers via Retrieve Render Template. +
R1. Issuer-Asserted Render Method (Reduce)
+ The issuer asserts one or more render methods in the verifiable credential, giving consumers an issuer-intended way to present the credential rather than inventing their own. This does not compel a consumer to use the issuer's presentation, but it makes the issuer's intended rendering available and unambiguous. +
R2. Bind the Presentation to the Credential (Reduce)
+ So that the asserted presentation is not silently substituted or altered, the issuer treats the render template as an integrity-protected external resource. Because the render template is an external resource whose content affects how the credential is presented, the integrity considerations for it are a subset of Tampering with Unprotected External Resources in the Verifiable Credentials Data Model v2.0 threat model; readers are referred there for the full analysis and responses. An issuer that intends to update branding or layout over time instead deliberately leaves the template mutable, accepting that previously issued credentials render using the updated template. +
Affected Components: E1: Issuer, P1: Publish Render Template, O1: Render Template, S1: Render Template Storage, P3: Render, F1: Retrieve Render Template, C1: Issuer System
Threat Taxonomy: STRIDE (Tampering)
+

Implementation Threats

+ +

3.2.2 T2. Unsafe Rendering of Untrusted Data

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+

T2. Unsafe Rendering of Untrusted Data + + security + +

+ [Threat List] +
+
+ The Render process combines a render template retrieved via Retrieve Render Template with claim values taken from a verifiable credential, and produces output a person perceives, which can be visual, auditory, tactile, or textual. In the html render suite the template is an HTML fragment that carries its own CSS and JavaScript, and that code runs in order to render the credential. Both the template code and the credential values placed in the data block are untrusted input from the point of view of the software running the Render process. Template code, or a credential value it consumes, can attempt to reach the surrounding holder system or verifier system, navigate away, or load and contact external locations, giving hostile content access to the context in which it renders. Successful verification of the credential's securing mechanism confirms that the content is authentic, not that it is safe to render, so hostile content can arrive inside a well-formed, verified credential. At the level of the data model this threat is a render-time instance of Code Injection via Credential Content in the Verifiable Credentials Data Model v2.0 threat model; the additional concern here is that the render method deliberately executes template-supplied code as part of rendering. +
R1. Confine the Render Process (Reduce)
+ The html render suite runs the template code in a confined rendering environment rather than disabling the code it relies on. The specification defines this in terms of required security outcomes: the environment allows the template's JavaScript to render the credential while preventing it from navigating away, reaching the surrounding host page, and loading or contacting external content. How the environment enforces those outcomes is an implementation detail, and sandboxing can be achieved in a variety of ways. A browser based implementation, for example, can realize it by hosting the template in a sandboxed iframe that permits scripting but blocks navigation and top-level access, together with wrapper code that adds a Content Security Policy denying network requests; other environments provide equivalent isolation through different mechanisms. Whatever the mechanism, the environment further limits the resources and capabilities exposed to the template so that hostile template code has as little to act on as possible. +
Affected Components: P3: Render, F1: Retrieve Render Template, O1: Render Template, S1: Render Template Storage, C2: Holder System, C3: Verifier System
Threat Taxonomy: STRIDE (Elevation of Privilege)
+

Deployment Threats

+ +

3.2.3 T3. Tracking via Template and Resource Fetches

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+

T3. Tracking via Template and Resource Fetches + + privacy + +

+ [Threat List] +
+
+ A render method can reference its template, and the template can in turn reference further resources such as images, by location rather than embedding them. When the Render process resolves such a reference over the network via Retrieve Render Template, the request reveals to the issuer or to whoever hosts the resource that a particular credential is being rendered, along with the requester's network address, timing, and other request metadata. An issuer that assigns a distinct template or resource location per credential turns each render into a signal that identifies the specific credential and correlates the times and places it is displayed. In the html render suite, a template that is permitted to load external content could also encode credential data into the URLs of resources it fetches, such as image requests, exfiltrating rendered data to an external location. Embedding the template and its resources in the credential avoids the network requests entirely, at the cost of increasing the size of the credential, which can be significant for constrained devices. This threat is the render-time expression of Device Tracking and Fingerprinting in the Verifiable Credentials Data Model v2.0 threat model, to which readers are referred for the general analysis. +
R1. Block Network Access During Rendering (Reduce)
+ The rendering environment prevents the template from initiating its own network requests, so that a template cannot fetch per-user resources or encode credential data into outbound requests while rendering. The specification requires this as a security outcome for the html render suite; how it is enforced is an implementation detail. A browser based implementation, for example, can enforce it with a Content Security Policy applied by the wrapper code, while other rendering environments deny network egress by other means. Whatever the mechanism, blocking network access during rendering closes the linked-resource exfiltration vector for content loaded while the template runs. +
R2. Embed, Cache, or Relay Template Retrieval (Reduce)
+ Where the retrieval of a template cannot be avoided, the requester protects it rather than revealing each render to the host. As the specification notes, template references are aggressively cached on the client so that a template is fetched at most once, and retrieval is performed through Oblivious HTTP or a similar relay that disassociates the requester from the requested origin. An issuer that prioritizes offline use and unlinkability embeds the template and its resources in the credential, accepting the increase in credential size. The general responses in Device Tracking and Fingerprinting in the Verifiable Credentials Data Model v2.0 threat model apply here as well. +
Affected Components: P3: Render, F1: Retrieve Render Template, O1: Render Template, S1: Render Template Storage, E1: Issuer, C1: Issuer System
Threat Taxonomy: STRIDE (Information Disclosure)
+

External Threats

+ +

3.2.4 T4. Harmful Rendering Output

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+

T4. Harmful Rendering Output + + security + +

+ [Threat List] +
+
+ Because a render template controls the visual, auditory, and tactile output produced by the Render process, a hostile template can be crafted to harm the person viewing it rather than to inform them. A template can drive the display with a rapidly flashing or strobing pattern capable of triggering a seizure in a person with photosensitive epilepsy, or emit sudden loud, screeching, or otherwise disruptive sound. The harm lands on the human observing the rendering, in the physical environment around the holder system or verifier system, rather than on the data or the software, and the underlying credential can be entirely authentic. The ability of arbitrary displayed or played content to affect a susceptible person is a real-world condition of any rendering technology and is outside what the Render Method specification itself governs, so it is treated as an external threat. +
R1. Acknowledge as an External Condition (Accept)
+ The possibility that arbitrary visual or auditory output can affect a susceptible person exists for any technology that renders content and is not something the Render Method specification eliminates. This threat is documented so that implementers and deployers are aware of it and can apply platform-level and accessibility protections appropriate to their context. +
R2. Constrain and Vet Rendering Output (Reduce)
+ Deployers reduce exposure by favoring render suites and output modes that constrain what a template can do to the person, such as the card suite, which produces a standardized, static output rather than animated or sound-producing content, and by honoring platform accessibility settings that limit motion, flashing, and sound. Where templates originate from parties a deployer does not trust, the rendering output is reviewed or transformed to a safe static form before it is shown. +
Affected Components: P3: Render, F1: Retrieve Render Template, O1: Render Template, C2: Holder System, C3: Verifier System
Threat Taxonomy: STRIDE (Denial of Service)
+

Dependency Threats

+ +

3.2.5 T5. Inherited Rendering Environment Attack Surface

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+

T5. Inherited Rendering Environment Attack Surface + + security + +

+ [Threat List] +
+
+ The html render suite performs the Render process by executing template code inside a confined rendering environment and relies on that environment's isolation mechanisms to keep the code from navigating away, reaching the surrounding host page, or contacting the network. The specification defines these confinement requirements as security outcomes and leaves the mechanism that enforces them to the implementation; a sandbox can be provided in a variety of ways. A common realization is a browser, which enforces confinement through the iframe sandbox attribute, Content Security Policy, and srcdoc isolation, but other environments provide equivalent isolation through different mechanisms. Whatever mechanism is chosen, the safety of rendering inherits the security of that underlying mechanism: a defect that lets the confinement be escaped, a policy be bypassed, or the isolation between the template and the host be broken becomes a defect in the render process, even when the render method is used exactly as specified. The suite also inherits the ambient risk that a rendering environment, or its configuration, does not enforce the required outcomes faithfully. This is a dependency threat: the Render Method specification does not implement these protections itself but depends on the chosen environment enforcing them correctly and being available. +
R1. Rely on Maintained Rendering Environments (Transfer)
+ Deployers perform the Render process using an actively maintained rendering environment that receives timely security updates, such as a current browser engine, so that responsibility for the correctness of the environment's isolation mechanisms rests with its vendor and known defects are patched promptly. +
R2. Defense in Depth Beyond a Single Mechanism (Reduce)
+ Rather than relying on a single isolation primitive, the rendering environment combines the protections that achieve the specification's required outcomes: confinement of the executing template, denial of network egress, digest checking of retrieved template code, and prevention of host access, so that a failure in one mechanism does not by itself expose the holder system or verifier system. Because the choice of sandboxing mechanism is an implementation detail, an environment providing equivalent isolation is selected wherever the render method runs, whether or not it is a browser, and constrained suites such as card and nfc, which do not execute template code, are preferred where they meet the use case. +
Affected Components: P3: Render, C2: Holder System, C3: Verifier System
Threat Taxonomy: STRIDE (Elevation of Privilege)
+
+
+ +

4. 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. +

+

4.1 Adding a Threat

+ +

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

+
    +
  1. A short, descriptive name
    2. +
  2. +A unique ID (letter T followed by an integer, +e.g., T1) +
    3. +
  3. +A description of the threat with enough detail for readers to understand +its scope +
    4. +
  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. +
  5. +A list of affected DFD elements drawn from the dictionary above +
    6. +
  6. +The threat taxonomy used (e.g., STRIDE) and the threat class within that +taxonomy +
    7. +
+

+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. +

+
+
+ + + + +

A. References

A.1 Informative references

+ +
[VC-DATA-MODEL-2.0]
+ Verifiable Credentials Data Model v2.0. Ivan Herman; Michael Jones; Manu Sporny; Ted Thibodeau Jr; Gabe Cohen. W3C. 15 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/ +
+
diff --git a/transitions/2026/DNOTE/threats/threat-model.css b/transitions/2026/DNOTE/threats/threat-model.css new file mode 100644 index 0000000..35499a3 --- /dev/null +++ b/transitions/2026/DNOTE/threats/threat-model.css @@ -0,0 +1,168 @@ +table.visual-terminology, +table.dfd-dictionary { + padding: 1em; + border: 1px solid black; +} + +table.visual-terminology th, +table.visual-terminology td, +table.dfd-dictionary th, +table.dfd-dictionary td { + border-bottom: 1px solid black; + border-collapse: collapse; + padding: .5em; +} + +table.visual-terminology tr { + border-collapse: collapse; +} + +table.visual-terminology th { + width:11em; + font-weight: bold; +} + +table.visual-terminology td.term-def { + +} + + +table.visual-terminology td.term-img { + width: 11em; +} + + +table.dfd-dictionary { +} + + +table.dfd-dictionary td.dfd-id { + width: 3em; + font-weight: bold; + +} +table.dfd-dictionary td.dfd-name { + width: 10em; +} +table.dfd-dictionary td.dfd-type { + width: 6em; +} + +#threat-toc { + counter-reset: threat; +} + +ol.threat-toc { + list-style: none; +} + +ol.threat-toc li::before { + content: "T" attr(value) ". "; + font-weight: bold; +} + +ol.threat-toc li.section-title::before { + font-weight: bold; + counter-increment: none; + content: ""; +} + +ol.threat-toc li.section-title { + font-weight: bold; + font-style: italic; +} + +table.threat td.threat-name span.index-link { + position:absolute; + right: 10px; + height: 1em; + font-size: small; + margin-top: -0.7em; + top: 50%; +} +ol.threat-toc h5 { + margin:0; +} + +table.threat { + border: thin solid black; + border-collapse:collapse; + margin: 1em 0 1em 0; + width:100%; + padding-left:30px; +} +table.threat a.self-link { + left:-35px !important; +} +table.threat h3, +table.threat h4, +table.threat h5 { + color:black; + margin:0 0 0 -5px; + font-weight: bold; + font-style:normal; +} +table.threat td { + padding: 1em; + position:relative; + border-bottom: thin solid black; +} + +table.threat td.threat-name { + font-weight:bold; + background-color: #c9daf7; +} + +table.threat td.response-name { + font-weight:bold; + background-color: #d9ead4; +} + +table.threat td.affected-component { + background-color: #fff2ce; +} +table.threat span.component-entry { + font-weight:bold; +} +table.threat td.analysis-taxonomy { + background-color: #fce5ce; +} + +p.threatCategory { + font-size: larger; + font-weight: bolder; + margin:0; +} + +section.threatDetail { + visibility: hidden; + height:1px; +} + +span.threat-tag { + border-radius: 8px; + padding: 2px 5px; + color: white; + margin: 0px 2px; + font-weight: normal; + color: black; + background-color: #a9c9e8; +} + +span.threat-tag.threat-tag-security { + background-color: #f4a7a3; +} + +span.threat-tag.threat-tag-privacy { + background-color: #f8c49a; +} +table.dictionary, +table.dictionary th, +table.dictionary td { + border: thin solid rgb(176, 176, 176); + border-collapse: collapse; + padding: 5px; +} +table.dictionary td.left { + width: 12em; +} From 547a377679f6fa5fb50b3a737e4a9bdc92c6c0ec Mon Sep 17 00:00:00 2001 From: Dmitri Zagidulin Date: Fri, 2 Oct 2026 10:29:55 -0400 Subject: [PATCH 2/3] Apply review suggestions (remove js scripts). Signed-off-by: Dmitri Zagidulin --- threat-model/index.html | 17 ++++------------- 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/threat-model/index.html b/threat-model/index.html index 4c03366..690dcc4 100644 --- a/threat-model/index.html +++ b/threat-model/index.html @@ -3,11 +3,11 @@ - Verifiable Credentials Render Method Threat Model + Verifiable Credentials Render Method Threat Model 1.0 - - + + From a1d67f13ee0f7d12da56c42757faa7048dbc1362 Mon Sep 17 00:00:00 2001 From: Dmitri Zagidulin Date: Fri, 2 Oct 2026 10:52:47 -0400 Subject: [PATCH 3/3] Fix links. Signed-off-by: Dmitri Zagidulin --- index.html | 4 ++-- threat-model/index.html | 4 ++-- transitions/2026/DNOTE/index.html | 18 +++++++++--------- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/index.html b/index.html index 70988fc..4a4a816 100644 --- a/index.html +++ b/index.html @@ -1590,9 +1590,9 @@

Data Integrity and Proof Mechanisms

[[[VC-DATA-INTEGRITY#resource-integrity|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.

diff --git a/threat-model/index.html b/threat-model/index.html index 690dcc4..16de4ab 100644 --- a/threat-model/index.html +++ b/threat-model/index.html @@ -116,7 +116,7 @@

Description

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 +Verifiable Credentials Data Model threat model are shown grayed as context.

@@ -185,7 +185,7 @@

Dictionary

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

diff --git a/transitions/2026/DNOTE/index.html b/transitions/2026/DNOTE/index.html index da2ba83..b0ba1d1 100644 --- a/transitions/2026/DNOTE/index.html +++ b/transitions/2026/DNOTE/index.html @@ -100,7 +100,7 @@ privacy threats specific to the publication, retrieval, and processing of render methods used to produce a human-readable rendering of a verifiable credential."> - +