Verifiable Credentials Working Group Special Topic Call on JSON Schemas — Minutes

Date: 2023-07-25

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Ivan Herman, Andres Uribe, Shigeya Suzuki, Sebastian Crane, Phillip Long, David Chadwick, Ted Thibodeau Jr., Dmitri Zagidulin, Hiroyuki Sano, Dave Longley, Kristina Yasuda, Manu Sporny, Will Abramson, Paul Dietrich, Joe Andrieu, Gabe Cohen

Regrets:

Guests:

Chair: Brent Zundel, Kristina Yasuda

Scribe(s): Sebastian Crane, Manu Sporny

Content:

1. vc-data-model PRs.

Manu Sporny: https://github.com/w3c/vc-data-model/pulls/.

1.1. Add confidenceMethod to table of reserved terms and v2 @context (pr vc-data-model#1142)

See github pull request vc-data-model#1142.

Manu Sporny: Pull request 1142 is waiting for CCG members to review.

1.2. Add “author” and “party” to terminology, rewrite “claim” terminology (pr vc-data-model#1172)

See github pull request vc-data-model#1172.

Manu Sporny: 1172 continues to have discussion.

1.3. Add validation section regarding holder (pr vc-data-model#1199)

See github pull request vc-data-model#1199.

Manu Sporny: There are some disagreements on pull request 1199.

1.4. Add section on JSON Processing. (pr vc-data-model#1202)

See github pull request vc-data-model#1202.

Manu Sporny: 1202 has multiple positive reviews, but has pending requested changes. kristina, will you be able to re-review this week?

Kristina Yasuda: I will try.

1.5. Add section on Ecosystem Compatibility. (pr vc-data-model#1203)

See github pull request vc-data-model#1203.

Manu Sporny: 1203 has all positive reviews, but I will not merge it until others have reviewed it.

1.6. Move data schemas to basic concepts section (pr vc-data-model#1207)

See github pull request vc-data-model#1207.

Manu Sporny: 1207 will be merged.

2. What is the difference between JsonSchema2023 and CredentialSchema2023? (issue vc-json-schema#172)

See github issue vc-json-schema#172.

Kristina Yasuda: decentralgabe, are you able to talk here?

Gabe Cohen: Yes. The current spec defines JSON schema 2023 as well as the credentials schema 2023. The latter just wraps it in a verifiable credential, allowing the provenance of schemas to be verified.

Manu Sporny: The examples had some surprising context values. This made the subject of the verifiable credentials appear to be a plain JSON object rather than JSON-LD data.

Dave Longley: +1 to a new property with @json because VCDM itself has requirements that JSON schema may not conform to.

Ivan Herman: See JSON Literals in the JSON-LD spec.

Manu Sporny: Regarding the decision last meeting about datestamps, which version of JSON Schema applies? It is not clear which would apply.

Dave Longley: +1 because JSON schema uses date-based versioning itself there could be confusion.

Gabe Cohen: I am happy to move the data to a new property where the type is ‘json’. As for the versioning, I’m happy to change this as well.
… We have a section in the specification about processing, where we say the processors can detect the version of JSON-LD used.

Manu Sporny: That would address my high-level concerns. The only other concern I have is that sometimes people state the wrong version of JSON Schema. You can’t always depend on the metadata.
… Therefore, we need a conformance test suite to ensure that conforming processors test for the version of the JSON Schema used.

Gabe Cohen: We should maybe introduce a normative requirement to specify a version of JSON Schema, but I don’t think we should require a specific version.

Sebastian Crane: Wanted to ask, semantically, what does a JSON Schema VC mean in contrast to JSON Schema published via GPG?
… so, VCs requiring use of JSON Schema, would allow it to be verified in that ecosystem.

Gabe Cohen: GPG would be one way to secure a VC, but that’s out of scope… there could be other ways to secure JSON Schema that are valid.

Manu Sporny: I wanted to agree with decentralgabe that we should make the normative statement stronger, however, I think we should also require at least one specific version of JSON Schema, and make older version support optional.

Kristina Yasuda: why require? that does not make sense. compliance to the spec is voluntary.

Gabe Cohen: decentralgabe: semantically…a vc json schema provides optional validation for as a step in a longer credential validation process.

Sebastian Crane: manu, kristina, if one version supports 2020 but another supports 2018, they will be unable to understand each other. This will result in an ecosystem that will not be interoperable.

Manu Sporny: If we remove the version specifier, though, we’ll be locked in to that JSON Schema version forever. We could introduce language to require parsing the version identifier.

Ivan Herman: There is a blog post in the JSON Schema website which may resolve the issue of version incompatibilities.

Ivan Herman: See “Towards a stable JSON Schema”.

Ivan Herman: It may well be that by the time we go to REC, the issue might have disappeared.
… The other point is editorial: the text now says that JSON Schema 2023 is defined at a vocabulary URL, but that is not correct, the definition is this specification. That should be rephrased.

Gabe Cohen: manu, I like the idea of making at least one required and others optional.
… I’ll open an issue about that.
… I don’t know when JSON Schema’s movements will happen.

Manu Sporny: kristina, I think you said we had a path to CR and REC. What is that?

Gabe Cohen: It’s the OpenJS Foundation specifications that we are allowed to reference normatively.
… It was pointed out that normatively referencing IETF drafts is not a good idea.

Manu Sporny: Glad that is finally resolved, after many, many years. :).

Sebastian Crane: https://datatracker.ietf.org/doc/draft-wkumari-not-a-draft/.

Ivan Herman: We are not the only ones to have this trouble.

Ivan Herman: See Strategy team’s relevant issue.

3. Issue triage.

Ted Thibodeau Jr.: I suggest least-recently-updated https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Abefore-CR+-label%3Apost-CR+sort%3Aupdated-asc.

3.1. Move Data Schemas to Basic Concepts section (issue vc-data-model#1196)

See github issue vc-data-model#1196.

Kristina Yasuda: Do you need extra time to work on #1196?

Manu Sporny: #1207 will resolve it.

3.2. validFrom and validUntil fields need better specification of dateTime (issue vc-data-model#1193)

See github issue vc-data-model#1193.

Manu Sporny: assign to me and pre-CR.

3.3. Ensure the base context doesn’t constrain lower-maturity specifications (issue vc-data-model#1175)

See github issue vc-data-model#1175.

Manu Sporny: We have marked the context as ‘at risk’, so if anything looks like it’s going to hold up our CR process it can be removed.

Dave Longley: +1 to already addressed.

Ivan Herman: +1.

Phillip Long: +1 that we have language addressing this already.

Manu Sporny: We currently have this in the spec:.

ISSUE: (AT RISK) Hash values might change during Candidate Recommendation.

Manu Sporny: This section lists cryptographic hash values that might change during the Candidate Recommendation phase based on implementer feedback that requires the referenced files to be modified.

Manu Sporny: (in the base context section).

Manu Sporny: Link to that text is here: https://w3c.github.io/vc-data-model/#base-context.

Dave Longley: -1 to needing additional language, right now we can modify in any way.
“can be changed in any way, including removal”.

Ivan Herman: +1 to dlongley.

Manu Sporny: I’ll take an action item on 1175 to make this more specific.

3.4. Define Controller Documents in the Core Data Model (issue vc-data-model#1205)

See github issue vc-data-model#1205.

Dave Longley: VC-COSE-JOSE can reference data integrity if it so desires.

Dave Longley: or reference DID core like DI does.

Manu Sporny: DID documents are subclasses of controller documents.

Dave Longley: +1 controller documents have been part of data integrity for a decade, DID documents are specific subclass of controller documents.

Dave Longley: https://w3c.github.io/vc-data-integrity/#controller-documents.

seabass2: !nick seabass.