proposal for @shift keyword

[bblfish]

The reason for the proposal will be clear if one understands the problem it is meant to solve, which arises from a slight shift between RDF semantics and the syntax JSON folks would like.
The problem goes back to at least 2016 from the desire, made clear in the VC Data Integrity Spect to start from a simple JSON Example 1

{
  "title": "Hello world!"
}

and then add a signature to get a document such as that given in Example 2

{
  "title": "Hello world!",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "jcs-eddsa-2022",
    "created": "2023-03-05T19:23:24Z",
    "verificationMethod": "https://di.example/issuer#z6MkjLrk3gKS2nnkeWcmcxiZPGskmesDpuwRBorgHxUXfxnG",
    "proofPurpose": "assertionMethod",
    "proofValue": "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQApmEcqaqA3Q1gVHMrXFkXJeV6doDwLWx"
  }
}

It has been a constant in the aim of the VC folks to have something this simple.
This thinking is then extended to the VC Data Model 2.0 Example 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",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-2022",
    "created": "2023-06-18T21:19:10Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "https://university.example/issuers/565049#key-123",
    "proofValue": "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQApmEcqaqA3Q1gVHMrXFkXJeV6doDwLWx"
  }
}

After careful work translating the above JsonLD to NQuads and then to N3 I was able to then draw it out as the following graph

But as explained most concisely in this reply to issue 1248 of the VC DM, that gives us the wrong graph semantics because we can't tell what is being signed. The signature is enclosed in a (Green) surface where what is needed is that the signed graph be enclosed in a node. Ie we need it to be as follows, where the to-be-signed graph is enclosed in the pink surface:

In other words: We need the default graph to be shifted along the "proof" relation.
But we need this to happen without changing the JSON surface syntax.

Therefore I propose this group consider a @shift context annotation that could be placed on a "proof" element that would have the above effect.

The name of that annotiation is not important of course - it is the effect that is needed.

[gkellogg]

It seems to me that this would work with a reverse property, although that doesn't work with properties that are graph containers. This would be akin to N3's "is ... of" syntactic sugar for reversed properties. And, even if it did, there isn't (currently) a way to reference the default graph. Hypothetically, you might frame the results using a frame such as the following:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2",
	{
      "@context": {
        "proofOf": {
          "@reverse": "https://w3id.org/security#proof",
          "@container": "@graph"
        }
      }
    }
  ],
  "@type": "DataIntegrityProof",
  "proofOf": {}
}

If something like this were to be considered, it would be targeted at least in JSON-LD 1.2, which is likely a couple of years away. But, it might run into issues that would make it impractical.

I'd favor trying to leverage current semantics rather than introduce another keyword with its own specific behavior.

[bblfish]

I am not a Json-LD specialist, so I don't know if the existing Json-LD structures can give the right answer. I leave that up the Wizards here to tell us :-)

As I see it, the VC folks are 100% tied to their JSON syntax pattern shown above. It was part of their initial sales pitch. So they need that syntax to give the right results. And they will rather have broken RDF that makes no sense than to have a different JSON syntax.

The RDF produced is unacceptable and will be a blocker to getting 2.0 out.
So a solution has to be found. If there is nothing in the current Json-LD that works, and @shift did happen to work, then they could get their spec out of the door by mentioning that it requires a Json-LD version that supports @shift, which could be specced out ahead of time and agreed to without needing to wait for Json-LD 1.2.

Anyway, I think this is a good puzzle to think about.

Verifiable Credentials are meant to be used worldwide and would be a very important use case for Json-LD and the semantic web. But it would be a huge failure if VCs with broken RDF get deployed.

[TallTed]

@bblfish -- Please note that JsonLD does not exist, except in your writing. JSON-LD is the name of the thing I believe you are talking about.

Also note that you should codefence all strings that begin with @ in GitHub comments and titles, including those on commits. The uncodefenced @shift in your #817 (comment) will cause that GitHub user to be pinged on every future update to this issue until and unless all instances of @shift are replaced with `@shift`. You did this in your initial comment on this issue, so I'm sure you know how to do it; I include details in this comment for the benefit of others who may read it.

---

As I see it, the VC folks are 100% tied to their JSON syntax pattern shown above

This perception suggests that you have not studied the history of VCs nor spoken to many if any of us (I am one of those "VC folks") about it. As I see it, we are 100% tied to our Linked Data, hence JSON-LD, which is closely tied to RDF. All valid JSON-LD is valid JSON, and that is a major reason why we settled on JSON-LD as the "native" structure of W3C VCs, because it eases uptake by people who are accustomed to JSON and/or don't care (yet) about LD and/or are allergic to RDF.

Any errors that surface when handling JSON-LD W3C VCs as RDF are undesirable, almost certainly unintentional, and should be flagged as errata on published documents, and as quickly as possible as errors on documents-in-process. They should also be raised as implementation experience during the development and review cycles of documents-in-process.

I do ask that you strive not to speak about the motivation or desire or commitment of the people who have devoted years of effort to producing these documents, and rather focus simply on the facts of whatever content is problematic and on any revisions you may be able to suggest to fix those errors, preferably with the smallest change possible and further preferably that they do not break existing implementations.

[bblfish]

(I got used to "JsonLD" as that works better on hashtags. Fixed it and quoted uses of @shift)
I am not @TallTed looking for personal reasons for the problem but for structural reasons. We need to explain why the problem explained (partially) in January 2016, and on several occasions before that, has persisted up to now, as per issue 1248.
I explained above that it seems to be related to the requirement to move from

{
  "title": "Hello world!"
}

to

{
  "title": "Hello world!",
  "proof": { ... } 
}

as per VC Data Integrity Spec Example 1.

If anyone can give me a Json-Ld context that would allow the following JsonLD from Example 1 of the Data Model Spec

{
  "@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",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-2022",
    "created": "2023-06-18T21:19:10Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "https://university.example/issuers/565049#key-123",
    "proofValue": "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQApmEcqaqA3Q1gVHMrXFkXJeV6doDwLWx"
  }
}

to produce the following RDF Graph

then I would be proven wrong.

But I think @gkellogg just argued above yesterday that this cannot be done.

Now I also bet you won't succeed in getting any change to the surface Json-Ld syntax so as to produce the needed graph. I am not saying it would be difficult to propose such a surface syntax change. My guess is it would require the json signed to be the value of a relation "signing", ie. something like this

{
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-2022",
    "signing" : {
       "title": "Hello World!"
    }
}

But I guess this will not be acceptable to the JSON VC community, probably because they fear they would need to change the mime types of all their content when signing it.

It is easy to prove me wrong:

1. Either get the last change of syntax for VCs accepted by the Verifiable Credential 2.0 folks,
2. or find a JSON-LD context that will fit the current surface JSON VC syntax to give the needed result

My proposal for a @shift context operator is a suggested answer for the case where I am not shown wrong in either 1 or 2.

As an extra constraint, I think we need the VC Data Model Verifiable Presentation Example 2 JSON to produce a graph such as

Though, if I am right about the issue being related to JSON mime-type stability, I think that much more can change as long as that promise is held.

[niklasl]

@bblfish Is the following a correct representation in TriG of the desired RDF data?

prefix : <https://www.w3.org/2018/credentials#>
prefix xsd: <http://www.w3.org/2001/XMLSchema#>
prefix dct: <http://purl.org/dc/terms/>
prefix sec: <https://w3id.org/security#>
prefix ex: <https://www.w3.org/ns/credentials/examples#>

graph <#verified-credential-graph> {
  <http://university.example/credentials/1872> a :VerifiableCredential ,
      ex:ExampleAlumniCredential ;
    :credentialSubject <did:example:ebfeb1f712ebc6f1c276e12ec21> ;
    :issuer <https://university.example/issuers/565049> ;
    :validFrom "2010-01-01T19:23:24Z"^^xsd:dateTime .

  <did:example:ebfeb1f712ebc6f1c276e12ec21> ex:alumniOf <did:example:c276e12ec21ebfeb1f712ebc6f1> .

  <did:example:c276e12ec21ebfeb1f712ebc6f1> ex:name "Example University" .
}

<#verified-credential-graph> sec:proof [ a sec:DataIntegrityProof ;
    dct:created "2023-06-18T21:19:10Z"^^xsd:dateTime ;
    sec:cryptosuite "eddsa-2022" ;  # nitpick: should be <eddsa-2022>?
    sec:proofPurpose sec:assertionMethod ;
    sec:proofValue "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQApmEcqaqA3Q1gVHMrXFkXJeV6doDwLWx"^^sec:multibase ;
    sec:verificationMethod <https://university.example/issuers/565049#key-123> ] .

And that, given the context at https://www.w3.org/ns/credentials/v2, specifically:

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

the result "looks close" to the above, but does not express this intended meaning? I.e. that, while the result "looks close", the proof ends up in a named graph, and the verified data in the default graph, along with a statement linking the data to its proof (and is thus asserted in the wrong graph)? And if so, the root of the problem is that the VC JSON "looks like" that (having the proof link embedded in the probed data), but it does not mean that?

Since JSON-LD has a bunch of "tricks" for similar reintepretation of surface shapes ("transforming the AST before evaluating the semantics", if you will), I can understand this desire. And I think @gkellogg is onto something with a @reverse container for that purpose. But I also agree that it could take time before that could land (in JSON-LD 1.2), if it turns out to be practical. And I agree that it would be valuable for VC to explore a design where the "data shape to semantics" distance is reduced. But I can see it both ways.

[bblfish]

yes, that is correct @niklasl, though the graph name can be anonymous. In n3 I would write it something like this ex1.desired.n3 [1], which is very similar to what you wrote.
Having the to-be-signed graph inside the { } is essential for the signature to be well defined, as the { .. } encloses the triples. The open world does not apply inside the graph node: we know exactly what triples and quads of an RDF graph we are dealing with - note: the enclosed graph could also contain nodes with graphs in their nodes.

I understand that there is pressure to bring out a VC 2.0 in a year, so I think we'll need to define @reverse if needed before JSON-LD 1.2 is out that they can reference, and that can then be incorporated into JSON-LD 1.2 later. We should find out if something like that can work.

[1] Ideally, we could distinguish the metadata and the claim as in ex1.desired.ideal.1.n3, as it would make clear what is claimed.
You can use EYE to test n3 out

$ eye --quiet --nope ex1.desired.ideal.1.n3 --pass

[niklasl]

If we can work out the relationship between RDF-star and named graphs, we might work out something for this by leveraging the potential outcome of json-ld/json-ld-star#45.

That'd hinge on @quoted being able to quote both the arc itself and the entire sets of triples "under" that arc, so it'd take some serious consideration. Also, in the original example in this issue, it appears that what is being signed is the implicit graph resulting from the document payload? This in itself demands a lot (although I can see that line of reasoning in a document-oriented context).