Schema Validation for GS1 VCs

[OR13]

Picking on GS1 here, but really this applies to any credential with multiple contexts.

Here is the problem:

We need to validate @context before doing JSON-LD processing.

We have to write a separate validation case for each possible expected context value, this causes the verifiers to have to do lots of context schema validation for GS1 specifically, because they ship so many separate context files.

In addition to that, GS1 does not use https://w3id.org/traceability/v1 so we have lost our ability to assert simple things like:

first context is https://www.w3.org/2018/credentials/v2
second context is https://w3id.org/traceability/v1
additional contexts must match this allow list, etc...

instead, best we can do is the following:

first context is https://www.w3.org/2018/credentials/v2
additional contexts from an allow list, which includes https://w3id.org/traceability/v1 and all GS1 contexts known today.

It would be nicer if https://w3id.org/traceability/v1 bundled GS1 contexts... (all of them), so that we could simply do this:

first context is https://www.w3.org/2018/credentials/v2
second context is https://w3id.org/traceability/v1
additional contexts false.

^ this would be safest option.

[OR13]

For example:

describe('v2', () => {
  const validate = ajv.compile(
    yaml.load(`
title: Example Title 
description: Example Description
type: object
properties:
  '@context':
    type: array
    readOnly: true
    default:
      - https://www.w3.org/2018/credentials/v2
      - https://w3id.org/traceability/v1
    items:
      - type: string
        const: https://www.w3.org/2018/credentials/v2
    additionalItems:
      type: string
      enum:
        - https://w3id.org/traceability/v1
        - https://w3id.org/vc/status-list/2021/v1
        - https://ref.gs1.org/gs1/vc/licence-context/
        - https://ref.gs1.org/gs1/vc/trade-item-context/
        - https://ref.gs1.org/gs1/vc/declaration-context/
`)
  );

  it('minimal context', async () => {
    const instance1 = {
      '@context': ['https://www.w3.org/2018/credentials/v2', 'https://w3id.org/traceability/v1'],
    };
    const validation1 = validate(instance1);
    expect(validation1).toBe(true);
    const instance2 = {
      '@context': ['https://www.w3.org/2018/credentials/v2'],
    };
    const validation2 = validate(instance2);
    expect(validation2).toBe(true);
  });

  it('extended context', async () => {
    const instance1 = {
      '@context': [
        'https://www.w3.org/2018/credentials/v2',
        'https://w3id.org/traceability/v1',
        'https://extension.example/v42', // not in allow list
      ],
    };
    const validation1 = validate(instance1);
    expect(validation1).toBe(false);
    const instance2 = {
      '@context': [
        'https://www.w3.org/2018/credentials/v2',
        'https://w3id.org/traceability/v1',
        { '@vocab': 'https://extension.example/#' }, // not in allow list
      ],
    };
    const validation2 = validate(instance2);
    expect(validation2).toBe(false);
  });
});

[nissimsan]

Conversation to be had with the GS1 team.

[mgh128]

Even better if the examples actually leveraged the GS1 EPCIS / CBV 2.0 open standards instead of completely ignoring them.

EPCIS / CBV 2.0 provides a JSON-LD context at https://ref.gs1.org/standards/epcis/epcis-context.jsonld

The EPCIS / CBV 2.0 standards are published at https://ref.gs1.org/standards/epcis/ and https://ref.gs1.org/standards/cbv/ and have provided (since 2007) a GS1 open standard for interoperable exchange of event data for visibility and traceability, both across a supply chain / value network and within an organisation. This is already widely deployed in the food sector, healthcare sector and other sectors of industry.

EPCIS / CBV v2.0 (ratified and published in June 2022) added support for also reporting business-relevant sensor data within events, e.g. for temperature, humidity etc., as well as modernising the data format and interface, providing a JSON/JSON-LD data format and REST / OpenAPI interface, even though the previous XML data format and SOAP/WSDL interface remain valid within the standard. EPCIS / CBV v2.0 also added support for Web URIs (GS1 Digital Link URIs) as an alternative to EPC URNs, since Web URIs can resolve / redirect to multiple kinds of relevant information and services about the things they identify. More about GS1 Digital Link at https://ref.gs1.org/standards/#digital-link

Linked Data ontologies for EPCIS and CBV are provided at https://ref.gs1.org/standards/epcis/epcis-ontology.jsonld and https://ref.gs1.org/standards/epcis/cbv-ontology.jsonld and in browsable human-friendly format at https://ref.gs1.org/epcis/ and https://ref.gs1.org/cbv/

Example 4.23 ( https://w3c-ccg.github.io/traceability-vocab/#FSMACreatingCTECredential ) could have been based on an EPCIS ObjectEvent with "bizStep" : "commissioning"

Example 4.24 ( https://w3c-ccg.github.io/traceability-vocab/#FSMAFirstReceiverDataCredential ) could have been based on an EPCIS ObjectEvent with "bizStep" : "shipping"

Example 4.25 ( https://w3c-ccg.github.io/traceability-vocab/#FSMAGrowingCTECredential ) could have been based on an EPCIS ObjectEvent with "bizStep" : "commissioning"

Example 4.26 ( https://w3c-ccg.github.io/traceability-vocab/#FSMAReceivingCTECredential ) could have been based on an EPCIS ObjectEvent with "bizStep" : "receiving"

Example 4.27 ( https://w3c-ccg.github.io/traceability-vocab/#FSMAShippingCTECredential ) could have been based in an EPCIS ObjectEvent with "bizStep" : "shipping"

Example 4.28 ( https://w3c-ccg.github.io/traceability-vocab/#FSMATransformingCTECredential ) could have been based on an EPCIS TransformationEvent

Several EPCIS examples in JSON-LD are provided at https://ref.gs1.org/docs/epcis/examples and on GitHub at https://github.com/gs1/EPCIS

EPCIS event data typically focuses on the essential "What? Where? When? Why?" dimensions and does not overload the event data with associated master data fields. For example, by using a GS1 Digital Link URI based on a Global Location Number (GLN) for an organisation or location, it's possible to perform a simple Web request for the associated master data (e.g. specifying linkType=gs1:masterData in the URI query string), to retrieve the associated master data (expressed using schema.org and/or the GS1 Web Vocabulary) about address details, geolocation etc. only when needed, rather than embedding all of that master data in each event, which is clearly far more efficient when considering storage of large volumes of event data in repositories.

The Core Business Vocabulary (CBV) 2.0 standard defines standard code lists for populating EPCIS event data fields such as bizStep and disposition as well as recommendations for best practice ways of expressing identifiers for physical objects, locations etc.

[nissimsan]

Good input, @mgh128. I agree with your viewpoint on EPCIS alignment and would love to see PRs maturing this area.

I do think EPCIS alignment is orthogonal to this issue, though. @OR13 is discussing the structure of validating contexts with reference to https://ref.gs1.org/gs1/vc/data-model/

[mgh128]

By design, EPCIS is extensible and supports additional data fields from external namespaces defined outside of GS1, e.g. by industry sectors, solution providers, consortia or even by individual companies.

If these data fields are expressed as CURIEs or if their values require any data type casting (e.g. string to dateTimeStamp, string to URI etc.) then those extension fields will need a corresponding JSON-LD context resource to specify CURIE prefix expansions and data type casting that applies to the extension fields from that custom namespace.

Given this designed extensibility of EPCIS, I'd question whether there is any value in attempting to constrain the number of JSON-LD contexts that are declared or to only permit those that are expected to be present.

If the concern is that an unexpected additional context might over-write declarations defined in expected / standard JSON-LD contexts, then perhaps the solution is to ensure that those expected contexts are all well designed and use protected scopes for anything that should not be overwritten by an unexpected context for a custom namespace e.g. for an industry-specific extension or user extension.

The JSON-LD context for EPCIS at https://ref.gs1.org/standards/epcis/epcis-context.jsonld already makes extensive use of @protected to do exactly this.