decentralgabe
commented
1 year ago Closed decentralgabe closed 1 year ago
decentralgabe
commented
1 year ago 
iherman
commented
1 year ago Not that it affects the security analysis, but it is better to be precise. In
2.12 What temporary identifiers do the features in this specification create or expose to the web?
Each VC JSON Schema is identified with an id or $id property as per the associated JSON Schema specification. If the type CredentialSchema2023 is used, a new identifier for the given verifiable credential will be create. Exposure of these identifiers to the web is entirely dependent on any recipient of the document(s) publishing or making them available on the web.
I believe the "$defs" feature of JSON Schemas (that provides a series of identifiers that can be referred to from the schema) also belongs to the situation described in the question, but it can be said that these identifiers strictly remain within a given schema (I believe, or am I wrong?).
decentralgabe
commented
1 year ago That's correct @iherman the $defs and even $refs can contain IDs, though they may be externally defined.
decentralgabe
commented
1 year ago calling out we should address the concerns raised in this comment https://github.com/w3cping/privacy-request/issues/119#issuecomment-1638924033
andresuribe87
commented
1 year ago decentralgabe
commented
1 year ago With https://github.com/w3cping/privacy-request/issues/119 the review is complete.
This review is a Security and Privacy Self-Review for the following specifications:
When reviewing the Security and Privacy considerations, it is important to first be aware of the Security and Privacy Considerations for Verifiable Credentials:
2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
The information epxosed to web sites or other parties includes all information in the JSON Schema, and the wrapping verifiable credential, if the type
CredentialSchema2023is used. The JSON schema and its optional associated credential are necessary to be exposed so that any recipient of a verifiable credential using VC JSON Schema can accurately validate that the credential is conformant with the data shape defined by the schema. If the schema is packaged as a credential, that credential's data is necessary to be exposed for integrity verification, and the communication of other data such as authorship information, and credential status.What information does your spec expose to the first party that the first party cannot currently easily determine.
To the first party the spec exposes a JSON Schema and optionally a Verifiable Credential if the
CredentialSchema2023type is used. Neither of these values could be determined without their inclusion in thecredentialSchemaproperty of a verifiable credential.Without exposure of a VC JSON Schema the first party (a verifiable credential holder) will not be able to perform a static validity check on any given verifiable credential. This static validity check is useful in enforcing that certain properties are present and of a certain shape (e.g. match a regular expression, are of a correct JSON data type). A first party such as a verifiable credential holder has an interest in determining whether the data they recieve will be considered valid by any third party.
What information does your spec expose to third parties that third parties cannot currently easily determine.
To the third party the spec exposes a JSON Schema and optionally a Verifiable Credential if the
CredentialSchema2023type is used. Neither of these values could be determined without their inclusion in thecredentialSchemaproperty of a verifiable credential.Without exposure of a VC JSON Schema the third party (a verifiable credential verifier) will not be able to perform a static validity check on any given verifiable credential. This static validity check is useful in enforcing that certain properties are present and of a certain shape (e.g. match a regular expression, are of a correct JSON data type). A third party such as a verifiable credential verifier has an interest in determining whether the data they recieve is considered valid.
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).
No information is duplicated to the first party.
What potentially identifying information does your spec expose to third parties that third parties can already access.
No information is duplicated to the third party except for in the case of collusion between third parties, where VC JSON Schema values could be shared.
2.2 Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
Yes. Data schemas are encouraged to use the
additionalPropertiesfeature of JSON Schemas, as noted in our specification. This encourages putting a minimal amount of data in each JSON Schema.2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
Any time there is an opportunity for a document's inclusion there is a risk for exposure of PII. There is nothing prohibiting a JSON Schema from including PII whilst still maintaining compliance with a given JSON Schema specification. The concerns here match those outlined in the VC Data Model itself. We have an issue open to track improving our language in this area.
2.4 How do the features in your specification deal with sensitive information?
Any time there is an opportunity for a document's inclusion there is a risk for exposure of sensitive information. There is nothing prohibiting a JSON Schema from including PII whilst still maintaining compliance with a given JSON Schema specification. The concerns here match those outlined in the VC Data Model itself. We have an issue open to track improving our language in this area.
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?
Each VC JSON Schema is identified with an
idor$idproperty as per the associated JSON Schema specification. If the typeCredentialSchema2023is used, a new identifier for the given verifiable credential will be create. Exposure of these identifiers to the web is entirely dependent on any recipient of the document(s) publishing or making them available on the web.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?
We have an issue open to track improving our language in this area.
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.
2.18 What should this questionnaire have asked?
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 data schemas for a data model such as the VC Data Model.