Sync and fix bugs in v2 context. #1259

iherman · 2023-08-26T09:54:51Z

Just trying to test my own understanding, @dlongley @msporny. My JSON-LD knowledge is rusty.

Setting @context to null means that, at this point, that the active context is reduced to nothing, except some basic mapping specified by the JSON-LD spec (like @type mapping to a URL). Per our spec, the value of the verifiableCredential property in JSON-LD is supposed to be a VerifiableCredential (which is, in the RDF side, enclosed in a separate graph). The effect of this is new setting that unless the @type is explicitly set to VerifiableCredential in the value object things will, and should, go wrong. Put it another way, it reinforces the requirement that the value object must explicitly declare itself to be a Verifiable Credential (and relates to the fact that the vocabulary explicitly says that a VerifiableCredentialGraph should contain a single Verifiable Credential).

Is this indeed the goal of this extra setting? If so, shouldn't there be a similar setting in the security @context for the proof property?

It seems like it would make some of these examples illegal:

https://w3c.github.io/vc-jose-cose/#presentations

{ "@context": ["https://www.w3.org/ns/credentials/v2"], "type": ["VerifiablePresentation"], "holder": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:_Fpfe27AuGmEljZE9s2lw2UH-qrZLRFNrWbJrWIe4SI", "verifiableCredential": [{ "@context": [ "https://www.w3.org/ns/credentials/v2" ], "type": [ "VerifiableCredential" ], "issuer": "https://issuer.example/issuers/68", "validFrom": "2023-06-07T21:14:14.148Z", "credentialSubject": { "id": "https://subject.vendor.example" } }, "https://vendor.example/credentials/42", "did:example:123", "urn:uuid:01ec9426-c175-4e39-a006-d30050e28214", "urn:ietf:params:oauth:jwk-thumbprint:sha-256:_Fpfe27AuGmEljZE9s2lw2UH-qrZLRFNrWbJrWIe4SI", "data:application/vc+ld+json;base64,eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJkaWQ6andrOmV5SnJhV1FpT2lKMWNtNDZhV1YwWmpwd1lYSmhiWE02YjJGMWRHZzZhbmRyTFhSb2RXMWljSEpwYm5RNmMyaGhMVEkxTmpwdlFtUm1kbVpET1hoNk1GOUJVWFpSTjNZMU1YbERXbDl6ZUdwNU56VkNUSEpJZWsxT1Jqa3lPV1U0SWl3aWEzUjVJam9pVDB0UUlpd2lZM0oySWpvaVJXUXlOVFV4T1NJc0ltRnNaeUk2SWtWa1JGTkJJaXdpZUNJNklqTmljbU5zYjBJNGFEUk5XbFZJYms5UVVHbGtTbXd0U2pkdVVsRkpXSFJUYUZwM1oyNW1jbHAxVDI4aWZRIiwidmFsaWRGcm9tIjoiMjAyMy0wNi0wN1QyMToxNDoxNC4xNDhaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJodHRwczovL3N1YmplY3QudmVuZG9yLmV4YW1wbGUifX0=" ] }

Or are these ok, as long as they "dereference" to a compact JSON-LD object representing a conforming document for a verifiable credential ?

Or are these ok, as long as they "dereference" to a compact JSON-LD object representing a conforming document for a verifiable credential?

The processing rules don't allow it as the content is expected to be present (it will not be auto-dereferenced and even then, there are no content hashes).

It seems like it would make some of these examples illegal:

Those examples were never legal in v1.0, v1.1, and v2.0... none of them are conforming documents as defined by the specification.

The addition is the null'ing of the context, which is required to address issue #1150. So, this change is purely additive and doesn't impact the examples you provided (the answers below would be the same w/o this PR).

That said:

"https://vendor.example/credentials/42"

If you pre-processed this URL and put this object into the array, it might be a conforming document. By itself, it's not a conforming document.

"did:example:123",

A DID Document isn't a VC, so, no, that wouldn't work, AFAICT. It's not a conforming document.

"urn:uuid:01ec9426-c175-4e39-a006-d30050e28214",

Presuming this thing is an identifier for a graph, you could potentially express it, but then it's not clear how you'd dereference it or guarantee the security around the object unless you were to provide a content hash. This couldn't work unless one were to presume that there was some sort of "graph dereferencing" function in play. Again, not a conforming document.

"urn:ietf:params:oauth:jwk-thumbprint:sha-256:_Fpfe27AuGmEljZE9s2lw2UH-qrZLRFNrWbJrWIe4SI",

Same answer as the above.

"data:application/vc+ld+json;base64,eyJAY29udG...ifX0=

If you pre-processed this URL and put the resulting object into the array, it might be a conforming document. By itself, it's not a conforming document.

If you pre-processed this URL and put this object into the array, it might be a conforming document. By itself, it's not a conforming document.

I'd like to see spec text addressing this, its not obvious that what you are saying is true, and these n-quads look fine to me:

_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiablePresentation> . _:c14n0 <https://www.w3.org/2018/credentials#holder> <urn:ietf:params:oauth:jwk-thumbprint:sha-256:_Fpfe27AuGmEljZE9s2lw2UH-qrZLRFNrWbJrWIe4SI> . _:c14n0 <https://www.w3.org/2018/credentials#verifiableCredential> _:c14n1 . _:c14n0 <https://www.w3.org/2018/credentials#verifiableCredential> _:c14n3 . _:c14n0 <https://www.w3.org/2018/credentials#verifiableCredential> _:c14n4 . _:c14n0 <https://www.w3.org/2018/credentials#verifiableCredential> _:c14n5 . _:c14n0 <https://www.w3.org/2018/credentials#verifiableCredential> _:c14n6 . _:c14n0 <https://www.w3.org/2018/credentials#verifiableCredential> _:c14n7 . _:c14n2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> _:c14n1 . _:c14n2 <https://www.w3.org/2018/credentials#credentialSubject> <https://subject.vendor.example> _:c14n1 . _:c14n2 <https://www.w3.org/2018/credentials#issuer> <https://issuer.example/issuers/68> _:c14n1 . _:c14n2 <https://www.w3.org/2018/credentials#validFrom> "2023-06-07T21:14:14.148Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> _:c14n1 .

A DID Document isn't a VC, so, no, that wouldn't work, AFAICT. It's not a conforming document.

This can't be true, the only normative requirement for a DID Document is that it have an id that is a DID... that makes any VC that has an id that is a DID a DID Document... especially if its returned with content type application/did+json (where context can be present and is ignored).... there are a lot of use cases where a controller document might need to be a VC. Consider also https://openid.net/specs/openid-connect-userinfo-vc-1_0-00.html

This is one step off of a signed did resolution result... we should not be designing incompatibility here, we don't want to preclude use cases we see developing in the wild.

Presuming this thing is an identifier for a graph, you could potentially express it, but then it's not clear how you'd dereference it or guarantee the security around the object unless you were to provide a content hash. This couldn't work unless one were to presume that there was some sort of "graph dereferencing" function in play. Again, not a conforming document.

Similar to DID Documents, you can't presume that DIDs can't be dereferenced, even though it's not defined normatively.

I didn't share the resolved document, but if I shared one that had an id that matched this, and was a status list credential, that would work... the verifier may have previously dereferenced the identifier, the holder does not need to send them a massive status list when thats the case.

Same answer as the above.

Same answer as above.

If you pre-processed this URL and put the resulting object into the array, it might be a conforming document. By itself, it's not a conforming document.

Its clear we don't have agreement on the domain / range of verifiableCredential... I see it as having the same structure as issuer and holder, or proof... it can be an object, or an array of strings and objects.... similar to verification relationships.

The v1 context seems to support this assertion.

"issuer": { "@id": "cred:issuer", "@type": "@id" },

"proof": { "@id": "sec:proof", "@type": "@id", "@container": "@graph" },

"verifiableCredential": { "@id": "cred:verifiableCredential", "@type": "@id", "@container": "@graph" }

This is the definition in the v2 context today:

"verifiableCredential": { "@id": "https://www.w3.org/2018/credentials#verifiableCredential", "@type": "@id", "@container": "@graph" },

For comparison, here are the context definitions for verification relationships:

"assertionMethod": { "@id": "https://w3id.org/security#assertionMethod", "@type": "@id", "@container": "@set" },

As you can see the only difference is @graph vs @set... this does not imply that the property must ALWAYS be an array of objects of type "VerifiableCredential".... afaik.

It does mean that the n-quads produce blank nodes, as you can see from the example above.

There are lots of cases in RDF / JSON-LD where you may have previously dereferenced an identifier to a graph node / object... and you don't need to send a "full copy" of the same object over and over again... this is especially common in supply chain use cases cc @mprorock @mkhraisha ... we use this pattern when communicating references to previous "credentials" and "presentations" and "workflows" which are just another large JSON object that is referred to be "id".

TLDR, I am opposed to breaking changes to this experience in the v2 context.

I am fine leaving the behavior as it is above (where you can always replace an id with an object that contains that id), for places where you see "@type": "@id",... This would preserve the experience we created with DIDs, where the same "verificationMethod" object is referred to by several "verification relationships", for example, a P-256 Public Key might be used for both authentication and encryption, or authentication and credential issuance.

TLDR, I am opposed to breaking changes to this experience in the v2 context.

There aren't breaking changes here -- verifiableCredential has always used a @graph container to ensure that the data expressed in the value there is put into its own graph. The VP has a relationship with other graph containers via verifiableCredential, where each value is its own graph containing either a VerifiableCredential or other data conformant with the data model that is derived from a VerifiableCredential. This latter bit was for the CL Signature ZKP folks that wanted to not necessarily put a VC directly in the value, but to put a "derived credential with ZKP proof data" in it. This has been the case since 1.1.

If you just put a string value in that field, then all that happens is an empty graph container (with a blank node identifying it) is created and there's a relationship established between the VP and this empty graph. A string value (ID / URL) for a subject does not establish any claims or additional relationships so the new graph is just empty. The only relationship added is between the VP and the blank node of this empty graph via the verifiableCredential property (loosely, the claim is: VP -> verifiableCredential -> blank node of an empty graph). This empty graph is not a valid VerifiableCredential nor is it data derived from one, so it's not a valid use of the VCDM.

But! There is a property that can do what you want to do in VCDM 2.0. I would recommend using relatedResource to add whatever additional resources you want -- and there's the added bonus of being able to include a content integrity hash to go along with it, which is something you'd want for that approach anyway. Hopefully this resolves the issue.

@OR13,

I've also mentioned that we need to make sure to add relatedResource to both VCs and VPs here: #1263 (comment)

This latter bit was for the CL Signature ZKP folks that wanted to not necessarily put a VC directly in the value, but to put a "derived credential with ZKP proof data" in it. This has been the case since 1.1.

This AFAIK, never actually resulted in implementations.

If you just put a string value in that field, then all that happens is an empty graph container (with a blank node identifying it) is created and there's a relationship established between the VP and this empty graph.

Yes, unless we remove the @container, or change it to @set, I expect this will continue to be the case.

A string value (ID / URL) for a subject does not establish any claims or additional relationships so the new graph is just empty.

When you say subject here, you mean the identifier for a verifiable credential, (assuming it has graph node id), right?

The only relationship added is between the VP and the blank node of this empty graph via the verifiableCredential property (loosely, the claim is: VP -> verifiableCredential -> blank node of an empty graph). This empty graph is not a valid VerifiableCredential nor is it data derived from one, so it's not a valid use of the VCDM.

This seems to be confusing "VerifiableCredential" with "VerifiableCredentialGraph" cc @iherman & @msporny , we discussed confusion related to this on #1240

It would help to understand the normative / english language value of the "VerifiableCredentialGraph" since that is what is "empty".

But! There is a property that can do what you want to do in VCDM 2.0. I would recommend using relatedResource to add whatever additional resources you want -- and there's the added bonus of being able to include a content integrity hash to go along with it, which is something you'd want for that approach anyway. Hopefully this resolves the issue.

I like the suggestion, lets not let it stop this PR, I will file a separate issue for follow up: #1265

Staying on topic, I am opposed to adding the "null" context here: https://github.com/w3c/vc-data-model/pull/1259/files#diff-267b7e47789daf9a1d312b42826aa937a1bb5af4312ee90df6b8a64cd6426f4fR154

Until we achieve clarity / consensus on the topic above.

This latter bit was for the CL Signature ZKP folks that wanted to not necessarily put a VC directly in the value, but to put a "derived credential with ZKP proof data" in it. This has been the case since 1.1.

This AFAIK, never actually resulted in implementations.

Yes, if you wanted to strike that part ("or data derived from verifiable credentials"), I'd be ok with it and would favor just requiring embedded VCs.

A string value (ID / URL) for a subject does not establish any claims or additional relationships so the new graph is just empty.

When you say subject here, you mean the identifier for a verifiable credential, (assuming it has graph node id), right?

Well, what the subject actually is doesn't matter, its identifier isn't associated with any statements because nothing is said about it (making the graph of statements "empty"). It's true that the subject could be a verifiable credential, but if nothing is claimed about that credential directly within the embedded data (as opposed to who knows what might be there by reference). In short, the verifiableCredential property has not been for referencing things, but instead for directly embedding data-model-compliant things in a presentation whilst preserving a wrapper around them (a "named graph") to isolate them from one another.

The only relationship added is between the VP and the blank node of this empty graph via the verifiableCredential property (loosely, the claim is: VP -> verifiableCredential -> blank node of an empty graph). This empty graph is not a valid VerifiableCredential nor is it data derived from one, so it's not a valid use of the VCDM.

This seems to be confusing "VerifiableCredential" with "VerifiableCredentialGraph" cc @iherman & @msporny , we discussed confusion related to this on #1240

The verifiableCredential (property name) relationship is between a VP and a graph (VerifiableCredentialGraph`). This is what I said above when I said: "(loosely, the claim is: VP -> verifiableCredential -> blank node of an empty graph)". Of course, this embedded graph must not be empty to be valid, but I was pointing out the invalid case in that sentence.

It would help to understand the normative / english language value of the "VerifiableCredentialGraph" since that is what is "empty".

If I understand you, the value is to put a wrapper around a set of statements to isolate them from other statements made: to help keep track of associations. The statements made in a VC are "wrapped" by a separate graph (put "into" that graph) to keep them separate from statements made in any other VC embedded in the VP. A VP can carry N-many VCs this way, potentially coming from many different issuers, whilst tracking the association of the statements in the graph model.

But! There is a property that can do what you want to do in VCDM 2.0. I would recommend using relatedResource to add whatever additional resources you want -- and there's the added bonus of being able to include a content integrity hash to go along with it, which is something you'd want for that approach anyway. Hopefully this resolves the issue.

I like the suggestion, lets not let it stop this PR, I will file a separate issue for follow up: #1265

+1

-Original file line number
+Diff line change
@@ Expand Up / @@ -5,6 +5,7 @@ @@
         "id": "@id",
         "type": "@type",
         "kid": {
           "@id": "https://www.iana.org/assignments/jose#kid",
           "@type": "@id"
@@ Expand Down Expand Up / @@ -146,7 +147,8 @@ @@
             "verifiableCredential": {
               "@id": "https://www.w3.org/2018/credentials#verifiableCredential",
               "@type": "@id",
-              "@container": "@graph"
+              "@container": "@graph",
+              "@context": null
             },
             "termsOfUse": {
               "@id": "https://www.w3.org/2018/credentials#termsOfUse",
@@ Expand Down Expand Up / @@ -273,7 +275,10 @@ @@
                 }
               }
             },
-            "cryptosuite": "https://w3id.org/security#cryptosuite",
+            "cryptosuite": {
+              "@id": "https://w3id.org/security#cryptosuite",
+              "@type": "https://w3id.org/security#cryptosuiteString"
+            },
             "proofValue": {
               "@id": "https://w3id.org/security#proofValue",
               "@type": "https://w3id.org/security#multibase"
@@ Expand Down @@

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sync and fix bugs in v2 context. #1259

Diff view

Diff view

There are no files selected for viewing

iherman Aug 26, 2023

OR13 Aug 26, 2023

msporny Aug 26, 2023 •

edited

Loading

OR13 Aug 31, 2023

dlongley Aug 31, 2023

dlongley Aug 31, 2023

OR13 Sep 1, 2023

OR13 Sep 1, 2023

dlongley Sep 1, 2023 •

edited

Loading

Sync and fix bugs in v2 context. #1259

Sync and fix bugs in v2 context. #1259

Diff view

Diff view

There are no files selected for viewing

iherman Aug 26, 2023

Choose a reason for hiding this comment

OR13 Aug 26, 2023

Choose a reason for hiding this comment

msporny Aug 26, 2023 • edited Loading

Choose a reason for hiding this comment

OR13 Aug 31, 2023

Choose a reason for hiding this comment

dlongley Aug 31, 2023

Choose a reason for hiding this comment

dlongley Aug 31, 2023

Choose a reason for hiding this comment

OR13 Sep 1, 2023

Choose a reason for hiding this comment

OR13 Sep 1, 2023

Choose a reason for hiding this comment

dlongley Sep 1, 2023 • edited Loading

Choose a reason for hiding this comment

msporny Aug 26, 2023 •

edited

Loading

dlongley Sep 1, 2023 •

edited

Loading