02 · Specification family
The five documents
Four normative specifications and one informative overview. Each answers a single question. Read them in order — later documents assume the earlier ones.
- Normative
- 4BI-002, 004, 008, 009
- Informative
- 1BI-001
- Standards track
- 1IETF Internet-Draft
- Assertions
- 112testable, in BI-009
Contents
01
Normative and informative
The distinction is not decorative. You can conform to a normative document. You cannot conform to an informative one.
| Class | Contains | Binding? |
|---|---|---|
| Normative |
Requirements stated with MUST, MUST NOT, SHOULD,
SHOULD NOT, MAY — as defined in BI-009 §0.
Every requirement is testable and appears in the conformance suite.
|
Yes. An implementation either satisfies it or does not. |
| Informative | Context, rationale, worked examples, and reference code. Explains why the normative documents say what they say. | No. Nothing here can be conformed to, and nothing here adds a requirement. |
Mixed documents are marked internally
BI-008 is normative, but two of its three appendices are not. Appendix A (reference Merkle implementation) and Appendix C (reference implementation) are informative — they illustrate, they do not require. Appendix B (test vectors) is normative: a log that does not reproduce those vectors is not conformant.
Read the heading, not the document title. An implementer who treats Appendix A as binding has copied our code when they should have written their own — and independent implementations are the point.
Source: BI-008 Appendices A, B, C
02
The document map
Each document answers one question. Later documents assume the earlier ones and do not repeat them.
- BI-001 Architecture Overview Why is this an integration profile, and what is actually new? Informative
- BI-002 Broadcast Object Model What is a broadcast object, and how is it identified, versioned, and described? Normative
- BI-004 Publisher Authority Who is allowed to correct this record, and how does a consumer check? Normative
- BI-008 Supersession Protocol How does a correction reach a system that cannot delete? Normative
- BI-009 Conformance How do I prove — or disprove — that an implementation is correct? Normative
Dependency order
The arrows are load-bearing. BI-008 cannot be implemented without BI-004 — a log that accepts statements without verifying publisher authority is a censorship weapon, not a transparency log.
BI-001 Architecture Overview informative — read first, cite never
│
│ (frames)
▼
BI-002 Broadcast Object Model the record: identity, versioning, fields
│
├──────────────────────────────┐
▼ ▼
BI-004 Publisher Authority BI-008 Supersession Protocol
│ who may correct │ how the correction propagates
│ │
│ BI-008 §8.1 REQUIRES BI-004 │
└───────────────►───────────────┘
│
▼
BI-009 Conformance 112 testable assertions over all of the above
Sources: BI-001 §4 (Document Map) · BI-008 §8.1
03
BI-001 — Architecture Overview
Informative Frozen
Why this is an integration profile, and what in it is actually new. Nothing in BI-001 is binding. It exists so that a reviewer can judge the architecture before reading a single requirement.
Sections
| § | Section |
|---|---|
§1 | What This Is |
§2 | What Is Actually New — the honest inventory of the novel contribution |
§3 | The Central Security Property |
§4 | Document Map |
§5 | Conformance Levels, in One Paragraph |
§6 | What This Family Does Not Claim |
§7 | Governance and Ownership — the donation intent |
§8 | Reference Implementation |
Read §2 and §6 together
§2 states what is new. §6 states what is not claimed. A reviewer who reads only §2 will overestimate the work; a reviewer who reads only §6 will underestimate it. The architecture is only assessable with both.
§7 is the section most likely to be cited against us: it commits the correction protocol to donation to a standards body, and no steward has yet been named. See Governance.
04
BI-002 — Broadcast Object Model
Normative Frozen
The record itself: what a broadcast object is, how it is identified, how it is versioned, and what it must state. Everything else in the family builds on this.
Structure
| § | Section | Why it matters |
|---|---|---|
§2 | Terminology | Includes §2.4 Namespace Policy — the unmet steward gate |
§3 | Object Hierarchy | Work / Edit / Manifestation, after FRBR and EIDR |
§4 | Identifiers and Versioning | §4.4 content-addressed versionId; §4.5 Memento |
§5 | Serialisation and Discovery | JSON-LD, Signposting, content negotiation |
§6 | Common Fields | Present on every object |
§7–§9 | Work, Edit, Manifestation | The three object types |
§10 | Transcript | fidelityClass — the field that decides whether a quote may be attributed |
§11 | Entity | basisOfIdentification; §11.1 makes consentStatus mandatory for biometric matches |
§12 | Rights | §12.1 aiUsage — training and retrieval as separate permissions |
§13 | Provenance | C2PA for the essence; PROV-O for the record. They are not interchangeable. |
§14–§18 | Claim, Disclosure, Accessibility, Distribution, Archive | Disclosure booleans are explicit, never omitted |
§19 | Correction and Supersession | Where BI-002 hands off to BI-008 |
§20 | Conformance | Levels 1 Core, 2 Verified, 3 Governed |
§21 | Security Considerations |
The two fields that carry the model
Both are described in full on the overview. They are repeated here only because implementers skip them, and both are where the record stops being honest if you get them wrong.
| Value | Meaning |
|---|---|
script-derived | The words as written for broadcast |
human-authored | A person typed this |
human-corrected | A machine drafted it; a named human took responsibility |
asr-inferred | A machine guessed, and nobody checked |
The hard part of BI-002 is organisational, not technical
Every deadline pressure pushes toward declaring a transcript human-corrected when
someone glanced at it, and script-derived when the ASR output happened to be clean.
The schema makes that harder. Only the publisher can make it not happen.
These fields are the ones on which the whole family's value rests. A record that lies about
fidelityClass is worse than no record, because it launders a machine's guess into
an attributable quotation.
Source: BI-002 §10 · BI-009 CON-6
05
BI-004 — Publisher Authority
Normative Frozen
Who is allowed to correct a record, and how a consumer checks — rooted entirely in the ordinary Web PKI. No new trust framework. No registry. No gatekeeper.
Structure
| § | Section | Why it matters |
|---|---|---|
§3 | The Authority Chain | Origin control, proven with X.509 + Certificate Transparency |
§4 | Authority Types and Scopes | object-sign, correct, supersede, withdraw — unordered |
§5 | The Authority Document | Served at a well-known URL, with Memento history |
§6 | Key Lifecycle | Rotation, revocation, delegation, compromise recovery |
§7 | Authorisation Verification | §7.1 the effective-time rule; §7.2 the 12-step algorithm |
§8 | Failure Semantics | Fail closed. Always. |
§9 | Threat Model | Including T-6 retroactive repudiation and T-7 domain hijack |
§10 | Conformance Requirements | AUTH-* |
§12 | Open Issues | Published, not buried |
The two things implementers get wrong
1 · Scopes are not ordered
A key may hold correct without holding withdraw. This is not an
oversight — it is the design.
If a publisher's online signing key is stolen, the attacker can publish a false
correction but cannot erase the broadcast. Withdrawal requires a separate key, held
offline. A model in which correct implied withdraw would make the
routine compromise catastrophic.
Source: BI-004 §4
2 · Authority is evaluated at the log timestamp, not now
A consumer resolves the Authority Document as it stood when the statement was merged, using Memento — not the version being served today.
This is the bug most implementations will write. Checking the current document
instead would invalidate a publisher's entire correction history on the first key rotation —
and it passes every happy-path test before doing so. The reference implementation carries a test
(A1′) whose only purpose is to fail if someone writes it.
Source: BI-004 §7.1
06
BI-008 — Supersession Protocol
Normative Frozen The novel contribution
How a correction reaches a system that cannot delete. This is the one part of the family that does not already exist somewhere else — and it is the part intended for donation to a standards body.
Structure
| § | Section | Why it matters |
|---|---|---|
§2 | Threat Model | Including T8b cross-log replay, closed at the consumer |
§4 | The Supersession Statement | §4.2 RFC 8785 canonicalization; §4.3 signature algorithms; §4.4 idempotence |
§5 | The Log | §5.1 the timestamp-bound leaf — the fix for Critical finding C-1 |
§6 | Proofs | Inclusion, consistency, and the honest cost of completeness (§6.3.1) |
§7 | Severity Classes and Consumer Obligations | §7.0 Maximum Poll Interval; the five MADs |
§8 | Message Flow and Endpoints | Nine public endpoints. Nothing implementation-specific. |
§9–§10 | Monitor and Auditor roles | Gossip is a MUST. An auditor that does not gossip provides no equivocation defence. |
§11 | Log Operator Requirements | §11.4.1 what "independent" means; §11.6.1 disaster recovery |
§13 | Failure Modes | F1–F16. Fail closed. |
§15 | Privacy Considerations | Statement descriptions MUST NOT contain personal data — the log cannot forget |
§16 | Open Issues | Including the verifiable map deferred to v1.1 |
The appendices are not all normative
| Appendix | Status |
|---|---|
| A — Merkle construction | Informative Illustrates. Do not copy it; write your own. |
| B — Test vectors | Normative A log that does not reproduce these is not conformant. |
| C — Reference implementation | Informative Non-normative. |
The leaf binds the log's own timestamp
Every authority decision in BI-004 §7.1 turns on when a statement was logged. That timestamp is therefore committed inside the Merkle leaf — so a log cannot restate it after the fact.
A one-millisecond restatement is a hard verification failure. This was not true in the previous candidate; see Security review, C-1.
Source: BI-008 §5.1 · Appendix B
07
BI-009 — Conformance
Normative Frozen
How to prove — or disprove — that an implementation is correct. 112 testable assertions across five roles.
Structure
| § | Section | Prefix |
|---|---|---|
§0 | Requirement Language | — |
§2 | Publisher Conformance — Object Levels | OBJ-* |
§3 | Publisher Protocol Conformance | PUB-* |
§4 | Consumer Conformance | CON-* |
§5 | Log Operator, Monitor, Auditor | LOG-*, MON-*, AUD-* |
§5.4 | Canonicalization — gating | JCS-* |
§6 | Automated Conformance Testing | — |
§7 | Certification | §7.3 no mark. §7.4 the portability test. |
§8 | Conformance Claim Format | — |
§9 | Open Issues | — |
§5.4 gates every other assertion
An implementation whose RFC 8785 canonicaliser fails any golden vector
must not claim conformance at any role or level. Not waivable. Not reportable
as not-automatable. Fully automatable; no judgement involved.
That gate exists because the reference implementation itself failed it. If we could ship that defect, so can anyone.
§7.3 — there is no conformance mark
We do not operate a certification programme, we do not issue a badge, and we do not maintain a list of approved implementations. A mark under our control would be a registry, and a registry is a chokepoint.
There is a test suite. You run it. You publish the result.
Six assertions cannot be automated — they are reported as
not-automatable, never as pass, and each requires a
named human attestor of record.
Source: BI-009 §7.3 · erratum m-8
08
Supporting artifacts
Machine-readable, runnable, and checkable. None of it requires our cooperation.
-
draft-alexander-bsp-00The Supersession Protocol as an IETF Internet-Draft. Prepared for submission. This is the vehicle by which the protocol leaves our hands. - JSON Schema Validates a Broadcast Object against BI-002. Run it in CI.
- JSON-LD context 93 terms. Resolve terms through the context — never string-match the namespace IRI, which is provisional and may be reallocated.
- Three worked examples A television commercial, an interview, a livestream replay. All validate.
- Normative test vectors Normative Merkle roots, inclusion and consistency proofs — and the attack vectors a conformant log must reject, including a one-millisecond timestamp restatement.
-
MANIFEST.jsonMachine-readable release record. Verdict, open gates, errata, and the post-freeze amendment history. The same artifact as the one in the package — not a copy of it. - Conformance suites Validation, negative tests, the 30 RFC 8785 golden vectors, and cross-document consistency checks. Run them yourself.
09
Reading paths
Nobody needs all five documents. Read for your role.
| If you are… | Read, in order |
|---|---|
| Evaluating the idea | BI-001 — then stop. It is informative and short, and it states what the family does not claim. |
| Implementing a publisher | BI-002 → BI-004 → BI-009 §2–§3 |
| Implementing a consumer | BI-008 §7 → BI-004 §7 → BI-009 §4 (CON-*) |
| Operating a log | BI-008 §5–§11 → Appendix B → the Log Operator Onboarding Package |
| Writing a monitor or auditor | BI-008 §9–§10 → BI-009 §5. Nobody has built one yet. |
| Reviewing it adversarially | The audit first. Then BI-008 §5 and BI-004 §7 — the two places a Critical was found. |
If you are implementing anything, start by running the conformance suites against your own code before you read the prose. The suites are the specification made executable, and they will tell you what you have got wrong faster than we can explain it.
10
What is not in the family
Readers repeatedly assume a gap is an omission. It is a decision, and it is stated here so that nobody has to guess.
BI-005 and BI-006 do not exist and are not being written
They are referenced by BI-001 as possible future work. No such documents exist, none are drafted, and none are planned for v1.0.
The one consequence is recorded honestly: ODRL profile validation
(OBJ-3.3, OBJ-3.4) has no profile to validate against. Those assertions
are reported not-validated — never pass.
Source: audit/KNOWN-ISSUES.md
| Not provided | Because |
|---|---|
| A new identifier scheme | EIDR, Ad-ID, ISAN and ISNI already exist. The canonical name of an object is an ordinary HTTPS URL that resolves. |
| A new trust framework | Authority is rooted in the Web PKI. A new trust root would be a new gatekeeper. |
| A registry | A registry is a chokepoint. BSP allocates no identifiers and maintains no list. |
| A conformance mark | BI-009 §7.3. A mark under our control would be a registry by another name. |
| A Version 2 | The family is frozen. Two items are deferred to v1.1 and named: a verifiable map, and key transparency. |
11
Change control
The family is frozen. Errata only, and only from independent review.
| Change | Permitted? |
|---|---|
| Erratum correcting a defect found in review | Yes The only permitted change. |
| New feature, field, or requirement | No |
| New terminology | No |
| Clarifying an existing requirement without changing it | Yes As an erratum, published. |
| Silently editing a published document | Never Every change appears in the changelog and the errata list. |
Errata already applied
FC1 exists because an adversarial audit found defects in the previous candidate: 2 Critical, 7 Major, 8 Minor, 6 Editorial. The remediation surfaced three further defects the audit had missed. Every one is published, with the correction and the regression test that now guards it.
One editorial item is formally deferred (e-5) with its reason, risk,
target, and workaround stated. It has no conformance impact. Deferring it openly is better than
fixing it quietly.
Changelog & errata The audit that produced them
Submit an Independent Engineering Review
Email [email protected]
Security findings, interoperability reports, conformance issues, implementation feedback, and specification comments are welcome.
Substantive technical reviews may be published, with attribution unless anonymity is requested.