docs(rfcs): RFC-AI-0008 — the coordinator role (multi-hop relay of security reports)

[ppkarwasz]

What

Adds RFC-AI-0008 (status: Draft): names the coordinator persona of coordinated vulnerability disclosure — the party that receives, triages on behalf of others, and forwards to the owning vendor — and defines:

• CVD role vocabulary (finder / reporter / coordinator / vendor), with a strictly pairwise relay contract instead of named chain levels;
• the coordinator profile (functions + termination authority + upstreams + downstream directory);
• provenance fields carried verbatim across hops (finder credits, append-only reporter chain, origin references, embargo terms);
• the handling-identifier exchange between hops;
• bidirectional forwarder adapters (emit templates + detect signatures in one directory, closing the current two-repo drift gap);
• coordinator-mode skills (security-coordinator-import / -assess) generalized from the ASF Security team's out-of-tree pipeline, which becomes the reference adopter.

Review fallout (second commit)

Cross-reference verification of the RFC against the tree surfaced two pre-existing inconsistencies, fixed here:

• tools/forwarder-relay/README.md still documented contact_handle: '@raboof' as the shipping default, contradicting the newer org-level security@apache.org in organizations/ASF/organization.md (feat(organizations): introduce Organization-adapter entity + document adapters #622). The shared inbox is now the documented default; an individual liaison's handle remains the override example. The one stale worked example in docs/security/forwarder-routing-policy.md is updated to match.
• CONTRIBUTING.md's directory-tree comment enumerated "RFC-AI-0002, 0003, 0004" (stale since 0005); it now says "RFC-AI-0002 onward".

Modified paragraphs are reflowed to semantic line breaks per #1108.

🤖 Generated with Claude Code

https://claude.ai/code/session_018SKtoF3YBbXye9jmnZp1Pt

[potiuk]

Reviewed as a design read rather than a code review, since this is a Draft that implements nothing.

Checks that came back clean:

• Numbering is correct — 0002 through 0007 exist, 0008 is free.
• Conforms to the sibling RFC shape (Abstract / Status / Motivation / Proposal / Drawbacks / Alternatives considered / Out of scope / References, per RFC-AI-0007), and adds a Security model section, which is right for this subject.
• Confidentiality: no real CVE IDs, no other ASF project named in a vulnerability context, no personal handles beyond the liaison discussion. The one address hit is CNCERT/CC's public intake, which is correct in a forwarder-adapter context.
• HITL is preserved — "drafts only; a human sends", and verdict is structurally excluded from coordinator functions rather than merely discouraged.
• No PRINCIPLES.md edit, so no amendment vote is triggered.
• There is no RFC index that needs a new row; the existing 0006/0007 references elsewhere are contextual rather than enumerative.

On the review-fallout half: moving contact_handle to the shared security@apache.org inbox and demoting the individual handle to an override example is the right direction — it takes a single person out of shipped config while keeping the liaison pattern documented.

The Drawbacks section naming the single-reference-adopter overfitting risk is good practice; that is the failure mode most likely to bite here.

One substantive point inline, about §15 and the Security model section. I believe the RFC already complies via the per-hop dedup scoping — the issue is that the compliance is implicit where §0's is explicit. Left open for you rather than resolved, since it is a design question rather than a nit.

---

🤖 This review was drafted by an AI-assisted tool and may contain mistakes. It has been reviewed and confirmed by an Apache Magpie maintainer before submission. See CONTRIBUTING.md for what this project considers a maintainer review.