Closed AFlowOfCode closed 10 months ago
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.
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 errorjsonld.SyntaxError: Invalid JSON-LD syntax; tried to redefine a protected term.
Changing
PermanentResidentCardCredential
toPermanentResidentCard
allows the processor to proceed. I tested this with every term that ends in "Credential" and the result is the same.