gs1 / vc-data-model Goto Github PK

In the context of the COPPA project, signing EPCIS data will become an important pillar. We currently use the EPCIS 2.0 context for the data fields, but a CredentialType (e.g. EPCISDocumentCredential) is still needed and we assume it not possible to be added to the EPCIS 2.0 context, as it can be considered finalized. Futher, a such credential type may fit much better in the GS1 vc-data-model than in the EPCIS context.

If your feedback is positive, i will transform this into a PR.

W3C sets the credential ID as optional in their 1.0 data model the credential ID (all IDs) are optional. I believe our extends mechanism requires that all GS1 credentials contain a credential ID. I could not find a statement in the document clarifying this requirements.

Can we confirm whether credential ID is a required field in all GS1 credentials and update the document to make this clear.

Signing a GS1PrefixLicenseCredential with the context on https://ref.gs1.org/gs1/vc/licence-context/ results in a JSON-LD SafeModeWarning, which results in not being able to sign the credential.

 2023-05-12T10:11:06.980Z [error] jsonld.ValidationError: Safe mode validation error.
     at safeEventHandler (/usr/src/app/node_modules/jsonld/lib/events.js:133:11)
     at _handle (/usr/src/app/node_modules/jsonld/lib/events.js:82:7)
     at api.handleEvent (/usr/src/app/node_modules/jsonld/lib/events.js:71:3)
     at /usr/src/app/node_modules/jsonld/lib/expand.js:619:17
     at Array.map (<anonymous>)
     at _expandObject (/usr/src/app/node_modules/jsonld/lib/expand.js:612:25)
     at processTicksAndRejections (node:internal/process/task_queues:96:5)
     at async api.expand (/usr/src/app/node_modules/jsonld/lib/expand.js:251:3)
     at async Function.jsonld.expand (/usr/src/app/node_modules/jsonld/lib/jsonld.js:321:18)
     at async Function.jsonld.toRDF (/usr/src/app/node_modules/jsonld/lib/jsonld.js:680:16)
 2023-05-12T10:11:06.980Z [error] Error details:
 {
   "event": {
     "type": [
       "JsonLdEvent"
     ],
     "code": "relative @type reference",
     "level": "warning",
     "message": "Relative @type reference found.",
     "details": {
       "type": "GS1PrefixLicenseCredential"
     }
   }
 }

The error origins from here https://github.com/digitalbazaar/jsonld.js/blob/main/lib/expand.js#L617

Not sure what exactly causes the error, but i will investigate further.

The name property in the PartyDataCredential example requires an additional schema context. Is name a required property for a PartyDataCredential?

"@context": [ { "name": "https://schema.org/name" } ]

In the sample GS1 Credentials there are a couple out of date credentials type references.

VerifiedByGS1DataCredential is used in the Verified By GS1 Data Credential sample. This type does not exist in any of the GS1 JSON-LD files. There is a GS1VerifiedByGS1TradeItemDataCredential type in the trade item context.

DelegationCredential is used in the Delegation Credential sample. This type does not exist in any of the GS1 JSON-LD files. There is a GS1DelegationCredential type in the Declaration Context.

All the GS1 Credential Types start with GS1 accept PartyDataCredential. Is there a reason why this credential types does not start with GS1?

https://ref.gs1.org/gs1/vc/planogram-context/

is 404 in https://ref.gs1.org/gs1/vc/data-model/

  {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://ref.gs1.org/gs1/vc/planogram-context/", // we are expecting this to resolve
      "https://w3id.org/vc/status-list/2021/v1"
    ],
    "id": "did:example:7b993cf5-379e-470e-9575-6f9fe75ab03b",
    "type": [
      "VerifiableCredential",
      "GS1PlanogramDataCredential"
    ],
    "issuer": "did:key:z6MktHQo3fRRohk44dsbE76CuiTpBmyMWq2VVjvV6aBSeE3U",
    "issuanceDate": "2020-12-03T03:14:59Z",
    "credentialSubject": {
      "id": "https://id.gs1.org/01/07541234555551",
      "keyAuthorisation": "did:example:a60d21a8-485b-4f28-8510-c9b64325bab5",
      "dataCertification": [
        "https://www.gs1ca.org/credentials/certification/534a928a-704c-41b6-9e47-aee0a756fb79"
      ],
      "length": "24",
      "lengthUOM": "cm"
    },
    "credentialStatus": {
      "id": "https://www.egsolutionprovider.ca/status/7b993cf5-379e-470e-9575-6f9fe75ab03b",
      "type": "CredentialStatusList2021"
    },
    "proof": {...}
  }

Looking for clarity between the VerifiedByGS1DataCredential and GS1DataCredential. Both credential have the same fields.

• What use cases would a VerifiedByGS1DataCredential be used instead of a GS1DataCredential?
• Who can issue VerifiedByGS1DataCredential?

Do I need to fetch this every time I verify, or can I cache the Status lists daily/weekly/monthly basis?

This came up in a discussion on the GS1 prefix credentials. Its likely large trade organizations would cache these as there is a limited set. The credentials themselves don't have any expiration, so there is no guidance within them how often to look for new ones. GS1 intended this as nearly all prefixes licenses are renewed, and expirations would disrupt the supply chain. So these large orgs would likely need to check the expiration of these credentials periodically, as it might be prohibitive to check with every verification.

From the perspective of how quickly these things change, I think daily would be much more than sufficient, with something 72 hours being conservative.

Traceability vocab is starting the migration to VCDM 2.0. Do we want to consider a migration to support our credentials in this new 2.0 format? The benefit to doing this now is that we could identify any issues with the new data model that might affect our credentials before it gets to an approved standard.

I believe we have to consider the following (not sure this is exhaustive, but the things that were identified)

1. issuanceDate is not in the 2.0 model. Its validFrom
2. Data integrity proofs are contained in a new format
3. VC-JWT

https://www.gs1.org/standards/gs1-product-image-specification-standard/current-standard#1-Introduction+1-2-Determining-the-front-face

can you add the example here?

GS1DataCredential is defined in https://ref.gs1.org/gs1/vc/declaration-context/, but the example (in section 5.6.1) only includes https://ref.gs1.org/gs1/vc/trade-item-context/ (which defines all the rest of the terms).

For GS1DataCredential to be defined, either:

• include it in https://ref.gs1.org/gs1/vc/trade-item-context/
• or include both contexts on the example

Example of the latter option: https://w3id.org/traceability/#GS1DataCredential

GS1KeyCredential has the same issue, the term isn't actually defined in the example (section 5.5.1).