What is the difference between JsonSchema2023 and CredentialSchema2023?

[msporny]

While reviewing w3c/vc-data-model#1178, it was not clear what the difference between https://w3c.github.io/vc-json-schema/#jsonschema2023 and https://w3c.github.io/vc-json-schema/#credentialschema2023 are. They both seem to use JSON Schema to validate an input document, with no differentiating features that I could tell.

What is the difference between those two types? When should you use one vs. the other?

[decentralgabe]

@msporny the CredentialSchema2023 type wraps a JSON schema in a VC, so that when you resolve the id property of credentialSchema you get a VC where the credentialSubject is a schema.

The JsonSchema2023 type is a json schema alone, meaning when you resolve the id in the credentialSchema you get a json schema document.

[msporny]

@msporny the CredentialSchema2023 type wraps a JSON schema in a VC, so that when you resolve the id property of credentialSchema you get a VC where the credentialSubject is a schema.

The JsonSchema2023 type is a json schema alone, meaning when you resolve the id in the credentialSchema you get a json schema document.

Ok, thanks, I think I understand the difference now. If that is the difference, it seems like Example 3 is wrong in the spec today:

https://w3c.github.io/vc-json-schema/#credentialschema2023

Specifically, the credential subject is a DID object that has an email address

  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "emailAddress": "subject@example.com"
  },

... and is almost exactly the same as Example 2:

https://w3c.github.io/vc-json-schema/#example-example-jsonschema2023

It's also not clear where I'd use one vs. the other, as the specification seems to be silent on that topic (at present).

Are you trying to get to a JSON Schema that is signed by the issuer? If so, have you considered using relatedResource instead?

https://w3c.github.io/vc-data-model/#integrity-of-related-resources

[decentralgabe]

Specifically, the credential subject is a DID object that has an email address
... and is almost exactly the same as Example 2:

I just reviewed them both and I believe them to be correct, help me understand what might be wrong.

Example 2 (under JsonSchema2023) shows:

• A credential with a credentialSubject containing an id and an emailAddress
• A credentialSchema referencing an id to a JSON schema, enforcing the presence of the emailAddress

Example 3 (under CredentialSchema2023) shows:

• A credential with a credentialSubject containing an id and an emailAddress
• A credentialSchema referencing an id to a verifiable credential, where its credentialSchema is a JSON schema enforcing the presence of the emailAddress

It's also not clear where I'd use one vs. the other, as the specification seems to be silent on that topic (at present).

You would want to use JsonSchema2023 when you do not care who authored the schema. Use CredentialSchema2023 when you do. Using CredentialSchema2023 also gives you other VC-benefits, like the ability to revoke the usage of a schema (it could be replaced by a newer version).

I agree the usage of the two can and should be clarified. Opened #173 to address.

Are you trying to get to a JSON Schema that is signed by the issuer? If so, have you considered using relatedResource instead?

Yes, this seems to be to provide a hash...which we would also want, I'll add a note to #120. But does it solve signing too?

[dmitrizagidulin]

If anyone is confused, following the second link, it's supposed to be https://w3c.github.io/vc-json-schema/#verifiablecredentialschema2023 (not #credentialschema2023)

[iherman]

The issue was discussed in a meeting on 2023-07-25

• no resolutions were taken

View the transcript

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.