Considered, not adopted

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, 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.

RFC 9875 defines two response headers: Cache-Groups tags a response as belonging to one or more named groups, and Cache-Group-Invalidation declares a group stale. Together they let a server say “these seven URLs are one thing” — something HTTP has never been able to express, since invalidation has always been per-URL.

It is a genuinely good idea, and it is finished: Proposed Standard, published October 2025, with both field names registered permanently at IANA. The problem is that nothing appears to implement it. There is no MDN page and no Browser Compatibility Data key, no Chrome Platform Status entry, and no mention in Cloudflare’s cache documentation or changelog — Cloudflare still purges by proprietary Cache-Tag through its dashboard and API, with no in-band header path. Fastly, Varnish, nginx and Squid show no sign of it either. The one candidate implementation, the Go cache Souin, describes its support against the pre-RFC draft.

So a page today would recommend a header that no cache on any reader’s path would read. That is the opposite of what this spec is for. The standard is not the problem; the deployment is, and that can change quickly.

IANA has registered dpp as a link relation type: “a link from a context URI that identifies a product to its digital product passport”, on the authority of the UN Transparency Protocol. A Digital Product Passport is the machine-readable record of a product’s materials, provenance and sustainability data that EU Ecodesign regulation will require for a widening list of categories, starting with textiles, footwear and batteries in 2026–2027. Three separate signals arrived within a few months of each other: the IANA registration, schema.org 30.0 adding EU Digital Product Passport examples aligned to UN/CEFACT codes, and the UNECE/ISO joint initiative. On the face of it that looks like a topic arriving.

The problem is where the link actually lives. UNTP does not put rel="dpp" on the product’s web page. It puts it in a linkset — RFC 9264, the same media type this spec already covers under the api-catalog — returned by an identity resolver, extending the GS1 Digital Link resolver schema. The context URI is a GS1 product identifier, the client is a scanner following a QR code on physical packaging, and the passport itself comes back as a verifiable credential. None of that is a property of a website. A spec page here would have to recommend that ordinary product pages emit a Link: <…>; rel="dpp" header, and nobody is doing that, because the protocol does not ask them to.

So this is not the usual too-early case of a good header nothing reads yet. It is a registered relation that is genuinely in use, in a place this spec does not describe. That could change: the regulation lands on manufacturers who already run product pages, and the cheapest way to make a passport discoverable to a crawler rather than a barcode scanner is to advertise it from the page. If that becomes the convention, it is a page — and the Link header and structured data topics are where it would connect.

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.

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.

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 or 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.