Skip to content
Reference

Conformance

This page is normative

This page is considered a core part of the Vultron Protocol. This is a normative section of the documentation.

The whole specification on one page

The specification is also published as a single page that holds every section and annex in order, for printing or for searching the whole text at once.

This page holds section 12 of the Vultron Protocol Specification: what an implementation claims when it claims conformance, and how that claim is tested. A conforming participant maintains the Report Management (RM), Embargo Management (EM) and Participant Embargo Consent (PEC) state machines, and the Case State (CS) dimensions. One of its roles assigns Common Vulnerabilities and Exposures (CVE) identifiers.

12. Conformance [N]

12.1 Conformance Model Overview

Conformance is two-dimensional: capability sets (what protocol machinery an implementation provides) and a role profile (which roles it claims). A conformance claim names capability sets and roles directly:

CapabilitySet [+ CapabilitySet ...] / Role [+ Role ...]

Examples: Case Observer / Reporter, Case Observer / Vendor, Case Observer / Vendor + Deployer, Case Observer + Case Decision + Case Hosting / Coordinator + Case Owner.

The Case Observer capability set is required for all participation. Role obligations are additive and orthogonal: no role subsumes another.

Capability set names and role names come from §12.2 Capability Sets and §12.3 Role Taxonomy respectively.

Roles and capability expectations. The relationship between roles and capabilities is bidirectional. An implementation must have the capability prerequisites for a role before it can be assigned that role (§12.3.1 Process Roles). Conversely, holding a role in a case creates an expectation that the implementation has those capabilities — other participants act on that assumption. See §11.1 Role Assignment for the role assignment gatekeeping rules.

Capability sets are not the same as conformance test layers

This project uses two distinct schemes, and they must not be conflated:

  • Capability sets, defined here, describe what an implementation provides — a claim an implementer makes about their software.
  • Conformance test layers (L1–L4), used in the behavioral conformance material, describe what a test verifies — syntax, semantics, behavior, and internal process structure. These are orthogonal: a Case Observer implementation is tested at layers L1 through L3.

A conformance claim names capability sets; a test result names a layer. The two are answering different questions and are not interchangeable.

12.2 Capability Sets

A capability set is a group of obligations an implementation takes on. Three are defined: Case Observer, which every participant must provide, and Case Decision and Case Hosting, which add the obligations of deciding for a case and of running one. The Case prefix marks each as a capability set — a property of software — distinct from the similarly-named roles it serves.

Most of what a capability set requires is expressed as maintaining a state machine, so that phrase needs pinning down first.

What 'implement a state machine' means

Implementing a state machine has two components:

  1. Track: maintain a local value for the machine, and update it as incoming messages report transitions.
  2. Drive: cause a transition that the participant's roles authorize, and announce it so the other participants learn of it.

The two are separate obligations. A participant that tracks but does not drive leaves the others to discover its state changes some other way. A participant that drives but does not track acts on case state it does not know. Which transitions a participant may drive depends on its roles (§12.4 Role-Specific Normative Requirements); every participant tracks.

Four dimensions, five state machines

Case State (CS) is a compound of two independent axes, so four tracked dimensions are realized as five state machines:

This specification says "four dimensions" when describing what is tracked and "five state machines" when describing what an implementation must provide. Both counts are correct; they count different things.

Case Observer capability set

The Case Observer capability set is the participation floor. Every actor that participates in any Vultron case MUST implement it.

There is no sub-Observer participation level. An actor that accepts a case invitation has committed to Observer behavior from that point. It must track state and notify others of its own transitions.

  • MUST maintain all five state machines — RM, EM, PEC, VFD, PXA — for itself: it MUST hold a current value for each, and MUST drive the transitions its roles authorize
  • SHOULD also track the states of the other participants in the case, to inform its own decisions. This is a SHOULD rather than a MUST because correct operation of the protocol MUST NOT depend on any participant holding perfect information about the others
  • MUST send the messages appropriate to its claimed roles when its own state transitions occur
  • MUST receive and update local state when notified of other participants' transitions
  • MUST participate in embargo negotiation: responding to Invite(Event), and recording consent or refusal via PEC
  • MUST route all case-scoped messages through the CASE_MANAGER (§5.4.2 Routing Topology)
  • MAY report PXA observations; no VFD drive obligations unless a role extension set adds them

Why there is no sub-Observer level

A monitoring-only actor might seem to need message parsing and nothing else. Two things rule that out. An actor that does not track its own PEC state cannot take part in embargo negotiation, and the CASE_MANAGER decides what to send it on the basis of that state — so an untracked participant cannot be reliably served. An actor that does not track RM has no basis for evaluating case status. Meaningful use of Vultron data requires the full Observer set.

The protocol governs what the CASE_MANAGER sends, not what a recipient does with information it already holds. Vultron gates dissemination; it cannot constrain display.

A parse-only tool is not a case Participant: it holds no CaseParticipant record and no case is obliged to deliver anything to it.

Role-specific drive obligations

All Observer participants track all five machines. Which transitions a participant drives depends on its role extension set: a Vendor drives its own VFD transitions; a Reporter drives RM; any participant may report PXA observations. See §12.3 Role Taxonomy and §12.4 Role-Specific Normative Requirements.

Case Decision capability set

The Case Decision capability set defines Case Owner governance capabilities. It is separable from the Case Hosting capability set.

  • Case Observer capability set, plus:
  • Status updates MUST be adopted without requiring an external approval gate (the Case Owner's own updates are authoritative)
  • MUST be able to drive shared EM transitions
  • MUST be able to transfer case ownership via the Offer(VulnerabilityCase) / Accept handshake

A human Coordinator typically provides the Case Decision capability set while a service actor provides Case Hosting.

Case Hosting capability set

The Case Hosting capability set defines Case Manager infrastructure capabilities. It is separable from the Case Decision capability set.

  • Case Observer capability set, plus:
  • MUST hold the CASE_MANAGER role for each case it hosts, and therefore MUST implement the single-writer authority rules of §5.4.1 Single-Writer Authority
  • MUST maintain the authoritative canonical case ledger and replicate it to participants via Announce(CaseLedgerEntry)
  • MUST implement multi-party case management: participant invitation, acceptance, role assignment, and case ownership operations
  • MUST implement the two-seam status adoption model (§10.3 Status Adoption: The Two-Seam Model), including the canonical-write-before-side-effects ordering
  • MUST deliver full case content only when the §9.7 Gating Full Case Delivery gate is satisfied

Ledger replication mechanics are specified separately

This specification states the obligation: an implementation holding the Case Hosting capability set MUST maintain the canonical ledger and replicate it via Announce(CaseLedgerEntry). The single-writer-plus-fan-out model is normative: one CASE_MANAGER holds exclusive write authority and sends each entry to every participant actor.

The mechanics of that replication — hash-chaining, gap detection and ordering guarantees — are specified in a companion Vultron Ledger Replication Specification, which is still in draft and is not yet published alongside this document. An implementation cannot demonstrate conformance to the replication mechanics from this document alone. The reasoning for splitting them is recorded in ADR-0077.

Distributed consensus among several case managers is a possible future extension and is out of scope here.

Named configurations

Common combinations of capability sets have names because they appear frequently in real deployments. These names are informative; conformance claims use the full capability set list.

Configuration Capability sets Roles
Hosting Coordinator Case Observer + Case Decision + Case Hosting Coordinator + Case Owner
Self-coordinating Vendor Case Observer + Case Decision + Case Hosting Vendor + Deployer + Case Owner
Bug Bounty Platform Case Observer + Case Hosting Case Manager (Case Decision optional)

A Hosting Coordinator is a type:service actor that holds both CASE_OWNER and CASE_MANAGER roles. It decides and executes without a separate human approval step for its own status updates.

12.3 Role Taxonomy

12.3.1 Process Roles

Process roles define what an actor does within a case and which protocol transitions it is authorized to drive. An actor may hold multiple process roles.

Role Protocol capability
Reporter Initiates cases; drives RS; authoritative source of the original report
Vendor Drives its own VFD transition f→F (fix ready, CF)
Deployer Drives its own VFD transition d→D (fix deployed, CD)
Coordinator Drives case participant management; coordinates multi-party disclosure
CVE Numbering Authority (CNA) May assign CVE IDs directly; a participant without the role delegates assignment. Orthogonal to the other roles, and typically co-held with Coordinator or Vendor
Observer Holds no drive obligations for VFD; may report PXA observations (§12.4.2 Participant-Agnostic CS Transitions (PXA))

Capability prerequisites. Every case Participant — whatever its roles — MUST implement the Case Observer capability set (§12.2 Capability Sets, §12.3.3 Roles and Capability Sets Are Independent). Role extension sets add obligations on top of that floor; they do not substitute for it. An implementation SHOULD verify that an actor has the capability prerequisites for a role before completing a role assignment (§11.1 Role Assignment).

This specification states the per-role obligations in §12.4 Role-Specific Normative Requirements. It does not yet state a complete capability prerequisite for every role.

Note on Reporter

Reporters are most often also the discoverer of the vulnerability, but the protocol is concerned with who reported it, not who found it. The identity of the original discoverer may be recorded in the report itself or in case Notes, but nothing in the technical protocol hinges on that distinction. Reporter is the protocol-salient role from first contact.

12.3.2 Protocol Coordination Roles (protocol authority)

These roles confer specific protocol-layer authority and are distinct from process roles. They describe what an actor controls within the protocol machinery, not what it does in the world.

Role Protocol authority
Case Owner Authoritative decision-maker for a case; status updates are treated as authoritative without requiring approval; drives shared EM transitions
Case Manager Holds the case's single-writer authority (§5.4.1 Single-Writer Authority): writes the canonical case ledger, relays case-scoped messages, and manages the roster on the Case Owner's behalf (§2.2 Roles). Authority follows the role, not the actor that holds it; the role is commonly co-held with Coordinator but need not be (§12.3.3 Roles and Capability Sets Are Independent)

Delegation scenarios: Protocol responsibilities may transfer during a case lifecycle. For example, a Reporter who initially creates a case may delegate coordination to a Coordinator (reporter → coordinator hand-off), or a primary Vendor may bring in additional Vendors as the case grows. When a Case Owner transfers ownership (via Offer(VulnerabilityCase) / Accept handshake routed through the CASE_MANAGER), the receiving actor acquires Case Owner authority and the associated protocol responsibilities.

Open architectural question: key handover

Moving the CASE_MANAGER role to a different actor raises an unresolved key-handover question for future case-encryption designs. The question is stated once, at §11.3 Case Ownership Transfer.

12.3.3 Roles and Capability Sets Are Independent

A role is a position within a case. A capability set is a property of software. Mixing them produces contradictions, so the relationship is stated explicitly:

  • Every case Participant — whatever its roles — MUST implement the Case Observer capability set. Holding a role means having a CaseParticipant record, an RM state, and therefore tracking obligations.
  • A parse-only actor is not a case Participant: it holds no role and no case owes it delivery.
  • An implementation holding the Case Hosting capability set additionally hosts the CASE_MANAGER role and is obliged to run the ledger. Case Hosting is commonly co-held with the Coordinator role. Ledger authority follows the CASE_MANAGER role the implementation holds — not its hosting location, and not any actor name (ADR-0088).

Observer is a participant role, not a passive state

An Observer role holder that is in a case implements the full Case Observer capability set: it has an RM state, it is subject to embargo consent, and it may report PXA observations. The Observer role is distinguished by holding no VFD drive obligations — not by being exempt from state tracking.

Observer role admission follows the standard Invite / Accept(Invite) path. Role semantics are normative per ADR-0057; see the note at §12.3.1 Process Roles.

12.4 Role-Specific Normative Requirements

12.4.1 Participant-Specific CS Transitions (VFD)

VFD records what a specific participant has done, so authority to cause a VFD transition is scoped to the participant that did it.

Recall: vendor/fix/deploy states

State Vendor Aware Fix Ready Fix Deployed
vfd no no no
Vfd yes no no
VFd yes yes no
VFD yes yes yes

Full definitions are in §8.1 VFD — Vendor Aware, Fix Ready, Fix Deployed.

For self-reported VFD transitions (a participant advancing its own state via the local trigger path):

  • f→F (VFd, fix ready): MUST only be driven by an actor holding Vendor; MUST fail when Vendor is absent
  • d→D (VFD, fix deployed): MUST only be driven by an actor holding Deployer; MUST fail when Deployer is absent
  • A Vendor-only actor MUST NOT advance past VFd without also holding Deployer

Publishing a fix is not deploying it

A vendor that publishes a patch has made the patch available. It has not deployed it: deployment happens in the systems that run the product, and it is a Deployer's act. Fix Ready and Fix Deployed are therefore distinct protocol facts, and one MUST NOT be inferred from the other.

The same separation applies to public awareness. A notification that information is public sets Public Aware, which is world state. It MUST NOT set Fix Deployed, which is participant state requiring the Deployer role. An implementation that treats publication as deployment produces an unauthorized VFD advance.

Open question: who may assert that a vendor became aware

The first VFD transition — v→V, vendor becomes aware — has no trigger-side specification and no implementation. Design intent is a third-party assertion ("I notified this Vendor"), not a self-report.

Open questions: who may assert it, whether the subject Vendor may dispute it, and whether transport-level delivery success, a Hypertext Transfer Protocol (HTTP) 200 response, suffices to constitute the assertion.

Do not infer a rule from this document's silence.

12.4.2 Participant-Agnostic CS Transitions (PXA)

PXA records the state of the world rather than the state of any participant, so these transitions are not scoped to a role. Anyone may notice that a vulnerability has become public.

Recall: public/exploit/attacks axes

Axis Not yet Set Meaning when set
Public Aware p P The vulnerability is known outside the case participants
Exploit Public x X An exploit for the vulnerability has been published
Attacks Observed a A Attacks exploiting the vulnerability have been seen

Full definitions are in §8.2 PXA — Public Aware, Exploit Public, Attacks Observed.

PXA records the state of the world rather than of any participant, so any participant MAY report a PXA observation. These transitions are role-ungated: information may become public, exploits may appear, and attacks may be observed independently of anything a case participant does or causes.

  • p→P (publicly aware): any participant may report
  • x→X (exploit public): any participant may report
  • a→A (attacks observed): any participant may report

Reporting is not adoption. A reported observation is a claim. Whether it becomes canonical case state, and whether it triggers embargo teardown, is decided by the CASE_MANAGER, following the two-seam model of §10.3 Status Adoption: The Two-Seam Model and subject to Case Owner authorization by default. The role rule here — who may report — is deliberately separate from the authorization rules there — what the CASE_MANAGER does with a report.

Informative: automated observers

An actor may be an automated service that monitors external sources — threat feeds, public disclosures, vulnerability databases — and reports what it finds into a case. Such a service is not a distinct protocol role: it reports PXA observations on the same terms as any other participant, and its reports are adopted through the same authorization as theirs (§10.3 Status Adoption: The Two-Seam Model).

12.4.3 CVE ID Assignment

An actor holding the CVE Numbering Authority (CNA) role MUST be able to assign CVE IDs, which requires evaluating a vulnerability against the eligibility criteria before assignment.

An actor that does not hold the CNA role MUST delegate ID assignment. It MAY delegate to an external CNA service, or to another participant in the same case that holds the CNA role — a coordinator or vendor acting as a CNA can perform the assignment without the case leaving the protocol.

Eligibility criteria posture. This specification does not normatively cite a specific edition of the CNA Operational Rules, nor does it treat eligibility checks as fully implementation-defined. Instead, the reference implementation follows CNA Operational Rules v4.1.0 as the conformance baseline. Adopting a newer edition requires updating the spec and the implementing call-out. This avoids coupling the Request for Comments (RFC) to an independently-versioned external document's release cycle while remaining transparent about which edition the reference implementation follows.

Eligibility checking is a single logical capability: the full set of criteria applied as a unit against one rules edition. The protocol treats it as one decision with one outcome, and does not specify how an implementation reaches that decision.

12.4.4 Case Owner Authority

Adopting a reported status as canonical case state requires the Case Owner's authorization. The Case Owner is the party whose disclosure decision the case exists to serve, so it is the party entitled to decide what the case asserts. The CASE_MANAGER MUST obtain that authorization by default before adopting a participant's reported status (§10.3 Status Adoption: The Two-Seam Model).

One case is exempt. Where the Case Owner is itself the sender, the CASE_MANAGER MUST adopt the status without seeking approval: asking the Case Owner to approve its own report would be circular.

12.5 Conformance Testing Approach

Conformance is judged from outside the implementation. A test supplies a sequence of messages and an input state, and checks the messages the implementation emits and the state it reaches. It does not inspect internal structure.

Each test case is therefore a message-sequence scenario paired with the state outcome it expects.

Some capabilities that define a role are not protocol-observable at all. Developing a fix, deploying a fix and publishing an advisory happen outside the protocol. Conformance verifies the protocol messages that this work produces, not the work itself.

Conformance testing is organized in four layers, which describe what a test verifies. Layers are orthogonal to the capability sets of §12.2 Capability Sets, which describe what an implementation provides (see the warning in §12.1 Conformance Model Overview):

Layer Verifies
L1 — Syntax Messages are well-formed against the wire format (§5 Syntactic Layer — Wire Format)
L2 — Semantics Each message drives the correct state transition (§4 Semantic Layer — Message Meanings, §6 Report Management (RM) State Machine through §11 Participant Lifecycle Within a Case)
L3 — Behavior Correct observable outputs: right messages emitted and states reached, given input state plus received message
L4 — Process Correct internal decision structure (e.g. precondition before state write before side-effect)

L4 is only enforceable against a reference implementation and is therefore outside the scope of independent conformance claims. Some process ordering surfaces at L3 where the output sequence is itself observable — the canonical-write-before-side-effects rule of §10.3 Status Adoption: The Two-Seam Model being the clearest case.

See also

  • Process Models — the behavioral material the L2 and L3 layers test against

12.6 Capability Shapes

Capability shapes describe optional, pluggable capabilities an implementation may connect to its own decision points. They are not part of the Case Observer, Case Decision or Case Hosting capability sets, and a conformance claim does not state which shapes an implementation provides.

Where an implementation does provide a capability shape, it MUST satisfy that shape's contract. The shapes and their contracts are described in Annex G Capability Shapes.