Skip to content

Resolve tension between Threat Model and Privacy & Security Considerations #711

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
eric-schuh wants to merge 9 commits into
base: main
Choose a base branch
from
Open

Resolve tension between Threat Model and Privacy & Security Considerations #711

Show file tree
Hide file tree
Changes from 5 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
cf51b1c
Adding threats created from transforming the privacy and security con…
eric-schuh Aug 25, 2026
453af4f
Apply @kezike's tag and editorial updates
eric-schuh Sep 1, 2026
b7cab16
Merge branch 'main' into transform_privacy_and_security_to_threats
eric-schuh Sep 8, 2026
297bb5e
Apply editorial changes and tag updates from @TallTed and @kezike
eric-schuh Sep 8, 2026
2bddd1b
Apply additional editorial changes from @kezike
eric-schuh Sep 8, 2026
0974570
Editorial changes to R44 in T40
eric-schuh Sep 8, 2026
f329f53
Moving secure coding practices
eric-schuh Sep 8, 2026
7fa6ebd
Clean up old security consideration appendix
eric-schuh Sep 8, 2026
9642adb
Adding new threats to the threat model appendix
eric-schuh Sep 8, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
173 changes: 24 additions & 149 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3703,7 +3703,6 @@ <h3>Verification Errors vs. Warnings</h3>

<section class="appendix informative">
<h2>Threat Model</h2>

<p>
This section details the general threat model for this specification
including security considerations, privacy considerations, and market
Expand Down Expand Up @@ -4126,158 +4125,34 @@ <h3>Unknown Proof Types</h3>
deriving a proof. It is vital that a wallet not present a base proof by
accident, as it might include information that is secret to the [=holder=].
</p>
</section>

<section>
<h3>Use of HTTPS for Interaction URLs</h3>

<p>
This specification strongly suggests the use of HTTPS for [=interaction URLs=]
for the following reasons:
</p>

<ul>
<li>
The HTTPS URL used in an interaction firmly establishes trust in the
interaction based on the existing and well understood same-origin trust model
used by browsers.
</li>
<li>
The initial URL provided establishes trust such that subsequent protocols used
in the interaction can be simply and safely delegated or outsourced to other
systems, some of which can be in a separate domain.
</li>
<li>
Graphical interfaces that need to gather consent can use domain names, which
are understood well enough by the general population to combat phishing attacks.
</li>
<li>
Protocols that require stronger verification of any party can use
protocol-specific mechanisms, such as [=verifiable credentials=], to verify
the [=holder=], [=issuer=], or [=verifier=] during a particular protocol
exchange.
</li>
</ul>

<p>
Using protocol schemes that are not rooted in the HTTPS trust model requires
separate encryption protocol, key management, and trust models to be used, which
are often less broadly developed and deployed and require much more development
and analysis to determine the threat and privacy model.
</p>

</section>

<section>
<h3>Deletion</h3>

<p>
The APIs provided by this specification enable the deletion of
[=verifiable credentials=] and [=verifiable presentations=] from
[=storage services=]. The result of these deletions
and the side-effects they might cause are out of scope for this specification.
However, implementers are advised to understand the various ways deletion can be
implemented. There are at least two types of deletion that are contemplated by
this specification.
</p>

<p>
<dfn>Partial deletion</dfn> marks a record for deletion but continues to store
some or all of the original information. This mode of operation can be useful if
there are audit requirements for all credentials and/or presentations over
a particular time period, or if recovering an original credential might be a
useful feature to provide.
</p>
<p>
<dfn>Complete deletion</dfn> purges all information related to a given
[=verifiable credential=] or [=verifiable presentation=] in a way that
is unrecoverable. This mode of operation can be useful when removing information
that is outdated and beyond the needs of any audit or when responding to any
sort of "<a href="https://en.wikipedia.org/wiki/Right_to_be_forgotten">right
to be forgotten</a>" request.
</p>
<p>
When deleting a [=verifiable credential=], handling of its status
information needs to be considered. Some use cases might call for deletion
of a particular [=verifiable credential=] to also set the revocation
and suspension bits of that [=verifiable credential=], such that any sort of
status check for the deleted credential fails and use of the credential is
halted.
</p>
<p>
Given the scenarios above, implementers are advised to allow the system actions
that occur after a delete to be configurable, such that system flexibility is
sufficient to address any [=verifiable credential=] use case.
</p>
</section>

<section>
<h3>Payload Sizes</h3>
<p>
Larger transactions can trigger DoS incidents. It's recommended to configure the
payload size accepted by endpoints at an instance level.
</p>
</section>

<section>
<h3>Additional Validation</h3>
<p>
In most cases, simply verifying the proof might not be sufficient to properly
handle the received data. [=Verifier services=] are expected to configure additional
validation steps based on their use cases. To define such additional
validations, implementers can refer to specifications such as
<a data-cite="?VC-DATA-INTEGRITY#resource-integrity">Section 2.3: Resource
Integrity</a> and
<a data-cite="?VC-DATA-INTEGRITY#contexts-and-vocabularies">Section 2.4:
Contexts and Vocabularies</a>
in the [[[?VC-DATA-INTEGRITY]]] specification where further information can be
found about context handling and integrity verification.
</p>
<p>
Improper validation will often lead to security vulnerabilities.
</p>
<p>
Additional validation steps can be accounted for when returning a verification
response object, through the problem details.
A <a href="threat-model/index.html">threat model for the VCALM specification</a> has been created
based on a use case of a first responder onboarding themselves to a new incident. This use case was chosen because it could be simplified
to detail the issuance of a [=verifiable credential=] for the particular incident, predicated on the [=verification=] of an existing emergency
responder credential. This enabled the data flow diagram in the threat model to detail both the [=verification=] and issuance steps, in the
same workflow.
</p>
</section>

<section>
<h3>Secure Coding Practices</h3>

<p>
Implementers are urged to use industry standard secure coding practices when
implementing this specification. Even deeply experienced software developers can
make mistakes and the use of secure coding checklists and vulnerability scanning
software can catch errors that would result in security compromises. Following
checklists and guides such as the
<a href="https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/">
OWASP Secure Coding Practices Checklist</a> and the
<a href="https://owasp.org/www-project-web-security-testing-guide/">
OWASP Web Security Testing Guide</a> can help reduce the chance of insecure
implementations.
</p>
</section>

<section>
<h3>Other Security Considerations</h3>

<p>
Since the interfaces to manage the lifecycle of [=verifiable credentials=]
described by this specification are generalized in nature, the security
implications of their use might not be immediately apparent to readers.
To understand the sort of security
concerns one might need to consider in a complete software system, implementers
are urged to read about how this technology can be used by the
[[[?VC-DATA-MODEL-2.0]]] specification (specifically the section
on <a data-cite="?VC-DATA-MODEL-2.0#security-considerations">
Verifiable Credential Security Considerations</a>), as well as the
[[[?VC-DATA-INTEGRITY]]] specification (specifically the section
on <a data-cite="?VC-DATA-INTEGRITY#security-considerations">
Data Integrity Security Considerations</a>).
</p>
</section>

<section class="notoc">
<h3>Security Considerations</h4>
<p>
W3C is migrating to a holistic threat modelling approach and is in the process
of deprecating the Security Considerations sections in new specifications.
Please refer to Appendix [[[#threat-model]]] for documentation related to
security considerations.
</p>
</section>

<section class="notoc">
<h3>Privacy Considerations</h4>
<p>
W3C is migrating to a holistic threat modelling approach and is in the process
of deprecating the Privacy Considerations sections in new specifications. Please
refer to Appendix [[[#threat-model]]] for documentation related to privacy
considerations.
</p>
</section>
</section>

<section class="appendix">
Expand Down
58 changes: 58 additions & 0 deletions threat-model/index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -114,6 +114,17 @@
<script src="threats/t27-workflow-variables-allow-workflow-template-to-be-misused.js"></script>
<script src="threats/t28-callback-urls-during-workflows-slow-to-respond.js"></script>
<script src="threats/t29-ecosystem-gatekeeping-in-the-name-of-security-or-privacy.js"></script>
<script src="threats/t30-issuance-request-and-or-delivery-made-by-third-party.js"></script>
<script src="threats/t31-unintended-data-leak-due-to-third-party-processing.js"></script>
<script src="threats/t32-malicious-entity-acts-on-behalf-of-incapable-party.js"></script>
<script src="threats/t33-verifier-phones-home-about-specific-verifiable-credential.js"></script>
<script src="threats/t34-unknown-proof-types.js"></script>
<script src="threats/t35-interaction-url-does-not-use-https.js"></script>
<script src="threats/t36-deletion-request-only-results-in-partial-deletion-of-credential.js"></script>
<script src="threats/t37-credential-deletion-violates-legal-regulation.js"></script>
<script src="threats/t38-mishandled-status-information-upon-credential-deletion-reveals-information.js"></script>
<script src="threats/t39-large-payload-triggers-denial-of-service-dos.js"></script>
<script src="threats/t40-improper-credential-validation-leads-to-security-vulnerabilities.js"></script>
</head>

<body>
Expand Down Expand Up @@ -726,6 +737,53 @@ <h2>Threats</h2>
</section>


<section class="appendix">

@kezike kezike Aug 28, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don’t know if it makes sense to have traditional security and privacy consideration sections in the threat model, but I agree with Manu about finding strategic places to place this information in the core spec (e.g., conformance, threat model, or some other appendix) or the new threat model document.

<h2>Security Considerations</h2>
<p>
This section details additional security considerations that were not
found to have direct threats related to this specification but the group
still wanted to highlight.
</p>

<section>
<h3>Secure Coding Practices</h3>

@msporny msporny Aug 25, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this goes in the conformance section? Or where we talk about conforming implementations?


<p>
Implementers are urged to use industry standard secure coding practices when
implementing this specification. Even deeply experienced software developers can
make mistakes and the use of secure coding checklists and vulnerability scanning
software can catch errors that would result in security compromises. Following
checklists and guides such as the
<a href="https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/">
OWASP Secure Coding Practices Checklist</a> and the
<a href="https://owasp.org/www-project-web-security-testing-guide/">
OWASP Web Security Testing Guide</a> can help reduce the chance of insecure
implementations.
</p>
</section>

<section>
<h3>Other Security Considerations</h3>

@msporny msporny Aug 25, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can put this in the Threat Model section introduction?


<p>
Since the interfaces to manage the lifecycle of [=verifiable credentials=]
described by this specification are generalized in nature, the security
implications of their use might not be immediately apparent to readers.
To understand the sort of security
concerns one might need to consider in a complete software system, implementers
are urged to read about how this technology can be used by the
[[[?VC-DATA-MODEL-2.0]]] specification (specifically the section
on <a data-cite="?VC-DATA-MODEL-2.0#security-considerations">
Verifiable Credential Security Considerations</a>), as well as the
[[[?VC-DATA-INTEGRITY]]] specification (specifically the section
on <a data-cite="?VC-DATA-INTEGRITY#security-considerations">
Data Integrity Security Considerations</a>).
</p>
</section>

</section>


</body>

</html>
4 changes: 2 additions & 2 deletions threat-model/threats/outline.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,12 +8,12 @@
{
name: "Implementation Threats",
id: "threat-model-implementation-threats",
threats: ["T2", "T3", "T9", "T14", "T15", "T16", "T18", "T20", "T22", "T23", "T24", "T25", "T26", "T27"],
threats: ["T2", "T3", "T9", "T14", "T15", "T16", "T18", "T20", "T22", "T23", "T24", "T25", "T26", "T27", "T33", "T34", "T35", "T36", "T38", "T39", "T40"],
},
{
name: "External Threats",
id: "threat-model-externnal-threats",
threats: ["T8", "T10", "T11", "T12", "T13", "T29"],
threats: ["T8", "T10", "T11", "T12", "T13", "T29", "T30", "T31", "T32", "T37"],
},
{
name: "Dependency Threats",
Expand Down
15 changes: 15 additions & 0 deletions threat-model/threats/t30-issuance-request-and-or-delivery-made-by-third-party.js
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
(function () {
var threat = {
id: "T30",
name: "Issuance Request and/or Delivery Made by Third Party",
desc: "Verifiable credentials issuance has a request phase and a delivery phase. The request might be made by the subject or another role, and delivery can be to a client that might or might not be controlled by the subject.",

@kezike kezike Aug 28, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This threat is a bit confusing. For one, the terms “request phase” and “delivery phase” are a bit confusing. Secondly the notion of the subject requesting issuance is not common, unless you’re referring to the credential refresh flow. Could you reword this threat or explain the intention behind it in a comment?

@eric-schuh eric-schuh Sep 8, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I gave it a try. This language came from the existing Security Considerations section this used to belong to so I am interpreting what was there. I do think that "requesting" the issuance of a credential is a fairly common pattern but agree that the "phase" terminology is likely from old language.

@eric-schuh eric-schuh Sep 8, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
desc: "Verifiable credentials issuance has a request phase and a delivery phase. The request might be made by the subject or another role, and delivery can be to a client that might or might not be controlled by the subject.",
desc: "There are no guarantees that a request for the issuance of a verifiable credentials is made by the subject of the credential. Similarly there are no guarantees that the credential is being delivered to a wallet controlled directly by the subject of said credential. Workflows allowing these third party actors to act as, or on behalf of, the subject without their authorization can create unknown harms to the subject in question.",

@TallTed TallTed Sep 8, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am more than a bit concerned that this is being re-written as if the default condition is that a (worse, the) subject of a verifiable credential is the default holder, and vice versa. There is no reason that "unknown harms" should be suggested as likely for a "subject" that is not a/the "holder". Subjects need not every know that a VC has been issued, nor what holders have ever or are how holding a VC of which they are a subject!

Suggested change
desc: "Verifiable credentials issuance has a request phase and a delivery phase. The request might be made by the subject or another role, and delivery can be to a client that might or might not be controlled by the subject.",
desc: "There is no guarantee nor general requirement that a request for the issuance of a verifiable credential is being made by a subject of the credential. Similarly, there is no guarantee that such a credential is being delivered to a wallet controlled by a subject of that credential. Workflows allowing such loosely coupled behaviors are generally considered to be a benefit of the verifiable credential ecosystem, though it is important that issuers, holders, and verifiers be aware of the possibilities.",

response: [
{ id: "R45", name: "Cryptographic Delegation", type: "Reduce", desc: "Use of cryptographically bound delegation techniques, such as zCaps, allow for third parties to act on behalf of the subject." }
],
elements: ["F1", "F19", "P1", "P4", "P5"],
Comment thread
eric-schuh marked this conversation as resolved.
tags: ["security", "privacy"],
taxonomyName: "STRIDE",
taxonomyClass: "Spoofing"
};
window.ThreatModel.register(threat);
})();
16 changes: 16 additions & 0 deletions threat-model/threats/t31-unintended-data-leak-due-to-third-party-processing.js
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
(function () {
var threat = {
id: "T31",
name: "Unintended Data Leak Due to Third Party Processing",
desc: "An issuer or verifier may make use of a third party service to process some data during an issuance or verification workflow. This third party service becomes a potential data leak risk as it may be able to aggregate across different issuers or verifiers using its services.",
response: [
{ id: "R46", name: "Minimize Data Sent to Third Party Services", type: "Reduce", desc: "Sending only data necessary for a third party service to perform its intended function limits the ability of the service, maliciously or via attacks on said service, to reveal unintended data." },
{ id: "R47", name: "Appropriate Legal Contracts", type: "Transfer", desc: "When making use of a third party service, having appropriate legal contracts in place around the usage of the data sent to the service allows issuers and verifiers to have recourse should data leaks occur." }
],
elements: ["P4"],
Comment thread
eric-schuh marked this conversation as resolved.
tags: ["privacy"],
taxonomyName: "STRIDE",
taxonomyClass: "Information Disclosure"
};
window.ThreatModel.register(threat);
})();
15 changes: 15 additions & 0 deletions threat-model/threats/t32-malicious-entity-acts-on-behalf-of-incapable-party.js
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
(function () {
var threat = {
id: "T32",
name: "Malicious Entity Acts on Behalf of Incapable Party",
desc: "Some subjects such as a new born baby, a pet, or a person with dementia, are incapable of acting on their own behalf. In these cases requests may be made on behalf of a subject with no cryptographic delegation possible. This can be problematic when guardians have malicious intent.",
response: [
{ id: "R48", name: "Additional Validation Steps in Workflow", type: "Reduce", desc: "In cases where the requesting party is not the intended subject of the action being requested, the workflow in question can include additional validation steps that ask the requesting party for additional information." }
],
elements: ["F1", "F19", "P1", "P4"],
Comment thread
eric-schuh marked this conversation as resolved.
tags: ["security", "privacy"],
taxonomyName: "STRIDE",
taxonomyClass: "Spoofing"
};
window.ThreatModel.register(threat);
})();
16 changes: 16 additions & 0 deletions threat-model/threats/t33-verifier-phones-home-about-specific-verifiable-credential.js
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Loading
Loading