Update language around the defined types and their usages

[decentralgabe]

Fix #172 #178

I believe this needs a change to the core vocab to add a new property jsonSchema with the type as @json

---

Preview | Diff

[decentralgabe]

As discussed on the call today I've updated CredentialSchema2023 to make use of a new property in a VC, jsonSchema instead of the credentialSubject.

My understanding -- and please correct me otherwise -- is that to make this work in LD-land there needs to be a definition in a context file that adds a property to VerifiableCredential such as:

 "jsonSchema": {
  "id": "https://www.w3.org/TR/vc-json-schema#jsonSchema"
  "type": "@json"
}

which should go here.

But it seems like then the data model would need some text on the jsonSchema property.

I would like to avoid this specification shipping its own context which will then need to be included with each VC that intends to use this specification....is there another way to accomplish this? @msporny @OR13

[andresuribe87]

-1 to this approach.

The credentialSubject property is required in the VCDM, so removing results in an object that isn't a VC.

As an alternative, I suggest taking the same approach as the one taken in StatusList2021Credential. That is, make credentialSubject.type mandatory. An example of my suggestion below. This would make the vc graph much more palatable, and I believe this uses the more typical JSON-LD patterns.

{
  "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://example.com/credentials/3734",
  "type": ["VerifiableCredential", "VerifiableCredentialSchema2023"],
  "issuer": "https://example.com/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "https://example.com/credentials/schema/12",
    "type": "JsonSchema2023",
    "jsonSchema": {
      "$id": "https://example.com/schemas/email-credential-schema.json",
      "$schema": "https://json-schema.org/draft/2020-12/schema",
      "name": "EmailCredential",
      "description": "EmailCredential using VerifiableCredentialSchema2023",
      "type": "object",
      "properties": {
        "credentialSubject": {
          "type": "object",
          "properties": {
            "emailAddress": {
              "type": "string",
              "format": "email"
            }
          },
          "required": ["emailAddress"]
        }
      }
    }
  }
}

[msporny]

Yes, to what @andresuribe87 said above. That's a better way to do it.

[decentralgabe]

great suggestion! thank you

[msporny]

As discussed on the call today I've updated CredentialSchema2023 to make use of a new property in a VC, jsonSchema instead of the credentialSubject.

@andresuribe87 proposes something cleaner above.

Given @andresuribe87 example... you're probably better off renaming VerifiableCredentialSchema2023 to JsonSchemaCredential... that would bring it almost entirely inline w/ a bog standard VC.

My understanding -- and please correct me otherwise -- is that to make this work in LD-land there needs to be a definition in a context file that adds a property to VerifiableCredential such as:

I expect that might get push back from the WG. I suggest that @andresuribe87's approach is a better design.

But it seems like then the data model would need some text on the jsonSchema property.

No, the vocabulary could just point to your JSON Schema spec... we wouldn't need to document anything in vc-data-model.

I would like to avoid this specification shipping its own context which will then need to be included with each VC that intends to use this specification....is there another way to accomplish this?

Yes, put your definition in the core VC context (so you don't need to ship your own vocabulary/context), triggered by type... so, something like this:

    "JsonSchemaCredential": "https://www.w3.org/2018/credentials#JsonSchemaCredential",
    "JsonSchema": {
      "@id": "https://www.w3.org/2018/credentials#JsonSchema", <-- ideally, this would be defined by the JSON Schema community, not us.
      "@context": {
        "@protected": true,

        "id": "@id",
        "type": "@type",

         "jsonSchema": {
           "id": "https://www.w3.org/2018/credentials#jsonSchema" <-- ideally, this would be defined by the JSON Schema community, not us.
           "type": "@json"
       }
    },

Then your example becomes:

{
  "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://example.com/credentials/3734",
  "type": ["VerifiableCredential", "JsonSchemaCredential"],
  "issuer": "https://example.com/issuers/14",
  "validFrom": "2023-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "https://example.com/credentials/schema/12",
    "type": "JsonSchema",
    "jsonSchema": {
      "$id": "https://example.com/schemas/email-credential-schema.json",
      "$schema": "https://json-schema.org/draft/2020-12/schema",
      "name": "EmailCredential",
      "description": "EmailCredential using VerifiableCredentialSchema2023",
      "type": "object",
      "properties": {
        "credentialSubject": {
          "type": "object",
          "properties": {
            "emailAddress": {
              "type": "string",
              "format": "email"
            }
          },
          "required": ["emailAddress"]
        }
      }
    }
  }
}

[decentralgabe]

thank you @andresuribe87 @msporny I've updated the PR with your suggestions. I also included the term definition for jsonSchema here (which I think is better than no where) until it can be defined by the json schema org itself.

Follow-up PR for the VCDM w3c/vc-data-model#1215

[iherman]

Once merged, not only the @context must be changed but the credential vocabulary must be updated as well. I am happy to make the change when the time comes, though I would prefer to do that after w3c/vc-data-model#1209 is finalized and merged.

[decentralgabe]

thanks @iherman I'm happy to transfer ownership of w3c/vc-data-model#1215 to you after this and 1209 are merged

[decentralgabe]

@msporny @OR13 @andresuribe87 please take a look and see if you're ready to approve

[andresuribe87]

Why call out the schema resolution as a separate process? Isn't it a simple URL fetch?

[decentralgabe]

it is but it's a necessary step in using the spec, so it can be given a name which would be useful in enumerating the steps to process like

1. get credential
2. perform schema resolution
3. evaluate schema against credential