iherman
commented
10 months ago The issue was discussed in a meeting on 2024-01-16
- no resolutions were taken
Closed mkhraisha closed 5 months ago
iherman
commented
10 months ago The issue was discussed in a meeting on 2024-01-16
msporny
commented
5 months ago PING review completed, SING review is ongoing. Closing since this issue was raised to track the pre-CR privacy and security review. The document is now in CR, closing.
Self-Review Questionnaire: Security and Privacy
This review is a Security and Privacy Self-Review for the following specification:
When reviewing the Security and Privacy considerations, it is important to first be aware of the Security and Privacy Considerations for Verifiable Credentials:
01.What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
This feature exposes a bitstring list associated with a verifiable credential that indicates the status of the credential. The status list is intended to be used to indicate the status of the credential, such as whether it has been revoked or suspended.
In the three party model issuer-holder-verifier as defined in the VC-DATA-Model, the status list allows a malicious issuer to correlate the holder's interactions with the verifier. This is a privacy concern.
The status list does not expose information to the holder that it cannot easily determine.
The status list exposes to the verifier the status of the credential, which is the primary purpose of the specification.
If a third party is presented with the verifiable credential it is able to check its status with the issuer. The third party can then regularly query the issuer and know about any change of status to that credential.
02.Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
Yes
03.Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
The status list does not deal with personal information, personally-identifiable information (PII), or information derived from either, any personal information, personally-identifiable information (PII), or information derived from either is contained in the Verifiable Credential and is not exposed by the status list.
04.How do the features in your specification deal with sensitive information?
The status list does not deal with sensitive information, all sensitive information is contained in the Verifiable Credential and is not exposed by the status list.
05.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 the state of the status of the credential is persistent and can be queried by the verifier.
06.Do the features in your specification expose information about the underlying platform to origins?
No.
07.Does this specification allow an origin to send data to the underlying platform?
These specifications allow origins to send digitally signed messages to an underlying platform, which would then process the digital signature to ensure that it has not been tampered with. That is, the origin's public key and digital signature are exposed to the underlying platform which then uses that information to verify the proof.
08.Do features in this specification enable access to device sensors?
No
09.Do features in this specification enable new script execution/loading mechanisms? No.
10.Do features in this specification allow an origin to access other devices? No.
11.Do features in this specification allow an origin some measure of control over a user agent's native UI? No.
12.What temporary identifiers do the features in this specification create or expose to the web? The feature does not interoduce any temporary identifiers. All identifiers are intended to live throughout the lifecycle of the verifiable credential.
13.How does this specification distinguish between behavior in first-party and third-party contexts?
It does not, as this does not apply to the specification.
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.
15.Does this specification have both "Security Considerations" and "Privacy Considerations" sections? Yes. The group is currently attempting to determine how to relate these sections to the existing RFCs and other working group item.
16.Do features in your specification enable origins to downgrade default security protections? No.
17.How does your feature handle non-"fully active" documents? It does not interact with non-"fully active" documents.
18.What should this questionnaire have asked?
The questionnaire should focus more on the dependencies of the specification in question, the maturity level of those dependencies and if they have received any security analysis or review, it was more concerned with the browser security context rather than the general web security model.