From 8e429fd37c58b2b4e08848f9b41465df15da0a8b Mon Sep 17 00:00:00 2001 From: Joost de Valk Date: Wed, 23 Sep 2026 10:28:14 +0200 Subject: [PATCH] Keep considered register focused on omissions readers need explained --- CLAUDE.md | 8 +++- CONTRIBUTING.md | 2 +- ops/routines/daily-standards-scan.md | 38 ++++++++++++------- src/content/considered/bluejetty.md | 22 ----------- .../considered/cross-device-flow-security.md | 19 ---------- src/content/considered/css-subgrid.md | 16 -------- src/content/considered/cyclic-trigger.md | 24 ------------ .../considered/hosting-provider-well-known.md | 22 ----------- src/content/considered/http-query-method.md | 16 -------- .../considered/oauth-browser-based-apps.md | 19 ---------- src/content/considered/sanitizer-api.md | 19 ---------- .../considered/scitt-keys-well-known.md | 22 ----------- .../considered/vacation-rental-json.md | 25 ------------ .../considered/webhook-authorized-senders.md | 22 ----------- src/content/considered/xregistry.md | 22 ----------- src/pages/considered.astro | 18 ++++++--- 16 files changed, 44 insertions(+), 270 deletions(-) delete mode 100644 src/content/considered/bluejetty.md delete mode 100644 src/content/considered/cross-device-flow-security.md delete mode 100644 src/content/considered/css-subgrid.md delete mode 100644 src/content/considered/cyclic-trigger.md delete mode 100644 src/content/considered/hosting-provider-well-known.md delete mode 100644 src/content/considered/http-query-method.md delete mode 100644 src/content/considered/oauth-browser-based-apps.md delete mode 100644 src/content/considered/sanitizer-api.md delete mode 100644 src/content/considered/scitt-keys-well-known.md delete mode 100644 src/content/considered/vacation-rental-json.md delete mode 100644 src/content/considered/webhook-authorized-senders.md delete mode 100644 src/content/considered/xregistry.md diff --git a/CLAUDE.md b/CLAUDE.md index 81327bfd..30bedfa5 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -175,10 +175,14 @@ So there are three honest shapes for a page, and all three are fine: **This particular call belongs to the maintainer, not to an agent.** If a topic is real and well-sourced but adoption looks thin, do not add the page and do not silently drop it either — surface it (Slack, for the daily scan; the PR description otherwise) and let Joost decide. -When a topic is turned down, record it in **`src/content/considered/`** — the hand-curated collection rendered at [`/considered/`](src/pages/considered.astro). One file per topic: +**Record only omissions that need explaining.** `src/content/considered/`, rendered at [`/considered/`](src/pages/considered.astro), is a selective register of credible candidates a reader could reasonably expect this specification to cover. An entry must explain that expectation by connecting the topic to existing guidance or a direct website outcome, and explain why the omission matters to readers. Being found by the scan, registered at IANA, or newly Baseline is not enough. + +Routine exclusions stay in internal scan notes or the existing PR/issue discussion. Do not create public entries for every vendor integration, specialised infrastructure protocol, or CSS/JavaScript implementation choice. A familiar source of confusion, such as AGENTS.md versus website-facing agent discovery, can still merit a short scope explanation. Thin adoption remains the maintainer's decision; a scan finding is not a decision already taken. + +For an omission that meets this bar, use one file per topic: - `title`, `date` (the decision), `reason` (`too-early` | `out-of-scope` | `too-narrow`), `sources`, and `revisit` — the last being _what would change our mind_, which is what keeps the register from becoming a graveyard. -- A two-or-three-paragraph body: what the thing is, why it did not land, and — where the reasoning generalises — what it is the reference case for. +- A short body: what the thing is, why a reader might expect it here, and why it did not land. Do not add an entry merely to illustrate a general scope rule. Being in `/considered/` is not a rejection forever. When the reason expires (something ships it; adoption broadens), delete the entry in the same PR that adds the spec page. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b8631d8d..6742d0e4 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -51,7 +51,7 @@ Just open a PR. You can use the "Edit this page on GitHub" link on any spec page A topic has to be **used**, not merely standardised. A final RFC with a permanent IANA registration still does not earn a page if nothing implements it — the page would recommend a header no cache reads. The reverse also holds: a widely-deployed convention can earn a page before its RFC lands. If adoption looks thin, say so in the issue and let the maintainer weigh it. -Topics that get turned down are recorded publicly at [`/considered/`](https://specification.website/considered/), with the reason and with what would reverse the decision. That page is worth reading before you open an issue — your topic may already be there, in which case the useful contribution is evidence that its `revisit` condition has now been met. +[`/considered/`](https://specification.website/considered/) explains selected omissions: credible candidates readers could reasonably expect this specification to cover, with the reason they are absent and what would reverse the decision. It does not catalogue every topic we decline. Vendor integrations, specialised infrastructure and implementation techniques usually need no separate entry; an IANA registration or a Baseline milestone alone does not qualify. Check the register before opening an issue: if your topic is there, evidence that its `revisit` condition has been met is the useful contribution. Note that we do **not** require the site to implement something before specifying it. Plenty of good advice does not apply to a small static site; such a page simply says so in one line, and explains why. diff --git a/ops/routines/daily-standards-scan.md b/ops/routines/daily-standards-scan.md index f676f574..7c97e5e7 100644 --- a/ops/routines/daily-standards-scan.md +++ b/ops/routines/daily-standards-scan.md @@ -94,9 +94,9 @@ context. detail and the canonical URL. A feature newly reaching Baseline supports a promotion or a new page; thin support argues against `required`. But most newly-Baseline features are CSS/JS authoring conveniences with no auditable website outcome — those do **not** earn a - page or a PR (the subgrid/PR #82 rule under "Scope & status rules"). Note them in Slack - under "skipped, and why" so the Baseline firehose stays visible without generating PR - spam. + page or a PR (the subgrid/PR #82 rule under "Scope & status rules"). Keep routine + exclusions in internal scan notes; mention only consequential scope questions in the + maintainer summary. 3. **Dead or stale citations** — sources on existing pages that 404, moved, or no longer say what the page claims. Spot-check a **rotating slice** each run, not every page every day. For MDN sources specifically, resolve the current canonical URL via the @@ -116,7 +116,7 @@ context. user-facing outcome: container queries → components adapt to the space they are given; Popover API → native semantics, focus and dismissal users can rely on. If you cannot phrase the page's "Why it matters" in terms of visitors, crawlers, or agents - — rather than the developer — skip it and mention it in Slack instead. + — rather than the developer — skip it and keep the reason in internal scan notes. - Status bar: `required` only if the web platform contract breaks without it; otherwise `recommended`/`optional`; `avoid` for outdated/harmful. Default to `recommended`. - Primary sources only (WHATWG / W3C / IETF / IANA / WCAG / schema.org first; MDN / @@ -132,13 +132,22 @@ context. well-sourced but you cannot find implementations, do not open the PR and do not silently drop it. Put it in Slack with what you checked (MDN/BCD, Chrome Platform Status, the relevant CDN or server docs) and let Joost decide. If he says add it, add it. -- **Record every turn-down.** Anything you skip on adoption or scope grounds gets an entry - in `src/content/considered/` — `title`, `date`, `reason` (`too-early` | `out-of-scope` | - `too-narrow`), `sources`, `revisit` (what would change our mind), and a short body. That - register at `/considered/` is public and is the reason the Slack "skipped, and why" - section exists: the two should agree. Adding an entry there is a normal PR, and it is the - right output for a scan that found something real but premature. When the reason later - expires, delete the entry in the same PR that adds the spec page. +- **Record only omissions that need explaining.** `/considered/` is a selective public + register, not the scan's rejection log. Before proposing an entry, explain why a reader + could reasonably expect the topic in this specification: its connection to existing + guidance or a direct website outcome, and what the reader gains from an explanation + of its absence. Finding it in the scan, in IANA, or in a Baseline update is not enough. + Do not open considered-entry PRs for routine vendor integrations, specialised + infrastructure, or implementation choices merely to illustrate a scope rule. Keep + those exclusions in internal scan notes or an existing PR/issue discussion. A familiar + confusion such as AGENTS.md versus website-facing agent discovery can qualify. +- **A finding is not a decision.** For a credible candidate with thin adoption, follow + the maintainer-call rule above. Do not turn the question into a public rejection. + After the maintainer decides to defer or exclude a candidate whose omission needs + explaining, a considered entry may be proposed with `title`, `date`, `reason` + (`too-early` | `out-of-scope` | `too-narrow`), primary `sources`, a concrete `revisit` + condition, and a short explanation. When the reason expires, remove the entry in the + same PR that adds the spec page. ## Dedup (critical for a daily job) @@ -174,8 +183,9 @@ DM the maintainer with: - New topics found → PR links (or "flagged, needs implementation decision"). - Status changes → page + what moved + source + PR link. - Stale/dead citations → page + broken source + fix PR link. -- Anything deliberately skipped, and why — plus whether it earned a `/considered/` entry - (and the PR link if so). Anything you skipped for thin adoption goes here as an explicit - question for Joost, not as a closed decision. +- Consequential scope questions or credible candidates deferred for thin adoption, + with the evidence checked and the decision needed from Joost. Link a `/considered/` + proposal only when it meets the selective-register rule above. Routine exclusions + remain in internal scan notes and do not require public entries or a list in Slack. Keep it scannable: grouped, one line each, links inline. diff --git a/src/content/considered/bluejetty.md b/src/content/considered/bluejetty.md deleted file mode 100644 index f0026661..00000000 --- a/src/content/considered/bluejetty.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "/.well-known/bluejetty" -date: "2026-09-18" -reason: too-narrow -revisit: "The descriptor becoming something other than a pointer to one vendor's integration. If the format is handed to a standards body, or a second, unrelated company starts publishing and consuming it under the same suffix, the scope argument changes and the topic is worth re-opening." -sources: - - title: "Well-Known URIs registry" - url: "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" - publisher: "IANA" - - title: "Well-Known Uniform Resource Identifiers (URIs)" - url: "https://www.rfc-editor.org/rfc/rfc8615.html" - publisher: "IETF" - - title: "Registration request: bluejetty" - url: "https://github.com/protocol-registries/well-known-uris/issues/106" - publisher: "Well-Known URIs registry (GitHub)" ---- - -`bluejetty` was added to the IANA Well-Known URIs registry on 16 September 2026 as a **provisional** entry. The change controller is PopUp Space Systems LLC, trading as Blue Jetty; the registered specification is a page on that company's own documentation site. A participating publisher serves the file so that Blue Jetty's software can find that publisher's integration with the product: the response is, in the registration's own words, a bounded JSON discovery descriptor pointing at the origin's Blue Jetty app packets. - -It did not land here because the registration answers the scope question itself. Filed on 7 September 2026, it states that the suffix is "an application-specific name under RFC 8615" that "does not claim a generic app, manifest, metadata, AI, or agent namespace", and asks for provisional rather than permanent status because "this is a commercial-organization specification and broad community use has not yet been established". That is an accurate and well-behaved registration — it is exactly what RFC 8615 provisional status is for. It is also a description of something that is not a property of a good website. An origin that has no relationship with this vendor has nothing to publish, and no visitor, crawler, or agent is worse off for the file's absence. - -This is the fourth registration in two months to fail a scope test, and it is worth separating from the other three. [`xregistry`](/considered/#xregistry) failed on which host was expected to answer; [`webhook-authorized-senders.json`](/considered/#webhook-authorized-senders) failed because IANA permanence says nothing about adoption; [`vacation-rental.json`](/considered/#vacation-rental-json) failed on thin implementation. `bluejetty` is the reference case for the easiest of the four to check: **read the registration text before investigating further.** A suffix whose registered specification is a single company's product documentation, and whose payload is a pointer back to that company's integration, is a vendor namespace using a shared registry for its intended purpose. When the request says so in as many words, the decision is already made. diff --git a/src/content/considered/cross-device-flow-security.md b/src/content/considered/cross-device-flow-security.md deleted file mode 100644 index c5b61783..00000000 --- a/src/content/considered/cross-device-flow-security.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Cross-device flow security (RFC 10027 / BCP 247)" -date: "2026-08-21" -reason: out-of-scope -revisit: "If a site-published artefact grows around it — a well-known document, a header, or metadata declaring which cross-device flows an origin will accept — that artefact is the topic, and it would earn a page in `well-known` or `security`." -sources: - - title: "RFC 10027 — Best Current Practice for Security of Cross-Device Flows" - url: "https://www.rfc-editor.org/rfc/rfc10027.html" - publisher: "IETF" - - title: "RFC 8628 — OAuth 2.0 Device Authorization Grant" - url: "https://www.rfc-editor.org/rfc/rfc8628" - publisher: "IETF" ---- - -A cross-device flow is one where authentication starts on one device and finishes on another: scanning a QR code with a phone to sign in on a TV, or typing a short code shown on a console into a laptop. RFC 10027, published in August 2026 as BCP 247, catalogues the attacks these flows invite — largely variants of persuading someone to authorise a session they did not start — and sets out the mitigations: establish proximity where you can, keep codes short-lived and single-use, rate-limit and watch for anomalies at the authorization server, and prefer FIDO2/WebAuthn over a device authorization grant when the choice is available. - -It is good advice, and it is not advice to a website. The document names its audience — architects, fraud analysts, and engineers building authentication systems — and every mitigation lands inside an authorization server or a native client. Nothing here is visible at an origin: there is no header to send, no element to emit, no resource to publish, and so nothing an outside observer could check. A site that consumes a well-implemented identity provider satisfies the BCP without doing anything, and a site that runs its own cannot express its compliance in any form this spec could describe. - -This is the same line drawn for [the HTTP QUERY method](/considered/): a real standard, correctly aimed at the people who build protocol infrastructure, with no property of a good website at the other end of it. Where authentication *does* surface at the origin — the passkey-reuse assertion at [`/.well-known/webauthn`](/spec/well-known/webauthn/), the password-change hint at [`/.well-known/change-password`](/spec/well-known/change-password/), the cognitive-load rules in [accessible authentication](/spec/accessibility/accessible-authentication/) — this spec already covers it. diff --git a/src/content/considered/css-subgrid.md b/src/content/considered/css-subgrid.md deleted file mode 100644 index 8c6ac3cc..00000000 --- a/src/content/considered/css-subgrid.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: "CSS subgrid" -date: "2026-07-06" -reason: out-of-scope -revisit: "Nothing. This is a settled scope decision, kept here because the reasoning generalises to every CSS and JavaScript authoring feature that reaches Baseline." -sources: - - title: "CSS Grid Layout Module Level 2 — Subgrids" - url: "https://drafts.csswg.org/css-grid-2/#subgrids" - publisher: "W3C" ---- - -A page on subgrid was written and proposed, then closed unmerged. It is worth recording why, because the argument for it was a good one: subgrid has been Baseline widely available since September 2023, the spec already covers container queries and anchor positioning, and cross-component alignment is a real problem. - -The reason it did not land is that subgrid is a way of *building* a site rather than something a good site *does*. A layout built with subgrid and the same layout built with flexbox and a few explicit track sizes are indistinguishable to the visitor, the crawler, and the agent. There is no header to check, no element to look for, no behaviour to verify. The benefit is real, but it accrues to the developer. - -This is the reference case for every newly-Baseline CSS or JavaScript feature the daily standards scan turns up. Container queries and the Popover API earned pages because each maps to something a visitor experiences — components that adapt to the space they are given; dismissal and focus behaviour users can rely on. Most authoring conveniences do not, however well supported they are. diff --git a/src/content/considered/cyclic-trigger.md b/src/content/considered/cyclic-trigger.md deleted file mode 100644 index 17f90a8c..00000000 --- a/src/content/considered/cyclic-trigger.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "/.well-known/cyclic-trigger" -date: "2026-08-21" -reason: out-of-scope -revisit: "Evidence that this is something public sites publish for callers they do not already control, rather than a private hook between an orchestrator and its own services — and an error model that uses HTTP status codes. Both would have to change; adoption alone would not move it." -sources: - - title: "Well-Known URIs registry" - url: "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" - publisher: "IANA" - - title: "Cyclic Trigger specification" - url: "https://github.com/SmartStandards/.well-known.cyclic-trigger" - publisher: "SmartStandards Community" - - title: "RFC 8615 — Well-Known Uniform Resource Identifiers (URIs)" - url: "https://www.rfc-editor.org/rfc/rfc8615.html" - publisher: "IETF" ---- - -IANA registered `cyclic-trigger` as a provisional well-known URI suffix on 17 August 2026. The idea behind it is a reasonable one for a certain kind of deployment: rather than every service keeping a timer or a background worker alive, a service exposes `/.well-known/cyclic-trigger/go`, and external infrastructure POSTs an empty JSON object to it on whatever schedule the ecosystem decides. The trigger carries no parameters at all — it says only "here is an opportunity to run", and the receiving service decides for itself whether anything happens. In a serverless estate where idle workers cost money, that is a sensible inversion. - -It is not, however, a property of a website. Nothing a visitor, a crawler or an agent does is affected by whether this endpoint exists, and nobody outside the operator's own control plane is meant to call it. The `/.well-known/` prefix makes it look like the discovery documents this spec normally covers — [security.txt](/spec/security/security-txt/), [the api-catalog](/spec/well-known/api-catalog/), [an agent card](/spec/agent-readiness/a2a-agent-cards/) — but those are files a third party fetches to learn something about the site. This is a remote procedure call that happens to have a fixed name, addressed by infrastructure that already knows the service is there. Registering a suffix reserves a path; it does not make what lives at that path a website concern, and [the well-known overview](/spec/well-known/well-known-overview/) is where that distinction is drawn. - -The second problem would keep it out even if the first went away. The specification requires that failures return `200 OK` with a `fault` property in the body, explicitly to spare orchestrators from transport-level error handling. That is the [soft-404](/spec/seo/soft-404/) antipattern — which this spec marks `avoid` — generalised from one status code to all of them, and it contradicts what [error pages](/spec/resilience/error-pages/) says about signalling failure in the status line where every intermediary can see it. We would be recommending a convention that teaches the opposite of a page we already publish. - -Adoption does not rescue it either. The registered reference is a two-commit GitHub repository created on 23 June 2026 and untouched since, with no stars, forks, watchers or issues, no named implementers, and no security section for an endpoint whose entire purpose is to make a service perform work on an unauthenticated POST. This entry is our reference case for a narrower rule than the usual one about adoption: a `/.well-known/` name is not automatically a website property. Some registrations are private machinery wearing a public prefix. diff --git a/src/content/considered/hosting-provider-well-known.md b/src/content/considered/hosting-provider-well-known.md deleted file mode 100644 index f0d99be8..00000000 --- a/src/content/considered/hosting-provider-well-known.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "The /.well-known/hosting-provider URI" -date: "2026-09-13" -reason: out-of-scope -revisit: "Evidence of independent consumers using the endpoint in a website-facing workflow, such as routing abuse reports or identifying a support provider, with guidance for checking the hint against other evidence. That would establish a practical reason for website operators to request or publish it." -sources: - - title: "IANA — Well-Known URIs registry (hosting-provider, provisional, registered 2020-07-21)" - url: "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" - publisher: "IANA" - - title: "hosting-provider Well-Known Resource Identifier" - url: "https://github.com/Automattic/hosting-provider" - publisher: "Automattic" - - title: "RFC 8615 — Well-Known Uniform Resource Identifiers (URIs)" - url: "https://www.rfc-editor.org/rfc/rfc8615" - publisher: "IETF" ---- - -A CDN can obscure which hosting provider actually serves a site's content. `/.well-known/hosting-provider` is Automattic's convention for exposing that information: a participating host returns a `text/plain` string containing its URL, domain or business name, optionally identifying a reseller. The specification describes combining that hint with hostname and IP checks to identify the provider actively serving the content, even when reseller records are stale. IANA carries the suffix as provisional, registered in July 2020. - -That is a concrete operational use case. The endpoint has an observable response, and an operator who controls the server can publish it or ask their hosting provider to do so. Its value is self-reported and can be spoofed, so consumers must check it against other evidence; this limits the confidence they can place in it without making the hint useless. Being configured by a host is also no reason by itself to exclude a website feature. - -We leave it outside this specification because its documented purpose is provider and reseller attribution, a specialised hosting-management concern. The cited sources do not establish an independently implemented visitor or agent workflow that website operators should support by publishing it. That is a scope decision about the outcome we would recommend, rather than a claim that attribution has no benefit. A demonstrated use such as routing reports to the responsible provider would justify revisiting it, including how consumers handle incorrect or missing values. diff --git a/src/content/considered/http-query-method.md b/src/content/considered/http-query-method.md deleted file mode 100644 index 057ee6d9..00000000 --- a/src/content/considered/http-query-method.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: "The HTTP QUERY method (RFC 10008)" -date: "2026-07-23" -reason: out-of-scope -revisit: "Nothing likely. If a discovery convention grows around it — a well-known URI, or a Link relation that advertises QUERY support — that convention would be the topic, not the method." -sources: - - title: "RFC 10008 — The HTTP QUERY Method" - url: "https://www.rfc-editor.org/rfc/rfc10008.html" - publisher: "IETF" ---- - -`QUERY` is a safe, idempotent HTTP method that carries a request body, filling the long-standing gap between `GET` (safe and cacheable, but no body) and `POST` (body, but neither). It is a real addition to the platform, published as a Proposed Standard in June 2026. - -It is also a property of an API, not of a website. A site does not become better for a visitor, a crawler, or an agent by supporting `QUERY`; the sites that need it are the ones exposing a search or filter API, and for them the method is an implementation choice among several reasonable ones. There is nothing here to check from the outside and no outcome to describe in terms of the people using the site. - -That is the line this spec draws throughout: HTTP methods are how you build a thing, not what a good website does. diff --git a/src/content/considered/oauth-browser-based-apps.md b/src/content/considered/oauth-browser-based-apps.md deleted file mode 100644 index d93975aa..00000000 --- a/src/content/considered/oauth-browser-based-apps.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "OAuth 2.0 for Browser-Based Applications (RFC 10017 / BCP 212)" -date: "2026-09-11" -reason: out-of-scope -revisit: "If the BCP's advice grows an artefact a site publishes — metadata declaring that its tokens are held server-side or sender-constrained, say — that artefact would be the topic. Separately, the `__Host-Http-` cookie prefix it recommends earns a line on the cookie attributes page once browsers are confirmed to enforce it." -sources: - - title: "RFC 10017 — OAuth 2.0 for Browser-Based Applications" - url: "https://www.rfc-editor.org/rfc/rfc10017.html" - publisher: "IETF" - - title: "RFC 9700 — Best Current Practice for OAuth 2.0 Security" - url: "https://www.rfc-editor.org/rfc/rfc9700" - publisher: "IETF" ---- - -RFC 10017, published in August 2026 as BCP 212, is the IETF's guidance for single-page applications that use OAuth. It ranks three architectures. A backend-for-frontend (BFF) keeps tokens out of application JavaScript; the browser authenticates to it with a session cookie. A token-mediating backend obtains the tokens but hands access tokens to the browser. A purely browser-based client holds everything itself. The BCP strongly recommends the BFF for business applications, sensitive applications and anything handling personal data. Public browser clients must use PKCE and, if issued refresh tokens, those tokens must be rotated or sender-constrained. The refresh-token requirement in [RFC 9700 §2.2.2](https://www.rfc-editor.org/rfc/rfc9700.html#section-2.2.2) applies to public clients; confidential backends authenticate when using their refresh tokens and are not universally required to rotate or sender-constrain them. - -Its central recommendations concern how the OAuth client obtains, stores and uses tokens. Assessing those choices requires inspecting the application's authentication flow and implementation; published origin metadata alone does not establish compliance. Some website-level controls are already covered here. The BFF's cookie must be `Secure` and `HttpOnly`, and should be `SameSite=Strict` ([cookie attributes](/spec/security/cookie-attributes/)). A nonce- or hash-based policy helps prevent injected script from executing ([Content Security Policy](/spec/security/content-security-policy/)). These are useful checks, but meeting them does not establish compliance with the whole BCP. - -This is the line drawn for [cross-device flow security](/considered/#cross-device-flow-security): a sound best-practice document aimed at authentication engineers, with nothing of its own at the origin. One detail may still reach this spec by another route. For the BFF's cookie, the RFC recommends the `__Host-Http-` prefix, which marks a cookie as set over HTTP rather than by script. It is newer than the `__Host-` and `__Secure-` prefixes the cookie attributes page describes, and browser support for it has not yet been confirmed here. diff --git a/src/content/considered/sanitizer-api.md b/src/content/considered/sanitizer-api.md deleted file mode 100644 index 3203004f..00000000 --- a/src/content/considered/sanitizer-api.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Sanitizer API (setHTML)" -date: "2026-09-11" -reason: too-narrow -revisit: "A broader spec page on preventing HTML injection, with verification based on safe handling of untrusted content rather than use of a particular sanitiser. The Sanitizer API could be an implementation example there. Safari support alone would not change the scope decision." -sources: - - title: "HTML Standard — Element.setHTML() and the Sanitizer API" - url: "https://html.spec.whatwg.org/multipage/dynamic-markup-insertion.html#dom-element-sethtml" - publisher: "WHATWG" - - title: "Element: setHTML() method" - url: "https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTML" - publisher: "MDN" ---- - -The Sanitizer API gives browsers a built-in way to handle untrusted HTML. `element.setHTML(string)` parses and sanitises markup before inserting it into the DOM, removing script elements, event-handler attributes and other unsafe HTML even when a custom configuration allows them. It is part of the HTML Standard and already ships in Chrome 146 and Firefox 148. Safari has not shipped it, so sites using it need feature detection and a suitable fallback for unsupported browsers. That compatibility limit does not make the API too early to discuss. - -Preventing untrusted content from executing as script is a website outcome worth specifying. A standalone checklist item requiring `setHTML()` would prescribe one way to achieve it. Sites can handle untrusted HTML safely through other sanitisation implementations, or avoid parsing untrusted content as HTML when only text is needed. The relevant assessment is whether the site's handling of that content prevents injection; finding or failing to find a particular API call does not answer that question. - -The API is therefore recorded as `too-narrow` for its own spec page. A broader page on preventing HTML injection could explain when sanitisation is needed, how to verify the outcome, and where this API helps. It should also distinguish sanitisation from [Trusted Types](/spec/security/trusted-types/), which enforces typed values at DOM injection sinks but depends on the policies that produce those values. Neither a policy header nor use of one safe method proves that every injection path is protected. Wider browser support would simplify implementation choices without resolving that scope question. diff --git a/src/content/considered/scitt-keys-well-known.md b/src/content/considered/scitt-keys-well-known.md deleted file mode 100644 index 72620d68..00000000 --- a/src/content/considered/scitt-keys-well-known.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "The /.well-known/scitt-keys URI" -date: "2026-08-21" -reason: too-narrow -revisit: "If serving a transparency-service endpoint ever becomes a normal part of publishing a website rather than of running supply-chain infrastructure. The likelier neighbour is content provenance — a C2PA-style manifest attached to the images and text a site actually publishes — and that would be its own page, not this one." -sources: - - title: "IANA — Well-Known URIs registry (scitt-keys, registered 2026-07-01)" - url: "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" - publisher: "IANA" - - title: "draft-ietf-scitt-scrapi — SCITT Reference APIs" - url: "https://datatracker.ietf.org/doc/draft-ietf-scitt-scrapi/" - publisher: "IETF" - - title: "RFC 9943 — An Architecture for Trustworthy and Transparent Digital Supply Chains" - url: "https://www.rfc-editor.org/rfc/rfc9943.html" - publisher: "IETF" ---- - -SCITT — Supply Chain Integrity, Transparency and Trust — gives software supply chains an append-only, auditable record. A publisher signs a statement about an artefact, a transparency service records it on a verifiable data structure, and the publisher gets back a receipt proving the registration happened. RFC 9943 published that architecture as a Proposed Standard in June 2026; the companion SCITT Reference APIs draft defines `/.well-known/scitt-keys`, which a transparency service serves so that relying parties can fetch the public keys needed to verify those receipts. IANA registered the suffix on 1 July 2026. - -The registration is what brought it into view here, because new well-known URIs are exactly what this spec watches for. But the registry is not a scope boundary — it holds well-known URIs for smart inverters and for job-posting feeds too. The question is who serves the file, and the answer is a transparency service: a piece of supply-chain infrastructure, operated by whoever runs the ledger. It is not something a website serves alongside its `security.txt`. A site that publishes to a transparency service is a *client* of one of these endpoints, never the host of one. - -That distinction is the useful part, and it generalises past SCITT. `/.well-known/` is a shared namespace, not a list of things every origin should have, and a suffix landing in the registry says only that somebody needed a stable path — not that the somebody was a website. The test that matters is whether serving the file makes *this* origin better for its visitors, crawlers, or agents. For [`security.txt`](/spec/security/security-txt/) or [`change-password`](/spec/well-known/change-password/) it plainly does. For `scitt-keys` it plainly does not, and no amount of adoption among ledger operators would change that — which is why the reason here is scope, not timing. diff --git a/src/content/considered/vacation-rental-json.md b/src/content/considered/vacation-rental-json.md deleted file mode 100644 index a15b2b9d..00000000 --- a/src/content/considered/vacation-rental-json.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "/.well-known/vacation-rental.json" -date: "2026-09-11" -reason: too-early -revisit: "Independent implementations publishing and consuming the format beyond the project's own reference implementation, with documented interoperability. Scope is not in doubt; broader adoption is the missing evidence." -sources: - - title: "Well-Known URIs registry" - url: "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" - publisher: "IANA" - - title: "Well-Known Uniform Resource Identifiers (URIs)" - url: "https://www.rfc-editor.org/rfc/rfc8615.html" - publisher: "IETF" - - title: "Vacation Rental Protocol — reference implementation and adoption" - url: "https://vacationrentalprotocol.com/" - publisher: "Vacation Rental Protocol" - - title: "Villa Åkerlyckan — live host discovery document" - url: "https://villaakerlyckan.se/.well-known/vacation-rental.json" - publisher: "Villa Åkerlyckan" ---- - -`vacation-rental.json` was added to the IANA Well-Known URIs registry on 19 August 2026, as a **provisional** entry pointing at a v0.1 document on `vacationrentalprotocol.com` and naming an individual as change controller. The stated purpose is discovery and configuration for vacation-rental applications: a holiday-let site would publish the file so that booking software could find out how to talk to it. - -The scope test passes: this is a file an ordinary content origin would serve, like [`api-catalog`](/spec/well-known/api-catalog/) or [`nodeinfo`](/spec/well-known/nodeinfo/). There is also an implementation. The project documents a live reference implementation running on HemmaBo, and Villa Åkerlyckan's [discovery endpoint](https://villaakerlyckan.se/.well-known/vacation-rental.json) returned JSON when checked on 11 September 2026. That confirms publication of the file; it does not establish interoperability with independent booking software. - -The remaining reason for `too-early` is limited independent adoption. The project's own site invites implementers to become its second independent node, and we have not found evidence of broader publishing and consumption beyond that reference implementation. A provisional registration and a working example justify watching the format. Independent implementations demonstrating that they can exchange and use the document would justify revisiting a recommendation. diff --git a/src/content/considered/webhook-authorized-senders.md b/src/content/considered/webhook-authorized-senders.md deleted file mode 100644 index e214f458..00000000 --- a/src/content/considered/webhook-authorized-senders.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "/.well-known/webhook-authorized-senders.json" -date: "2026-08-03" -reason: too-early -revisit: "A second, unrelated implementer. If a webhook platform with its own customer base — or the Standard Webhooks project — starts fetching this file to decide whether a sender is authorised, the convention becomes real and earns a page." -sources: - - title: "Well-Known URIs registry" - url: "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" - publisher: "IANA" - - title: "The webhook-authorized-senders.json file" - url: "https://intempus.dk/webhook-authorization" - publisher: "Intempus ApS" - - title: "Standard Webhooks specification" - url: "https://github.com/standard-webhooks/standard-webhooks/blob/main/spec/standard-webhooks.md" - publisher: "Standard Webhooks" ---- - -A site that receives webhooks has a genuine problem: anyone who learns the endpoint URL can post to it. `/.well-known/webhook-authorized-senders.json` proposes to solve it from the receiving end — the receiver publishes a JSON allowlist of the hostnames it is willing to accept deliveries from, and a well-behaved sender fetches that file and refuses to deliver if it is not named. The idea is sound, the file is trivial to serve, and it is the kind of externally-checkable property this spec normally likes. - -It has one implementer. The registration's change controller is Intempus ApS, the registered reference is that company's own documentation page, and we found no other party publishing or reading the file. Its **permanent** status in the IANA registry is easy to misread: permanent means a stable specification exists and the suffix will not be reassigned, not that anyone uses it. That is the whole of the adoption evidence, and it is not enough — a page here would tell readers to publish a file that exactly one sender in the world consults. - -The comparison that settles it is [Standard Webhooks](https://github.com/standard-webhooks/standard-webhooks/blob/main/spec/standard-webhooks.md), the multi-vendor effort covering the same ground. It verifies senders with HMAC or asymmetric signatures over the payload and tells receivers to keep a trust list of public keys — deliberately not a discovery document. Where the two approaches disagree, the one with several implementations behind it is the one to describe. This entry is our reference case for the rule that IANA permanence is a statement about the registry, not about the web. diff --git a/src/content/considered/xregistry.md b/src/content/considered/xregistry.md deleted file mode 100644 index 829a75cb..00000000 --- a/src/content/considered/xregistry.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "/.well-known/xregistry" -date: "2026-08-21" -reason: out-of-scope -revisit: "The document moving from the registry server to the site. If the specification — or a consumer of it — starts expecting an ordinary content origin to answer /.well-known/xregistry, rather than the registry service itself, the file becomes something a website publishes and earns a page." -sources: - - title: "Well-Known URIs registry" - url: "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" - publisher: "IANA" - - title: "xRegistry specifications" - url: "https://github.com/xregistry/spec" - publisher: "xRegistry (CNCF Serverless WG)" - - title: "xRegistry" - url: "https://www.cncf.io/projects/xregistry/" - publisher: "Cloud Native Computing Foundation" ---- - -xRegistry — "extensible registry" — is a CNCF Serverless Working Group project, a sibling of CloudEvents built largely by the same people. It "defines an abstract model for how to manage metadata about resources and provides a REST-based interface for creating, modifying, deleting and discovering of those resources", with three concrete registries layered on that model: schemas, message definitions, and messaging endpoints. The core specification and all three domain specifications sit at v1.0-rc4. The `xregistry` suffix was added to the IANA Well-Known URIs registry on 19 August 2026, with the xRegistry Authors as change controller. - -It did not land here because of whose origin is expected to answer. The well-known URIs this spec covers — [`security.txt`](/spec/security/security-txt/), [`change-password`](/spec/well-known/change-password/), [`api-catalog`](/spec/well-known/api-catalog/) — are published by the site a person or a crawler visits, and a site is better or worse for serving them. `/.well-known/xregistry` is answered by a registry server: a piece of messaging infrastructure whose clients are other services, discovering event schemas and endpoints. A content site that never serves it is not thereby a worse website, and there is no visitor, crawler, or agent outcome to phrase a "Why it matters" around. That the specification is still at release candidate is a second reason to wait, but not the operative one — a 1.0 would not change the scope argument. - -This is the third registration in a month to fail the same test, after `/.well-known/scitt-keys` and `/.well-known/cyclic-trigger`, so treat it as the reference case for the general rule rather than one more instance: **the Well-Known URIs registry is not a to-do list for websites.** It is a namespace shared by everything that speaks HTTP, and much of what lands in it belongs to servers that no one browses. Before a suffix earns a page here, ask which host is meant to serve it. If the answer is "an API gateway", "a registry", or "a control plane", it is out of scope no matter how permanent the registration or how healthy the standards body behind it. diff --git a/src/pages/considered.astro b/src/pages/considered.astro index f80624be..d0bd9af7 100644 --- a/src/pages/considered.astro +++ b/src/pages/considered.astro @@ -37,7 +37,7 @@ const groups = consideredReasonOrder
@@ -49,13 +49,21 @@ const groups = consideredReasonOrder Considered, not adopted

- A specification is defined as much by what it leaves out as by what it - contains. These are standards we have read, weighed, and decided not to - cover — each with the reason, and with what would change our mind. The + These are topics readers could reasonably expect this specification to + cover. Each entry explains why it is absent and what would justify + including it. The changelog {" "} - records what went in; this records what did not. + records changes to the specification. +

+

+ We focus on what a website does for visitors, crawlers and agents. + Vendor integrations, specialised infrastructure and implementation + techniques usually fall outside that scope. An IANA registration or + broad browser support alone does not make a topic a website + recommendation. Only omissions that need an explanation get an entry + here.