Traceability Vocabulary v0.1

Introduction

This specification is designed to enable global supply chain stakeholders to benefit from emerging technological web standards like the Verifiable Credential (VC) Data Model, Linked Data (i.e. JSON-LD), and the Decentralized Identifier (DID) Spec. This specification is relevant to prevalent supply chains but also allows for other use cases across a variety of market segments. The corresponding data exchange schemas are modeled for Verifiable Credentials, which is a standard for cryptographically signing business data. Schema semantics are precisely defined by use of Linked Data which leverage established vocabularies such as schema.org, GS1, and UN/CEFACT.

Supply Chain Digitization Challenges

While digitization has revolutionized other industries with decades of value, supply chain industries have been slow and fragmented in their digital transformation journey. The sheer number and variety of supply chain actors makes technological advances incredibly difficult. For example, physical paper, manual processing, and outdated technologies still support the vast majority of supply chain information flows. Paper processing costs the supply chain industry upwards of $3 billion every year (not counting the additional costs of paper, ink, and printing) (see "When Will Supply Chains Finally Move on From Paper?"). The resulting data silos and blind spots throughout the supply chain have created a crisis that enterprises and regulators can no longer ignore. This problem is made worse by the coordination challenges inherent in increasingly global supply chains.

As long as semantic standards depend on manual adoption and complex implementations, the impacts of these investments are limited and delayed. Semantic standards and code lists are being rigorously managed by various standards organizations. However, language barriers and differing contexts between standards is a major source of imprecision and errors. The fragmentary environment around different standard types, applications, and governing bodies only adds to the complexity involved in adoption and integration of standards.

The identity of supply chain actors is another problem resulting in costs and errors. While nations and platforms have established digital identity regimes within their boundaries, no useful global identity scheme has emerged or been adopted. Public policy, borders, and commercial obstacles create large barriers for a global centralized model to be adopted. The result is that most businesses need to invest heavily in IT infrastructure and middleware data mapping tools to be integrated with their trading partners. In fact, digitizing a major supply chain will cost tens of millions of dollars at the current pace and will be a 3-to-5 year transformation effort in the future (see "A Simpler Way to Modernize Your Supply Chain"). Today, most enterprises only have 20% visibility into their supply chains when they need about 70% to 90% visibility to properly monitor their investments (see "In 2020, Supply-Chain Digitization Is No Longer Optional"). This means a heavy investment of capital is required to achieve this visibility, which results in de-facto vendor software lock-in.

Technology Enablement

Establishing Trust

Trust and efficiency are fundamental to supply chains and global trade. Supply chains are a network of economically connected and collaborative stakeholders that includes shippers, carriers, importers, regulators, and other key actors. Traditionally, trust is established in the supply chain by analogue signed contracts, physical meetings, phone calls, faxes, and regular audits that prove credibility of the engaging parties and compliance with relevant regulation. Digitization efforts in the sphere of “contractual trust” have been limited by challenges like altering digital data such as PDFs, which is both easy to do and difficult to detect. Some noteworthy steps have been taken to address this such as encrypted communication channels like HTTP-over-TLS (a/k/a HTTPS) and commercial digital signature platforms (i.e. Docusign). However, a trusted channel does not prevent data alteration by either party and globally scaling a proprietary platform is expensive and comes with political and practical implications.

This landscape has changed with the advent of the VC standard. This standard makes digital contractual trust accessible and affordable for anyone on the planet. VCs work by applying existing cryptographic standards (particularly modern curve-based digital signature algorithms) to business data that is typically exchanged over APIs or XML. The VC specification provides a data model for how data paired with a cryptographic signature should be represented in a data file. The data itself can be anything; it can describe a shipment, an organization, a product, an agreement, etc. The cryptographic signature ensures that anyone with the VC can verify that the data is how the issuer intended it to be. In other words, the VC standard enables the use of cryptographic standards and provides the verifier a sense of trust when presented with the data file from the issuer. The implications of this technology for global supply chains are far-reaching.

However, there remains a great deal of untapped potential from VCs. Trust can be established remotely and fully automated provided that suitable claims are presented and issued by a trustworthy third party such as an existing business partner, a commercial agent, or a government. "Chains of trust" can be established by linking back through relevant claims to a known trust anchor. As you can see, VCs have a great deal of potential in the future of supply chain technology.

Linked Semantics

Supply chain organizations use different words to say the same thing. For example, “Shipper” and “Consignor” are used interchangeably in shipping. Ensuring precise communication across supply chain participants given these varying vocabularies is challenging. For example, standards bodies govern semantic models with term definitions, APIs for common use cases, and code lists in an attempt to avoid ambiguity. The traditional challenge for these technical publications has been the human element: reading the spec, interpreting the API attribute name, or skimming through the code lists. This labor is required because the data sender and the data receiver have to establish the same understanding. This results in effort and IT costs for both the sender and receiver to ensure they’re communicating unambiguously.

Linked Data addresses this problem by letting computers establish semantic meaning. Leveraging how the web works, Linked Data explicitly ties terms to a precise Uniform Resource Identifier (URI). Much like a URL pointing at a specific website, a URI defines a specific term. Thus, when the data sender defines a term by pointing at a URI, no interpretation is needed and a computer can automatically understand it. Beyond the obvious benefit of establishing shared understanding, integrating Linked Data is simpler and more cost-effective than data interpretation and mapping.

Linked Data is not new. It drives internet indexing and search engines. This traceability-vocab specification simply introduces this technology for use in the supply chain industry. All of the schemas which define the data content of Verifiable Credentials are constructed with explicit pointers to the most relevant URIs of the terms used. Existing term definitions, which are available in online vocabularies, can be used to construct the Verifiable Credential schemas.

Global Identification Scheme

A final important part of modernizing the digital supply chain is targeting the problem of identification. The difficulty of scaling centralized solutions has led to the emergence of Decentralized Identifiers (DIDs). DIDs rely on cryptography to prove that you are in control of a given identity. A variety of different types of DIDs exist and apply to different use-cases, like short-term DIDs or long-term, enterprise, security-grade DIDs. A DID is trustless, meaning that anyone can make and control a DID at any time. The value and credibility of a DID comes from its relationship with credentials that are tied to it. These credentials are typically issued by third-party organizations and/or governments.

While the identification of supply chain parties is a major identity problem, DIDs also provide value in other contexts. DIDs can be used to represent products, shipments, contractual agreements, or anything else in the supply chain that would benefit from the properties of DIDs. When paired with DIDs representing supply chain actors, DIDs that represent supply chain products or shipments stand to offer an ever more granular snapshot of the supply chain.

Note that the traceability-vocab's use of Decentralized Identifiers is limited to example uses. Traditional means of identification can also be used, but use of DIDs is encouraged to ensure that actual control of an identity can be proven.

Technology Summary

This section describes the emerging technology standards of Verifiable Credentials, Linked Data, and Decentralized Identifiers with a real-world supply chain use case.

The Commercial Invoice is a critical supply chain document that is essential to Customs who use it for duty determination and other tasks. This document includes data such as the description of the goods, where the goods are being shipped to and from, and the value of the goods. This document is supplied by the shipper.

The Commercial Invoice document is typically exchanged via PDF, email, or EDI. With the use of Verifiable Credential technology, we are able to digitize a Commercial Invoice into a verifiable Commercial Invoice credential. Each data point on the Commercial Invoice VC is mapped to a semantic model for common definition using Linked Data. For example, the “Consignee” field or the “Shipper” field on the Commercial Invoice are defined unambiguously to precise URIs. This promotes a singular, common definition of the data labels so that organizations have a shared understanding.

In addition, certain data points on the Commercial Invoice are used to identify an organization. For example, the “Consignee” field identifies the receiver of the goods and the “Shipper” field identifies the shipper of the goods. In this example, both the consignee and shipper would be organizations. Using a Decentralized Identifier (DID), for example, the consignee organization can self-authenticate as the receiver of the goods.

The Shipper’s Decentralized Identifier is included as the Verifiable Credential issuer, binding the claims on the Commercial Invoice back to the Shipper. Cryptographic traceability of the Commercial Invoice is thus established from the Shipper to the Consignee. Anyone presented with the Commercial Invoice can verify that it originates from the Shipper and is targeted to the Consignee.

This example portrays a specific use case with a Commercial Invoice and shows how Verifiable Credentials, Linked Data, and Decentralized Identifiers apply. We apply these technologies to common trade documents to further digitize documents and promote trust throughout the entire supply chain.

Structure

Generally, this vocabulary may be looked at as a set of common objects that are shared across multiple business verticals, and vertical or use case specific items that apply to one or more specific commodities or market segments. A primary goal of this specification is to standardize the creation of Verifiable Credentials from standardized JSON-LD which is itself created from JSON Schema definitions as would normally be passed of REST and other APIs. This promotes code re-use and establishes a pattern for the creation of JSON-LD and related Verifiable Credentials derived from those JSON-LD objects in a manner that is friendly to code and API development as well as to promote better interoperability between vendors who serve common or related markets.

The Vocabulary section covers each vocabulary item, its properties, other attributes, and provides and example Verifiable Credential for each item.

This repository has primary contributors from four main market segments, and has subject matter experts from those market segments delegated as leads for objects related to vocabulary items for each segment.
These subject matter leads help identify common elements across verticals as well as in assessing contributions of new objects to the vocabulary.

Market Segment	Subject Matter Expert	Contact
Agriculture	Michael Prorock	mprorock@mesur.io
E-Commerce	Nis Jespersen	nis@transmute.industries
Oil and Gas	Mahmoud Alkhraishi	mahmoud@mavennet.com
Software Supply Chain	Benjamin Collins	benjamin@transmute.industries
Steel and Metals	Orie Steele	orie@transmute.industries

Vocabulary Linkage

The traceability-vocab ensures that coherent sets of use case-specific schemas, blended together with corresponding resolvable @context data, point all the schemas' terms to their defining URIs. These URIs will generally point at existing, established vocabularies. Only when no applicable vocabularies can be found are terms defined as part of the traceability-vocab spec; these are considered exceptional cases.

In determining the most applicable vocabulary for a particular term, the most generic and widely adopted vocabulary is chosen. For example, a common term defined in schema.org will be chosen over a similar term defined in a industry-specific vocabulary. This is to ensure the broadest possible interoperability, within and beyond supply chain.

Open API

This vocabulary can also be viewed as an Open API Specification.

See w3id.org/traceability/interoperability for REST API and interoperability tests associated with this vocabulary.

Undefined Terms

This vocabulary uses '@vocab': 'https://www.w3.org/ns/credentials/issuer-dependent#' to disable JSON-LD related errors associated with Verifiable Credentials, issued about terms that have not yet been added here.

Issuers are advised to review the JSON-LD and all associated terms before issuing verifiable credentials.

Terminology

The following terms are used to describe concepts in this specification.

entity: A thing with distinct and independent existence, such as a person, organization, or device, that performs one or more roles in the ecosystem.
user agent: A program, such as a browser or other Web client, that mediates the communication between the various roles in this specification.
URI: An identifier as defined by [[RFC3986]].

Extensions to Standard

Verifiable Credential

The object MUST conform to the basic requirements section of the W3C VC Data Model.

The @context MUST contain "https://w3id.org/traceability/v1".

The object MUST have an id property, and its value MUST be a valid IRI (URI, URN).

Verifiable Presentation

The object MUST conform to the basic requirements section of the W3C VC Data Model.

The @context MUST contain "https://w3id.org/traceability/v1".

The object MUST have an id property, and its value MUST be a valid IRI (URI, URN).

Workflow Definition

The sequence of industrial, administrative, or other processes through which a piece of work passes from initiation to completion.

In the context of this vocabulary, we consider the specifics of workflows out of scope. We acknowledge that different use cases may have complicated workflows, which may yield many individual presentations of credentials.

There are several systems for workflow definitions. See BPMN, YAWL, and/or GitHub Workflows.

We enable the grouping of all presentations related to a definition, using the convention:

                {
                  "@context": [
                    "https://www.w3.org/2018/credentials/v1",
                    "https://w3id.org/traceability/v1"
                  ],
                  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
                  "type":
                  [
                    "VerifiablePresentation",
                    "TraceablePresentation"
                  ],
                  "workflow": {
                    // This refers to a Workflow Definition
                    "definition": [
                      "urn:uuid:n1552885-cc91-4bb3-91f1-5466a0be084e" 
                    ],
                    "instance": [
                      "urn:uuid:f5fb6ce4-b0b1-41b8-89b0-331ni58b7ee0"
                    ],
                  },
                  "holder":{
                    "id":"did:web:sender.example",
                    "type":"Organization",
                    "location":{
                       "type":"Place",
                       "geo":{
                          "type":"GeoCoordinates",
                          "latitude":"68.7083",
                          "longitude":"4.6377"
                       },
                       "address":{
                          "type":"PostalAddress",
                          "organizationName":"Ratke - Bergstrom",
                          "streetAddress":"21851 Ima Heights",
                          "addressLocality":"O'Connellborough",
                          "addressRegion":"Missouri",
                          "postalCode":"65587",
                          "addressCountry":"Cyprus"
                       }
                    }
                 }
                }

Workflow Instance

Each defined workflow may be executed many times for different sets of inputs and among different stakeholders.

We refer to Workflow Instance's as an execution of a particular workflow, which may or may not be formally defined.

An example of a workflow definition is US Customs ACE Entry Summary Process. Where specific instances are used to track cross border imports, it is important to be able to identify specific collections of documents associated with a given import. Workflow instances help achieve this by providing a topic identifier enabling the grouping of related credentials and presentations.

We enable the grouping of all presentations related to an instance, using the convention:

                {
                  "@context": [
                    "https://www.w3.org/2018/credentials/v1",
                    "https://w3id.org/traceability/v1"
                  ],
                  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
                  "type":
                  [
                    "VerifiablePresentation",
                    "TraceablePresentation"
                  ],
                  "workflow": {
                    "definition": [
                      "urn:uuid:n1552885-cc91-4bb3-91f1-5466a0be084e"
                    ],
                    // This refers to a Workflow Instance
                    "instance": [
                      "urn:uuid:f5fb6ce4-b0b1-41b8-89b0-331ni58b7ee0"
                    ]
                  },
                  "holder":{
                    "id":"did:web:sender.example",
                    "type":"Organization",
                    "location":{
                       "type":"Place",
                       "geo":{
                          "type":"GeoCoordinates",
                          "latitude":"68.7083",
                          "longitude":"4.6377"
                       },
                       "address":{
                          "type":"PostalAddress",
                          "organizationName":"Ratke - Bergstrom",
                          "streetAddress":"21851 Ima Heights",
                          "addressLocality":"O'Connellborough",
                          "addressRegion":"Missouri",
                          "postalCode":"65587",
                          "addressCountry":"Cyprus"
                       }
                    }
                 }
                }

Use Cases

The following use cases outline a number of key scenarios that readers might find useful in a variety of sectors, especially those that deal with cross border supply chain data interchange.

Steel and Metals

The global steel industry relies on cross-party communication of product and business information to successfully move materials from mines, to manufacturers, through customs, to end customers (such as automotive and construction companies). Today this information exists primarily in siloed paper documents. In the current format it is very difficult to make data comparisons across a small number of parties, let alone across millions of shipments over time. It can also be difficult to catch forged documents in the absence of digital signatures and clearly defined organization data attributes.

A shared vocabulary creates opportunities for steel trading partners to work from a common digital representation of trade information. Take the example of a mill report for a steel product. This document provides important information about the chemical make-up of steel materials, helping to ensure the desired specification and grade have been met. It also acts as evidence about the origins of steel materials. Unambiguous representation of mill report fields is critical for assessing appropriate duties, meeting customer requirements, and ultimately ensuring consumer safely.

By defining the schema for each field, importers can now answer questions like “How many pipes of specification XYZ did we purchase last year?” (i.e., ChemicalProperty). The mill report can also be linked to other trade documentation such as commercial invoices and bills of lading when those credentials are specified and defined. Regulators can also ask questions across a large number of mill reports to help catch transshipment issues, such as “How much steel product imported last month specified Vietnam as the country of origin?” (i.e., addressCountry).

Mill Test Certification

Steel Inspection Agency issues a Mill Test Report (1) for the Steel Manufacturer, which gets presented (2) and verifies the Mill Test Report (3).

Steel Manufacturer issues a Commercial Invoice as part of a sales transaction and an Intent To Import to initiate the import (4). The documents are presented to the customer, Steel Importer (5), which can verify the originality of both documents, respectively tracing the Commercial Invoice back to the Manufacturer (6) and the Mill Test Report back to a trusted steel certifying agent (7).

SIMA Steel License

SIMA License Workflow — SIMA Steel License Workflow

Steel Inc applies for a SIMA Licence, issuing (1) and presenting a SIMA Steel License Application to SIMA (2).

Steel Import Monitoring and Analysis verifies (3) and processes Steel Inc’s application, issues a SIMA Steel License (4) which is presented back to Steel Inc. (5).

At time of import, Steel Inc. issues an Intent To Import and a 7501 Entry Summary (6) which are presented to CBP together with the SIMA License (7).

CBP Verifies that the SIMA Certificate originates from the SIMA issuer (8) and that the certified organization match the issuer of the import credentials (9).

Steel Import Under USMCA Free Trade Agreement

Steel Importer issues a USCMA Certificate of Origin (1). Initiating the importing workflow, Steel Importer also issues an Intent To Import (2).

Steel Importer presents the USMCA Certificate of Origin and Intent To Import along with a Mill Test Report to Customs (3).

Customs verifies the USMCA Certification of Origin (4), cross checks HTS codes with the Mill Test Report (5), and initiates the import procedures (6).

Steel Import Customs Brokerage

Steel Importer issues Commercial Invoice (1) and Packing List (2) in relation to a shipment of steel. These are presented to the Customs Broker along with a SIMA License, a USMCA Declaration, a Mill Test Report, and a CTPAT Importer Certificate.

The Customs Broker issues a 3461 Immediate Delivery Certificate (3) and an Intent To Import (4), and has received the Bill of Lading from the carrier.

The full pouch of documents are presented to Customs (5) for verification (6) and import processing.

Food and Agriculture

Several use cases exist for common vocabulary in the food and agriculture space. Key priorities for this project revolve around items that are required for the safe and succesful importation of food to various countries.

The top level AgInspectionReport object has been created as a parent object that allows for the recording of the following inspections and audits, while giving flexibility to account for newly defined inspction types as needs change in the food and agricultre industry. This object can be sub-classed to allow for schema level validation of specific types of inspections and audits as required by the specifics of a given use case. Verifiable Credentials can be issued for this object or sub classes of this object to allow for external verification by third parties that are implementing the Verifiable Credentials sepcification

Farm GAP Inspection Report: Keep track of Good Agricultural Practices (GAP) audits and share results with a vendor
FSMA Inspection: Food Safety Modernization Act inspections and results for sharing with relevant parties, regulatory bodies and vendors.
Foreign Site Certificate of Inspection and/or Treatment: USDA APHIS PPQ FORM 203 that is required for pre-clearance of imported food and ag goods into the US

Oil and Gas

A common traceability vocabulary will enable creation of a common digital representation of an oil and gas assets and a variety of use cases. The main priority of this project is the border clearance and regulatory compliance use cases, that enable industry players to rely on the asset history, origin, and composition recorded as Verifiable credentials to be used in these processes.

The asset-specific CrudeOil VC (and NaturalGas VC) object serves as a root object that stores the key attributes of the asset as well as origin and composition. In addition to the asset VC, we are planning to represent key events in the asset’s lifecycle (inspection, transportation, transfer of ownership) as Verifiable Credentials.

E-Commerce

A common traceability vocabulary will allow complex supply chains that import goods to US-resident customers to register individual packages and pre-register products intended for sale to the US with US Customs. For the data needs of Customs to be met by highly heterogenous supply chains that might require much "internal confidentiality" (between supply chain actors), a highly sharded data model is required, whereby many different actors can each submit data points separately that get combined at time of customs processing.

Without strong identification of legal entities (i.e., legally defined and registered supply chain actors) and of products, and without high levels of semantic flexibility, the shards can be quite hard to combine usefully. Linking the registration of individual packages together with the pre-registration of commercial products and actors is the key value-add of this system, but could also be a burdensome request on importers, retailers, and freight forwarders. To minimize this burden, we are aligning wherever possible with the ontology work of GS1 (GTINs and vLEIs), and with shipping and tracking semantics already adopted today by international logistics consortia. We distinguish between the VCs that are issued in relation to a specific package and the contextual information that needs to be queried to validate package information, as well as to make valuable assessments, inferences, and data quality remediation on Customs pre-entry data.

CTPAT Ecommerce Incentive Program Marketplace Registration

Ecommerce Marketplace CTPAT EIP Certification workflow. Registration is mandatory for subsequent benefits, including pre-processing of shipments and issuance of CTPAT EIP Certificate.

Ecommerce Marketplace Registration Workflow

Mandatory Input

CTPAT EIP Application: Issuer: Applicant Marketplace; Credential Subject: Applicant Marketplace
Verifiable Business Card: Issuer: Applicant Marketplace; Credential Subject: Applicant Marketplace

Optional Input

AEO Certificates such as CTPAT Certificate: Issuer: CTPAT; Credential Subject: Applicant Marketplace
Other Organizational Evidence: Issuer: Relevant Issuer; Credential Subject: Applicant Marketplace

Output

Marketplace CTPAT EIP Certificate: CTPAT Ecommerce Incentive Program Marketplace Credential; Issuer: CTPAT EIP; Credential Subject: Applicant Marketplace

De Minimis Shipment

As part of an international ecommerce sale, the Ecommerce platform issues a De Minimis Shipment Certificate (1) indicating exemption from importing duties. An Intent To Import is also issued (2) to initiate the import workflow (3).

Customs verifies both (4) and (5) and allows the shipment "direct pass" through customs.

Packing and Shipping

A purchase is made on a US eCommerce platform, triggering issuance of a Purchase Order (1), which is passed to the foreign fulfillment center (2).

Receiving and verifying the Purchase Order, the fulfillment center organizes shipping with an international carrier, issuing (4) and presenting Shipping Instructions (5).

Upon shipping, the Fulfillment Center issues a Packing List (7), presented to the courier (8). The courier verifies the Shipping Instructions (6) and prepares for shipping.

The carrier verifies the Packing List (9) and automatically correlates it to the shipment through the common workflow instance id.

Importing Procedures

Express Carrier issues a House Bill of Lading (1), which is presented to the Customs Broker along with other documents associated with the Packing List (2).

The Customs Broker issues 3461 Immediate Delivery (3) and Intent To Import (4) certificates. The documents are submitted to Customs through a Traceable Presentation with a defined workflow instance id such as “a123-b456” (5).

Customs verifies the pouch of documents associated with the shipment (6) and initiates importing procedures based on submitted data (7).

Import Completion

The Customs Broker completes the importing procedures by issuing the 7501 Entry Summary (1), presenting it to Customs (2), and associating it with the earlier submission by correlating the workflow instance id ("a123-b456").

Customs verifies the Entry Summary (3) and completes the importing assessment.

Trusted Trader Program

CTPAT runs vetting procedures, and issues and presents to the Importer (2) a CTPAT Certificate (1).

Upon importing goods, the Importer issues a 7501 Entry Summary (4) and an Intent To Import (5), which are presented to CBP (6) along with the CTPAT Certificate.

Freight Forwarder Consignment

This workflow demonstrates how separate workflows graphs may be joined by use of the instance id array.

The product importer of record issues Proforma Invoice (1) and Intent To Import (2) credentials which are presented to CBP (3) with instance id [inst_1] well ahead of shipping.

CBP verifies the initial import documentation submitted by the Importer (4).

Upon shipping, the Freight Forwarder issues a House BL (5) which is presented to CBP (6) with a separate instance id [inst_2].

The Importer issues the final Commercial Invoice (8) which is presented to the Freight Forwarder (9) also with instance id [inst_1]. Passing on the Commercial Invoice, the Freight Forwarder includes both its own and the Importer’s instance ids [inst_1, inst_2], indicating to Customs that the workflows are related.

Receiving the Commercial Invoice (10), CBP can also join the two graphs, thus knowing that the original Proforma Invoice relates to the Freight Forwarder’s presentations.

Product Identifier Verification from Company Prefix License

Workflow for proving control over a GS1 Company Prefix, identification of a product, and makes data assertions about the product.

A GS1 Member Organization issues GS1 Company Prefix Licence Credential (1), which is presented to the GS1 User Company (2).

The GS1 User Company issues GS1 Key Credential (3) for GTIN identification of a product.

The GS1 User Company associates product data by issuing a GS1 Data Credential (4) about the identified product.

The GS1 User Company presents License, Key and Data to CBP (5, 6, 7) to CBP.

Product Identifier Verification from Identification Key License

Workflow for proving control over a GS1 Key, identification of a product, and makes data assertions about the product.

A GS1 Member Organization issues GS1 Company Identification Key Licence Credential (1), which is presented to the GS1 User Company (2).

The GS1 User Company issues GS1 Key Credential (3) for GTIN identification of a product.

The GS1 User Company associates product data by issuing a GS1 Data Credential (4) about the identified product.

The GS1 User Company presents License, Key and Data to CBP (5, 6, 7) to CBP.

GS1 Prefix License Verification

Workflow for establishing the trust relationship from a GS1 Member Organizations to GS1 Global Office.

GS1 Global Office issues GS1 Prefix Licence Credential (1) about a GS1 Member Organization.

In conjunction with verification of a GS1 User Company's claims, if the GS1 Prefix Licence Credential of an issuing GS1 Member Organization is not already cached, or if a cached GS1 Prefix Licence Credential has been revoked, the verifier fetches the corresponding GS1 Prefix Licence Credential which is publicly avaiable from GS1 Global Office (2).

Software Supply Chain

Modern physical supply chains are heavily dependent upon software supply chains. As such, being able to secure digital services has become a requirement for securing physical ones.

As with physical supply chains, customers demand vendors to take responsibility and prove the provenance of software products and platforms. Beyond organizations securing their supply chains, the digital supply chain has become an issue of national security. Notably, this led to the May 21st, 2021 US President Executive Order of enhancing software supply chain security, outlining minimum software traceability requirements.

One approach for increased visibility and accountability in software is to provide a Software Bill of Materials which allows consumers to understand what is in the software, much like how food ingredients are labeled. Software is widely built from open source and other types of components, and the Software Bill of Materials document lists all such dependencies, providing a detailed and accurate understanding of organizations' software infrastructure. This is key for remediating software vulnerability exposure and assessment of software licensing compliance.

Including the Software Bill of Materials in a Verifiable Credential establishes a verifiable link from the software back to its origin.

Supporting Documents

Mill Test Report Certificate: Sample Mill Test Report

The Mill Test Report certifies metal type and quality, listing chemical and mechanical properties.
Commercial Invoice Certificate: Sample Commercial Invoice

Commercial Invoice indicates to authorities the value of goods subject to tariffs and duties.
Bill of Lading Certificate: Sample Bill of Lading

Bill of Lading certificates are issued by the carrier, indicating a) receipt of goods, b) evidence of consignment contract, and c) title of goods.
Verifiable Business Card: Verifiable Business Cards hold verifiable presentation endpoint addresses.
USMCA Certificate Of Origin: USMCA Certificate Of Origin

The USMCA Certificate Of Origin schema is adapted from FedEx's and UPS's USMCA Forms, implementing the United States - Mexico - Canada Agreement (USMCA).

Purchase Order: Sample Purchase Order

Sample Purchase Order form

The Purchase Order is a formal request of goods by buyer to seller.
Packing List: Packing List example

Sample Packing List form

The Packing List lists the goods of a shipment. It is used by the consignee and Customs to practically manage and organize the consgned goods.
Waybill: Sample Air Waybill form

A Waybill is a transport document issued by the carrier. It serves a similar purpose as a Bill of Lading, except that it does not carry title. Instead, the consignee is identified on the document.
Proforma Invoice: Sample Proforma Invoice form

The Proforma Invoice is a sample invoice provided by an exporter prior to a sale.
Commercial Invoice: Sample Commercial Invoice

An Invoice requests payment for a shipment of goods. It is based on the same schema as the Commercial Invoice, but is typically at a finer level of details, line items corresponding to the Purchase Order.; Sample Importer Security Filing form

The Importer Security Filing, commonly referred to as "10+2" is a requirement for import containerized cargo into the United States.

Privacy Considerations

This section details the general privacy considerations and specific privacy implications of deploying this specification into production environments.

Security Considerations

There are a number of security considerations that implementers should be aware of when processing data described by this specification. Ignoring or not understanding the implications of this section can result in security vulnerabilities.

While this section attempts to highlight a broad set of security considerations, it is not a complete list. Implementers are urged to seek the advice of security and cryptography professionals when implementing mission critical systems using the technology outlined in this specification.

Accessibility Considerations

There are a number of accessibility considerations implementers should be aware of when processing data described in this specification. As with any web standards or protocols implementation, ignoring accessibility issues makes this information unusable to a large subset of the population. It is important to follow accessibility guidelines and standards, such as [[WCAG21]], to ensure all people, regardless of ability, can make use of this data. This is especially important when establishing systems utilizing cryptography, which have historically created problems for assistive technologies.

This section details the general accessibility considerations to take into account when utilizing this data model.

Internationalization Considerations

There are a number of internationalization considerations implementers should be aware of when publishing data described in this specification. As with any web standards or protocols implementation, ignoring internationalization makes it difficult for data to be produced and consumed across a disparate set of languages and societies, which would limit the applicability of the specification and significantly diminish its value as a standard.

This section outlines general internationalization considerations to take into account when utilizing this data model.