Re: Modelling problem in Verifiable Credentials 1.1 and 2.0

omg- he was so just here
what happened
just a week after Doug Lenat

sorry Henry, I never replied to this thread
too dense for my sparse brain these days
you have been  such a fixture on this list

There is no death really, we are all just passing through
I like to think of death as the end of mortal struggle

let us be reminded of impermanence, and to be considerate
with each other and that every thread counts

On Mon, Sep 4, 2023 at 4:24 PM Henry Story <henry.story@bblfish.net> wrote:

> Dear Semantic Web community,
>
> I think I have found a serious modeling problem with the RDF in the
> Verifiable Claims Data Model standard [1] (VC-DM) and the currently worked
> on VC-DM 2.0 [2].
>
> Last week, I translated the examples from the spec into N3 [0], as it is
> not easy to see from a JSON-LD file what the namespaces are and where the
> graphs stard and end. The 1.1 DM example 1 JSON-LD has some minor problems
> like a <sec:jws> URL [3], which, when fixed and then massaged for more
> clarity, ended up giving a pattern very similar to the current DM 2.0. I
> show here the DM 2.0 translated to N3 with headers omitted (see
>  ex1.pg.v3.n3 on github [4] for the full version)
>
> <did:example:ebfeb1f712ebc6f1c276e12ec21>
>     credEx:alumniOf
>        <did:example:c276e12ec21ebfeb1f712ebc6f1> .
>        <did:example:c276e12ec21ebfeb1f712ebc6f1>
>              credEx:name "Example University" .
>
> uniCred:1872 a credEx:ExampleAlumniCredential, cred:VerifiableCredential;
>    cred:issuer <https://university.example/issuers/565049> ;
>    cred:credentialSubject <did:example:ebfeb1f712ebc6f1c276e12ec21> ;
>    cred:validFrom "2010-01-01T19:23:24Z"^^xsd:dateTime ;
>    sec:proof {
>       [] a sec:DataIntegrityProof ;
>          dct:created "2023-06-18T21:19:10Z"^^xsd:dateTime ;
>          sec:cryptosuite "eddsa-2022" ;
>          sec:proofPurpose sec:assertionMethod ;
>          sec:verificationMethod <
> https://university.example/issuers/565049#key-123> ;
>          sec:proofValue
> "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQApmEcqaqA3Q1gVHMrXFkXJeV6doDwLWx"^^sec:multibase
> .
>    } .
>
> As you see, the signature is in a graph, and the data to be signed is in
> the default graph.
> The opposite needs to happen: the to-be-signed graph needs to be in { … }
> quotes,
> where it can act as a literal. That places it in a closed world such that
> one can know exactly
> what triples are being signed. The signature itself does not need to be in
> the default graph at all.
>
> The problems are numerous:
> 1. An inferencing engine need only add an owl:sameAs from any node to
> itself, and the agent wanting to verify the signature would no longer know
> what was being signed.
> 2. other inferences such as that a node is a foaf:Agent could lead to the
> same problem.
> 3. the graph when merged with any other graph that was thougth to be true
> would make the resulting signature useless.
> 4. It follows that most graphs with signatures from a VC DM will be
> uniseable even if the original was perfectly valid.
>
> What we want is, therefore [5] is
>
> {
>   uniCred:1872 a credEx:ExampleAlumniCredential, cred:VerifiableCredential
> ;
>     cred:issuer <https://university.example/issuers/565049> ;
>     cred:credentialSubject
>        [ id <did:example:ebfeb1f712ebc6f1c276e12ec21>
>              credEx:alumniOf [ id
> <did:example:c276e12ec21ebfeb1f712ebc6f1>
>                 credEx:name "Example University" ];
>        ];
>     cred:validFrom "2010-01-01T19:23:24Z"^^xsd:dateTime .
> } sec:proof [ a sec:DataIntegrityProof ;
>      dct:created "2023-06-18T21:19:10Z"^^xsd:dateTime ;
>      sec:cryptosuite "eddsa-2022" ;
>      sec:proofPurpose sec:assertionMethod ;
>      sec:proofValue
> "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQApmEcqaqA3Q1gVHMrXFkXJeV6doDwLWx"^^sec:multibase
> ;
>      sec:verificationMethod <
> https://university.example/issuers/565049#key-123>
>  ] .
>
> I reported the problem on the VC-DM GitHub repo in issue 1248 in detail
> [6]
> and I also proposed a potential extension to JSON-LD that could fix this
> in issue 817
>
> https://github.com/json-ld/json-ld.org/issues/817
>
> This problem arises because I believe there is a strong desire to follow a
> specific
> pattern in JSON for signatures. I explain in detail in 817 above.
>
> A new extension to JSON-LD needs to be urgently worked on
> to allow the current JSON to give the correct RDF.
>
> I think this should be a priority topic at the upcoming TPAC.
>
> Yours sincerely,
>
>    Henry Story
>    https://co-operating.systems/
>
>
> [0] https://w3c.github.io/N3/reports/20230703/
> [1] VC Data Model 1.1 spec:
>
> https://www.w3.org/TR/vc-data-model/#example-a-simple-example-of-a-verifiable-credential
> [2] Current work in progress VC Data Model 2.0 spec
>
> https://w3c.github.io/vc-data-model/#example-a-simple-example-of-a-verifiable-credential
> [3] translated using JsonLD playground I think
>
> https://github.com/co-operating-systems/PhD/blob/main/Logic/VC/model/vcdm.ex1.nq
> [4] see the various ex1.pg.* versions I worked through here
>     https://github.com/co-operating-systems/PhD/blob/main/Logic/VC/model2/
> [5]
> https://github.com/co-operating-systems/PhD/blob/main/Logic/VC/model2/ex1.desired.n3
> [6]
> https://github.com/w3c/vc-data-model/issues/1248#issuecomment-1697508577
>