Skip to content

Security Considerations: Secure Context #426

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

Draft
simoneonofri wants to merge 2 commits into
base: security-introduction
Choose a base branch
from
Draft

Security Considerations: Secure Context #426

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
28587e7
Security Considerations: Secure Context
simoneonofri Jan 8, 2026
0518646
Update index.html
simoneonofri Jan 10, 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
167 changes: 96 additions & 71 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1316,112 +1316,137 @@ <h2>
<p>
This section is a work in progress as this document evolves.
</p>
</div>
<p>
The Security Considerations section describes the API's security
properties, the threats in scope, the assumptions on which security
depends, and the residual threats that remain after the responses are
applied. This specification defines requirements for the User Agent's
behavior only when mediating credential presentation and issuance.
</p>
<p>
Other security properties that depend on protocols, Wallet
Copy link
Contributor

@TallTed TallTed Jan 13, 2026

Choose a reason for hiding this comment

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

Suggested change
Other security properties that depend on protocols, Wallet
Other security properties that depend on protocols, wallet

implementations, operating systems, or transport security are described
as expectations or preconditions and are not normative requirements of
this specification unless already explicitly stated in its conformance
text.
</p>
<section>
<h3>
Threat Model
</h3>
<p>
The <a href=
"https://docs.google.com/document/d/1BpBBiv7GgkGi1_Y7NvyD3Mkalj0g857Qw-aan3NqYwU/edit?usp=sharing">
Threat Model for the Digital Credentials API</a> includes threats to
this API and to adjacent levels of the ecosystem.
</p>
<p>
The documents listed below outline initial security considerations
for Digital Credentials, both broadly and for presentation on the
web. Their contents will be integrated into this document gradually.
Further analysis and threats are specified in related Threat Models,
such as the Threat Model for Decentralized Credentials (at the
ecosystem level for Decentralized Identities), the Threat Model for
the Web (at the web ecosystem level), RFC 3552 (at the internet
level), and the FIDO Security Reference, since the FIDO's Client to
Authenticator Protocol (CTAP) protocol is used for cross-device flow.
Copy link
Contributor

@TallTed TallTed Jan 13, 2026

Choose a reason for hiding this comment

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

Suggested change
Authenticator Protocol (CTAP) protocol is used for cross-device flow.
Authenticator Protocol (CTAP) is used for cross-device flow.

</p>
<p>
For this specification, threats fall into two categories:
</p>
<ul>
<li>
<a href=
"https://github.com/w3c-fedid/digital-credentials/wiki/Horizontal-reviews#self-review-questionnaire-security-and-privacy">
TAG Security and Privacy Considerations Questionnaire (WIP)</a>
<li>In-scope threats introduced or addressed by the DC API itself.
</li>
<li>
<a href=
"https://github.com/w3c-cg/threat-modeling/blob/main/models/decentralized-identities.md">
Threat Model for Decentralized Identities</a>
<li>Out-of-Scope threats handled by protocols, Wallets, OS platform
Copy link
Contributor

@TallTed TallTed Jan 13, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

Suggested change
<li>Out-of-Scope threats handled by protocols, Wallets, OS platform
<li>Out-of-scope threats handled by protocols, wallets, OS platform

security, or transport layers. Even if Out-of-Scope, they are
Copy link
Contributor

@TallTed TallTed Jan 13, 2026

Choose a reason for hiding this comment

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

Suggested change
security, or transport layers. Even if Out-of-Scope, they are
security, or transport layers. Even if out-of-scope, they are

relevant because they are assumed or transferred, influencing the
end-to-end security of credential presentation and issuance.
</li>
</ul>
</div>
<section>
<!---->
<h3>
Credential Protocols
</h3>
<p class="issue" title="Work in progress">
Explain that while the API provides security at the browser API
level, that security for the underlying credential issuance or
presentation protocol is a separate concern and that developers need
to understand that layer of the stack to get a total picture of the
protections that are in place during any given transaction.
</p>
<section>
<h4>
In-scope threats or attacks
</h4>
<p>
The following threats or attacks arise directly from the API's
mediation role:
</p>
<ul>
<li><strong>T1</strong>: Presentation Request Modification (Tampering) — A malicious script or compromised page attempts to alter a DigitalCredentialGetRequest before processing.</li>
Copy link
Contributor

@TallTed TallTed Jan 13, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

Suggested change
<li><strong>T1</strong>: Presentation Request Modification (Tampering) — A malicious script or compromised page attempts to alter a DigitalCredentialGetRequest before processing.</li>
<li><strong>T1</strong>: Presentation Request Modification (Tampering) —
A malicious script or compromised page attempts to alter a
DigitalCredentialGetRequest before processing.</li>

<li>To be written...
</li>
</ul>
</section>
<section>
<h4>
Out-of-scope threats or attacks
</h4>
<p>
The following attacks are out of scope for this specification but
are addressed by dependent systems:
</p>
<ul>
<li>To be written...
</li>
</ul>
</section>
</section>
<section>
<!--
// MARK: Cross-device Protocols
-->
<h3>
Cross-device Protocols
Security properties and threat responses defined by this
specification
</h3>
<p class="issue" title="Work in progress">
Explain that cross-device issuance or presentation uses a separate
protocol that has its own security characteristics.
<p>
The following mitigations derive from normative requirements already
present in the specification.
</p>
<section>
<h4>Secure Context</h4>
<p>WebIDL [=interfaces=] of the Digital Credential API are only exposed in a Secure Context, thus reducing [=tampering=].</p>
Copy link
Contributor

@TallTed TallTed Jan 13, 2026

Choose a reason for hiding this comment

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

Suggested change
<p>WebIDL [=interfaces=] of the Digital Credential API are only exposed in a Secure Context, thus reducing [=tampering=].</p>
<p>WebIDL [=interfaces=] of the Digital Credential API are only exposed in a
Secure Context, thus reducing [=tampering=].</p>

</section>
</section>
<section>
<!--
// MARK: Quishing
-->
<h3>
Quishing
Assumptions and transferred security responsibilities
</h3>
<p class="issue" title="Work in progress">
Explain that the API is designed to avoid the problem of quishing
(phishing via QR Codes) and other QR Code and non-browser API-based
attacks and to be aware of exposure of QR Codes during digital
credential interactions.
<p>
Correct and secure operation of the API depends on multiple
components not defined in this specification. These are assumed to be
trusted or expected to meet certain security properties.
</p>
</section>
<section>
<!--
// MARK: Data Integrity
-->
<h3>
Data Integrity
Denial of service considerations
</h3>
<p class="issue" title="Work in progress">
Explain that the API does not provide data integrity on the digital
credential requests or responses and that responsibility is up to the
underlying protocol used for the request or response.
<p>
To be written...
</p>
</section>
<section>
<!--
// MARK: Authentication
-->
<h3>
Authentication
Residual Threats
</h3>
<p class="issue" title="Work in progress">
Explain that authentication (such as a PIN code to unlock) to a
particular app, such as a digital wallet, that responds to an API
request is crucial in high-risk use cases.
<p>
Even with all mitigations in place, the following threats remain:
</p>
<ul>
<li>To be written...
</li>
</ul>
</section>
<section>
<!--
// MARK: Cross-Site Scripting (XSS) and Cross-Site
-->
<h3>
Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF)
Misuse considerations
</h3>
<p class="issue" title="Work in progress">
Explain what attacks are possible via XSS and CSRF, if any.
<p>
To be written...
</p>
</section>
<section>
<!--
// MARK: Session Security
-->
<h3>
Session Security
Applicability considerations
</h3>
<p class="issue" title="Work in progress">
Explain that once a secure session is established at a website using
credentials exchanged over this API, that the subsequent security is
no longer a function of the credential used or this API and is up to
the session management utilized on the website.
<p>
To be written...
</p>
</section>
</section>
Expand Down