Security and Privacy Self-Review Questionnaire #1157
Assignees
Labels
before-CR
HorizontalReview
privacy-tracker
Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response.
security-tracker
Group bringing to attention of security, or tracked by the security Group but not needing response.
Comments
awoie
added
privacy-tracker
This was referenced Jun 15, 2023
|
External review requests created:
|
1 task
This was referenced Jun 16, 2023
|
We got first feedback from @kdenhartog here w3cping/privacy-request#121 (comment). We should be aware that this is not the final review from PING but we should already tackle these issues in our specification. |
We have final feedback from PING. I created issues for all points in this repo. |
|
Excellent, thank you @awoie Closing this issue now that review is complete. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Security & Privacy
This review is a Security and Privacy Self-Review for the following specification:
The specification above is a data model specification and does not define protocols or browser APIs that expose instances of that data model to any party. Such protocols or browser APIs are out-of-scope of the specification, and those would need to answer this question in their own privacy considerations section. Since this specification does not define browser APIs or protocols, most of the questions below cannot be answered directly.
However, this self-review aims to answer questions as if the first-party was the issuer and third-parties were verifiers of Verifiable Credentials and Verifiable Presentations.
2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
This question does not directly apply for the reasons pointed out in the introduction.
The data model itself is based on JSON-LD, and due to its extensibility model, Verifiable Credentials and Verifiable Presentations can encode any information, including sensitive or personally identifiable information (PII). This includes identifiers about the subject of the Verifiable Credential as well as identifiers of the Verifiable Credentials and Verifiable Presentations.
Exposing data adhering to the specified data model requires protocols and/or browser APIs that are out of the scope of this specification. Holders of Verifiable Credentials and Verifiable Presentations can decide where and how the information encoded in the data model gets exposed.
Due to this, the following questions are not directly relevant to VCDM 2.0, but we tried to answer on a best-effort basis based on the assumptions in the introduction.
2.1.1 What information does your spec expose to the first party that the first party cannot currently easily determine?
This question does not directly apply for the reasons pointed out in the introduction.
However, in some cases, the issuer (first-party) must collect and verify additional evidence about the subject before making a claim and before the Verifiable Credential containing those claims gets issued. That type of evidence can be any sort of information, including sensitive information and PII, and is typically provided by the holder or subject of the Verifiable Credential during the provisioning or issuance process.
2.1.2 What information does your spec expose to third parties that third parties cannot currently easily determine?
This question does not directly apply for the reasons pointed out in the introduction.
However, Verifiable Credentials are presented to verifiers (third-parties) typically in the form of Verifiable Presentations, which, due to its extensibility model, can contain sensitive data and PII, including identifiers that verifiers cannot currently easily determine.
2.1.3 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)?
This question does not directly apply for the reasons pointed out in the introduction.
In general, this is a case-by-case decision due to the extensibility model of Verifiable Credentials and the wide variety of usage scenarios.
To answer the question, an issuer (first-party) might have an existing relationship with the subject and collected some of the data to make the claims about the subject in via an out-of-band process. This might include the identifier of the subject (
credentialSubject.id) as well as other sensitive information or PII about the subject of the Verifiable Credential.2.1.4 What potentially identifying information does your spec expose to third parties that third parties can already access?
This question does not directly apply for the reasons pointed out in the introduction.
In general, this is a case-by-case decision due to the extensibility model of Verifiable Credentials and Verifiable Presentations and also due to the wide variety of usage scenarios.
A verifier (third-party) might have an existing relationship with the subject and collect some of the data about the subject via an out-of-band process. This might include any information in the Verifiable Credentials or Verifiable Presentations. Consequently, this question cannot be answered and has to be answered case-by-case.
2.2 Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
The specification explicitly describes privacy-preserving techniques to share Verifiable Credentials and Verifiable Presentations between the actors of the ecosystem - Verifier, Holder and/or Subject, Issuer. Amongst others, this includes selective disclosure of claims which is the ability of a holder to make fine-grained decisions about what information to share, or zero-knowledge proofs to prevent correlation based on linkable identifiers. Furthermore, data minimization is described in a dedicated section of the VCDM 2.0 specification, see The Principle of Data Minimization.
2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
Verifiable Credentials and Verifiable Presentations can contain any information that PII, such as potential identifiers.
Therefore, the VCDM 2.0 specification has an extensive section on privacy considerations, see Privacy Considerations.
2.4 How do the features in your specification deal with sensitive information?
Verifiable Credentials and Verifiable Presentations can contain any information that includes sensitive data.
Therefore, the VCDM 2.0 specification has an extensive section on privacy considerations, see Privacy Considerations.
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?
Potentially yes. The subject’s ID in a Verifiable Credential could be a temporary identifier not stored permanently anywhere.
2.13 How does this specification distinguish between behavior in first-party and third-party contexts?
This question does not directly apply for the reasons pointed out in the introduction.
However, the specification distinguishes between the behavior between the Issuer (first-party) and the Holder, and the Holder and Verifier (third-party).
2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
This question does not directly apply for the reasons pointed out in the introduction.
However, protocols that use this specification should be able to work in incognito mode.
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?
No. Does not apply.
2.18 What should this questionnaire have asked?
The VCDM 2.0 specification does not introduce new browser features (APIs) or protocols in general. It is focused on a JSON-LD data model representation for Verifiable Credentials and Verifiable Presentations. The questionnaire focuses on the browser security model as well as interactive user agents for the Web. While it asks important questions related to that context, it is difficult to map these questions to the usage of a data model such as the VCDM 2.0.
The text was updated successfully, but these errors were encountered: