Update term definition for vc json schemas as creds #1215

decentralgabe · 2023-07-26T01:30:57Z

As per w3c/vc-json-schema#186 (comment)

Preview | Diff

decentralgabe · 2023-07-26T01:32:05Z

This should be merged (and will need to fix conflicts) after #1209

msporny

Concrete change request: date-stamped or not?

msporny · 2023-08-01T22:26:03Z

contexts/credentials/v2

@@ -123,9 +123,9 @@
      }
    },

-    "VerifiableCredentialSchema2023": {
+    "JsonSchemaCredential2023": {


Suggested change

"JsonSchemaCredential2023": {

"JsonSchemaCredential": {

Are you keeping the date or removing it?

msporny · 2023-08-01T22:26:15Z

contexts/credentials/v2

      "@id":
-        "https://w3.org/2018/credentials#VerifiableCredentialSchema2023",
+        "https://w3.org/2018/credentials#JsonSchemaCredential2023",


Suggested change

"https://w3.org/2018/credentials#JsonSchemaCredential2023",

"https://w3.org/2018/credentials#JsonSchemaCredential",

Same question as above?

contexts/credentials/v2

decentralgabe · 2023-08-01T22:41:29Z

removing versioning here w3c/vc-json-schema#192

iherman · 2023-08-02T08:09:37Z

The issue was discussed in a meeting on 2023-08-01

no resolutions were taken

View the transcript

1.5. Update term definition for vc json schemas as creds (pr vc-data-model#1215)

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

Brent Zundel: Update Term Definition for VC JSON Schema as creds, raised by Gabe, so far no reviews.
… Gabe, can you talk us through this PR?

Gabe Cohen: there is a change to the naming of the credential representation of the JSON Schema VC, which this PR addresses.
… there's also docs on how to use the @json property in the JSON Schema credential.
… so, two small changes - to use a type, and to represent a json schema in the credentialSubject property of the VC.

Brent Zundel: thank you, seem straightforward.

Manu Sporny: Gabe, I was waiting for you to update before reviewing, I thought you'd get rid of the datestamp stuff. (I just added a request).
… in StatusList, looks like we're getting rid of the datetime stamp.
… you're putting the vocab definition for JSON Schema into the spec, but not any vocabulary file.
… not sure if you meant to put it into the VC DM vocab, or create a separate one.
… the current state - the URL might not resolve over time, that would be bad.
… anyways, I left comments.

Gabe Cohen: not intentional. I know Ivan has another PR opened, 1218, that does add it to vocab.

Manu Sporny: it's sufficient if you just use the vocab term from that PR.

Gabe Cohen: happy to delay the merge, till the VC JSON Spec removes the year; I didn't want to be the first one to do that.

Manu Sporny: you don't have to wait, if you're gonna update the JSON Schema spec, you can do both in parallel.
… so this PR can go in. (remove the date, update to the vocab url Ivan created in the other PR, and you're good to go).

Gabe Cohen: thanks, will do.

Brent Zundel: Gabe is quick to respond, so changes will be in very soon, so folks, review those.
… any more comments on this PR?

contexts/credentials/v2

msporny

Still requires fixes to use the https://w3.org/2018/credentials# base vocabulary URL... see PR https://github.com/w3c/vc-data-model/pull/1218/files for details.

dlongley

See my suggestion and +1 to @msporny's suggestions.

dlongley · 2023-08-04T01:43:22Z

contexts/credentials/v2

@@ -112,9 +112,9 @@
      }
    },

-    "JsonSchema2023": {
+    "JsonSchema": {


This looks like a duplicate of what's below. This one should be removed as the one below looks more correct (has jsonSchema defined in its scoped context).

Co-authored-by: Manu Sporny <msporny@digitalbazaar.com>

dlongley · 2023-08-04T20:01:20Z

contexts/credentials/v2

      "@id":
-        "https://w3.org/2018/credentials#JsonSchema2023",
+        "https://w3.org/2018/credentials#JsonSchemaCredential",
      "@context": {


Hmm -- this scoped context has now moved into JsonSchemaCredential. It should be under JsonSchema instead. That way, when an object of "type" JsonSchema is used, it will have the jsonSchema property (where the actual JSON schema goes) defined. It's that object that has that property, not the JsonSchemaCredential.

@dlongley that seems reversed to me. Perhaps examples make this clearer:

Pulled from https://w3c.github.io/vc-json-schema/#jsonschema

Case 1

JsonSchema ... a type that refers to a JSON Object that validates JSON... (we intend to implement this one).

{ "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "https://example.com/credentials/3732", "type": ["VerifiableCredential", "EmailCredential"], "issuer": "https://example.com/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "emailAddress": "subject@example.com" }, "credentialSchema": { "id": "https://example.com/schemas/email-credential-schema.json", "type": "JsonSchema" // type } }

Case 2

JsonSchemaCredential ... a type that refers to a VerifiableCredential, that contains a json object, that validates JSON... (we do not plan to implement this one).

{ "@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"], // type "issuer": "https://example.com/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "https://example.com/schemas/email-credential-schema.json", "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 JsonSchemaCredential", "type": "object", "properties": { "credentialSubject": { "type": "object", "properties": { "emailAddress": { "type": "string", "format": "email" } }, "required": ["emailAddress"] } } } } }

Perhaps you are suggesting this?

{ "@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"], // type "issuer": "https://example.com/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "$id": "https://example.com/schemas/email-credential-schema.json", "$schema": "https://json-schema.org/draft/2020-12/schema", "name": "EmailCredential", "description": "EmailCredential using JsonSchemaCredential", "type": "object", "properties": { "credentialSubject": { "type": "object", "properties": { "emailAddress": { "type": "string", "format": "email" } }, "required": ["emailAddress"] } } } }

@OR13,

My suggestions will make Case 1 and Case 2 work. The "Perhaps you were suggesting this" is not something I was suggesting and don't believe we should do.

@OR13,

Right now, this PR will create these term mappings:

"JsonSchemaCredential": { "@id": "https://w3.org/2018/credentials#JsonSchemaCredential", "@context": { "@protected": true, "id": "@id", "type": "@type", "jsonSchema": { "id": "https://w3.org/2018/credentials#JsonSchema", "type": "@json" } }, "JsonSchema": { "@id": "https://w3.org/2018/credentials#JsonSchema", "@context": { "@protected": true, "id": "@id", "type": "@type" },

This would mean that jsonSchema would only be defined at the top-level of a VC that used the type JsonSchemaCredential. Something like this (which we do not want):

{ "@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"], // type which // defines the scoped-context with "jsonSchema" for use on this object // which we do not want "issuer": "https://example.com/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", // we do not want this "jsonSchema": { "$id": "https://example.com/schemas/email-credential-schema.json", "$schema": "https://json-schema.org/draft/2020-12/schema", "name": "EmailCredential", "description": "EmailCredential using JsonSchemaCredential", "type": "object", "properties": { "credentialSubject": { "type": "object", "properties": { "emailAddress": { "type": "string", "format": "email" } }, "required": ["emailAddress"] } } }, "credentialSubject": { "id": "https://example.com/schemas/email-credential-schema.json", "type": "JsonSchema" // note that "jsonSchema" would be undefined in here } }

Instead, it should do this:

"JsonSchemaCredential": "https://w3.org/2018/credentials#JsonSchemaCredential", "JsonSchema": { "@id": "https://w3.org/2018/credentials#JsonSchema", "@context": { "@protected": true, "id": "@id", "type": "@type", "jsonSchema": { "id": "https://w3.org/2018/credentials#JsonSchema", "type": "@json" } },

Which will enable Case 2:

{ "@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"], // type "issuer": "https://example.com/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "https://example.com/schemas/email-credential-schema.json", "type": "JsonSchema", // this type has the scoped-context that // defines "jsonSchema" for use on this object "jsonSchema": { "$id": "https://example.com/schemas/email-credential-schema.json", "$schema": "https://json-schema.org/draft/2020-12/schema", "name": "EmailCredential", "description": "EmailCredential using JsonSchemaCredential", "type": "object", "properties": { "credentialSubject": { "type": "object", "properties": { "emailAddress": { "type": "string", "format": "email" } }, "required": ["emailAddress"] } } } } }

It also enables Case 1 by simply defining JsonSchema as a usable type at all.

@dlongley I've updated the PR to reflect your changes ( I think )

@dlongley one question -- I would assume since we want to expose the term jsonSchema inside the credentialSubject of a JsonSchemaCredential then the term would need to be defined under JsonSchemaCredential why is it that there's no need to define jsonSchema within the JsonSchemaCredential type?

There's a situation I don't quite understand. Imagine the following scenario

The VC has the property below.

{ "credentialSchema": {"id": "https://example.com/my-json-schema.json", "type": "JsonSchema"} }

And the contents that result from dereferencing https://example.com/my-json-schema.json are the following:

{ "$id": "https://example.com/my-json-schema.json", "$schema": "https://json-schema.org/draft/2020-12/schema", "name": "EmailCredential", "type": "object", "properties": {} }

Would the VC.credentialSchema.type conflict with dereferenceURL(VC.credentialSchema.id).type? Note that the result of dereferenceURL does not contain any jsonSchema property within it.

@decentralgabe,

@dlongley one question -- I would assume since we want to expose the term jsonSchema inside the credentialSubject of a JsonSchemaCredential then the term would need to be defined under JsonSchemaCredential why is it that there's no need to define jsonSchema within the JsonSchemaCredential type?

Because jsonSchema is not a property of an object of type JsonSchemaCredential. It's a property of an object of type JsonSchema.

Type-scoped contexts are applied to the objects where the type is declared. It's similar to OOP where you declare the properties that can appear on an object of a certain type. An object of type JsonSchema can use the jsonSchema property. We want that property to be defined on an object of that type, not on JsonSchemaCredential.

As an example:

{ "@context": { "pet": "example:pet", "id": "@id", "type": "@type", "Dog": { "@id": "example:Dog", "@context": { "id": "@id", "type": "@type", "name": "example:name", "breed": "example:breed", "favoriteToy": "example:favoriteToy" // etc. } } }, "pet": { "id": "example:some_id", "type": "Dog", "name": "Bark Hamill", "breed": "Chihuahua" // "favoriteToy" you don't have to use every defined property } }

@andresuribe87,

There's a situation I don't quite understand. Imagine the following scenario

The VC has the property below.

{ "credentialSchema": {"id": "https://example.com/my-json-schema.json", "type": "JsonSchema"} }

And the contents that result from dereferencing https://example.com/my-json-schema.json are the following:

{ "$id": "https://example.com/my-json-schema.json", "$schema": "https://json-schema.org/draft/2020-12/schema", "name": "EmailCredential", "type": "object", "properties": {} }

Would the VC.credentialSchema.type conflict with dereferenceURL(VC.credentialSchema.id).type? Note that the result of dereferenceURL does not contain any jsonSchema property within it.

Just because a term mapping exists in a JSON-LD context does not mean it has to be used. Also, since the content at that URL is not application/ld+json, there's no reason to think (nor any automated way) its contents should be merged into a knowledge graph. If you wanted to enable some kind of automated way to merge, you could also serve application/ld+json from that URL with a different representation (when requested via content negotiation), but that doesn't sound like it's really even a use case here.

Btw, the alternative representation in (application/ld+json) could be something like this:

{ "@context": "https://www.w3.org/ns/credentials/v2", "id": "https://example.com/my-json-schema.json", "type": "JsonSchema", "jsonSchema": { "$id": "https://example.com/my-json-schema.json", "$schema": "https://json-schema.org/draft/2020-12/schema", "name": "EmailCredential", "type": "object", "properties": {} } }

dlongley

@decentralgabe, very close -- a couple more suggestions.

The jsonSchema suggestion is important since the property jsonSchema should be mapped to the URL with the matching lower case URL fragment. The class / type name JsonSchema (upper case) is mapped to the URL with the upper case URL fragment.

contexts/credentials/v2

dlongley · 2023-08-07T16:53:38Z

contexts/credentials/v2

+    "JsonSchemaCredential": {
      "@id":
-        "https://w3.org/2018/credentials#JsonSchema2023",
+        "https://w3.org/2018/credentials#JsonSchemaCredential",


Since no scoped context is needed here, this can be simplified to:

"JsonSchemaCredential": "https://w3.org/2018/credentials#JsonSchemaCredential",

thanks, updated

Co-authored-by: Dave Longley <dlongley@digitalbazaar.com>

OR13

Based on the discussion on the PR, I don't feel comfortable approving this until additional examples are added along with the context changes.

OR13 · 2023-08-08T22:52:09Z

We have the following test case today:

https://github.com/transmute-industries/vc-jwt-test-suite/blob/main/data/inputs/claimsets/alumni-credential-with-schema.json#L12

Case A.1

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/1872",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSchema": {
    "id": "https://university.example/schemas/ExampleAlumniCredential",
    "type": "JsonSchema"
  },
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  }
}

After this PR is merged, will this test case still be valid?

Can we include an example to make this clearer?

Can we also add an example based on the thread above?

Case A.2

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/1872",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSchema": {
    "id": "https://university.example/schemas/ExampleAlumniCredential",
    "type": "JsonSchema",
    "jsonSchema": {
      "$id": "https://university.example/schemas/ExampleAlumniCredential",
      "$schema": "https://json-schema.org/draft/2020-12/schema",
      "name": "ExampleAlumniCredential",
      "type": "object",
      "properties": { ... }
    }
  },
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  }
}

To be clear, current blocking feedback:

add an example for A.1 and A.2
confirm my understanding is correct regarding both being legal after the PR is merged.

msporny · 2023-08-09T12:14:37Z

confirm my understanding is correct regarding both being legal after the PR is merged.

FWIW, @OR13's understanding of the PR is aligned with my understanding of the PR, but I think there is another use case that needs to be explained...

Non-blocking thought:

I wouldn't expect credentialSchema.id to be used in the second example... or if it's used, I would expect the contents of credentialSchema.jsonSchema to match the credentialSchema.id file when dereferenced. That is, I would expect the contents of jsonSchema to match the contents of https://university.example/schemas/ExampleAlumniCredential.

In addition to the examples above, I'd also expect an example that would be something along these lines

Case A.2

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/schemas/9288",
  "type": ["VerifiableCredential", "JsonSchemaCredential"],
  "issuer": "https://university.example/issuers/827",
  "validFrom": "2023-08-01T19:23:24Z",
  "credentialSubject": {
    "id": "https://university.example/schemas/ExampleAlumniCredential",
    "type": "JsonSchema",
    "jsonSchema": {
      "$id": "https://university.example/schemas/ExampleAlumniCredential",
      "$schema": "https://json-schema.org/draft/2020-12/schema",
      "name": "ExampleAlumniCredential",
      "type": "object",
      "properties": { ... }
    }
  }
}

... and then, again, jsonSchema is expected to match the contents of https://university.example/schemas/ExampleAlumniCredential ... it feels like using a digest would be simpler, not duplicate content, and might possibly lead to a better developer experience. That would be an argument to remove jsonSchema from the specification.

I also question if these examples should be in the base specification, or the JSON Schema specification (and we point over to that document for examples).

Again, all of the above are non-blocking thoughts on this PR.

OR13 · 2023-08-09T13:00:19Z

And for the case where we have:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/1872",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSchema": {
    "id": "http://university.example/credentials/schemas/9288",
    "type": "JsonSchemaCredential",
  },
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  }
}

It would point to:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/schemas/9288",
  "type": ["VerifiableCredential", "JsonSchemaCredential"],
  "issuer": "https://university.example/issuers/827",
  "validFrom": "2023-08-01T19:23:24Z",
  "credentialSubject": {
    "id": "https://university.example/schemas/ExampleAlumniCredential",
    "type": "JsonSchema",
    "jsonSchema": {
      "$id": "https://university.example/schemas/ExampleAlumniCredential",
      "$schema": "https://json-schema.org/draft/2020-12/schema",
      "name": "ExampleAlumniCredential",
      "type": "object",
      "properties": { ... }
    }
  }
}

Or alternatively:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/1872",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSchema": {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "id": "http://university.example/credentials/schemas/9288",
    "type": ["VerifiableCredential", "JsonSchemaCredential"],
    "issuer": "https://university.example/issuers/827",
    "validFrom": "2023-08-01T19:23:24Z",
    "credentialSubject": {
      "id": "https://university.example/schemas/ExampleAlumniCredential",
      "type": "JsonSchema",
      "jsonSchema": {
        "$id": "https://university.example/schemas/ExampleAlumniCredential",
        "$schema": "https://json-schema.org/draft/2020-12/schema",
        "name": "ExampleAlumniCredential",
        "type": "object",
        "properties": { ... }
      }
    }
  },
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  }
}

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/1872",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSchema": "compact jwt or sd-jwt here", //  ?,
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  }
}

Regardless of where the examples are, there will need to be tests that cover the following:

credentialSchema with json schema by value
credentialSchema with json schema by reference
credentialSchema with json schema credential by value
credentialSchema with json schema credential by reference

I'd tend to recommend against including schema's by value especially for data integrity proofs because it will increase the processing time... unless @json is used to stop the rdf processing of the json schema.

I'm approving based on the comments... no need to add these 4 cases to the core spec as examples... but we should remove any RDF types that are in the core data model context, that are not tested fully in a securing specification... or there will not be interoperability.

I am assuming nobody wants to use "JsonSchemaCredential" without some proof... either internal or external... so the examples should include "things with proofs"... not plain JSON objects

decentralgabe · 2023-08-09T15:30:48Z

thanks @OR13 @msporny we'll address the examples in the vc-json-schema spec, along with language to handle the usage of the credentialSubject's id property when using the JsonSchemaCredential type

decentralgabe · 2023-08-09T15:31:28Z

comments addressed. multiple approvals from editors. open for >1 week. merging.

iherman · 2023-08-09T16:12:42Z

The issue was discussed in a meeting on 2023-08-09

no resolutions were taken

View the transcript

2.6. (pr vc-data-model#1215)

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

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

Manu Sporny: PR 1215 1218. approvals.

decentralgabe requested review from msporny, OR13, selfissued and awoie as code owners July 26, 2023 01:30

decentralgabe mentioned this pull request Jul 26, 2023

Update language around the defined types and their usages w3c/vc-json-schema#186

Merged

msporny force-pushed the main branch from b1d3e02 to 7cac20d Compare July 27, 2023 21:52

decentralgabe mentioned this pull request Aug 1, 2023

Added JsonSchemaCredential to the vocabulary, and remove '2023' from JsonSchema2023 #1218

Merged

msporny requested changes Aug 1, 2023

View reviewed changes

one more try

207bbcb

decentralgabe force-pushed the add-json-schema-term branch from 678f01c to 207bbcb Compare August 1, 2023 22:36

msporny reviewed Aug 4, 2023

View reviewed changes

contexts/credentials/v2 Outdated Show resolved Hide resolved

msporny reviewed Aug 4, 2023

View reviewed changes

contexts/credentials/v2 Outdated Show resolved Hide resolved

msporny requested changes Aug 4, 2023

View reviewed changes

msporny requested review from dlongley, iherman, dmitrizagidulin, brentzundel, Sakurann and seabass-labrax August 4, 2023 01:36

dlongley requested changes Aug 4, 2023

View reviewed changes

decentralgabe and others added 3 commits August 4, 2023 13:14

Apply suggestions from code review

95daa83

Co-authored-by: Manu Sporny <msporny@digitalbazaar.com>

pr comments

614f5eb

pr comments

13ca019

dlongley requested changes Aug 4, 2023

View reviewed changes

update to pr comments

74b1d23

dlongley requested changes Aug 7, 2023

View reviewed changes

decentralgabe mentioned this pull request Aug 7, 2023

JSON schema's type and VC.context.JsonSchema.type w3c/vc-json-schema#194

Closed

decentralgabe and others added 2 commits August 7, 2023 13:13

Update contexts/credentials/v2

887e12b

Co-authored-by: Dave Longley <dlongley@digitalbazaar.com>

pr updates"

79f13dc

dlongley approved these changes Aug 7, 2023

View reviewed changes

OR13 suggested changes Aug 8, 2023

View reviewed changes

OR13 self-requested a review August 9, 2023 13:00

OR13 approved these changes Aug 9, 2023

View reviewed changes

msporny approved these changes Aug 9, 2023

View reviewed changes

decentralgabe merged commit d4357e2 into main Aug 9, 2023

andresuribe87 mentioned this pull request Aug 18, 2023

Formalize the jsonSchema property in the VCDM vocabulary? w3c/vc-json-schema#206

Closed

msporny deleted the add-json-schema-term branch November 11, 2023 15:58

	"https://w3.org/2018/credentials#JsonSchemaCredential2023",
	"https://w3.org/2018/credentials#JsonSchemaCredential",

Update term definition for vc json schemas as creds #1215

Update term definition for vc json schemas as creds #1215

Conversation

decentralgabe commented Jul 26, 2023 • edited by pr-preview bot Loading

decentralgabe commented Jul 26, 2023

msporny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

decentralgabe commented Aug 1, 2023

iherman commented Aug 2, 2023

1.5. Update term definition for vc json schemas as creds (pr vc-data-model#1215)

msporny left a comment

Choose a reason for hiding this comment

dlongley left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OR13 Aug 4, 2023 • edited Loading

Choose a reason for hiding this comment

Case 1

Case 2

OR13 Aug 4, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dlongley Aug 4, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dlongley Aug 7, 2023 • edited Loading

Choose a reason for hiding this comment

dlongley Aug 7, 2023 • edited Loading

Choose a reason for hiding this comment

dlongley left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OR13 left a comment

Choose a reason for hiding this comment

OR13 commented Aug 8, 2023 • edited Loading

Case A.1

Case A.2

msporny commented Aug 9, 2023 • edited Loading

Case A.2

OR13 commented Aug 9, 2023 • edited Loading

decentralgabe commented Aug 9, 2023

decentralgabe commented Aug 9, 2023

iherman commented Aug 9, 2023

2.6. (pr vc-data-model#1215)

decentralgabe commented Jul 26, 2023 •

edited by pr-preview bot

Loading

OR13 Aug 4, 2023 •

edited

Loading

OR13 Aug 4, 2023 •

edited

Loading

dlongley Aug 4, 2023 •

edited

Loading

dlongley Aug 7, 2023 •

edited

Loading

dlongley Aug 7, 2023 •

edited

Loading

dlongley left a comment •

edited

Loading

OR13 commented Aug 8, 2023 •

edited

Loading

msporny commented Aug 9, 2023 •

edited

Loading

OR13 commented Aug 9, 2023 •

edited

Loading