Suggest to remove R9

[shujingliew]

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

[monkeypants]

It's plausible that the transport layer could enforce uniqueness on file fingerprints, but unless we courted complexity with "canonical forms" it would be hard to prevent attackers making small bit-flip differences (e.g. extra space in a header somewhere).

How would the transport layer know which document types are single use? Maybe that's an attribute of the business semantics model.

If the channel itself enforced uniqueness, we would have interesting difficulties when routing tables change. i.e. an old channel is depricated in favour of a new one. A document sent on the old channel would never have been seen on a new channel (possible to send a-gain) - but presumably correct behavior would be to reject it all the same. Channel routing behaviours should be opaque to users.

Because the API for submitting to a node has to perform some logic based on the type of message (e.g. which channel to use), maybe that would be a good place to check/ensure document uniqueness. That's not without consequence either - nodes would need to maintain an index of all documents seen to be able to do this - but that seems like it would probably be cheaper than maintaining an index over a changing network of ledgers.

[shujingliew]

not sure if we talking about the same thing.

for example, Telegram has a secret chat feature that :

• allows end-to-end encryption
• leave no trace on the servers
• support self-destructing messages
• don't allow forwarding

however, there is no way that Telegram can stop screenshot taken.

[monkeypants]

provide a mechanism for preventing an importer or exporter from re-using a document which is intended to have a single use

I understood this to mean "user must not send the same document twice, and pretend they are different documents". That's what I meant by enforce uniqueness.

TL;DR; I think double-ratchet (like Telegram) is possible now, I don't see the use-case for it in IGL (yet).

I think telegram uses a double-ratchet algorithm, meaning more or less that each message contains some new key material, so that subsequent messages are always encrypted with new keys. I.e. message exchange and key distribution are coupled. The purpose is both end-to-end encryption AND plausible deniability (you can't prove that I sent you this message, yes you can make a screen shot but I could claim it's a fake and you can't counter that claim) plus being confident that you are talking to who you think you are talking to.

If two parties want private, end-to-end encrypted communications with plausible deniability, I don't think a cross-border exchange of trade documents is the right way to do it. That's what I mean by not seeing the use-case in IGL. In general, double-ratchet communications between businesses is probably a great idea for maintaining privacy and conducting nuanced discussions without risk of statements being taken out of context. But that's not what trade documents are for - not a "B2G2G" type IGL channel. The notarisation spec could apply to double-ratchet channels however.

Having said that, double ratchet is really cool and I think it's possible now without any changes in the IGL channel spec :) (assuming the semantic standards support it). Currently each message has a "subject" attribute that groups messages that are part of the same "conversation" - you can think of the semantic subject as a kind of "correlation ID". For example, if a COO is created, and then revoked or acquitted, those messages would all have the same subject (unique COO identifier). Messages also have an explicit sequence, more or less, which could be tightened up with a sequence ID in the payload too.

To implement double-ratchet, you would need a semantic spec that allows documents (payload, contents of the message rather than metadata like subject) that contain a signed, encrypted envelope. The envelope would need to contain the message cleartext, plus a sequence number, plus key material to be used to encrypt the subsequent message. There might need to be some tricks around putting the sequence number on the envelope too, probably requires more work for those details. I also think there would need to be a different key exchange method to establish the first message in each conversation (maybe would require some kind of PKI).

in summary, if we need this on an IGL channel we should be able to do it with an appropriate document spec. But an appropriate document spec that supports double-ratchet could be tunnelled through any channel, even email; and could be notarised (encoded as open-attestation format and notarised using the notary spec) even without the IGL channel. I think it's probably across purposes to the IGL channel spec.

[yehjxraymond]

Dont get us wrong, we are not asking for it to be implemented. We are asking for R9 to be removed because whether a recipient reuse a document is not within the control of the network and should not be it's responsibility. It's alright to have this functionality as a DRM module on top of the IGL but putting it as the requirement may be unnecessary.

[monkeypants]

🤦‍♂️

OK, I get you now. Sorry, I took that on a bit of a tangent...

Would you be happy with the idea that some channels MAY implement rules (not MUST), including but not limited to R9?

I suggest this because I agree in general "neutral carrier" approach to channels, but can also imagine a situation where a multilateral agreement states that certain rules must be strictly followed. i.e. "I agree to participate but only if these rules are always followed", and "I don't trust any individuals to enforce the rules on my behalf". That's a situation where a "smart channel" message ledger might apply, there is consensus that the rules have been followed.

[onthebreeze]

The original intent of this requirement was to allow channels to specify rules as smart contracts. But I agree that the requirement was badly worded because

• blocking re-use of single-use contracts is only one type of rule.
• whether or not a rule needs to be applied is not universal - it depends on the channel requirements, not on the general IGL protocol.

Therefore I propose to re-word R9 as :

"The IGL SHOULD provide an extension mechanism to allow smart contract to be defined where appropriate for the business context. "

I've updated the page accordingly. let use know if there are any remaining concerns.

[monkeypants]

blocking re-use of single-use contracts is only one type of rule.

You mean single-use documents, like permits, right? Use of word contracts is throwing me a bit here.

The IGL SHOULD provide an extension mechanism to allow smart contract to be defined where appropriate for the business context.

SHOULD means recommended but not compulsory (https://tools.ietf.org/html/rfc2119). Are you saying the spec probably should but it's OK if it doesn't allow this mechanism?

Do you mean that specific channels may implement policies (using smart contracts) that restrict the messages that can be sent, depending on the business context of the channel? Because I think that's what it should say, but I can't get reading that from the new text.