RCV Embargo Scenario: Reporter + Coordinator + Vendor
Overview
The RCV embargo scenario follows the embargo from end to end in a three-party case. A Reporter submits a report to a Coordinator, who opens the case and invites a Vendor. Creating the case activates the default embargo, so the Reporter's later proposal revises that embargo rather than starting a first one. The Coordinator then ends the embargo deliberately, before the vulnerability is published.
Participants:
- Reporter — discovers the vulnerability, submits the report and proposes new embargo terms.
- Coordinator — receives the report; validates, engages and owns the case; activates the revised embargo and later ends it.
- Vendor — joins by invitation, consents to the revision and develops the fix.
- Case Actor — the actor that holds the CASE_MANAGER role for this case; it commits every embargo decision to the ledger and relays each proposal to the other participants.
Protocol narrative
1. Report submission
The Reporter submits the report, the Coordinator validates it and engages the case, and the Vendor joins by invitation.
The default embargo is active from case creation, so the case is at Embargo Management (EM) state ACTIVE.
Antecedent: Reporter has knowledge of the vulnerability.
2. Embargo proposal
The Reporter proposes new embargo terms.
The proposal goes to the CASE_MANAGER only, which moves the case to EM REVISE, records the proposal and relays it to the Coordinator and the Vendor.
The Vendor accepts, which records its consent and changes no EM state.
The Coordinator, as case owner, answers with its decision for the case: it activates the revision, which returns the case to EM ACTIVE.
Each participant waits for the relayed invitation on its own replica; none waits for another participant's message.
Antecedent: the case is engaged and EM is ACTIVE.
3. Fix lifecycle
The Vendor reports the fix ready. The embargo is untouched.
Antecedent: the revised embargo is active.
4. Embargo termination
The Coordinator terminates the embargo.
The CASE_MANAGER records the termination and EM moves to EXITED on the canonical case, then on each replica as the ledger entry reaches it.
Antecedent: the revised embargo is active.
5. Publication
Every participant reports publication.
The embargo has already ended, so publication tears nothing down and EM stays EXITED.
Antecedent: the embargo has ended.
6. Case closure
Every participant closes the case. The Vendor and the Reporter leave first; the Coordinator, the Case Owner, leaves last. A departure sent after the owner's is not recorded, so every other participant's departure is recorded first.
Antecedent: the vulnerability has been published.
7. Ledger dump
The scenario writes each participant's case ledger for the invariant harness, on success and on failure.