Clarifications on Requirements 9

[shujingliew]

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.

[monkeypants]

This is an interesting distinction.

Prevention suggests the ICL will guarantee of single use artefacts will not be "double-spent". This seems possible from a technology perspective, assuming a protocol where "spending" is always recorded. Do you agree?

Detecting (rather than preventing) suggests the ICL will not actively refuse the second "spend", instead it will allow the second spend to occur (but make a permanent record of the violation). This still requires the "spending" to be recorded.

Why is detecting better than preventing? Is it because the person doing the spending (e.g. import official) needs to be able to decide what to do next, they need the discretion ? Or is is because they need to take some action rather than be stuck (hung process, computer says you can't exist).

[onthebreeze]

This goes to whether the DLT transaction validator has opinions about the semantics of a message / message type. For the example of a CoO

• if the ICL is a dumb, high integrity pipe then the blockchain not know or care whether a CoO can be "acquitted". In this case, it is entirely up to the application layer to apply business rules.
• But in some cases, a DLT "smart contract" might apply validation rules before it allows a transaction to be written to the chain. If the smart contract says "you cant acquit the same CoO twice" then that will be enforced at the time the acquittal message is written to the DLT channel.

I suspect that we will see a transition over time from a dumb (but secure & high integrity) pipe model to a smart contract model as use of the ICL matures.