Add Rendering Methods threat model - #60
Conversation
| 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 [=P3|Render=] process. Template | ||
| code, or a credential value it consumes, can attempt to reach the | ||
| surrounding [=C2|holder system=] or [=C3|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 | ||
| <a href="https://www.w3.org/TR/vc-data-model/threat-model/#t2-code-injection-via-credential-content">Code | ||
| Injection via Credential Content</a> in the [[[VC-DATA-MODEL-2.0]]] threat | ||
| model; the additional concern here is that the render method deliberately | ||
| executes template-supplied code as part of rendering. |
There was a problem hiding this comment.
This threat reads as if it was only on the problems with the html render suite, whereas R2 below also talks about nfc and card. Either R2 is wrongly placed, or there should be a reference to the other render suites in the generic description.
There was a problem hiding this comment.
Hmm, perhaps also worth nothing that while there is a difference between render methods that have code that is meant to be executed and those that are meant to only carry data, it may be possible to smuggle something into the latter that causes some unexpected execution during rendering anyway (but this I think is a separate threat ... or it's "external" to this spec vs. this spec offering different render suites with different properties/risk levels).
| that performs the [=P3|Render=] process. That software can present the | ||
| issuer's credential in a way that goes against the issuer's desires, for |
There was a problem hiding this comment.
Do we want to add "unintentionally" here? Software can always intentionally do whatever it wants, whether or not a render method is present. The threat here, I think, is that without any render method information, software that is trying to do its best can more easily misrepresent the issuer's desires (since the issuer hasn't published them as one or more render methods).
| that performs the [=P3|Render=] process. That software can present the | |
| issuer's credential in a way that goes against the issuer's desires, for | |
| that performs the [=P3|Render=] process. That software can unintentionally | |
| present the issuer's credential in a way that goes against the issuer's desires, for |
| that performs the [=P3|Render=] process. That software can present the | ||
| issuer's credential in a way that goes against the issuer's desires, for | ||
| example by using a layout that omits or de-emphasizes important claims, | ||
| reorders or relabels fields, drops disclaimers or validity information, or | ||
| applies branding that misrepresents the issuer. The person viewing the |
There was a problem hiding this comment.
I think this better expresses @dlongley's intended adjustment — the presentation is indeed intentional; the fact that it goes against the issuer's desires is the presumed accident ... which took some more wording changes as I read it a few more times.
| that performs the [=P3|Render=] process. That software can present the | |
| issuer's credential in a way that goes against the issuer's desires, for | |
| example by using a layout that omits or de-emphasizes important claims, | |
| reorders or relabels fields, drops disclaimers or validity information, or | |
| applies branding that misrepresents the issuer. The person viewing the | |
| that performs the [=P3|Render=] process. That software can introduce data | |
| integrity risks 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 |
longpd
left a comment
longpd
left a comment
There was a problem hiding this comment.
This looks like a good framework for renderMethod threat modeling. Approve.
5 participants
This PR adds a minimal threat model for the rendering methods specification based on the VC Data Model threat model and the brainstorming that was done over the summer. Only five threats have been added right now to ensure that the group is okay with the base threat model before continuing.
Preview | Diff