Self-review privacy and security checklist

[davebrowning]

Following the guidance in How to do Wide Review, this issue is for discussion/agreement (when complete) of the privacy and security considerations for DCAT3 in line with current processes and standards.

Specifically, it provides responses to Self-Review Questionnaire: Security and Privacy where further context and examples are available for each question.

The existing section on Security and Privacy can be found here, currently unchanged from DCAT2. As this says, the key points are that while the DCAT vocabulary supports the attribution of data and metadata to various participants and the association of rights and licences with cataloged Resources records either of which may raise privacy or security questions around personal or other sensitive information, the responsibility for ensuring that security and privacy considerations are addressed falls to the applications (and associated data management processes) that produce, maintain, publish or consume such vocabulary terms. In particular, the recommendation defines no protocol or user agent behaviour.

---

Responses:

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

• DCAT3 defines a vocabulary for expressing information related to cataloged resources, but doesn't define the mechanism for exchanging that information between interested parties. This is a different dimension to the concern of the question (as clarified in ..information describing the browser user..), so this is not applicable to DCAT

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

• N/A

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

• As described in the relevant section of the DCAT3 recommendation, no such information is explicitly exposed by DCAT. Implementations using DCAT need to ensure that any considerations need to be properly managed.

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

• Not applicable

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

• No

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?

• Not applicable

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

• Not applicable

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

• Yes, combined Both [RFC6973] (particularly Section 7) and [RFC3552] have been reviewed as input into drafting this response.

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

• Not applicable

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

• Not applicable

[riccardoAlbertoni]

I am marking this issue as "due-for-closing", implying that we can close it after six days if no objections arise.

Two reasons justified the closure of this issue.

• As discussed on different occasions with W3C contacts and in DXWG plenary meetings, it is allowed to time out requests for feedback. Considering our waiting period, the DXWG voted to move the process forward even though the security group has yet to react.
• Closing this GitHub issue does not impede the security group's ability to react and provide feedback in the future. The self-review privacy and security checklist remains accessible and explicitly mentioned in the feedback request to the security group even after this GitHub issue is closed.