search

w3c / vc-jose-cose

Verifiable Credentials Working Group — VC JSON Web Tokens specification
https://w3c.github.io/vc-jose-cose/
Other
31 stars 13 forks source link

Security and Privacy Self-Review Questionnaire #93

Closed OR13 closed 11 months ago

OR13 commented 1 year ago

This review is a Security and Privacy Self-Review for the following specification:

The specification listed leverages JOSE cryptographic algorithms and processes to provide data integrity and authentication 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:

Since the Securing Verifiable Credentials using JSON Web Tokens 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:

---------------- Decoded Protected Header ---------------
{
  "alg": "ES384",
  "typ": "vc+ld+jwt",
  "iss": "https://contoso.example",
  "kid": "#urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwX
F4W_7noWXFZAfHkxZsRGC9Xs"
}
--------------- Decoded Claimset ---------------
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2",
    "https://w3id.org/vc/status-list/2021/v1"
  ],
  "id": "https://contoso.example/credentials/23894672394",
  "type": [
    "VerifiableCredential"
  ],
  "issuer": {
    "id": "https://contoso.example"
  },
  "validFrom": "2021-04-05T14:27:42Z",
  "credentialStatus": {
    "id": "https://contoso.example/credentials/status/3#94567",
    "type": "StatusList2021Entry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://contoso.example/credentials/status/3"
  },
  "credentialSubject": {
    "id": "did:example:6789",
    "type": "Person"
  }
}
--------------- Compact Encoded JSON Web Token ---------------
eyJhbGciOiJFUzM4NCIsInR5cCI6InZjK2xkK2p3dCIsImlzcyI6Imh0dHBzOi8vY29udG9zby5
leGFtcGxlIiwia2lkIjoiI3VybjppZXRmOnBhcmFtczpvYXV0aDpqd2stdGh1bWJwcmludDpzaG
EtMjU2Ok56YkxzWGg4dURDY2QtNk1Od1hGNFdfN25vV1hGWkFmSGt4WnNSR0M5WHMifQ.eyJAY2
9udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL
3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiLCJodHRwczovL3czaWQub3Jn
L3ZjL3N0YXR1cy1saXN0LzIwMjEvdjEiXSwiaWQiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9
jcmVkZW50aWFscy8yMzg5NDY3MjM5NCIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiXS
wiaXNzdWVyIjp7ImlkIjoiaHR0cHM6Ly9jb250b3NvLmV4YW1wbGUifSwidmFsaWRGcm9tIjoiM
jAyMS0wNC0wNVQxNDoyNzo0MloiLCJjcmVkZW50aWFsU3RhdHVzIjp7ImlkIjoiaHR0cHM6Ly9j
b250b3NvLmV4YW1wbGUvY3JlZGVudGlhbHMvc3RhdHVzLzMjOTQ1NjciLCJ0eXBlIjoiU3RhdHV
zTGlzdDIwMjFFbnRyeSIsInN0YXR1c1B1cnBvc2UiOiJyZXZvY2F0aW9uIiwic3RhdHVzTGlzdE
luZGV4IjoiOTQ1NjciLCJzdGF0dXNMaXN0Q3JlZGVudGlhbCI6Imh0dHBzOi8vY29udG9zby5le
GFtcGxlL2NyZWRlbnRpYWxzL3N0YXR1cy8zIn0sImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoi
ZGlkOmV4YW1wbGU6Njc4OSIsInR5cGUiOiJQZXJzb24ifX0.YuPWiXE6ffUNwnpTiKRu6QKRn7R
MCzguSUY0huI4AsaJEQ36MkSxPAKHoNY-5IGpKGOBLVTXr7bqt4CdA8QCL48YFe0WPz7BwKzw0m
WuQmqm3aCRHDdQQQTPClKK-eJP

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 Protected Header and Signature structures, see https://datatracker.ietf.org/doc/html/rfc7519.

Note that the privacy and security issues associated with the core data model will be addressed in a separate review, so the Payload is not analyzed here.

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 Protected Header 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 Protected Header 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 Protected Header 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?

Yes.

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

The Protected Header could be used to uniquely identify the entity creating the digital proof across websites unless it is created in a pairwise manner. The Signature, 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 digital signatures are re-created for every presentation of the information to a verifier of the information.

While the signature is required, the details of the protected header, are outside the scope of this specification, see:

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.

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

No

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

The value of a digital signature, or the ProtectedHeader, could be viewed as temporary identifiers.

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?

Yes. The group is currently attempting to determine how to relate these sections to the existing RFCs and other working group item.

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.

The questionnaire should focus on the dependencies of the specification in question, and if those dependencies are standards, or have received security analysis and review.

For data model specifications, this would mean surfacing type safety issues in the serialization, or known issues with the underlying cryptographic operations, such as the presence of weak cryptography in the standard registries

selfissued commented 1 year ago

LGTM

OR13 commented 1 year ago

This seems ready, I removed the WIP tag

awoie commented 1 year ago

Created issues for PING to review:

OR13 commented 11 months ago

closing, we'll address follow ups as they come