1 of 15

GS1 License Credentials for Trading Partner Identity

POC Overview

IIW October 2021

2 of 15

Objective

Implement GS1 License Credentials�to provide digital verification of the authenticity of GS1 identifiers

Identify

Capture

Share

GS1 is on a mission to understand how W3C Verifiable Credentials and DID can augment our global trade identification system

GS1 is the largest global non profit with a missions to support identity, capture share for global trade. Identity represents our identification system where numbers are assigned to trade items, entities, locations, assets etc. Capture represents our standards designed for the machine captures if identifiers throughout the supply chain, including the barcodes on everyday products, but extending to RFID and other technologies to enable more reliable and efficient supply chains. Finally our mission to share is about creating the standards and services for parties in the supply chain to share trading data including product master data systems like GDSN and Verified by GS1 ,as well as standards like GS1 Digital Link, EPCIS and the GS1 Web vocabulary.

We learned through efforts in 2020 that GS1 does not need to change its current federated identifier architecture to take advantage of DIDs, VCs, and ToIP. Rather GS1 can add immediate value to its existing identifiers by implementing a layer of standardized cryptographic verification in the form of GS1 License Credentials and GS1 Identification Key Credentials.

This “trust layer” will enable all the participants in the GS1 Federation to combat fraud and counterfeiting because they can make cryptographically verifiable statements about products, entities, or relationships that are independently verifiable by any other party throughout the supply chain. And it will work with all types of GS1 identifiers without any modification to the identifiers themselves.

We want to thank this community for all their help and support during our learnings. We welcome the openness and sharing that goes on at events like this.

3 of 15

POC Development Overview

Expand learning in this area to build expertise required to create an enterprise architecture for a Digital GS1 License system.

To evaluate the technology to expand our internal understanding of maturity and compatibility.

To create and issue credentials to members engaging in Digital trust pilots. These members are looking for verifiable credential-based supply chain organizational identity.

Goals

3

4 of 15

Use VCs and GLN to establish a unique cryptographic identity between trading partners

VC Presentation

S A & E GLN

VC Presentation

Healthy Tots GLN

There are many ways DID and VCS can be applied to enhance digital trust in GS1 identifiers. Based on our feedback from members we chose to prototype the use of the GLN in supplier onboarding or TPRM.

Two companies doing business today exchange GLN identifiers that represent their respective corporate entity. Using VCs and the GS1 GLN identifiers, with this POC two companies can exchange these identifiers in a cryptographically verifiable way. At spring IIW we presented a proof of concept developed with Transmute to show two trading partners exchanging data using verifiable credentials. A short video is available to see our concepts.

Each party can prove they are talking to the entity identified by the GLN.

Each party can trace trust back to GS1 global office and prove that this entity is the licensee of the identifier.

This first, step would then allow these trading partners to exchange verifiable data about products, track and trace, and finance.

Functionality: Credential Issuance (VC) & Signature (DID), Credential Exchange, Wallet Functionality. Credential Presentation & Verification

Scale: This is an effort to understand tech and participate in limited pilots. Scalability requirements are minimal. Credential issuance of 100s during the lifetime of the pilot.
Security: It’s likely these credentials will be used in the pilot system. The pilot efforts are likely to persist for a year or more. Compromise of the credentials would create a large PR issue possibly derailing the tech evolution. It’s important that the issuance of credentials and the private keys are protected enough to endure this time frame and usage.

Commercialization: There are no requirements around commercialization at this time. Through sharing credentials with members we will help to uncover the value proposition and make recommendations for future commercialization. However, the understanding from this effort should enable our tech teams to develop (on paper) an architecture to roll out GS1 License issuing at global scale.

5 of 15

Verifiable Credential Chain for Parties

5

GS1 Prefix

Issuer is DID representing GS1 Global Office
Credential subject is DID representing GS1 Member Organisation
Provides proof of country Prefix license

GS1 Company Prefix

Issuer is DID representing GS1 Member Organisation
Credential subject is DID representing GS1 user company
Extends GS1 Prefix. Provides proof of GCP license

GS1 Key

Issuer is DID representing GS1 user company
Credential subject is GS1 Digital Link URI for GS1 location identifier GLN)
Extends GS1 Company Prefix. Provides proof company created GLN.

GS1 Party

Issuer is DID representing GS1 user company
Credential subject is another DID controlled by GS1 user company
Contains GLN. Provides proof that the company authorized this DID to represent this GLN

6 of 15

Verifiable Credential Chain for Identifiers

6

GS1 Prefix

Issuer is DID representing GS1 Global Office
Credential subject is DID representing GS1 Member Organisation
Provides proof of country Prefix license

GS1 Company Prefix

Issuer is DID representing GS1 Member Organisation
Credential subject is DID representing GS1 user company
Extends GS1 Prefix. Provides proof of GCP license

GS1 Key

Issuer is DID representing GS1 user company
Credential subject is GS1 Digital Link URI for GS1 identification key (e.g., GTIN)
Extends GS1 Company Prefix. Provides proof company created identifier.

GS1 Key Batch/Lot

Issuer is DID representing GS1 user company
Credential subject is GS1 Digital Link URI for key plus secondary key (e.g., GTIN + batch/lot)
Extends base GS1 Key. Provides proof of sub-identifier

The group spent considerable time understanding the building the credential data model. Specifically, the goal was to create a model that parallels the existing GS1 license system, provides consistent behaviors across the GS1 Identity system, and establishes cryptographic trust in identifiers, entities, and their data.

In the GS1 system a GS1 Global office manages the root of the identifier system licensing ”country prefixes” to the various country organizations.

Country organizations (called member orgs) are authorized to issue GS1 Company Prefixes to their members as long as these prefixes contain their assigned GS1 Prefix.

Member companies assigned GCP (GS1 Company Prefixes) are authorized to issued individual GS1 Keys such as GTIN, GLN, SSCC, GRAI etc… This Key credential uses a GS1 digital link as a subject (not a DID). This allows linkage to the universal resolver (or any resolver) and also ensure that companies can assert facts about trade items without requiring a DID for every product instance.

This chain forms the root of trusted product data where GCP owners can asserts facts about the product family or about individual serialized products or batches.

7 of 15

POC Flow

Presentation

GS1 Party

GS1 DID

Organization

GLN

Proof

GS1 GCP License

GS1 MO

Healthy Tots

GS1 Comp. Pref

PROOF

GS1 GCP License

GS1 MO

SA & E DID

GS1 Comp. Pref

PROOF

MO

GS1 Prefix License

GS1 Global Off.

GS MO

GS1 Prefix

PROOF

GS1 Prefix License

GS1 Global Off.

GS1 MO

GS1 Prefix

PROOF

Subject

Claim

Issuer

Cred Proof

Pres Proof

MO

8 of 15

Global Office Implementation

8

9 of 15

GS1 US SVIP Implementation

9

10 of 15

GS1 Germany Indy Implementation

10

11 of 15

Findings

Credential Model Standards/Products Ecosystem Compatibility

11

W3C

Indy

GS1 Prefix License

GS1 Company Prefix License

GS1 Key Credential

GS1 Party Credential

Our findings were grouped into three areas.

The GS1 license system is complex and thus has a complex credential license model. This was often difficult even for the GS1 POC team both in understanding and in grouping credentials for presentation and validation. We have more work to do here to explain, and provide libraries and guidance around this credential model.

We were unable to do any cross ecosystem validation with W3C and Indy. Even within these ecosystem we found incompatibilities. SVIP includes wallets Indy network don’t interoperate well across ledgers today.

Finally, we found that many standards are either immature or incomplete or not generalized across ecosystem. For example, the query language to ask a wallet for a credential for a specific company prefix. Or a standard to properly display credentials in Uis.

12 of 15

Key Challenges in SVIP – Standards & Learning

Significant ramp up time for new developers

Lots of interrelated specifications to learn
Limited number of real world examples and mature libraries
SVIP and Indy Hyperledger present different approaches & technologies

Revocation

Revocation List 2020 (Draft)
Bit masking approach adds additional complexity for issuing credentials
Significant overhead for managing multiple revocation lists
On the surface feels like it breaks the decentralized approach of DID/VCs

12

13 of 15

Key Challenges in SVIP – Web Wallets

CHAPI Specification are still in the early stages

Credential Handler API 1.0 (Draft)
Verifiable Presentation Request (Draft)

Limited number of working web wallets, even the ones that worked required some level of customization to support GS1 credentials.
Enterprise Company Based DID Support

Mobile and Web Wallet ecosystem seems geared towards B2C vs B2B
We will Enterprise Level DIDs need to be available to issue credentials
Security for Enterprise Level Wallets, who can access them, how will credential be shared to outside parties, etc.

13

14 of 15

Key Challenges in SVIP – Verifiable Credentials

Most examples show simple credentials issued by one party
Complex Hierarchical Credentials

No standard way to associate related credentials
Multiple parties issuing related credentials require coordination
Trust Verification requires custom business logic and code
Credentials have to be presented together or be resolvable

Dependency Management

Both issuing and verifying process rely on a number of standard JSON-LD, DID Documents, Custom JSON-LD, Revocation Lists etc.
Caching a subset of these are required to performance and security, but not all required documents can be cached effectively

14

15 of 15

Key Challenges in SVIP – Interoperability

We looked at two different eco-systems SVIP and Indy Hyperledger
Both presented different learning challenges and technical solutions
Interoperability

There is no clear path moving forward how interoperability will work between these ecosystem without building a custom solution
Out of the box there is no interoperability across different Indy Ledgers

15