06 · Governance
Who holds this, and who should
A specification that claims to have no chokepoint, published by an organisation that currently edits it, stewards its namespace, and operates its only log. That concentration is the problem this page exists to describe rather than to defend.
- Namespace steward
- NoneM-7 gate — unmet
- Independent logs
- 0Level 3 needs 2
- Options documented
- 3no decision made
- Intended destination
- Donationto a standards body
Contents
01
Conflict-of-interest disclosure
This is the first section of this page, not the last, because it is the thing a hostile reviewer will find first — and finding it themselves is worse.
360WiSE holds three roles at once
| Role | Held by |
|---|---|
| Editor of the specification family | 360WiSE |
| Candidate interim steward of the namespace | 360WiSE |
| Operator of Reference Implementation #001, and of the only log | 360WiSE |
That is three conflicts of interest in one organisation. It is a legitimate concern for a reviewer to raise, and the specification's own conformance code is written to refuse the claims that concentration would otherwise let us make.
The mitigations are structural rather than promissory. They are the reason the family mints no identifiers, operates no registry, and issues no conformance mark — each of those would have been a lever this concentration could pull.
| Lever we could have held | Why we do not |
|---|---|
| A conformance mark | BI-009 §7.3 — there is none. A mark under our control would be a registry by another name, and we would be certifying our own competitors against a suite we wrote. |
| A registry of identifiers | None exists. Objects are named by ordinary HTTPS URLs on the publisher's own domain. We allocate nothing. |
| A privileged log | Level 3 requires two independent logs, and our own code refuses to claim Level 3 while ours is the only one. |
| A lock-in feature | BI-009 §7.4 — a feature that makes migration harder is a defect, not a moat. |
02
What is actually blocked
Precision matters here, because "the namespace has no steward" sounds either fatal or trivial depending on how it is read. It is neither.
FC1 MUST NOT be published as Final until both are true
-
The
bo:namespace IRI and the JSON-LD context resolve under a domain controlled by a named steward with a published continuity commitment -
A named entity is responsible for submitting and maintaining the IANA
broadcast-authorityregistration
Source: M-7 · BI-002 §2.4 rule 6 · BI-004 §11.2
What is not blocked
Public review, implementation, and the Reference Consumer are not blocked.
The namespace is provisional, not broken. Rule 3 of §2.4 means
no object needs rewriting if the prefix later moves — and erratum
m-11 makes versionId provably stable across a reallocation, because it is
computed over the compact document as serialized.
Every technical mitigation presupposes an operator who does not exist
A versioned context, a defined prefix-reallocation rule, identifiers stable across a move — all of it is in place and all of it works. All of it assumes somebody is there to serve the context, honour the 301, and keep the domain registered.
This is a governance gap, not an engineering one, and no further engineering closes it. You cannot assess the durability of a thirty-year archive whose vocabulary might stop resolving — and durability is the entire proposition.
The domain is squattable today
An unstewarded namespace is not a theoretical risk. It is a live one, and it compounds the longer the namespace is public and unclaimed.
03
Three stewardship options
Published in full, including the recommendation and its risks. No decision has been made.
- Option A 360WiSE as interim steward Fast, honest, and a conflict of interest that must be published rather than managed. Bridge
- Option B Neutral nonprofit or independent governance entity Cleaner standing — if it is genuinely funded and genuinely multi-party. Slow
- Option C Contribution to an established standards body IETF, W3C, IPTC, SMPTE. Discharges both halves of M-7 at once. Destination
Option A — 360WiSE as interim steward
| Governance | Simplest — 360WiSE already controls the work. Requires a published, binding continuity and succession commitment: a document, not an intention. |
|---|---|
| Continuity | Minimum 10-year domain registration; registrar lock; DNSSEC; a named successor who has accepted in writing; Memento-served context with 301 on reallocation; wind-down notice of ≥ 12 months; escrow and transfer plan. |
| IANA | 360WiSE submits. Feasible — RFC 8615 registration is lightweight and does not require organisational standing. |
| Risk | The steward is also the editor and the reference implementer. Credible only if labelled interim and disclosed, not managed quietly. |
Option B — Neutral nonprofit
| Governance | Incorporate or recruit a neutral entity. Needs articles, a board, a conflict-of-interest policy, and a funding model that survives 360WiSE's involvement ending. |
|---|---|
| IANA | The entity submits. Cleaner standing than a single vendor. |
| Risk | Slow and expensive — and a nonprofit with one member and no funding is less credible than an honest interim vendor. It is Option A wearing a costume. |
Option C — Contribution to a standards body
| Governance | IETF (the BSP Internet-Draft is already written for it), W3C, IPTC, or SMPTE. The body's IPR regime applies; 360WiSE relinquishes editorial control. |
|---|---|
| Continuity | Discharged by the body. Their domain, their continuity, their institutional lifespan. That is the whole point. |
| IANA | Discharged by the body's process. Both halves of M-7 close at once. |
| Risk | Slowest, and not entirely in our control. A body may decline, or may take the work and change it. |
These are not mutually exclusive, and treating them as a single choice is the mistake to avoid. Option A is a bridge. Option C is a destination. Option B is only worth it if it is genuinely funded and genuinely multi-party — otherwise it is Option A wearing a costume.
04
The recommendation, and its risk
Option A, interim
Option A, explicitly and publicly labelled as interim, with Option C named as the intended destination.
This is the memo's recommendation. It has not been adopted. The reasoning is published so that a reviewer can disagree with it.
-
01
The domain is squattable today.
Securing it is a days-long task. The risk of not doing it compounds.
-
02
Public review does not require a permanent steward. It requires an honest one.
A published interim commitment — who holds this, under what terms, until when, and where it is going — is defensible to a hostile reviewer. Silence is not.
-
03
Waiting for Option C means no external review for a year or more.
External review is precisely what FC1 is ready for and what the work now most needs.
The risk of the recommendation, stated by the memo itself
Option A's credibility depends entirely on it being labelled interim and disclosed. An interim steward who quietly becomes a permanent one has done the thing the specification was written to prevent — and a reviewer would be right to say so.
05
Documents required
Whichever option is chosen, five documents must exist. None of them exists today.
| # | Document | Status |
|---|---|---|
| 1 | Namespace Stewardship Declaration — who holds it, under what commitment, until when, and what happens next. Published at the namespace IRI. | Not written |
| 2 | Continuity & Succession Commitment — registration term, registrar lock, DNSSEC, named successor with written acceptance, wind-down notice, escrow and transfer plan. | Not written |
| 3 | Context Serving Commitment — Memento-served history; 301 on reallocation; the §2.4 rule-3 guarantee restated as an operator obligation. | Not written |
| 4 | IANA Registration Submission — RFC 8615 template for broadcast-authority, with the named submitter. |
Not submitted |
| 5 | Conflict-of-Interest Disclosure — required under Option A. States that the steward is also the editor and the operator of Reference Implementation #001, and what that means. | Stated in §01 — not yet a signed document |
06
We need a second log operator
Level 3 requires two independent logs. One exists, and we run it. This is the condition we cannot engineer our way out of.
A correction protocol whose only log is run by the reference implementer has a chokepoint at exactly the place it claims not to have one. Your independence is the point. It is not a formality, and we cannot manufacture it.
| Asking | Not asking |
|---|---|
| Run a conforming log. Publish your independence metadata. Gossip your Signed Tree Heads. Be auditable by people who do not trust you. | No exclusivity. No fee. No editorial alignment. No governance seat. Any of those would compromise the independence we need — and the Level 3 gate would correctly refuse to recognise you. |
What you would be signing up for
The specification is frozen at v1.0-FC1 and under review. It is not Final and should not yet be relied upon operationally.
You would be an early operator of a protocol still under review, with everything that implies. We would rather you understand that now than discover it later.
07
What independence means
Defined normatively, and not self-assertable. A consumer or monitor fetches
get-log-metadata from both logs and checks these itself.
| # | Criterion | Force |
|---|---|---|
| 1 | Distinct legal entities, no common control — neither controls the other; no shared parent. | MUST |
| 2 | Distinct trust anchors; keys not in shared custody. | MUST |
| 3 | Distinct operational infrastructure — not two hostnames under one administrative control. | MUST |
| 4 | Distinct jurisdictions. Two logs subject to a single court's compulsion give no defence against compelled removal — which is much of why E-1 exists. For politically or legally sensitive material, treat same-jurisdiction logs as not independent. | SHOULD |
The self-assertion hole was closed deliberately
An earlier draft carried an is_self_operated boolean. It was deleted
— because a commonly-owned second log would simply have set it to false.
Independence is now derived from each log's own published metadata, so it can be checked by anyone, against nobody's word.
Source: erratum M-2 · BI-008 §11.4.1, §11.2
08
Donation to a standards body
The Broadcast Supersession Protocol is intended for donation to a standards body. It should not be ours.
BSP is the one genuinely novel contribution in this family — everything else is an integration profile over standards that already exist. A correction protocol owned by a single company is a correction protocol with an owner, and an owner is a chokepoint.
The Internet-Draft is already written for it
draft-alexander-bsp-00 exists and is prepared for submission.
It is the vehicle by which the protocol leaves our hands.
The broader family — the object model, the authority model — is a less natural fit for the IETF, and may belong with a media-standards body instead. That decision has not been made either.
Source: BI-001 §7 · spec/ietf/draft-alexander-bsp-00.md
Filing the Internet-Draft is a datestamp, and it is the step that makes the donation commitment checkable rather than stated. Until it is filed, the intent to donate is a sentence on a website.
Read the stewardship memo in full Read the Internet-Draft
Submit an Independent Engineering Review
Email [email protected]
Security findings, interoperability reports, conformance issues, implementation feedback, and specification comments are welcome. Prospective log operators and standards bodies are also welcome to write.
Substantive technical reviews may be published, with attribution unless anonymity is requested.