Verifiable Credentials JSON Schema Specification 2023-06-13

[decentralgabe]

We have conducted a self-review of our spec VC JSON Schema, and the results can be found at w3c/vc-json-schema#167.

Please check our findings.

[kdenhartog]

Notes for PING Reviewers

Noting that the terms First Party is not shared between the different VC data model specs. This isn't really an issue, but in general I think of the First party as the issuer, the holder as a UA, and the verifier as a third party so will refer to them within this context. This is the model that was used in the VC Data Model self review as well, but doesn't necessarily align with the specific definitions that are normally used within the browser and PING.

High level summary of the specs purpose for PING reviewers

The purpose of this specification is to define an extension point for the credentialSchema property in the VC Data Model. Essentially what it does is defined a JSON Schema for the Verifiable Credential to make it possible for validate the structure of the claims and metadata within the VC. E.g. validate that credentialSubject.firstName property value is a string not an object.

Feedback

1. In section 3.1.1 it says that it recommends that the ID property is a dereferenceable IRI. If this IRI is dereferenceable then it could be used to track the usage of the credential when the schema get's dereferenced and the IRI contains a unique identifier in IRI to detect when the schema is being dereferenced to correlate it to an IP address. Further information should be added to this section or to a separate privacy section to deter the inclusion of unique tracking identifiers in the IRIs.

2. When using CredentialSchema2023 with a Verifiable Credential that utilizes a selective disclosure proof suite, it may be possible for the verifier to determine additional attributes that would be available, but not presented when verifying a credential from the holder wallets. Wallets should be advised in a privacy section may want to reject these verification requests or selectively disclose the schema properties from the credential.

3. Section 6.3 could be improved to encourage the usage of OHTTP to cryptographically prevent IP address correlation during resolution of the JSON schema.

[OR13]

@kdenhartog thanks for the review!

[kdenhartog]

You're welcome! I believe next steps is that these will get presented by @pes10k on my behalf on the next PING call this Thursday (agenda permitting) and then we can take it from there as to what changes need to be made to the spec.

[sandandsnow]

As Kyle was not able to join our most recent call due to the timezone for our meeting, we decided to handle @kdenhartog's review asynchronously. If you have any questions about the results of the review, please let us know.

[kdenhartog]

@sandandsnow I'll be in US time zones for the month of August and can plan on attending the 18th to help close this and the other VC related ones out. Alternatively, I can reach out to the WG to meet them during one of their regularly scheduled times. In the mean time, I'm happy to assist on this asynchronously.

[sandandsnow]

@kdenhartog, to confirm, it would be great to have your join the call on Thursday UTC 16 and discuss your privacy reviews related to VC

[kdenhartog]

I will be there so we can add this to the agenda for tomorrow.

[kdenhartog]

We reviewed these points today during the PING call and there appeared to be consensus agreement these points should be added as privacy considerations sections to the specification and that would be the only aspects necessary to address this review.

One other broad point for all the related VC specs would be to point back to the VC Data Model privacy/security sections where possible to encourage people to pay attention to the previous points and reduce redundancy of points across the various specs.

[Keishalue79]

Lakeisha Luellen