signatures should be on quoted graphs

[bblfish]

In issue 204 on the N3 CG, I tried to translate 2 VC model examples. This revealed a few minor errors and some deeper conceptual problems, which are much easier to see in N3 than in Json-LD. These conceptual problems revolve around what is in a graph context and what is not. The JsonLD seems to place the contexts incorrectly, leading to unclarity about what is and what is not signed.

Update: the problem is perhaps most concisely expressed in a comment below in response to @msporny's feedback.

The N3 notation is to NQuads what Turtle is to NTriples: it makes it easy to read and reduces repetition for the author and the reader so that one can easily get an overview of what is being said. N3 makes it easy to read and write contexts. It also adds many other things, such as the ability to write rules for logical inferences... Where JsonLD makes it easy for developers happy with JSON to use the result, N3 makes it easy to see the data structure and reason about it. It especially makes it easy to see contexts, which are very difficult to see in jsonld.

1. Mapping the JSonLD of example 1 to N3

To take example 1, which I placed here https://bblfish.net/tmp/2023/08/vcdm.ex1.jsonld the result after fixing a few errors with namespaces, explained in detail in N3 issue 204 is that it gives me the following N3:

@prefix sec:     <https://w3id.org/security#> .
@prefix cred:    <https://www.w3.org/2018/credentials#> .
@prefix eg:      <https://example.org/examples#> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .

<did:example:c276e12ec21ebfeb1f712ebc6f1>
    <http://schema.org/name>
        "Exemple d'Université"@fr , 
        "Example University"@en .

<did:example:ebfeb1f712ebc6f1c276e12ec21>
    <http://schema.org/alumniOf>
        <did:example:c276e12ec21ebfeb1f712ebc6f1> .

<http://example.edu/credentials/1872>
    cred:issuer <https://example.edu/issuers/565049> ;
    a   eg:AlumniCredential ;
    a   cred:VerifiableCredential ;
    cred:issuanceDate "2010-01-01T19:23:24Z"^^xsd:dateTime ;
    cred:credentialSubject
        <did:example:ebfeb1f712ebc6f1c276e12ec21> ;
    sec:proof {
            []  a sec:RsaSignature2018 ;
                 dc:created "2017-06-18T21:19:10Z"^^xsd:dateTime ;
                sec:jws "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5XsITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUcX16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtjPAYuNzVBAh4vGHSrQyHUdBBPM" ;
               sec:proofPurpose sec:assertionMethod ;
              sec:verificationMethod
                    <https://example.edu/issuers/565049#key-1> .        
    }

The problem is that when signing data, one has to be very clear about which triples are signed. They, therefore, belong into a context which in n3 is placed inside the squiggly brackets { ... } .
In this N3 we have the signature in the context, but the claim that should be signed is outside of the context, so exactly what triples are being signed is unclear.

This can be made clearer by representing the above N3 in the diagram below, which shows graphs on rectangular surfaces when they appear inside {...} in the n3 notation.

Here we see that we can't tell clearly what is signed. We see that the credential links to the credential subject did:example:ebfeb1..., but what after that is included in the data signed? Is it also the alumniOf relation? Should one also add the literals? Which of the credential attributes has been signed? The data does not tell us that, but it should.

The problem is that one does not sign an object but a graph. Signatures are always applied to documents. Indeed, we can think of Graphs as semantically structured documents. Graphs are a type of object, of course, but we have a special syntax in N3 to relate them to other nodes by surrounding a set of triples with { ... }. Diagrammatically we represent this as nodes with graphs on the nodes.

As we will see next, we can have graphs in the nodes recursively: that is, graphs within nodes can also have graphs at their nodes. In the diagram below, we see this with the yellow rectangle surrounded by a green rectangle which itself is a node in a larger graph.

2. N3 corresponding to the VC Credentials diagram

The intuitions were clearly understood by the authors of diagram 6 from §3.2 of the VC-data-model spec, which uses surfaces to distinguish different claims.

This diagram represents the signature, the graph signed, and the claim, each in its own graph. This seems like the right model, aligning us with the well-known Says logic for decentralized access control.
We can interpret the colored surfaces as telling us who is making a claim.
Our trust in the claim being made depends on our trust in the agent making the claim, and our ability to verify that it did make that claim.

Anyway, the official Verifiable Claims interpretation of the JsonLD is that it should consist of 3 claims, i.e., sets of relations that we can think of as being placed on surfaces, following an idea from Pat Hayes, that he took from Peirce and which is now being worked on in the RDF Surfaces CG.

As shown in the diagram, a VC is data about a claim (the Yellow surface to the right) stating that Pat is an alumnus of "Example University". That claim is made or "said" by the issuer - the University in this case - at a certain date. The data about that is on the pink surface. Finally, the University key signs the above claim with the statement on the green surface.

In the says logic, this would be expressed as something like this:

$$\text{ UniKey } \text{ says } \text{ Uni } \text{ says } \text{ PaU}$$

where $\text{ PaU } \equiv \text{ Pat alumnusOf Uni }$

This suggests that the pink and yellow surfaces are placed onto the green surface, which follows by associativity of the says relation:

$$ \text{UniKey} \text{ says } ( \text{ Uni } \text{ says } \text{ PaU} ) $$

To be precise, we should perhaps start with The Guard initially receiving the following claim from some connAgent,
ie the agent at the other end of a connection.

$$ \text{ connAgent } \text{says} (\text{UniKey} \text{ says } ( \text{ Uni } \text{ says } \text{ PaU} )) $$

From the Guard's point of view, the only fact that exists at that point in time,
is that the connAgent said that thing (that the UniKey said...)
None of the embedded statements are to be taken as true or false at that point by the Guard.
They are quoted sayings, and their truth value is yet to be decided.

Yet, without needing to trust the connAgent at all, the Guard can verify the embedded claim made by the UniKey using cryptographic signatures so that it can conclude to the truth of the pink surface.
That is because the Guard trust the University key to speak for the University.
So he concludes:

$$ \text{ Uni } \text{ says } \text{ PaU } $$

Again here, the Guard has a fact that does not assert or deny that Pat is an alumnus of Uni, only that the Uni said so.
So we are now on the pink surface where the Guard does not yet know if the yellow surface is true or false.
If the Guard trusts the issuer about claims it makes regarding its own members - which seems like a reasonable assumption - then the Guard can proceed to believe that Pat is an alumnus of that university. Perhaps that is what is needed to be proven to satisfy an access control rule.

All that makes logical sense. If we wanted to write the above official diagram in N3, we would have something like the following N3.
(Note: the diagram has two links (credentialSubject and proof) that go from an object into a node in a graph context (a box). That requires an extra relation to point into the graph, it seems, but I'll ask and the N3 group if it could be done if it were really needed.)

@prefix sec:     <https://w3id.org/security#> .
@prefix cred:    <https://www.w3.org/2018/credentials#> .
@prefix eg:      <https://example.org/examples#> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix schema: <http://schema.org/>.

{   
<http://example.edu/credentials/1872>
    cred:issuer <https://example.edu/issuers/565049> ;
    a   eg:AlumniCredential ,  cred:VerifiableCredential ;
    cred:issuanceDate "2010-01-01T19:23:24Z"^^xsd:dateTime ;
    cred:credentialSubject
        <did:example:ebfeb1f712ebc6f1c276e12ec21> ;
    cred:claim { 
    <did:example:ebfeb1f712ebc6f1c276e12ec21>
         schema:alumniOf [ id <did:example:c276e12ec21ebfeb1f712ebc6f1> 
               schema:name "Exemple d'Université"@fr ,   "Example University"@en 
         ] 
   }
 } sec:proofObject _:gn;
    sec:proof {
    _:gn  a sec:RsaSignature2018 ;
           dc:created "2017-06-18T21:19:10Z"^^xsd:dateTime ;
           sec:jws "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5XsITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUcX16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtjPAYuNzVBAh4vGHSrQyHUdBBPM" ;
            sec:proofPurpose sec:assertionMethod ;
            sec:verificationMethod
                    <https://example.edu/issuers/565049#key-1> 
    ]  .
} .

Here the VC signed the information about who made the claim and the claim together.
Now we see that it is odd that the university's name is in the claim. Should it perhaps be outside the claim? It is not clear from the graph what is intended there, but both would be fine.

3. Slight Simplification of N3 translation of Diagram

We have two arguments for removing the green surface:

1. Since the information about the signature is not itself signed, the claim does not perhaps need to be in a graph context. In the language of RDF Surfaces, if the top surface is positive, then we can take it to be the default surface.
2. As argued above from the key says ... we can think of the green surface as containing the pink one and so the green surface being the base one. In that case we can see that the green surface would be the default graph and we can get rid of it altogether.

Removing the green surface simplifies the n3 quite a lot giving us:

@prefix sec:     <https://w3id.org/security#> .
@prefix cred:    <https://www.w3.org/2018/credentials#> .
@prefix eg:      <https://example.org/examples#> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix schema: <http://schema.org/>.

{   
<http://example.edu/credentials/1872>
    cred:issuer <https://example.edu/issuers/565049> ;
    a   eg:AlumniCredential ,  cred:VerifiableCredential ;
    cred:issuanceDate "2010-01-01T19:23:24Z"^^xsd:dateTime ;
    cred:credentialSubject
        <did:example:ebfeb1f712ebc6f1c276e12ec21> ;
    cred:claim { 
    <did:example:ebfeb1f712ebc6f1c276e12ec21>
         schema:alumniOf [ id <did:example:c276e12ec21ebfeb1f712ebc6f1> 
               schema:name "Exemple d'Université"@fr ,   "Example University"@en 
         ] 
   }
 } sec:proofObject [  a sec:RsaSignature2018 ;
     dc:created "2017-06-18T21:19:10Z"^^xsd:dateTime ;
     sec:jws "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5XsITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUcX16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtjPAYuNzVBAh4vGHSrQyHUdBBPM" ;
      sec:proofPurpose sec:assertionMethod ;
      sec:verificationMethod
               <https://example.edu/issuers/565049#key-1> 
    ]  .

Graphically this can be represented as

Would it be possible, with minor tweaking of the Json-ld contexts, to get the above interpretation to work?

4. proposition of N3 intended by the JsonLD

The above seems right but is not what the JsonLD mapping to RDF shows, if only because it is missing the yellow surface and has placed the data to be signed on the default surface.

The closest to something we could get that resembles the RDF we found the current JSonLD to translate to is to flip the
contexts. Instead of the signature being in the context, we get something more reasonable by having the signed data be in a context.

Perhaps this is what the VC data model intended the original json-ld to represent?

@prefix sec:     <https://w3id.org/security#> .
@prefix cred:    <https://www.w3.org/2018/credentials#> .
@prefix eg:      <https://example.org/examples#> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix schema: <http://schema.org/>.

{
<did:example:c276e12ec21ebfeb1f712ebc6f1>
    schema:name
        "Exemple d'Université"@fr ,   "Example University"@en .

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

<http://example.edu/credentials/1872>
    cred:issuer <https://example.edu/issuers/565049> ;
    a   eg:AlumniCredential ,  cred:VerifiableCredential ;
    cred:issuanceDate "2010-01-01T19:23:24Z"^^xsd:dateTime ;
    cred:credentialSubject
        <did:example:ebfeb1f712ebc6f1c276e12ec21>  .
 } sec:proof [  a sec:RsaSignature2018 ;
           dc:created "2017-06-18T21:19:10Z"^^xsd:dateTime ;
           sec:jws "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5XsITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUcX16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtjPAYuNzVBAh4vGHSrQyHUdBBPM" ;
            sec:proofPurpose sec:assertionMethod ;
            sec:verificationMethod
                    <https://example.edu/issuers/565049#key-1> 
    ]  .

That is, here we only use a graph context to enclose the signed triples, which in this case
I guess enclose the metadata about the issuer too. Graphically represented, this is what we have:

Is that correct? I don't know. It would require a very close analysis of the spec to understand what is intended to be signed. Update: See a detailed reasoning for why this follows from the previous two models.

(todo: We could also imagine that only the claim was intended to be signed.)

In issue 204 on the N3 repo I show the same problem with Example 6 in the spec.

Conclusion

Perhaps I missed something. Is there a mistake in the JsonLd or its @context statements? I have not written a JSON-LD parser, so I don't know the capabilities of contexts inside out. Perhaps it is easy to fix? What is the intended N3 corresponding to the Json-Ld?

[bblfish]

I also had a look at Example 2: A simple example of a verifiable presentation.

1. I placed a copy of the JsonLd here https://bblfish.net/tmp/2023/08/vcdm.ex2.jsonld
2. The first transformation led to something close to N3 but with broken URLs such as <sec:proofPurpose> for relations, and literals that appear as blank nodes https://bblfish.net/tmp/2023/08/vcdm.ex2.broken.n3 . The JsonLd playground gives the same result.
3. I repaired that and added namespaces https://bblfish.net/tmp/2023/08/vcdm.ex2.repaired.n3
4. Then I translated to pure N3 (ie without quads) doing the minimal work https://bblfish.net/tmp/2023/08/vcdm.ex2.pure.n3
5. Then I translated that using the Jena N3 parser Jen3 which made it more readable https://bblfish.net/tmp/2023/08/vcdm.ex2.jen3.n3
6. And finally, I improved it by hand https://bblfish.net/tmp/2023/08/vcdm.ex2.n3 but not to perfection

@prefix cred:    <https://www.w3.org/2018/credentials#> .
@prefix credEx:  <http://example.edu/credentials/> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sec:     <https://w3id.org/security#> .
@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sch:     <http://schema.org/> .
@prefix dc:      <http://purl.org/dc/terms/> .

credEx:1872 sec:proof {
     []  rdf:type sec:RsaSignature2018 ;
       dc:created "2017-06-18T21:19:10Z"^^xsd:dateTime ;
       sec:jws "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5XsITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUcX16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtjPAYuNzVBAh4vGHSrQyHUdBBPM" ;
       sec:proofPurpose sec:assertionMethod ;
       sec:verificationMethod
             <https://example.edu/issuers/565049#key-1> .        
} .

[] a  cred:VerifiablePresentation ;
   cred:verifiableCredential {
     <did:example:ebfeb1f712ebc6f1c276e12ec21>
         sch:alumniOf [ id <did:example:c276e12ec21ebfeb1f712ebc6f1> 
             sch:name "Example University"@en, "Exemple d'Université"@fr
         ] .
              
     credEx:1872 a cred:VerifiableCredential,
             <https://example.org/examples#AlumniCredential>; 
         cred:credentialSubject
             <did:example:ebfeb1f712ebc6f1c276e12ec21> .
     credEx:1872
         cred:issuanceDate "2010-01-01T19:23:24Z"^^xsd:dateTime ;
         cred:issuer <https://example.edu/issuers/565049> .        
    } ;
    sec:proof {
      [] a sec:RsaSignature2018 ;
        dc:created "2018-09-14T21:19:10Z"^^xsd:dateTime ;
        sec:challenge "1f44d55f-f161-4938-a659-f8026467f126" ;
        sec:domain "4jt78h47fh47" ;
        sec:jws "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqsLfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh4vGHSrQyHUGlcTwLtjPAnKb78" ;
        sec:proofPurpose sec:authenticationMethod ;
        sec:verificationMethod
           <did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1> .        
    } .

This makes more sense because we are linking a graph of verifiable credentials and a signature. But it seems like the signature needs not be placed in a graph. It is an acknowledged statement of fact. And indeed, it is a bit weird because the signature is a blank node so the proof is a statement in which one has to find the only blank node and continue from there to find the proof. The context could have been avoided and a link directly to the blank node made.

[iherman]

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

• no resolutions were taken

View the transcript

3.2. N3 rendering of Verifiable Claims Examples problems (issue vc-data-model#1248)

See github issue vc-data-model#1248.

Manu Sporny: This has to do with the 'verifiable credential graph' language that some would like, and also relates to the diagrams. I think Henry got it right, and suggested some post-CR modifications we could make.

Brent Zundel: I'm not hearing any objections to this being post-CR.

[bblfish]

@iherman reported

..
Brent Zundel: I'm not hearing any objections to this being post-CR.
...

Thanks for letting me know about that discussion.
What does post-CR mean? I tried to look at the tags for definitions or hints but without luck.

[brentzundel]

post-CR means that addressing this issue will not require additional features or normative requirements being added to the spec, which means we will be able to focus on it after the VC Data Model v2 has entered Candidate Recommendation.

[bblfish]

Just as an addendum note to @iherman, @brentzundel and @msporny
I think the official diagram discussed in §2 above entails the representation §3 and §4, and I detailed that in a comment on issue 206 to the N3 group.

More importantly, I argue that the JsonLd that is currently produced won't do. It is related to how graphs get merged, which is an essential property of RDF: merging true graphs should lead to true graphs.

Consider the graph reached by current jsonld conversion

Now consider merging this graph with another true graph. This could quickly render the signature meaningless. Take for example, the true graph

<did:example:ebfeb1f712ebc6f1c276e12ec21> foaf:name "Pay Hayes";
      foaf:publications <https://scholar.google.com/citations?sortby=pubdate&hl=en&user=VTNr4NMAAAAJ&view_op=list_works> .

If we merged that to the representation where only the signature is a surface, the new graph would consist of the intact green surface, the other data and those three triples on the same default surface. I.e. we have the following graph, and it would no longer be possible to know what was signed.
.
Now this may not be false, but it suddenly became useless. There is no longer any way of using the signature.

Compare this to the merging of the simplified model of §4 with the true Pat Hayes graph.
We get the following:

Here we can still verify the Credential Graph using the Proof object, and if we still believe it, then we can merge the content of the pink surface and the rest without problem.

So that provides a simple, pragmatic reason for why the current translation is not good.
The main issue description may not have been clear enough, so I thought this argument deserves particular attention.

[msporny]

@bblfish thanks for the very detailed issue report; the diagrams were very helpful.

They need to be in their own context because people can say untrue things, and others can be suspicious of what is being said….

Yes, exactly.

My initial response to you (which I deleted, but you still responded to) was incorrect, please discard that one and read this one instead. :)

I had to read through your issue multiple times in an attempt to understand the content at depth. I'm fairly convinced I'm still missing something, so apologies for the overly verbose reply. Just to establish some other content that might help you navigate this:

For securing a Verifiable Credential using Data Integrity (what you delve into above), you might want to familiarize yourself with the Data Integrity specification and at least one of the cryptosuite specifications, such as a EdDSA Cryptosuite that uses RDF Dataset Canonicalization.

Namely, the following are further detailed across these specifications:

• The current cryptosuites that do RDF processing, do the processing on RDF Datasets.
• Each item in the verifiableCredential set in a VerifiablePresentation is a separate RDF Dataset.
• The RDF Dataset for the proof, expressed via the proof predicate, is canonicalized and hashed separately from the default RDF Dataset (the Verifiable Credential). The hash for the default dataset and the hash for the proof dataset are then combined, hashed and digitally signed over to create the final proofValue. This "binds" the proof to the default RDF dataset.
• This also extends to proof sets (where each proof is its own RDF Dataset) and proof chains, where the latter encapsulates previous proof RDF Datasets in the signature.

What I'm trying to elaborate upon above is that we have put a lot of thought and time into ensuring that the proper boundaries are created around the default RDF Dataset, the proof RDF Datasets, and the verifiableCredential RDF Datasets as they are found in VerifiablePresentations. That said, we do not allow arbitrary information to be "mixed into" the default graph -- doing so will cause the signature to (rightly) fail. Similarly, adding another RDF Dataset into the ones that exist (as a part of the Verifiable Presentation or Verifiable Credential) will not merge or allow that dataset to affect the secured graphs of information; it will always be a RDF Dataset that exists, but has no proof attached to it (and can, therefore, not be trusted in the same way a VC or a VP can be trusted). To put it another way; don't merge graphs that you don't trust with graphs that you do trust. Similarly, don't merge two graphs together that have blank node labels as you might end up merging things that are labeled with the same label, but are not the same subject (this is the whole reason we're using RDF Datasets in the first place -- to keep the blank nodes separate).

There is a boundary to the information that is contained in a VP or a VC, and that boundary ends at the document you receive. Since we're using RDF Datasets, you /can/ make inferences across those boundaries if objects are identified using URLs, but merging RDF Datasets isn't something one should do without careful consideration (such as, there are no labeled blank nodes in either RDF Dataset that might conflict).

I do expect that we could do better to explain the above, but at the same time, remember that we have a number of people in the ecosystem that neither care about these formal modelling details or want to know about them. The more RDF we put into the specification, the more agitated a subset of the community becomes... so we've always struggled to provide just the right level of information, especially at the beginning of the specification, without opening up the flood gates into graph theory and formal semantics... which, people using this technology, don't need to know about... just like how someone operating a vehicle doesn't need to understand the physics behind it all... you just press one pedal to go and another pedal to stop.

All that said, we do have to do at least the following:

• Address the concept of a Verifiable Credential graph, a proof graph, and the default graph raised in issue Address normative concept of VerifiableCredentialGraph #1240.
• Perform some minor fixes to the diagrams (e.g., fix the proof arrows in Figure 6 and Figure 8)
• Perhaps address some variation of what you're concerned about in this issue, but when and where remains to be seen.

In the meantime, try this example instead, which is from the latest spec (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"
  }
}

I'll stop there and see if you have more concrete guidance on what we could do with the above.

[bblfish]

Thanks, Manu, for the Detailed response. Let me start with your final suggestion to look at the examples 1 and 2 from the 2.0 spec (I was looking at the 1.1 data model before)
Example 1 is found inside Example 2. As a visual reminder, this is the figure 6 from the data model 2.0 representing the verifiable presentation, containing a Verifiable claim.

I agree that is a good model.
(I would just say that one could simplify because there is no need to place the signature in its own graph.)

So, I started with Example 1 JsonLD and using the JSLd Playground transformed it into NQuads and then by hand to Example 1 N3. (It definitely would save a huge amount of time if @jeswr added his JS N3 lib to the JS playground as per comment). The resulting RDF was structurally no different than the 1.1 spec. Within a node of the default RDF graph, we have a Credential Proof Graph. We colored that node green here to match the spec colors. When a node contains a graph, we can call it a surface. (The default graph is on the default surface, too, if you think of every RDF graph as located on a single hidden node, which is just another way to say that it could be quote in a larger context)

I then translated the Json from Example 2 using the same procedure (and using Jen3) to an n3 file which makes it easier to see the semantic structure. I drew that out as

The problem here is less serious than above because both the credential graph and the presentation proof graph are wrapped in a node. (The proof does not need to be wrapped as above). Still, once the presentation proof is verified, we can unwrap the verifiable credential graph and pass it on to another agent who may want to verify the credential: but it will be stumped again because it won't be able to tell what is signed.

That is just like with cryptography: we sign a stringlike object. In RDF1.0, these graphs-in-nodes would have been rdf:XMLLiteral with an RDF/XML type. All we are doing here is showing more clearly the internal structure of such nodes.

To put it another way, don't merge graphs that you don't trust with graphs that you do trust.

Agree. My argument above works because I start with the assumption that I fully trust two graphs that I wanted to merge. I used this graph as an example

<did:example:ebfeb1f712ebc6f1c276e12ec21> foaf:name "Pay Hayes";
      foaf:publications <https://tinyurl.com/patHayesScholar> .

We assume those two triples are true. It is a law of RDF that when true graphs are merged the new conjoined graph will also be true.
RDF also defines that merging two graphs requires blank nodes from each graph to be kept distinct in the merged graph. This is equivalent to what in lambda calculus is called alpha reduction. All programming languages do this, and in RDF it is exceedingly easy to to so.

So given those two essential rules of RDF that are millions of times easier to understand than cryptographic algorithms, if we were to merge the Example 1 graph with the two triples above, we would get the following graph:

The color coding of nodes on the default surface indicates their role for VC: the only colors that count are the surface colors. So a program can not tell in advance that the grey nodes are different from the yellow ones.
Now notice that even though nothing may be false, we did move from a situation where we had a signature that we thought made sense - i.e., we thought we could verify it on a given graph - to one where it no longer did: because we don't know what set of triples are signed. This indicates that this is ill-defined.
We can also see that there will an indefinite number of such consequences that can be drawn from other true graphs.

But there is an even better example. Every graph with a node ?n entails a graph with the extra triple ?n owl:sameAs ?n.
So the diagram drawn from the JSON-LD example 1, entails the following diagram with only the arrow in red added

With just this small change, it will no longer be easy to tell what the signature was signing.

But the answer to this is very simple:

1. Place the triples that have been signed in what we call a surface (an RDF graph in a node), as you do in the pink diagram from the spec at the top. Those are the triples the cryptosuites have somehow canonicalized so that the signed text can be recreated - (just as with HttpSig headers).
2. You don't need to place the signature in its own graph, as RDF ensures that blank nodes from merged graphs will never be identified.

Here 1 is essential. 2 would just simplify your data structure. I say that, betting that you can't find a good reason not just to use a blank node.

Given those points, what you want is the RDF or JSON/LD for this diagram:

Is that problematic to express in JSON-LD?

[bblfish]

I think the simple rule should be that: whatever is signed should be a graph node; i.e., what goes into {...} in n3 or the things that are 4tuples in NQuads, or the surfaces containing graphs in our diagrams.

Following the rule, this is what the Example 2 Presentation should look like.

(Arguably, the yellow claim could be added to clarify what is being asserted precisely by whom.)

[TallTed]

@bblfish @msporny (and others) -- Please note that color coding will not be sufficient to mark elements of diagrams in our published documents, for a11y reasons. Dashed or otherwise differentiated lines and borders, and different kinds of B&W (or other high contrast) shading of interiors, is preferred.

Specifically regarding the draft diagrams above, @bblfish, I would like to have some border around each entire dataset. (The "page color" background is fine.)