edi3/edi3-igl

Inter-Goverment Ledger

edi3 Inter Goverment Ledger Specification

Specification (latest working draft)

Project administration (meeting minutes etc)

Mailing List

Discussion channel (slack channel)

Reference implementation (open source)

Test suite: Not yet available

Live test endpoint: Not yet available

edi3-igl's Issues

Message Tx/Rx API response could be augmented

this issue edi3/edi3.github.io#9 is in the www repo but I think it belongs here.

Singapore Workshop agenda

An ICL face to face workshop has been arranged for 17th to 19th September in Singapore.

Agenda is attached.
ICL Interim Meeting Invitation.pdf

This ticket will be closed when we have a list of actions from the singapore meeting.

role for delegated export authority

re: #5 (actor and role definitions) and #3 (document life-cycle), do we need a "delegated export authority" role?

It's not the case that export customs authority always directly administer the processes used to produce permits and certificates. Often, permits and certificates are issued different Government departments or by fully independent organisations under some regulatory regime (which is regulated in the same jurisdiction as the export customs authority).

In these situations, does it make sense to allow those the export customs authority to delegate the creation of digital assets delegated export authorities?

One example scenario that validates this idea is delegating (e.g. to Chambers of Commerce) the creation of Certificates of Origin under a free trade agreement.

Document transfer

Indication of how ICL transfer document, e.g. the document is stored in the repository and API will provide the link for document access.

document non-normative examples

TODO: raise tickets for each of a number of interesting scenarios that seem to validate the utility of the ICL, or seem to highlight relevant issues or challenges.

Conversation in PR #2 suggested removing non-normative scenarios into separate documents. These could be tickets first, then either separate documents or non-normative sections of the document (to be determined.

The comment was:

Maybe we should create non-normative documents (not part of the spec per-se) documenting scenarios, and reference them from this document.

ticket needed: The spec itself does need a scoping statement re: protocol and payloads

* are we talking about artefacts that are linked to a single export event and a single import event? or is that just the simple case...
* is there a consistent signalling pattern {approved, exported, imported} or is this one of multiple supported patterns?

The comment was in relation to this text

#### Example Scenarios
> FIXME  
> provide step by step description of the end to end process for a simple scenario, and a more complex one, focussing on the creation and transfer of documents.   
> Get full list of documents required for a simple case where only additional  
> documentation beyond generic shipment documentation is a Certificate of Origin  
> maybe a wine shipment?  
> 
> as well as all documents required for a more complex scenario, maybe orchids (certificate of origin, CITES, phytosanitary...) as well as full list of parties involved (e.g. Customs, CMA, Quarantine, CoC)  

role for import and export agents

Similar to #7 and #8 (roles for export and import delegated authorities), do we need to define roles for import and export agents.

Similar to delegated authority, an "agent" is a member of the regulated community of either the import or export customs authority. Unlike a delegated authority, they act on behalf of parties (importers and exporters) rather than the regulator.

Are there scenarios where we would expect an agent to participate in the on-chain document lifecycle (#3 and #4) or is their activity always off-chain? Do we need to define roles for them in the ICL protocol?

ICL Architecture Diagram (Channel Directory)

Agree with Dr Wang (China) that the Channel Directory will indicate centralised architecture. Suggest to remove the Channel Directory and indicate Route API in each ICL node instead.

Proposed CoO Data Model from UNESCAP meeting

UNESCAP Meeting on cross border data exchange has discussed the ICL project and has some early proposals for the CoO data model.

Attached here.

ToDo - reconcile against UN/CEFACT CCL and create proposed harmonised CoO model.

clearly articulate the problem an ICL solves

This was moved from original draft to this ticket

> FIXME
consise description of the problem that an ICL proposes to solve e.g. Clearance of shipments can be delayed because of uncertainty around accompanying documentation, causing signifant costs to bla bla bla... most important statement in document.

role for importers and exporters

In #7, #8 and #9 we discuss the need for roles for parties that act on behalf of regulators and/or the regulated community. Do we also need a direct, on-chain role for members of the regulated community (importers and exporters)?

Example scenarios (for discussion):

• Declarations of origin (rather than certificates of origin) could be made by exporters. Would this be done through an agent, delegated authority or directly by the exporter? If this something different jurisdictions would like to implement as they see fit, are there any jurisdictions which would like to authenticate and authorise exporters to do this directly?

To add Architectural Principles (Backward compatibility with legacy system)

What is a Document in the context of the Inter Customs Ledger?

discuss these two conceptual approaches:

a thing added to the chain by an authorised body which has state and allows some party to take some action dependant on that state?
a digital asset granted to a party that allows that party to trade the asset for some service?

Clarifications on Requirements 9

Recommend: to replace "preventing" as "detecting"

Existing R9: The ICL MUST provide a mechanism for preventing an importer or exporter from re-using a document which is intended to have a single use.

Recommended R9: The ICL MUST provide a mechanism for detecting an importer or exporter from re-using a document which is intended to have a single use.

To clarify whether Certifying Body (under Glossary) includes Government?

does an ICL create new burden of authentication on import authorities?

In the paper world, when an importer presents themself to their import customs authority, they also present their paper documents (whatever that means, #4) and make an identity claim, before their goods are released to them. In this situation, possession of the paper documents is an authentication factor that strengthens the identity claim made by the importer.

In a digital future where the document is delivered to the import authority through the ICL, the import authority is already in possession of the document before the importer presents themselves and makes their identity claim. The paper document authentication factor may be removed, so the authentication claim is weaker. To achieve the same level of identity assurance, the import authority may require the remaining authentication factors to be strengthened.

• Is this new authentication burden on import authorities inconvenient?
• Will it detract from adoption of the ICL mechanism from an import customs authority perspective?

Clarifications on Requirements 14

R14 - The ICL MUST allow transactions to be written individually or in bulk.

Would like to clarify the term "in bulk".
Does it mean sending 10 records in one transactions and
[1] ICL will process all 10 records concurrently; or
[2] ICL will process 10 records one by one?

raise tickets for each of the questions in the first draft

Open Questions

What is the relationship between a party running a node and a party authorised to view the contents of a Document?

This goes to the question of what content of a given document is available on-chain. Some options are:

FIXME
elaborate on each of the options below

1. all document content is on-chain and encrypted
2. document content is published by the issuing authority (who manages access) and only a reference to the document and it's hash is on-chain
3. all document content is on chain and not encrypted (being a node is the same as having authority to view document details)

Should an Inter Customs Ledger manage the state lifecyle of a Document?

What is a Document in the context of the Inter Customs Ledger?

FIXME
discuss these two conceptual approaches:

1. a thing added to the chain by an authorised body which has state and allows some party to take some action dependant on that state?
2. a digital asset granted to a party that allows that party to trade the asset for some service?

What is the appropriate 'chain of custody' of a document in the context of the Inter Customs Ledger?

FIXME
e.g.
export customs -> import customs
authorised body -> exporter -> importer -> import customs

How should the ICL function in the context of an existing legislated paper based process?

FIXME
other projects have maintained paper certificates and implemented print management solution and QR code for validation
review chapter 12 and artice 4.6 of ChAFTA for reference

Design Goals

Avoid proliferation of ledgers

FIXME
i.e. reduce burdon on parties wishing to join network

Maintain privacy of document content

FIXME
i.e. a node on the network may not be authorised to view the content of a document

Collect meaningful data about the use of a Document

FIXME
i.e. some state management to prevent double spend and track documents etc

Future Directions

FIXME
increase breadth and depth covered with interledger protocols. e.g. trade finance related processes may be managed on some other ledger which might need to reference the ICL for validation of the existance of a CoO. or before a certificate of origin is issued, some other ledger may track the provenance of a product and it's purchase by the exporter, opening the possibility of execution of smart contract for issuance of CoO

This service depends on - TBA.

Suggest to remove R9

R9 | The IGL MUST provide a mechanism for preventing an importer or exporter from re-using a document which is intended to have a single use | Link to smart contract patterns

Reason:

[1] the job of the document transportation is not to provide the DRM
[2] can build the DRM on top of the transport layer instead

To elaborate on Abstract section

role for delegated import authority

re: #5 (actor and role definitions) and #3 (document life-cycle), do we need a "delegated import authority" role?

This might be defined as "a party that acts on behalf of the import authority", who the other nations trust to the extent that they trust the import authority to exercise appropriate control over their regulated community.

This might give the import authority a mechanism to outsource the import authentication burden (#6). For example, by delegating the authority of acquitting a single-use digital asset, the import customs authority may make an arrangement that allows some delegated authority to acquit the documents on their behalf.

Potential examples of import delegated authorities might include port authorities, customs agents, or the systems and agents used to process import declarations.

identification, authentication and authorisation of parties

in #7, #8, #9 and #10 we discuss potential roles for members of the regulated community to interact with the ICL, under the control and regulatory authority of the nation in which those identities exist. If any of those roles are actually required, then authentication and authorisation of those parties must occur within the jurisdiction where those parties exist. In other words, it's the jurisdiction's business.

It seems that the ICL will need to support the concept of "identification scheme", where each identification scheme belongs to and is controlled by a jurisdiction. A jurisdiction may have one or many identification scheme, but in absence of a global identification scheme, if a jurisdiction is going to allow exporters, importers, agents or delegated authorities to interact with the ledger, they the jurisdiction will also need to be responsible for the authentication and authorisation mechanism used by those parties for those transactions. And this implies the identification scheme is also within their jurisdiction.

I don't think it's the case that the authentication and access control mechanism needs to be (or even should be) implemented at by the ICL itself. The most obvious scenario is a blockchain identities are node operators, and authentication and access control to specific transactions is managed by the node operators. Is there another way to do this?

Side chain model

Document received from Dr Wang, china customs - describing an approach to scalability that includes

• side chain model
• hierarchical smart contract model
  a3.Enhance feature.pdf

Create Open API Specification for CoO and CoNM

Based on the CoO requirements provided in #18 - remodel the CoO and CoNM based on UN/CEFACT BSP-RDM and using the edi3 UML profile. Then generate OpenAPI specifications for both.

What is the relationship between a party running a node and a party authorised to view the contents of a Document?

This goes to the question of what content of a given document is available on-chain. Some options are:

• all document content is on-chain and encrypted
• document content is published by the issuing authority (who manages access) and only a reference to the document and it's hash is on-chain
• all document content is on chain and not encrypted (being a node is the same as having authority to view document details)

Should CoO structured model be based on UN or WCO models or both?

This ticket is to facilitate an open discussion on the question of whether the data element needs of a Certificate of Origin should be met using a structured schema based on the WCO data model or the UN/CEFACT Reference Data Models - or both.

asynchronous POST to the message API

In the doc, (section "Message API") you state:

response is 200 OK if the message is successfully
processed by the relevant DLT channel

I don't think that's quite right.

• picky: it should be 201 (created), not 200 (OK)
• The 200 means the message was posted to the API, and it's in a queue for writing to the ledger.

Written vs. not-written is a bit nuanced in DLT. It's a slightly arbitrary decision, how many blocks on top of the last block do you consider successfully written? In other words, how deeply might a fork run before it's resolved? That question is technology specific, so should be answered by a technology specific component, not the generic interface.

Suggest an alternative that POST {message} /{message api}/ should return 201 and some sender reference (receipt), and subsequent calls to GET /{message api}/{receipt} should return a status of pending, accepted or rejected. That way, the technology specific apparatus of the channel can make a decision about the status of the message asynchronously.

elaborate the glossary: actors and roles

We need to define actors and roles, so that we can progress the discussion on #4

Actors:

• Nations / National Jurisdictional Authorities
• Parties - exist within a national jurisdiction

Roles:

• Export Customs Authority
• Import Customs Authority
• Exporter
• Importer
• Export Delegated Authority
• Import Delegated Authority (do we need this?)
• Export/Import Agents (do we need these?)

describe financial implications of ICL in the goals section of the spec

The original draft had this comment in the first section

> FIXME
there should be some text here describing the financial consequences of the last statement above

(in relation to a statement of the goals of the ICL standard)

This ticket opens that for discussion so that an appropriate statement about financial consequences can be added to the goals section of the document.

Should an Inter Customs Ledger manage the state lifecyle of a Document?