RVV Scenario: Reporter + Vendor1 + Vendor2
Overview
The RVV scenario extends the baseline rv workflow to include a second
affected Vendor (Vendor2). Vendor1 creates the case and directly invites
Vendor2 by sending an invitation through the protocol. Both vendors have
independent fix paths and must each reach the fix-ready state before 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 initially owns the case.
- Vendor2 — invited by Vendor1; an additional affected party with its own fix path.
- 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-actorcontainer, but its authority comes from the role, not from where it runs.
Protocol narrative
1. Reporter submits a vulnerability report to Vendor1
The Reporter identifies a vulnerability affecting products from both Vendor1 and Vendor2 and reports it to Vendor1 as the primary contact. This report submission is an out-of-band event; it precedes the case's creation.
Antecedent: Reporter possesses knowledge of the vulnerability.
2. Vendor1 validates and engages the case
Vendor1 reviews the report, confirms it is credible and in scope, and engages
the case. A validate_report entry and an engage_case entry appear in the
case ledger in that order.
Antecedent: Report received from Reporter (step 1).
3. Participant status records are created
Each record seated at case creation is ledgered as a create_case_participant entry, and each later status the Case Actor writes, Vendor1's engagement included, as an add_participant_status_to_participant entry.
Antecedent: engage_case is present in the ledger.
4. Vendor1 invites Vendor2
After confirming that Vendor2 is affected, Vendor1 sends Vendor2 an invitation
to join the case. This is recorded as an invite_actor_to_case entry.
Antecedent: engage_case is present in the ledger.
5. Vendor2 accepts the invitation
Vendor2 receives and reviews the invitation and decides to participate. The
acceptance is recorded as an accept_invite_actor_to_case entry.
Antecedent: invite_actor_to_case is present in the ledger (step 4).
6. Participants exchange notes
Reporter, Vendor1, and Vendor2 communicate via 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 present in the ledger.
7. Both vendors develop and ship fixes
Vendor1 and Vendor2 each advance through the fix lifecycle independently. Both reach fix-ready (VFd) state; participant status updates reflect progress.
Antecedent: engage_case is present in the ledger.
8. Vendors and Reporter publish; embargo terminates
All three participants publish. The embargo exits ACTIVE. The CS PXA state advances towards publicly-known for each participant.
Antecedent: Both vendors have reached fix-ready status.
9. All participants close the case
Vendor1, Vendor2, and Reporter each close the case.
close_case entries appear for each.
Vendor2 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 is an out-of-band API call that precedes the case's creation. |