Security and Privacy Self-Review

[msporny]

This review is a Security and Privacy Self-Review for the following specification:

• Controller Documents v1.0

Controller Documents v1.0 are a generalization of DID Documents v1.0 and some content from VC Data Integrity. Both of those specifications have already undergone horizontal review. The Working Group recently decided that it would rather have the Controller Documents v1.0 content in a separate specification than refer to DID Core or VC Data Integrity.

2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

The information exposed to websites is the Controller Document, which contains verification methods (cryptographic public key material). This information is used to verify cryptographic proofs such as digital signatures produced by Verifiable Credential Data Integrity.

What information does your spec expose to the first party that the first party cannot currently easily determine.

The specification exposes cryptographic material that is meant to be public (e.g., public keys) and is shared by the controller of the document.

What information does your spec expose to third parties that third parties cannot currently easily determine.

The specification exposes cryptographic material that is meant to be public (e.g., public keys) and is shared by the controller of the document.

What potentially identifying information does your spec expose to the first party that the first party can already access (i.e., what identifying information does your spec duplicate or mirror).

None.

What potentially identifying information does your spec expose to third parties that third parties can already access.

None.

2.2 Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Yes.

2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

The specification only exposes public cryptographic keys and warns against sharing PII. Global identifiers used in the specification can be used to correlate individuals if pair-wise identifiers are not used.

2.4 How do the features in your specification deal with sensitive information?

The response to this questions is the same as the response to 2.3.

2.5 Do the features in your specification introduce new state for an origin that persists across browsing sessions?

In general, no, the technology is more general than specific use in web browsers, local storage, and in the same-origin / cross-origin security model for the Web. That said, if a globally unambiguous identifier is shared with an origin, the same tracking concerns raised in 2.3 apply.

2.6 Do the features in your specification expose information about the underlying platform to origins?

No.

2.7 Does this specification allow an origin to send data to the underlying platform?

No.

2.8 Do features in this specification enable access to device sensors?

No.

2.9 Do features in this specification enable new script execution/loading mechanisms?

No.

2.10 Do features in this specification allow an origin to access other devices?

No.

2.11 Do features in this specification allow an origin some measure of control over a user agent’s native UI?

No

2.12 What temporary identifiers do the features in this specification create or expose to the web?

None.

2.13 How does this specification distinguish between behavior in first-party and third-party contexts?

No.

2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

The features do not work any differently in Private Browsing or Incognito modes.

2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

Yes.

2.16 Do features in your specification enable origins to downgrade default security protections?

No.

2.17 How does your feature handle non-"fully active" documents?

Non-"fully active" documents are not supported.

2.18 What should this questionnaire have asked?

It probably should have asked if the text has been reviewed before (it has) and to what degree a re-review is necessary (it's not clear a re-review is necessary).

[selfissued]

What is the workflow that this self-review is subject to?

[msporny]

What is the workflow that this self-review is subject to?

It is a review that someone in the WG performs and the WG reviews and approves (and can modify over time). The Privacy and Security groups then take it as input to determine if they agree with the self review (as they perform a critical review of their own).

You can read more about the process here:

https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review

[iherman]

The issue was discussed in a meeting on 2024-07-31

• no resolutions were taken

View the transcript

3.9. Security and Privacy Self-Review (issue controller-document#22)

See github issue controller-document#22.

See github issue controller-document#25.

Brent Zundel: This is an opportunity for folks to report what they know about what is happening.
… We have filled out this security/privacy review questionnaire in advance of review being done on Controller Document spec.
… I don't know how this is going elsewhere, we have requests in place but no indication that these requests are being acted on.
… A couple days ago, pending tag removed from a request, maybe a clue that it is being worked on.
… Security request still marked pending.

Manu Sporny: I have a tracking issue set up for all of them, #25, it looks like internationalization is done, but the others need a friendly nudge.

Brent Zundel: I need to ping, security, privacy, accessibility.
… with that, we have reached the end, meaning we can talk about #33 again.