w3c
Fill out the Security and Privacy self review questionnaire
This is here: https://www.w3.org/TR/security-privacy-questionnaire/
This is the example in DID: https://github.com/w3c/did/issues/891
We just need to confirm they haven't changed any questions since 891
This was discussed during the #did meeting on 18 September 2025.
View the transcript
w3c/did-resolution#191
Wip: this one is currently not assigned to anyone. Is anyone willing to take it?
… There is a link to the questionnaire.
markus_sabadello: I think I said I would do it. I should have time.
Wip: thank you. Please self assign.
TallTed: things are shifting. Not sure this questionnaire is what the group is now looking for.
… The other side is a threat-model based Security consideration section. But this is not yet well defined.
Wip: currently, the documentation says to fill in that questionnaire.
… We are just getting the process started.
<smccown> I just joined, so I didn't get it all, but I'd be happy to help with the privacy questionnaire
I would be happy to take a look at the questions and start drafting some answers.
This was discussed during the #did meeting on 25 September 2025.
View the transcript
w3c/did-resolution#191
Wip: 191 - maybe I can ask Markus or Steve
… it's about filling out & addressing the Security & Privacy self-review
… this is the last review that we need to get in, then we can request horizontal reviews
… so, either Steve or Markus --
smccown: when is it due by?
WIp: soon as possible
smccown: ok, I'll work on it this afternoon
Wip: thanks
Sorry it took a few extra days, but here are my responses to the survey questions. I took the DID spec responses (from https://github.com/w3c/did/issues/891) and modified them to apply to the DID Resolution spec:
2.1 What information does this feature expose, and for what purposes?
The DID resolution specification defines the process of obtaining a DID document for a given DID. DID documents contain data elements, such as: public keys, service endpoints, and verification methods associated with a DID. The purpose is to enable the posessor of a DID to obtain cryptographically verifiable DID document data without relying on centralized registries or authorities. This information may expose DID document data about an entity, its capabilities, and associated services, which the DID owner intentionally chooses to to disclose under the control of the DID controller.
In addition to exposing the DID document, the DID Resolution specification also defines two metadata structures. One is DID document metadata, which contains information about the DID document (e.g. timestamps), and the other is DID resolution metadata, which contains information about the DID Resolution process itself. The purpose of these metadata structures is to provide additional information about the identifier to a client, which might be necessary to establish trust in the DIDs, and for high-level functionality e.g. in Verifiable Credentials.
2.2 Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
Yes. The Decentralized Identifier Resolution specification defines methods by which a DID is resolved to provde a requestor with the requested DID document information. The content of DID documents is described more fully in the DID Core specification, which emphasizes that the content of DID documents should be minimal and purpose-specific, and that DID resolvers and methods should expose only information necessary to enable verification, authentication, or service discovery. It places responsibility on DID method specifications to constrain data exposure appropriately.
2.3 Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
In general, no, except that an identifier is deemed "PII" by a number of privacy regulations. While the specification itself is agnostic to the contents of DID documents, implementers might choose to include personal information (which is generally frowned upon by the specification), such as names, public keys tied to specific individuals, or service endpoints that correlate to individual-controlled infrastructure. The specification encourages implementers to avoid including personal data (Verifiable Credentials should be used instead) and to consider pseudonymous or pairwise DIDs when privacy is a concern.
2.4 How do the features in your specification deal with sensitive information?
The specification is not intended to define the data that may be placed into a DID document as this specification is limited to describing the process of resolving a DID and obtaining the DID document information. Details and recommendations on how to handle sensitive DID document information (e.g., PII or service metadata) are found in the DID Core specification. Notwithstanding the foregoing, DID Resolvers and DID URL dereferencers will be able to log requests to their services for resolution and dereferencing. This logging potential represents the ability to create a new type of sensitive metadata information. This specification, therefore, advises that mitigating risks associated with this logging potential is best performed when clients only make such resolution requests to services they trust via a business relationship or because the resolution service infrastructure is operating on infrastructure they control. Further, this specification advises clients to obfuscate their requests to services in order to reduce the possibility of correlation and profiling.
2.5 Does data exposed by your specification carry related but distinct information that may not be obvious to users?
Yes, indirectly. Public keys and service endpoints in DID documents can be correlated across different contexts if reused, revealing patterns or associations not immediately obvious to users. While the spec acknowledges this risk and suggests the use of different DIDs for different interactions, implementers must take care to avoid such linkability when privacy is a priority. Other technologies, such as Verifiable Credentials that use BBS, should be used if static identifiers are not desired for a particular use case.
2.6 Do the features in your specification introduce state that persists across browsing sessions?
Not directly. The specification itself does not define browser APIs or persistent client-side state. However, DIDs may be stored, cached, or referenced in user agents or applications across sessions. The persistence of such state is an implementation detail outside the scope of the specification, though implementers are encouraged to minimize retention of identifiers when not required.
2.7 Do the features in your specification expose information about the underlying platform to origins?
Not Applicable. The DID specification does not expose browser, operating system, or platform-level information to web origins.
2.8 Does this specification allow an origin to send data to the underlying platform?
Not Applicable. The specification defines a syntax and data model for identifiers, not APIs that send data to underlying platforms.
2.9 Do features in this specification enable access to device sensors?
Not Applicable. The DID specification does not interface with device sensors or enable their access.
2.10 Do features in this specification enable new script execution/loading mechanisms?
Not Applicable. The specification does not define mechanisms for loading or executing scripts.
2.11 Do features in this specification allow an origin to access other devices?
Not Applicable. The specification does not define APIs for device access or cross-device communication.
2.12 Do features in this specification allow an origin some measure of control over a user agent’s native UI?
Not Applicable. The specification does not define any features that control or influence the user agent's UI.
2.13 What temporary identifiers do the features in this specification create or expose to the web?
The specification does not define temporary identifiers itself. However, it does enable the use of pairwise or ephemeral DIDs in applications, which may function as temporary identifiers under application control to reduce correlation risk. These identifiers are created by DID Methods and implementers, not by the specification directly.
2.14 How does this specification distinguish between behavior in first-party and third-party contexts?
The specification does not explicitly distinguish between first-party and third-party contexts, as it is not a browser API and does not define execution contexts. However, applications using DIDs are expected to design their resolution and usage patterns with such context-specific concerns in mind, especially regarding correlatability and privacy.
2.15 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
The specification does not define user agent behavior, including private browsing. However, applications implementing DID functionality should take care to avoid caching or persisting identifiers or resolution results across sessions when operating in privacy-focused modes.
2.16 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Yes. The specification includes both Security Considerations (Section 12) and Privacy Considerations (Section 13). The Security Considerations section outlines risks such as DID caching, JSON-LD context integrity, versioning, VDR network forks, non-DID identifiers, etc. The Privacy Considerations section describes the risks for DID resolution profiling and steps that can mitigate those risks.
2.17 Do features in your specification enable origins to downgrade default security protections? Not directly. However, improper use of DIDs—such as failure to verify signatures, or reliance on insecure resolution endpoints—could undermine security. The specification emphasizes the need for secure DID method design, including resolution over authenticated channels and robust verification of signatures.
**2.18 What happens when a document that uses your feature is kept alive in
BFCache (instead of getting destroyed) after navigation, and potentially gets reused on future navigations back to the document?** Not Applicable. The specification does not define web APIs or browser behavior and does not affect or rely upon back/forward cache mechanisms.
2.19 What happens when a document that uses your feature gets disconnected?
Not Applicable. The specification does not define live connection-based features or user agent documents and is agnostic to lifecycle events in browsers.
2.20 Does your spec define when and how new kinds of errors should be raised?
Yes. The specification defines a set of error conditions and response codes for DID resolution and dereferencing (Section 10), specifying specific errors, their descriptions, and how those errors should be encoded and propagated to calling systems. This contributes to predictable and secure error handling in implementations.
2.21 Does your feature allow sites to learn about the user’s use of assistive technology?
Not Applicable. The specification does not interface with user agents or accessibility APIs and does not enable detection of assistive technology.
2.22 What should this questionnaire have asked?
The questionnaire could ask: “How does the specification enable or constrain correlation of identifiers across contexts, and what architectural features exist to mitigate correlation risk?” This is particularly important for identity systems like DIDs, where linking identifiers across domains or uses can expose behavioral patterns or private relationships.
Looks useful @mccown , thanks.
DID documents contain data elements, such as: public keys, service endpoints, and verification methods (i.e., DID Method) associated with a DID.
This sounds like verification methods and DID methods are the same, but they are not. So I would propose to remove the part in parentheses.
Also, I propose to add the following paragraph to the first answer:
In addition to exposing the DID document, the DID Resolution specification also defines two metadata structures. One is DID document metadata, which contains information about the DID document (e.g. timestamps), and the other is DID resolution metadata, which contains information about the DID Resolution process itself. The purpose of these metadata structures is to provide additional information about the identifier to a client, which might be necessary to establish trust in the DIDs, and for high-level functionality e.g. in Verifiable Credentials.
Thanks for this @mccown. I agree with @peacekeeper's suggestions.
Then I will raise the issue to trigger the review in with the security and privacy groups.
@mccown I updated the questionnaire responses the incorporate @peacekeeper suggestions
I looked at creating an issue tracking this for security review. However, the template is requesting a "a dated version in the TR namespace". Rather than an editors draft. Do we need to create one of this? cc @peacekeeper @msporny
Also, in terms of asking for these reviews to be done by a specific date. What should we request? Ideally before TPAC at least with some comments would be great, but that is quite close.
https://github.com/w3c/security-request/issues/new?template=request-a-check-of-a-self-review.md
Use this link for the dated version, which we auto-publish every time a PR gets merged to main.
https://www.w3.org/TR/2025/WD-did-resolution-20250929/
You can say before TPAC, but they're going to probably say: "That's ridiculous, do you know how deep our review queue is!? How about in 3-6 months?" :)
I would say "As soon as reasonably possible as we would like to process responses by TPAC and enter CR in January 2026."
DID WG Discussion 2-Oct:
Wip: there was a response from security that is asking us to do some Treath Modeling
Manu: Yes that was my interpretation as well, I reached out to Simone to talk about it, he indicated he wanted a Threat Model. However I indicated we may not have time in this WG....
Manu: I think there is value to Threat Modeling, but not sure if folks have enough bandwidth for it at the moment...
Manu: Simone is suggesting perhaps as fallback, we might suggest some security considerations from an RFC that implementers could be required to respond to...
Manu: We need to make a decision here.... perhaps we discuss here and then reach out to Simone to try to agree on something...
Wip: Yes, also would be good to get JoeA's perspective on this one...
Probably better to wait until Horizontal Review is complete I think. I will discuss with Will.