What is the purpose of the ReplayCouples attached to keri events in keripy on kli export?

[daidoji]

In keripy when exporting a kel first seen replay couples are attached to KERI events similar to below (using a snippet of code from our kerilixir implementation but you get the idea).

    CountCode.CD_E_FirstSeenReplayCouples.new([
        Primitive.CD_0A_Random_salt_seed_nonce.new(<<inc_event.s_sequenceNumber::size(16)-unit(8)>>),
        Primitive.CD_1AAG_DateTime.from_b64("1AAG" <> Utilities.keri_b64_datetime_now())
    ])])

What are the purpose of these replay couples? Security-wise we don't sign this information so attackers on the wire can change this at will. Also a malicious controller/transmitter can put whatever they want here so it doesn't suffice as a replay attack defense mechanism.

Is it just a forensic mechanism for kli export to signal when this event was first-seen or does it serve a security purpose like its use as some sort of nonce or something elsewhere that is escaping us?

[SmithSamuelM]

The first seen replay couple acts like a notification for convenient discover. Like any discovery mechanism in KERI. If a validator wants to veriify the dicovered information it chan. They just need ask for a replay of the FEL (FirstSeenEvent Log). The couple lets them know where in the FEL this KEL event shows up so they can query just that event instead of the whole FEL each time. When a Juror or Judge or Validator is managing duplicity seen in some KEL, where there has been a recovery rotation , then the disputed event in the fork created by the recovery rotation will not be replayed in the KEL. These components may find it useful to see the full set of events in "first seen order" by replaying the FELs from different watchers or jurors in the jury pool to decide how to reconcile that duplicity if at all. The FEL is fully verifiable like its KEL. The FEL cannot be forked so each event gets a monotonically increasing first seen sequence number that may not be that same as the KEL sequence number. They will be the same if there are no recovery rotations with disputed events. But as soon as there are any disputed events forks then the FEL sequence number will diverge from the KEL. The notification via the couple makes it easier to query the FEL for a given KEL SN where they are no longer the same number. One always must validate that the events are the same as returned by the query. If not in the case of an attack where the attacker falsifies the couple then the validator will have to walk the FEL to find the event. So its easy to protect ones self from such an attack. Its really an annoyance but the tradeoff is the the majority case is the couple is compact when not signed.

In the case of a Judge's Jury Pool where the Judge controls the Jury watchers and the Judge has good reason to trust them, then the datetime stamp of the first seen event can be used to adjudicate which version of a duplicitous event was "first seen" in time by a juror.

This can be secured by having the replay of the FEL evert use a signed reply `rpy' message from juror to judge. This discovery is similar to how OOBIs work and and how in general query/reply works. The query message is singned and the reply message is signed so queriying a watcher for the FEL event at the first seen sequence number from the couple will return the event itself which is signed by the controller of the event but the FSN and the Datetime are signed by the replier as part of the replay message since they are not in the actual event itself.

Similarly if the KEL replay in the first place is replayed via signed reply messages then both the First seen number and its datetime are signed by virtue of being included in the signed reply message. So not an attack vector in this case.

[daidoji]

Got it, thanks.