Remove `@version` from v2 context

[OR13]

https://community.neo4j.com/t/could-not-parse-jsonld-error-when-importing-a-json-ld-file/46792/4

requiring JSON-LD v1.1 seems to be constraining the useful tools that can be leveraged with verifiable credentials.

[dmitrizagidulin]

+1, the @version property should go.

[peacekeeper]

Yes there are existing tools and libraries that don't support JSON-LD 1.1, e.g. https://github.com/jsonld-java/jsonld-java.

[iherman]

The issue was discussed in a meeting on 2021-12-01

• no resolutions were taken

View the transcript

3.7. Remove @version from v2 context (issue vc-data-model#843)

See github issue vc-data-model#843.

Brent Zundel: This is clearly a v2 issue, any objections?.

Manu Sporny: No objections..

[VladimirAlexiev]

In contrast, the EPCIS contexts (https://github.com/gs1/EPCIS/blob/master/epcis-context-simple.jsonld or https://github.com/gs1/EPCIS/blob/master/epcis-context.jsonld) use "@version": 1.1 features.

Most of all scoped (local) contexts for things like:

• sensorReport.type is resolved to URL epcis:measurementType, and its values (eg "Temperature") are resolved in the https://gs1.org/voc/ namespace (eg https://gs1.org/voc/Temperature)
• Both sourceList.source and destinationList.destination are resolved to URL epcis:sourceOrDestination

We also use @protect to prevent people from redefining EPCIS terms.

@OR13 I mention this in relation to https://github.com/w3c-ccg/traceability-vocab, which reuses (or will reuse) some EPCIS stuff.

[OR13]

@VladimirAlexiev I am not suggesting nobody use @version 1.1 :)

I am suggesting that the base v2 context not use it.. and let EPCIS or trace or schema.org decide if they need version 1.1 or not.

The v1 context have a lot fo defintions that that the v2 context will likely not have.

The only ones that I think will be staying are:

"@context": {
    "@version": 1.1,
    "@protected": true,
    "id": "@id",
    "type": "@type",
    "VerifiableCredential": {
      "@id": "https://www.w3.org/2018/credentials#VerifiableCredential",
      "@context": {
        "@version": 1.1,
        "@protected": true,
        "id": "@id",
        "type": "@type",
        "cred": "https://www.w3.org/2018/credentials#",
        "sec": "https://w3id.org/security#",
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "credentialSchema": {
          "@id": "cred:credentialSchema",
          "@type": "@id",
          "@context": {
            "@version": 1.1,
            "@protected": true,
            "id": "@id",
            "type": "@type",
            "cred": "https://www.w3.org/2018/credentials#",
            "JsonSchemaValidator2018": "cred:JsonSchemaValidator2018"
          }
        },
        "credentialStatus": {
          "@id": "cred:credentialStatus",
          "@type": "@id"
        },
        "credentialSubject": {
          "@id": "cred:credentialSubject",
          "@type": "@id"
        },
        "evidence": {
          "@id": "cred:evidence",
          "@type": "@id"
        },
        "expirationDate": {
          "@id": "cred:expirationDate",
          "@type": "xsd:dateTime"
        },
        "holder": {
          "@id": "cred:holder",
          "@type": "@id"
        },
        "issued": {
          "@id": "cred:issued",
          "@type": "xsd:dateTime"
        },
        "issuer": {
          "@id": "cred:issuer",
          "@type": "@id"
        },
        "issuanceDate": {
          "@id": "cred:issuanceDate",
          "@type": "xsd:dateTime"
        },
        "proof": {
          "@id": "sec:proof",
          "@type": "@id",
          "@container": "@graph"
        },
        "refreshService": {
          "@id": "cred:refreshService",
          "@type": "@id",
          "@context": {
            "@version": 1.1,
            "@protected": true,
            "id": "@id",
            "type": "@type",
            "cred": "https://www.w3.org/2018/credentials#",
            "ManualRefreshService2018": "cred:ManualRefreshService2018"
          }
        },
        "termsOfUse": {
          "@id": "cred:termsOfUse",
          "@type": "@id"
        },
        "validFrom": {
          "@id": "cred:validFrom",
          "@type": "xsd:dateTime"
        },
        "validUntil": {
          "@id": "cred:validUntil",
          "@type": "xsd:dateTime"
        }
      }
    },
    "VerifiablePresentation": {
      "@id": "https://www.w3.org/2018/credentials#VerifiablePresentation",
      "@context": {
        "@version": 1.1,
        "@protected": true,
        "id": "@id",
        "type": "@type",
        "cred": "https://www.w3.org/2018/credentials#",
        "sec": "https://w3id.org/security#",
        "holder": {
          "@id": "cred:holder",
          "@type": "@id"
        },
        "proof": {
          "@id": "sec:proof",
          "@type": "@id",
          "@container": "@graph"
        },
        "verifiableCredential": {
          "@id": "cred:verifiableCredential",
          "@type": "@id",
          "@container": "@graph"
        }
      }
    },

If we can refactor these to NOT need 1.1 features or @version I think that is preferred.

If we can't refactor these to avoid 1.1, we should be clear that we are reducing the set of JSON-LD processors that support the vc data model to only ones that support 1.1... and that is reducing the potential support that developers would have.

I think many developers assume its best to "use the latest" and then discover that 1.1 is not as widely supported as they might have hoped.

In general, we should only use 1.1 features if they are absolutely necessary, and we should assume that the VC Data Model context will only be the 1st context required... never the last (unless we add support for @vocab)... so other contexts will also have too choose between 1.1 features and wider tooling support.

[VladimirAlexiev]

@OR13 I wasn't suggesting VC need to use 1.1, I was just giving examples of why we had to use 1.1 in EPCIS.
Since VC is small and fixed (to the point that it should be immutable, or is it the DID context will be immutable), I believe it won't have use 1.1 ever.

Not so for the Traceability effort, which mix and matches from many places and is huge, so may well need to use nested contexts.

[OR13]

@VladimirAlexiev I think I completely agree, but let me restate in my own words.

DID and VC contexts should not require 1.1 since they just define terms and don't bundle other ontologies.

But other contexts that have to bundle or integrate with many different ontologies have a good reason to consider 1.1 features?

[dlongley]

DID and VC contexts should not require 1.1 since they just define terms and don't bundle other ontologies.

The @protected feature from 1.1 is a hard requirement. It ensures that you can do a simple string comparison on context URLs without having to do processing -- and we fought very hard to create that feature and get it into the JSON-LD 1.1 spec whilst the VC 1.0 spec was being produced.

There's a well-maintained Java processor that supports JSON-LD 1.1 (and, it apparently also works in Android) here:

https://github.com/filip26/titanium-json-ld

That implementation also includes URDNA2015 RDF canonicalization.

I'm not sure which other languages people are concerned about having a 1.1 processor in, but every language listed on the json-ld.org page that has a 1.0 implementation also has a 1.1 one -- except Erlang and PHP: https://json-ld.org/

It would be good to hear what the specific issues are since a cursory look at the implementation landscape implies that if you have support for 1.0 you have 1.1 support too (I doubt anyone is clamoring for an Erlang or PHP 1.1 processor).

[OR13]

The @protected feature from 1.1 is a hard requirement. It ensures that you can do a simple string comparison on context URLs without having to do processing -- and we fought very hard to create that feature and get it into the JSON-LD 1.1 spec whilst the VC 1.0 spec was being produced.

If this is a good argument for keeping the 1.1 version in the context, then its also a good argument for why JSON-LD processing is not needed for VC-JWT in order to ensure conformance under the assumption that v2 context includes an @vocab...

Together these give you term definitions without any need to "do JSON-LD processing".

And they don't preclude you from doing "advanced JSON-LD processing".

I am happy to concede to retaining @version and 1.1 If we can have an @vocab as well... to ensure that string processing of the context really is all that is needed when importing a credential, and that JSON-LD processing is not required... I think the current assertion to the contrary is false due to the nature of undefined term errors in the v1 context.

In short, I am not convinced this is a hard requirement, because its insufficient (alone) in solving the proposed value add.

[dlongley]

@OR13,

As stated in another thread, I'm content with exploring adding @vocab to the core context. However, I don't agree that it's a requirement to avoid processing by a consuming application; it's solving an orthogonal problem. Already, an application that receives a verified VC can do a check for the proper expression of @context string values to know that any terms defined therein will match expectations (without having to perform any JSON-LD transforms).

This was an important goal in the VC 1.0 work (that was achieved through @protected) and we should preserve it. It is true that it requires term definitions in contexts, but @vocab would only change those from explicit to implicit. I do concur that the need to explicitly define terms in contexts has been a usability problem to date and that it may possibly be solvable (with acceptable tradeoffs) using @vocab. We shouldn't conflate guarantees with usability so that we can speak and understand both clearly -- but, yes, I'm with you that the former is little help without the latter.

IMO, we should also keep the @vocab conversation over here: #753