chore: make identifiers generic

website/docs/design-patterns/index.md

@@ -16,15 +16,15 @@ The ESG footprint of a finished product is the aggregation of it's components an
 
 ## Data Carriers
 
-Digital data needs to be linked to the physical product it describes and should be discoverable through the identifiers printed on that product serial or batch number. For high volume goods and easy / reliable discovery, these identifiers are already typically represented as barcodes, matrix codes, QR codes, or RFID encoded data. UNTP supports the use of these existing data carriers. A basic UNTP principle is that if you have a product then you should be able to find ESG data about that product even when the identifier is not a web link. Therefore, the UNTP defines a generalised protocol (based on [GS1 Digital Link](https://www.gs1.org/standards/gs1-digital-link)) to allow any identifier scheme (GS1 or otherwise) to be consistently resolvable so that product passports and other data can always be accessed from the identifier of the product. The UNTP also defines a specific QR based data carrier format for use on paper/PDF versions of conformity credentials or other trade documents that provides secure access to credentials in a way that is both human and machine readable.  This provides a simple but powerful mechanism to facilitate uptake of digital solutions alongside existing paper/PDF based frameworks.
+Digital data needs to be linked to the physical product it describes and should be discoverable through the identifiers printed on that product serial or batch number. For high volume goods and easy / reliable discovery, these identifiers are already typically represented as barcodes, matrix codes, QR codes, or RFID encoded data. UNTP supports the use of these existing data carriers. A basic UNTP principle is that if you have a product then you should be able to find ESG data about that product even when the identifier is not a web link. Therefore, the UNTP defines a generalised protocol to allow any identifier scheme to be consistently resolvable so that product passports and other data can always be accessed from the identifier of the product. The UNTP also defines a specific QR based data carrier format for use on paper/PDF versions of conformity credentials or other trade documents that provides secure access to credentials in a way that is both human and machine readable.  This provides a simple but powerful mechanism to facilitate uptake of digital solutions alongside existing paper/PDF based frameworks.
 
 ## Anti-Counterfeiting
 
 As the value of genuinely sustainable goods increases, so do the incentives to sell fake goods as the real thing. UNTP defines a simple and decentralised anti-counterfeiting protocol that can be implemented by any producer at very low cost. It builds upon the W3C DID standard by issuing a unique DID (and corresponding keypair) for every serialised (individual or batch) product. The DID (and therefore the public key) is discoverable from the product serial number using the standard link resolver protocol. The item/batch level DID is cryptographically linked to the product class level DID The private key is discoverable from a QR code hidden inside the product packaging. Scanning the QR provides the necessary key to update the individual serialised product public status to indicate consumption. Attackers that copy genuine serial numbers will find that their products are quickly identifiable as fakes. Attackers that try to create new serial numbers will not be able to create valid links to the genuine product class. The UNTP anti-counterfeiting protocol provides additional value/incentive for UNTP uptake beyond ESG integrity.
 
 ## Mass Balance
 
-Mass balance fraud is a particularly challenging greenwashing vector. It happens when a fraudulent actor buys a small quantity of high ESG integrity inputs (eg genuine carbon neutral, organic, deforestation free cotton) and mixes that input with lower quality alternatives and then sells the full volume of manufactures product (eg woven cotton fabric) as sustainable product, re-using the valid credentials from the niche supply. The UNTP solution to this problem involves trusted third parties (certifiers or industry associations) to act as quota managers that issue "guarantee of origin" credentials (a type of conformity credential). In this model, the guarantee of origin certificate for 10 Tons of cotton fabric (for example) can only be issued when the third party has evidence of the purchase of at least 10 Tons sustainable input materials. The third party will also mark the input batch as consumed (in a similar way to the anti-counterfeiting protocol) so that the valid sustainble input cannot be re-presented to a different third party.
+Mass balance fraud is a particularly challenging greenwashing vector. It happens when a fraudulent actor buys a small quantity of high ESG integrity inputs (eg genuine carbon neutral, organic, deforestation free cotton) and mixes that input with lower quality alternatives and then sells the full volume of manufactures product (eg woven cotton fabric) as sustainable product, re-using the valid credentials from the niche supply. The UNTP solution to this problem involves trusted third parties (certifiers or industry associations) to act as quota managers that issue "guarantee of origin" credentials (a type of conformity credential). In this model, the guarantee of origin certificate for 10 Tons of cotton fabric (for example) can only be issued when the third party has evidence of the purchase of at least 10 Tons sustainable input materials. The third party will also mark the input batch as consumed (in a similar way to the anti-counterfeiting protocol) so that the valid sustainable input cannot be re-presented to a different third party.
 
 ## ESG Rules
 

website/docs/specification/ConformityCredential.md

@@ -186,10 +186,10 @@ It should be noted that this `authorisations` structure is part of the attestati
 The `conformityCertificate` and `auditableEvidence` objects are both the same `SecureLink` type. The purpose is to provide a verifiable link to further details about the attestation (the certificate) or the auditable evidence (eg test results) that informed the attestation.  
 
 * `linkURL` points to the external certificate or evidence described by `linkName`.
-* `linkType` is an optional identifier that, if present, should be drawn from a controlled vocabulary of linktypes ([example](https://ref.gs1.org/voc/?show=linktypes)).  
+* `linkType` is an optional identifier that, if present, should be drawn from a controlled vocabulary of link types ([example](https://idr.untp.showthething.com/api/1.0.0/voc?show=linktypes)).  
 * `hashDigest` should equal the hash of the target. This provides an integrity measure to ensure that the external certificate or evidence has not been tampered since the DCC was issued. 
 * `hashMethod` code defines which hash algorithm to use.
-* `encryptionMethod` defines whether the target is encrypted and, if so, using which algorithm.  THis provides a privacy/confidentiality mechanism to protect more sensitive content. The decryption key is assumed to be passed out of bounds. 
+* `encryptionMethod` defines whether the target is encrypted and, if so, using which algorithm.  This provides a privacy/confidentiality mechanism to protect more sensitive content. The decryption key is assumed to be passed out of bounds. 
 
 ```json
     "conformityCertificate": {
@@ -321,9 +321,9 @@ One conformity credential may include many assessments. Each assessment includes
         "assessedProduct": [
           {
             "product": {
-              "id": "https://id.gs1.org/01/09520123456788/21/12345",
+              "id": "https://example.com/id/9520123456788",
               "name": "EV battery 300Ah",
-              "registeredId": "09520123456788.21.12345",
+              "registeredId": "9520123456788",
               "serialNumber": "12345"
             },
             "IDverifiedByCAB": true

website/docs/specification/DigitalProductPassport.md

@@ -153,7 +153,7 @@ All DPPs are issued as W3C Verifiable Credentials and MUST conform to the [VCDM
     "type": [
       "ProductPassport"
     ],
-    "id": "https://id.gs1.org/01/09520123456788/21/12345",
+    "id": "https://example.com/id/9520123456788",
     ... remainder of product passport information goes here ...
   }
 }
@@ -209,9 +209,9 @@ The `Product` object is a core component of the `ProductPassport`, encapsulated
 ```json
 "product": {
   "type": ["Product"],
-  "id": "https://id.gs1.org/01/09520123456788/21/12345",
+  "id": "https://example.com/id/9520123456788",
   "name": "Baked beans, tinned, 500g.",
-  "registeredId": "09520123456788.21.12345",
+  "registeredId": "9520123456788",
   "idScheme": {},
   "serialNumber": "12345",
   "batchNumber": "6789",
@@ -350,13 +350,13 @@ The `circularityScorecard` provides a concise summary of the product’s circula
     "type": ["Link"],
     "linkURL": "https://example.com/products/123456789/recycling.pdf",
     "linkName": "Recycling Instructions",
-    "linkType": "https://www.gs1.org/voc/recyclingAndRepairInfo"
+    "linkType": "https://idr.untp.showthething.com/api/1.0.0/voc/sustainabilityInfo"
   },
   "repairInformation": {
     "type": ["Link"],
     "linkURL": "https://example.com/products/123456789/repair.pdf",
     "linkName": "Repair Instructions",
-    "linkType": "https://www.gs1.org/voc/recyclingAndRepairInfo"
+    "linkType": "https://idr.untp.showthething.com/api/1.0.0/voc/sustainabilityInfo"
   },
   "recyclableContent": 0.5,
   "recycledContent": 0.3,

website/docs/specification/DigitalTraceabilityEvents.md

@@ -54,7 +54,7 @@ A UNTP digital traceability event may be rendered in any format desired by the i
 
 ## Overview
 
-Traceability events are very lightweights collections of identifiers that specify the “what, when, where, why and how” of the products and facilities that constitute a value chain. The UNTP is based on the [GS1 EPCIS](https://www.gs1.org/standards/epcis) standard for this purpose because it is an existing and proven mechanism for supply chain traceability. Note that UNTP supports but does not require the use of GS1 identifiers. The basic idea behind the traceability event structure is that any supply chain of any complexity can always be accurately modeled using a combination of four basic event types. An **object** event describes an action on specific product(s) such as an inspection. A **transaction** event describes the exchange of product(s) between two actors such as sale of goods between seller and buyer. An **aggregation** event describes the consolidation or de-consolidation of products such as stacking bales of cotton on a pallet for transportation. An **association** event describes the assembly of sub-components to make a composite product. Finally, a **transformation** event describes a manufacturing process that consumes input product(s) to create new output product(s). The UNTP uses these events in a decentralised architecture as the means to traverse the linked-data "graph" that represents the entire value-chain.
+Traceability events are very lightweights collections of identifiers that specify the “what, when, where, why and how” of the products and facilities that constitute a value chain. The basic idea behind the traceability event structure is that any supply chain of any complexity can always be accurately modeled using a combination of four basic event types. An **object** event describes an action on specific product(s) such as an inspection. A **transaction** event describes the exchange of product(s) between two actors such as sale of goods between seller and buyer. An **aggregation** event describes the consolidation or de-consolidation of products such as stacking bales of cotton on a pallet for transportation. An **association** event describes the assembly of sub-components to make a composite product. Finally, a **transformation** event describes a manufacturing process that consumes input product(s) to create new output product(s). The UNTP uses these events in a decentralised architecture as the means to traverse the linked-data "graph" that represents the entire value-chain.
 
 ## Conceptual Model
 
@@ -132,7 +132,7 @@ This transformation event example describes the manufacture of a battery cell (o
           "type": [
             "Item"
           ],
-          "id": "https://id.gs1.org/01/09520123456788/21/12345",
+          "id": "https://example.com/id/9520123456788",
           "name": "EV battery 300Ah."
         }
       ],
@@ -141,20 +141,20 @@ This transformation event example describes the manufacture of a battery cell (o
           "type": [
             "Item"
           ],
-          "id": "https://id.gs1.org/01/09520123456788/21/99876",
+          "id": "https://example.com/id/952012345678899876",
           "name": "Graphite Anode"
         },
         {
           "type": [
             "Item"
           ],
-          "id": "https://id.gs1.org/01/09520123456788/21/99987",
+          "id": "https://example.com/id/952012345678899987",
           "name": "Copper Cathode"
         }
       ],
       "inputQuantityList": [
         {
-          "productId": "https://id.gs1.org/01/095201299876",
+          "productId": "https://example.com/id/95201299876",
           "productName": "Lithium electrolyte",
           "quantity": 2,
           "uom": "KGM"
@@ -196,7 +196,7 @@ This association event example describes the replacement of a new battery cell (
           "type": [
             "Item"
           ],
-          "id": "https://id.gs1.org/01/09520123456788/21/12345",
+          "id": "https://example.com/id/95201234567881234",
           "name": "EV battery 3000Ah."
         }
       ],
@@ -221,7 +221,7 @@ This aggregation event describes the packaging for shipment of two battery cells
       "action": "add",
       "disposition": "active",
       "bizStep": "commissioning",
-      "bizLocation": "https://id.gs1.org/414/9520123456788",
+      "bizLocation": "https://example.com/id/9520123456788",
       "sensorElementList": [...],
       "parentEPC": {
         "type": [
@@ -235,14 +235,14 @@ This aggregation event describes the packaging for shipment of two battery cells
           "type": [
             "Item"
           ],
-          "id": "https://id.gs1.org/01/09520123456788/21/12345",
+          "id": "https://example.com/id/952012345678812345",
           "name": "EV battery 300Ah."
         },
         {
           "type": [
             "Item"
           ],
-          "id": "https://id.gs1.org/01/09520123456788/21/678910",
+          "id": "https://example.com/id/9520123456788678910",
           "name": "EV battery 300Ah."
         }
       ],
@@ -276,7 +276,7 @@ This transaction event describes the sale of 200 batteries (quantity list) from
       "epcList": [...],
       "quantityList": [
         {
-          "productId": "https://id.gs1.org/01/09520123456788",
+          "productId": "https://example.com/id/9520123456788",
           "productName": "EV battery 300Ah.",
           "quantity": 200,
           "uom": "KGM"
@@ -302,14 +302,14 @@ This object event describes the repair of a battery cell (EPC list).
       "action": "add",
       "disposition": "active",
       "bizStep": "commissioning",
-      "bizLocation": "https://id.gs1.org/414/9520123456788",
+      "bizLocation": "https://example.com/id/9520123456788",
       "sensorElementList": [...],
       "epcList": [
         {
           "type": [
             "Item"
           ],
-          "id": "https://id.gs1.org/01/09520123456788/21/12345",
+          "id": "https://example.com/id/952012345678812345",
           "name": "EV battery 300Ah."
         }
       ],
@@ -328,7 +328,7 @@ The item structure is designed to represent serialised items such as a specific
       "type": [
         "Item"
       ],
-      "id": "https://id.gs1.org/01/09520123456788/21/12345",
+      "id": "https://example.com/id/952012345678812345",
       "name": "EV battery 300Ah."
     }
   ]

website/docs/specification/VerifiableCredentials.md

@@ -69,16 +69,16 @@ Verifiable Presentations (VP) are widely used in the verifiable credentials ecos
 A shared understanding of the meaning of claims made in verifiable credentials is essential to interoperability. To this end, conformant UNTP implementations
 
 - MUST use the [JSON-LD](https://www.w3.org/TR/vc-data-model/#json-ld) syntax for the representation of data in all issued credentials.
-- MUST reference the relevant [UNTP @context](https://test.uncefact.org/vocabulary/untp/home) file for the given credential type. These context files are themselves extentions of the W3C VC Data Model 2.0 context.
-- MAY extend credentials with additional properties but, if so, MUST include additonal @context file reference that defines the extended properties. The @vocab "catch-all" mechanism MUST NOT be used.
-- SHOULD implement widely used industry vocabularies such as [schema.org](https://schema.org/) or [GS1 web vocabulary](https://ref.gs1.org/voc/) as a first choice for UNTP extensions requiring terms not in the UN vocabulary.
+- MUST reference the relevant [UNTP @context](https://test.uncefact.org/vocabulary/untp/home) file for the given credential type. These context files are themselves extensions of the W3C VC Data Model 2.0 context.
+- MAY extend credentials with additional properties but, if so, MUST include additional @context file reference that defines the extended properties. The @vocab "catch-all" mechanism MUST NOT be used.
+- SHOULD implement widely used industry vocabularies such as [schema.org](https://schema.org/) as a first choice for UNTP extensions requiring terms not in the UN vocabulary.
 - MAY use any other published JSON-LD vocabulary for any other industry or country specific extensions.
-- MUST maintain @context files at the same granularity and version as the corresponding credentila type. This prevents the risk of verification failures when context files change after credentials are issued. 
-- SHOULD provide a complete and versioned JSON schema for each credential type. This is to facilite simple and robust implementations by developers without detailed knowledge of JSON-LD.  
+- MUST maintain @context files at the same granularity and version as the corresponding credential type. This prevents the risk of verification failures when context files change after credentials are issued. 
+- SHOULD provide a complete and versioned JSON schema for each credential type. This is to facility simple and robust implementations by developers without detailed knowledge of JSON-LD.  
 
 The data governance architecture for UNTP credentials is shown below. the key points to note are
 
-* That credential instances contain Verifiable Credential Data Model (VCDM) type references for each unquely identified linked-data object. Each extension builds upon parent types and is enumerated in the type array (eg `["Facility", "Farm"]`).
+* That credential instances contain Verifiable Credential Data Model (VCDM) type references for each uniquely identified linked-data object. Each extension builds upon parent types and is enumerated in the type array (eg `["Facility", "Farm"]`).
 * UNTP @context types are `protected` and so MUST not be duplicated in extensions. Similarly UNTP @context does not duplicate `protected` terms in WCDM @context.  
 * Unlike @context files, the JSON schema for each credential MUST be a complete schema that defines the entire credential including terms from VCDM and UNTP.