Privacy and Security Self-Review for DIDs #891
Description
2.1 What information does this feature expose, and for what purposes?
The DID specification defines a mechanism for resolving Decentralized Identifiers (DIDs) into DID documents, which contain metadata such as public keys, service endpoints, and verification methods associated with a subject. The purpose is to enable cryptographically verifiable identifiers and interaction without relying on centralized registries or authorities. This information may expose data about an entity, its capabilities, and associated services, but is explicitly designed to be under the control of the DID controller.
2.2 Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
Yes. The DID Core specification 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 advises that sensitive information, especially PII or service metadata, be included only when necessary (which is almost never) and that the privacy impact of including such data in a DID document should be carefully considered. It also encourages the use of cryptographic techniques, such as Verifiable Credentials that use selective disclosure, pairwise identifiers, and privacy-preserving protocols layered on top of DIDs, to protect sensitive data.
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 7) and Privacy Considerations (Section 8), which outline risks such as metadata leakage, identifier correlation, key management, service endpoint exposure, and guidance for mitigating 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 6), specifying how systems should behave when identifiers cannot be resolved or if dereferencing fails. This contributes to predictable and secure error handling in implementations. Many of these errors are expected to be raised during DID Resolution (which is another specification that this group is creating).
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.
NOTE: ChatGPT's "Deep research" feature was used to analyze the Security and Privacy Self-Review Questionnaire, then analyze the latest DID v1.1 specification, and then answer each Security and Privacy self-review question. @msporny then edited every response to ensure accuracy.
We had initially performed a privacy and security self-review here, which was used by PING initially:
https://docs.google.com/document/d/1c36r86oI7q4qv0YKVsu0zlNiMwWTqCfWWReAkg3gd2A/edit#
That document has since been locked by the owner, which is a real shame and is why we shouldn't leave these reviews on closed systems (he says as he adds an issue into a proprietary system that might disappear if Microsoft loses interest in it).