Exchange of Electronic Certificate of Origin to facilitate Cross Border Trade

[cxcheng]

Background

Today, cross-border trade and transport of goods take place on the basis of many documents and processes that are paper-based (hence manual), time-consuming, and resource-intensive process for all stakeholders. Another downside of such paper-based processes is that there is no easy way to verify the accuracy and authenticity of the trade documents. This results in inefficiencies and delays as the time required to process such paper documents far exceeds the actual time taken for the physical movement of goods. According to a study by McKinsey in 2022, documentation for a single shipment can require up to 50 sheets of paper that are exchanged with up to 30 different stakeholders.

To address these inefficiencies, we have developed TradeTrust. TradeTrust, which is built upon OpenAttestation framework, comprises globally accepted standards and frameworks that allow governments and businesses to issue, verify and effect title transfer of electronic documents across different digital platforms seamlessly. TradeTrust uses cryptography and decentralised identifier (DID) technical methods to assure the authenticity and provenance of these electronic documents.

As a framework, TradeTrust is designed and developed to support the digitalization of documents used in Cross-Border Trade processes. Such documents could include those that are used to convey information such as Packing Lists and Certificates of Origin (CO) thus making them verifiable with respect to their authenticity and provenance. A CO is a document commonly used in Trade to attest that a product originates from a particular country. For more information, please see https://iccwbo.org/business-solutions/certificates-of-origin/.

Distinction

Existing trade documents are typically printed hardcopies secured with wet ink stamps. These documents are susceptible to forgery and manipulation. A digital verifiable document would allow for

• Assurance that the document has not been tampered with
• Assurance that the document was issued by a particular Issuer
• As these trade documents are shared across different parties in a long chain that may cross many borders, the holders of these documents may want control over what information is shared downstream. A shipper may choose to selectively redact commercially sensitive information (such as suppliers' names or products' pricing) before sharing it onto the next receiving party. This is based on a lossy selective redaction, removing the need to re-issue ‘a version sans the commercially sensitive information’.

Actors

Using an electronic Certificate of Origin (eCO) as an example of a digital document that is issued via the TradeTrust framework, below are the typical actors involved in its processing.

Customs Administration or duly licensed parties like Chambers of Commerce

Customs Administration and/or Chamber of Commerce are the typical authorities responsible for producing an eCO. It is typically needed by importers/buyers to claim tariff exemptions from the importing customs authority or to provide assurance that the goods are indeed from a particular country. It is provided to importers/buyers by the exporters/sellers whom they buy from and often used in financing arrangements with banks.

Banks

In cross-border trade, sometimes buyers and sellers may arrange for trade financing services to mitigate the risks of non-payment or non-delivery. Banks and other Financial Institutions are often engaged as intermediaries to mitigate these risks using financing instruments such as a Letter of Credit (L/C). A L/C is applied for by the Buyer and will specify a list of trade documents that the Banks will need to sight and verify on behalf of their clients. One of the often-required documents can be an eCO.

Importer

An Importer/Buyer is the party who purchases and receives products from the seller. If there is a Free Trade Agreement between the importing country and the goods’ origin country, the Importer can provide the eCO during importation clearance procedures to obtain tariff exemptions for the goods.

Exporter

An Exporter/Seller is the party who sells and transports products to his buyer. The Exporter is the party who applies for the eCO from the Customs Administration or duly licensed parties like Chambers of Commerce within the exporting country, upon the request of the Importer.

Issuer

A Customs Administration and/or Chamber of Commerce are the typical authorities responsible for producing an eCO.

Subject

The eCO attests that the origin of the goods is a particular country. It is used to claim tariff exemptions from the importing customs authority or to provide assurance that the goods are indeed from a particular country.

Holder

The eCO can be held by the Importer (and/or their appointed customs broker) and presented to the importing country’s customs administration for import tariff exemption if there is an in-force Free Trade Agreement between the goods’ origin country and the importing country. The eCO can also be held by the Exporter and Banks for trade financing purposes.

Verifier

The eCO is verified by the importing country’s Custom Authority during the importation of goods. It is also verified by Banks if the Exporter and/or Importer has financing arrangements that call for it. It is also verified by the importer to assure that the goods originated from the expected country.

Validation Requirements

Document verification can be initiated by invoking the open-sourced verification library, or via the trusted verification portals which run the open-sourced verification library.

There are no other relationship or dependencies on other Verifiable Credentials.

Example Artefacts

Verifiable Credential

Electronic Certificate of Origin

Based on older OpenAttestation v2. Latest OpenAttestation v4 Alpha is now W3C VC Data Model 2.0 compliant.

{
    "version": "https://schema.openattestation.com/2.0/schema.json",
    "data": {
        "firstSignatoryAuthentication": {},
        "supplyChainConsignment": {
            "exportCountry": {},
            "exporter": {
                "postalAddress": {}
            },
            "importCountry": {},
            "importer": {
                "postalAddress": {}
            },
            "loadingBaseportLocation": {},
            "mainCarriageTransportMovement": {
                "usedTransportMeans": {},
                "departureEvent": {}
            },
            "unloadingBaseportLocation": {}
        },
        "$template": {
            "type": "7a29f8c9-47a0-429d-a043-0eceee351090:string:EMBEDDED_RENDERER",
            "name": "907e4a2d-0d16-491d-99a6-531eb4a5d06f:string:CHAFTA_COO",
            "url": "7a149cd6-33d9-4813-9a6c-f7ea00b2683c:string:https://generic-templates.tradetrust.io"
        },
        "issuers": [
            {
                "name": "eef12038-1f5f-40de-9491-fea8a3c3771e:string:Demo Issuer",
                "documentStore": "b75454f5-79c8-4f8c-9e92-77626b6871d2:string:0x70f83193bE363348Ec769c8752690eB915E640A4",
                "identityProof": {
                    "type": "b4aee06a-d226-4f0e-8bf4-b0f125735a14:string:DNS-TXT",
                    "location": "4d830cea-5332-4cd7-91dd-0187c096e3af:string:sandbox.tradetrust.io"
                },
                "revocation": {
                    "type": "59cf4245-6d93-4b63-91b1-f9b100e8f304:string:NONE"
                }
            }
        ],
        "network": {
            "chain": "2d9f5493-416e-448c-8404-e308a6093bd7:string:FREE",
            "chainId": "bf39e664-b37c-4e0c-bf9b-e74c257da7bd:string:101010"
        }
    },
    "signature": {
        "type": "SHA3MerkleProof",
        "targetHash": "cff3db9808786f9ad214f3ae79cb83fccc74103a9db78f786335f85871b517cd",
        "proof": [],
        "merkleRoot": "cff3db9808786f9ad214f3ae79cb83fccc74103a9db78f786335f85871b517cd"
    }
}

Trust Hierarchy

The trust can be separated into 2 parts.

1. The issuer’s identity is based on the ownership of the DNS
   1. This is where we intend to have an alternative identity provided by the Trust Anchors
2. Data integrity is based on the hash that is written on blockchain OR signed by the issuer.

Threat Model

To be added.

Risk - Put simple description here

Put detailed description here, including and especially the response(s) to the risk.

[jandrieu]

Thanks for the PR. @KDean-GS1 and I are looking at it in more detail.

[cxcheng]

Thanks Joe and Kevin. Wondering if you guys have more comments regarding this

[jandrieu]

Ok. This is an intriguing use case, especially the progressive redaction as the VC travels through the supply chain.

However, that makes us wonder if we can, in fact, derive a secondary proof from the initial derived proof. Seems like it should be possible with BBS, but we haven't seen it done. I think Gordian envelopes may also offer that possibility.

Is that something you have working in practice?

In general, I'd like to see this focus on a single, concrete flow that we can describe concisely. For example, a particular product that originates somewhere, gets an eCOC, then travels through the supply chain with different reasons that various, different details are shared at different points.

For example, I can imagine a flow for a bottle of champagne that starts in France, makes its way through ports and customs to be purchased by a US Consumer. At which point does which party perform some form of redaction or selective disclosure? Who is giving this evolving eCOC to whom?

In particular, when considering possible flows, it seems at least one flow would not be viable. Consider selective disclosure as a product travels through the supply chain, but the final details are revealed to the final consumer. Intermediate parties often don't need to know the details, perhaps just that there is a valid eCOC for a particular class of goods from a particular country. However, end users will often want to know tons of details, such as the manufacturer or the date of manufacturing, etc. Unfortunately, that does not seem to be possible with any approach I'm familiar with.

Can you describe how a specific product would use this mechanism as it travels the supply chain?

[iherman]

The issue was discussed in a meeting on 2024-09-27

• no resolutions were taken

View the transcript

5.1. Exchange of Electronic Certificate of Origin to facilitate Cross Border Trade (issue vc-use-cases#157)

See github issue vc-use-cases#157.

Joe Andrieu: There is another trade supply usecase that we are working to unpack. This aims to make a concrete case for selective disclosure in products going through the supplychain.

Kevin Dean: This is issue 157.

Joe Andrieu: I want to mine the test suite for implementers to find people using VCs in the wild.
… Right now the extant usecases is empty.

Manu Sporny: Do the tradetrust folks(issue 157) want to speak to their usecase.

SinYong: If I issue an invoice to you, you may want to hide your name from me. To obfuscate from the invoices. This applies to suppliers of products.You have to pay to ship you product from point a to point b. You do no want your downstream parties to know how much you paid.

Kevin Dean: That is true in many supply chain cases. I may need proof that I am a retailer, without knowing exactly who I am.

Manu Sporny: This is a really important usecase, because it signals we do not have a cryptosuite that is capable of this yet.
… This use case is, I get a VC and want to selectively redact information on that VC without violating the signature.
… Each point in the supply chain can redact additional data from the VC.

Joe Andrieu: Is this possible? There is innovative/novel cryptography that can do this.
… I just want to know it is possible.

Manu Sporny: Yes, it is possible.

SinYong: When we do our project, the holder ???, We do not want to issue VCs to every party along the supplychain. We use the VC to represent a tree structure. It does not issue the VC to any particular holder.

Kevin Dean: interesting. In redaction you still have the same public key to identify the issuer. This can't go with the credential. It may still give the opportunity to identify who the supplier might be.

cc: Our merkle proof signatures are going to bepublished and made into an extension.

Denken Chen: We are starting to explore an open ecosystem of VC and DIDs. We could contribute our research back to the community.
… Our first focus is on the threat model. Do we need to deal with the W3C threat modelling group here?

Brent Zundel: I think yes.
… We will be meeting with the security people after the break.

Manu Sporny: +1 to brent. Simone is putting together a threat modelling approach for multiple groups to go through.
… There is going to be collaboration in the future.

Joe Andrieu: We do have a section about threats in the use case document. But this is not based on any of the work. What we have is closer to a risk analysis.
… A much simpler model.
… It would be great to use whatever Simone is producing.

Denken Chen: I know in W3C the threat modelling is an overview. In our work, we have a more detailed threat modelling of specific usecases. We are focused on threat modelling for issuers, holders and verifiers. We may be able to contribute this.

Brent Zundel: Any additional comments?
… Not hearing anything. meet back here in 1 hour.

[cxcheng]

@jandrieu and @KDean-GS1, let's follow up with a detailed walkthrough of the use case.
Since this is a use case discussion, it would be more important I feel to go through our use case details before we look into the technology aspects of it. We would like to get your agreement and also a game plan on how we can edit the use case document - User Needs, User Tasks, and Focal Use Cases.
While I feel it is important for us to have a live chat on this (would the weekly VC sessions be the right forum?), you can also let us know your preference on how we should proceed so we can prepare our homework to have a more productive session. I would also need to engage our IMDA colleagues as they are the ones best placed to do a deep dive on this.

[iherman]

The issue was discussed in a meeting on 2024-10-09

• no resolutions were taken

View the transcript

3. Controller Document.

See github issue vc-use-cases#157.

Calvin Cheng: I apologize if this is not the right time, because with my colleagues here, we are just trying to move forward on the use case, I want to highlight and mention this, but we will probably work with you all offline on a followup.

Joe Andrieu: I just want to confirm cc that we want to work with you and probably should set up a call. Now that I understand you have this novel cryptography that enables this use case, happy to work with you and move this forward.

Calvin Cheng: we will set up a call.

Manu Sporny: this is going back to controller document, but +1 to the use case that cc mentioned.

[KDean-GS1]

@cxcheng Hi, Calvin. We've drafted a preliminary branch at https://github.com/w3c/vc-use-cases/tree/5_cross_border_trade. We need the following:

• An up-to-date example credential in VC 2.0 form.
• A breakdown of that credential into a concrete example for the prose section.
  • Actors: who is the issuer, who is the subject, who is the verifier, etc., rather than just generic terms.
  • Validation requirements: What does it take to verify the content.
• An example that includes selective redaction.
  • What is redacted?
  • Why is it redacted?
  • How do verifiers work with the document when data has been redacted?

Thanks.

[cxcheng]

Thanks Kevin for putting this up. We will get back to you in 2-3 weeks as some of our key members are on leave.

[KDean-GS1]

Given the year-end holidays, we'll look for something in early January.