Skip to content
Reference

RVCV-extension Scenario: Reporter + Vendor1 + Coordinator + Vendor2

Overview

The RVCV-extension scenario shows a Vendor-initiated case that grows through a Coordinator to include a second Vendor via the actor-suggestion flow. The Reporter reports to Vendor1, who owns and coordinates the case. Vendor1 invites a Coordinator; the Coordinator then suggests Vendor2 to the case. Vendor1, as case owner, approves the suggestion, and the Case Actor formally invites Vendor2.

Both vendors reach the fix-ready state before joint disclosure.

Participants:

  • Reporter — discovers the vulnerability and submits the report; in the case it holds the Reporter role; the protocol has no separate Finder role (ADR-0078).
  • Vendor1 — receives the report; validates, engages, and owns the case.
  • Coordinator — invited by Vendor1; suggests Vendor2.
  • Vendor2 — joins via the actor-suggestion path; develops and ships a fix.
  • Case Actor — the actor that holds the CASE_MANAGER role for this case; it writes every canonical ledger entry and fans it out to the participants. In the demo it runs on the dedicated case-actor container, but its authority comes from the role, not from where it runs.

Protocol narrative

1. Reporter submits a vulnerability report to Vendor1

The Reporter reports to Vendor1's endpoint. No ledger entry is created yet.

Antecedent: Reporter has knowledge of the vulnerability.

2. Vendor1 validates and engages the case

Vendor1 reviews the report and accepts it. validate_report and engage_case entries appear in the ledger.

Antecedent: Report received from Reporter.

3. Participant status records are created

The Case Actor records the engagement's status as an add_participant_status_to_participant entry; each record seated at case creation was ledgered as a create_case_participant entry.

Antecedent: engage_case is in the ledger.

4. Vendor1 invites the Coordinator

Vendor1 sends the Coordinator an invite_actor_to_case entry.

Antecedent: engage_case is in the ledger.

5. Coordinator accepts the invitation

The Coordinator joins the case. An accept_invite_actor_to_case entry is recorded.

Antecedent: invite_actor_to_case is in the ledger (step 4).

6. Coordinator suggests Vendor2

The Coordinator recognizes that Vendor2 is affected and submits an offer_case_participant entry proposing Vendor2 for membership (ADR-0026).

Antecedent: Coordinator's accept_invite_actor_to_case entry is in the ledger.

7. Vendor1 approves the recommendation

Vendor1, as case owner, reviews and approves the suggestion. An accept_actor_recommendation entry is recorded.

Antecedent: offer_case_participant is in the ledger.

8. Case Actor invites Vendor2

The Case Actor, acting on Vendor1's approval, sends Vendor2 an invite_actor_to_case entry.

Antecedent: accept_actor_recommendation is in the ledger.

9. Vendor2 accepts the invitation

Vendor2 reviews and accepts. An accept_invite_actor_to_case entry is recorded.

Antecedent: The Case Actor's invite_actor_to_case entry is in the ledger.

10. Participants exchange notes

All participants communicate through case notes. Each note is sent as one Add(Note) carrying the note inline, and recorded as an add_note_to_case entry, which attaches it to the case.

Antecedent: engage_case is in the ledger.

11. Both vendors reach fix-ready

Vendor1 and Vendor2 each advance to VFd (fix-ready) status.

Antecedent: engage_case is in the ledger.

12. Participants publish; embargo terminates

All participants publish. The embargo exits ACTIVE.

Antecedent: At least one vendor has reached fix-ready.

13. All participants close the case

close_case entries appear for each participant. Vendor2, the Coordinator, and the Reporter leave first; Vendor1, 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: validate_report and engage_case are in the ledger.

Unobservable edges

Unobservable step Why not in ledger
Reporter submits report to Vendor1 Report submission precedes the case.