w3c-ccg / citizenship-vocab

A vocabulary for asserting Verifiable Credentials related to citizenship status

Home Page:https://w3c-ccg.github.io/citizenship-vocab/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Citizenship v2 terms ending in "Credential" incompatible with VC v2 context

AFlowOfCode opened this issue · comments

The issue is with redefining protected terms - "name" apparently being the trigger. To reproduce, the Permanent Resident Card Example can be pasted into the JSON-LD Playground, & then replace "https://www.w3.org/2018/credentials/v1" with "https://www.w3.org/ns/credentials/v2". The result is the processing error jsonld.SyntaxError: Invalid JSON-LD syntax; tried to redefine a protected term.

Changing PermanentResidentCardCredential to PermanentResidentCard allows the processor to proceed. I tested this with every term that ends in "Credential" and the result is the same.

Yes, that's an issue. What was the use case for trying to use these examples with the VC v2 context?

I'll get a bit technical about the problem. For the latest updates, it was suggested to use the credentials v1 context, since v2 is still a work in progress. This also effects terms like issuanceDate/expirationDate, which move to validFrom,validUntil. (And I'm not sure how you specify validFrom and an issue date at once). The v2 context defines name and description by default, but since this was v1, those terms were added. I was thinking the v2 name and description term definitions would be compatible with the updates here since they both use the same id. But it appears not to be so. It looks like other processors may fail on this too. So I'm not sure if this is a JSON-LD edge case that could be fixed or it should fail like this.

I think the issue here is which VC spec to support. It's more than the name and description fields that need to change, so I had assumed this whole thing would have a version bump with the switch to VC v2. A that point the local name and description fields and this problem would go away.

Here's a simplified test:

{
  "@context": [
    {
      "T0": {
        "@id": "ex:T0",
        "@context": {
          "@protected": true,
          "name": {
            "@id": "https://schema.org/name",
            "@context": {
              "value": "@value", "lang": "@language", "dir": "@direction"
            }
          }
        }
      }
    },
    {
      "T1": {
        "@id": "ex:T1",
        "@context": {
          "@protected": true,
          "name": "https://schema.org/name"
        }
      }
    }
  ],
  "ex:x": {
    "@type": ["T0","T1"],
    "name": "foo"
  }
}

name is very likely to be changed again in the v2 work -- and the resulting definition might be compatible with the context here. If not, we will need a new context version here with a matching definition.

Thanks for the response. My use case for VC v2 is because it includes the DataIntegrityProof terminology.

The deprecation of issuanceDate for the semantically nonequivalent validFrom did also strike me as a bit odd, but I think proof.created is a reasonable replacement for the same meaning, if not as explicit.

This was fixed by ea1470e.