Add EPCIS Document/Event Credential to VC-Data-Model

[F-Node-Karlsruhe]

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.

[F-Node-Karlsruhe]

Learning from TigerTeam 09/05/23:

An EPCISDocumentCredential does not fall into the category of a GS1DataCredential but GS1PrefixLicenceCredential with the focus on the GLN being an important verifiable information for an EPCIS Event.

Nevertheless a new credential type like EPCISDocumentCredential is needed.

Information on VC-DataModel2.0: Linking properties will be possible allowing any object to become a VC (e.g. eventId -> subject.id) as it is done for VC-JWT

[Echsecutor]

This is related to https://github.com/gs1/VC-Data-Model/pull/10

[Echsecutor]

@F-Node-Karlsruhe discussion with Kevin today: Most likely, the EPCIS VC is not of any type of those in the current Document

[KDean-GS1]

The existing data model is focused primarily on proof of identification, with the VC chain starting at GS1 Global Office and going down to the KeyCredential through one or more License credentials. Data about the object can then be declared via a derived class of DataCredential.

EPCIS doesn't fit into the existing model, for two reasons. First, the data is not about the object per se, but about the state, or change in state, of the object as it moves through the supply chain. Second, there's no explicitly declared chain of credentials that can be used to authorize a party to declare an EPCIS event.

What we can talk about instead is the level of confidence in the credential, depending on the specific business needs.

A party presenting a set of EPCIS events as a VC can also present VCs from the existing data model to establish their identity (OrganizationDataCredential -> KeyCredential -> GS1CompanyPrefixLicenseCredential -> GS1PrefixLicenseCredential). This doesn't prove that the party has the right to handle the trade items within the events, but it does establish their identity within the GS1 ecosystem.

The party can also present a set of KeyCredentials proving the validity of the GLNs within the EPCIS events.

Similarly, the first party in the chain can present a set of KeyCredentials providing the validity of the GTINs within the EPCIS events. If the first party is a contract manufacturer, they can present a set of AuthorizationCredentials instead.

To prove that the party has the right to handle the trade items within the events, you would have to collect all the upstream events and follow the object through the supply chain. So, to prove that party D is authorized to handle a trade item, you would need the VCs from parties A, B, and C showing the movement to party D.

There is more that we can do, but wrapping EPCIS events into VCs will have to go through GSMP to ensure that we cover the needs of the community properly.

[mgh128]

Somewhat related to this, we developed some ideas (https://gs1.github.io/EndToEndTraceability/GS1-WhitePaper-VerifiableCredentials-EPCIS-end-to-end-traceability.pdf) about how a set of EPCIS event data could be transformed into a proof-of-connectedness that is intended not to leak commercially sensitive business intelligence but could be used as one factor in an access control decision about whether or not to grant access to a requesting party based on their ability to prove connectedness for the specific objects they mention in their query. The draft white paper above also includes discussion of a chain navigation algorithm that could be automated. All of this is exploratory work, ahead of any formal GS1 standardisation effort in this area - but it might be of interest to this group.