Security and Privacy Self-Review Questionnaire

This review is a Security and Privacy Self-Review for the following specifications, the first being the base data integrity specification, and the latter two being specific cryptosuite implementations of the base specification:

The three specifications listed above are cryptographic message securing mechanisms and are intended to be reviewed together. The first specification, Verifiable Credential Data Integrity, is the base specification that defines the base concepts and algorithms. The "EdDSA Cryptosuite" and "ECDSA Cryptosuite" specifications are concrete implementations of the base specification and each define specific cryptographic algorithms and processes to be used when providing data integrity protection for Verifiable Credentials.

When reviewing the Security and Privacy considerations, it is important to first be aware of the Security and Privacy Considerations for Verifiable Credentials:

and then consider the Security and Privacy considerations provided in the Verifiable Credential Data Integrity specification:

and then finally consider the Security and Privacy considerations for each cryptography suite.

Since the Verifiable Credential Data Integrity largely deals with the creation of digital proofs on JSON data, the responses will be focused on the data exposed via those digital proofs. An example of such a digital proof is provided below:

{
  "title": "Hello world!",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "example-signature-2022",
    "created": "2020-11-05T19:23:24Z",
    "verificationMethod": "https://di.example/issuer#z6MkjLrk3gK...HxUXfxnG",
    "proofPurpose": "assertionMethod",
    "proofValue": "zQeVbY4oey5q2M3XKaxup3tmzN4...MrXFkXJeV6doDwLWx"
  }
}

Demonstration of interoperability between a subset of these technologies have been utilized by at least 17 implementers during a plugfest performed last year (specifically, the Verifiable Credential Data Integrity specification and the Ed25519Signature2020 variant of the EdDSA cryptosuite):

https://docs.google.com/presentation/d/19GmJ3bLMrbVadesnkmsWaaUr-U71Y9Kr775tZvgs-xI/edit#slide=id.g18a979873b4_2_50

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 Web sites or other parties includes all the information in the proof structure attached to JSON data. The type, cryptosuite, and proofPurpose values just identify the type of cryptographic suite and purpose used and do not create privacy or security concerns (other than conveying that the entity that created the signature is capable of creating such a signature). The created date conveys when a particular signature was done and thus could indicate when a particular individual took an action to create or receive the digitally signed information. The verificationMethod could be used to uniquely identify the entity creating the digital proof across websites unless it is created in a pairwise manner. The proofValue, if replayed across origins (which is expected) can be used as a tracking mechanism if verifiers of the digital signature collude, unless a specific type of DataIntegrityProof that utilizes unlinkability, such as the vc-di-bbs cryptosuite is used, OR digital signatures are re-created for every presentation of the information to a verifier of the information.

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

If an individual consents to the release of data to the first party, or a first-party shares the data with a 3rd party without the individual's consent, the created date and verificationMethod could be seen as information that a first party could not easily determine until it was transmitted to them.

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

If an individual consents to the release of data to the third party, or a first-party shares the data with a 3rd party without the individual's consent, the created date and verificationMethod could be seen as information that the third party could not easily determine until it was transmitted to them.

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.

If a third party is colluding with another third party, the created date and verificationMethod could be already known to a third party.

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

For Verifiable Credential Data Integrity, yes.

For the ECDSA Cryptosuite, yes.

For the EdDSA Cryptosuite, yes.

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

The verificationMethod could be used to uniquely identify the entity creating the digital proof across websites unless it is created in a pairwise manner. The proofValue, if replayed across origins (which is expected in a number of use cases) can be used as a tracking mechanism if verifiers of the digital signature collude, unless a specific type of DataIntegrityProof that utilizes unlinkability, such as the vc-di-bbs cryptosuite is used, OR digital signatures are re-created for every presentation of the information to a verifier of the information.

The expression of these features are mandatory; without them, the digital signature would not be verifiable.

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 proof 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?

In general, no. If specific types of new cryptography are used, such as unlinkable signatures, then the capabilities of the underlying platform could be exposed to the origins. However, given that this capability (the ability to generate unlinkable signatures) is generalized, and any platform is capable of generating those class of digital signatures, then it does not seem as if the exposure of that information to an origin is of deep concern.

2.7 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. When processing these messages, the concerns in question 2.4 apply. That is, the origin's public key and digital signature are exposed to the underlying platform which then uses that information to verify the Data Integrity proof.

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?

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

The value of a digital signature (expressed in proofValue), or the identifier for a digital proof (expressed in id and previousProof), could be viewed as a temporary identifiers.

The proofValue field is the result of a cryptographic operation, and ranges in size from 64 bytes to many kilobytes and is unique enough to be used as a tracking identifier (if unlinkable digital signatures are utilized).

The id and previousProof values are expected to be randomly generated, are expected to be at least 128-bits in size, and are therefore unique enough to be used as tracking identifiers if they are not re-generated for every digital proof (which is expected), or if a single digital signature is transmitted more than once (which is expected).

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 modees.

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

Yes, all three specifications have individual "Security Considerations" and "Privacy Considerations" sections. The group is currently attempting to determine how to structure the information across specifications by either:

Duplicating the section headers in the Verifiable Credential Data Integrity specification in both the EdDSA Data Integrity Cryptosuite and ECDSA Data Integrity Cryptosuite.
Referring to the Verifiable Credential Data Integrity Privacy Considerations section and Security Considerations section from both the EdDSA Data Integrity Cryptosuite and ECDSA Data Integrity Cryptosuite.

We are also wondering if it would be worthwhile to refer to the Verifiable Credentials Data Model Security and Privacy Considerations sections to provide one context in which this specification is expected to be utilized. That specification has a significant amount of detail on how PII and sensitive information might be handled in a real world setting.

We are looking for guidance from the Privacy and Security groups at W3C on the best way to express privacy and security requirements in a way that is specific to a specification, while providing a more general way to discover privacy and security requirements in related (or foundational) specifications.

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 data model security specifications to the questions.

For example, I found myself wanting to talk about how these specifications are used in the Verifiable Credentials ecosystem, but in doing so, would invoke security and privacy considerations that are outside the scope of these specifications (but handled in the other specifications).

Therefore, it becomes important to establish the appropriate security and privacy boundary for a review. Which things are in the control of the specification being discussed, and which things are outside of the control of the specifications being discussed? I did not find a section in the self-review questionnaire that discussed that provided that particular guidance and it might be a good addition to the questionnaire to guide future reviews.

The downside for creating security/privacy review boundaries is, of course, specifications drawing the boundary in a way that a critical security or privacy consideration is out of scope for all specifications. This approach would leave concerning privacy and security consideration gaps between specifications and thus a question related to the interplay between various specifications in an ecosystem might be appropriate.

w3c / vc-data-integrity