Participant conformance — org.webgcp/site-embed v0.1¶

⚠ This document specifies a test suite. It is not a passing result, and the suite is not yet built. Twenty-two assertions are defined below; zero fixtures exist; no implementation has been evaluated. The anchor spec's own §16 is the bar being held to — a standard without runnable conformance tests is aspirational — and this profile is aspirational until the fixtures ship. Saying so is the point: a conformance page that reads as though it passes is worse than none.

Twenty-two assertions across two suites, mapping the extension's normative section one-to-one. The split is by who can run it, which for this extension is not a detail: a participant is audited from outside, a network host is audited from inside.

SE-L0-P — the participant suite (third-party runnable)¶

Everything here is observable by fetching two documents and asking DNS one question. That is deliberate: a participant claim that only its own operator can check is not a claim, and the whole value of a domain-bound identity is that a stranger can audit it.

The descriptor — SE-1¶

Identity — SE-2¶

SE2-01 is the whole trust primitive in one line: identity is proven by the fetch itself. A descriptor at example.com claiming did:web:someone-else.com fails, and that failure is the mechanism — not a policy layered on top of it.

The credential rule — SE-3¶

⚠ SE3-01 is the assertion most likely to be implemented as a checker that cannot fail, and it is also the only one whose failure costs real money. A scanner that greps for api_key= against a bundle that never contained that string reports a pass it never earned — the failure mode this estate has hit repeatedly and the reason the control below is mandatory, not optional. The runner MUST refuse to report SE3-01 as passing unless the negative control tripped it in the same run.

The test is capability, not secrecy. A project id, a public origin, or the site's own did:web authorizes nothing alone and is expected in the bundle. The question is only ever: does presenting this value, by itself, make a metered call succeed?

Materialization — SE-5¶

SE5-04 is not redundant with SE5-01. The two labels answer different questions — origin versus output trust — and a suite that checked only ours would pass a card that tells an agent where a tool came from while telling it nothing about whether the tool's output can be trusted.

DNS-layer discovery — SE-7¶

SE-7 was ruled SHOULD by the specification authority on 2026-08-23, so all three assertions stand as written and none retires. They were drafted to survive either ruling — under a MUST, SE7-01 would have narrowed to requiring "live" and SE7-03 would have retired — which is why the unsettled question never blocked the tests around it.

Note what SE7-02 actually catches: a descriptor claiming svcb_status: "live" with no record behind it. That is the only failure here that is a false claim rather than a missing capability, and it is the reason the status field is worth requiring at all. Run it over DNS-over-HTTPS against any compliant public resolver — no local dig needed, per the anchor's own verification note.

SE-L0-N — the network-side suite (operator-run)¶

Seven assertions that a third party structurally cannot check, because they concern what the network host recorded, not what the participant published. Listing them separately is the honest move: folding them into the participant suite would imply an outside auditor had verified them.

SE6-03 reads oddly as a conformance assertion until you notice what it prevents: the extension's Known Limitations already admit the free-lane limit is per-instance, so a horizontally scaled host enforces N times the nominal rate. Requiring the scope to be documented means a future operator cannot quietly present a per-instance limit as a global one.

Controls — the suite must be able to fail¶

The suite is not shippable until it satisfies the discipline that made the sibling Attested Context suite trustworthy:

• Positive control: one fully conformant synthetic participant — descriptor, page bundle, card, and DNS answer — that the suite passes 15/15 on the participant side. A run that cannot pass its own positive control aborts as a broken runner rather than reporting failures.
• Negative controls: every one of the twenty-two assertions MUST be tripped by at least one control. Minimum set, one per failure that matters: wrong role; a conformance_level present; empty consumes; a did:web naming a different host than the one served; a bundle carrying a live metered credential; a materialized entry missing its source or its untrustedContentHint; a metered lane answering 429 where it owes a 402; a verification that mints balance without settling; a card that stops parsing once materialized entries are stripped; svcb_status: "live" with no DNS record behind it; "unavailable" with no reason.
• The abort rule: an assertion with no control that trips it is a suite defect, and --self-test MUST fail rather than report a clean run. An untrippable check is indistinguishable from a passing one, and this project has paid for that confusion more than once.
• Evaluate from artifacts, never live. Capture the descriptor, bundle, card, and DNS answer first; evaluate second. Every verdict then reproduces from the captured evidence, and a network blip cannot manufacture a failure or a pass.

What a pass will mean — and what it will not¶

A passing participant suite will mean: this domain publishes a well-formed participant descriptor, its identity is provably its own, and it is not shipping a spendable credential to browsers.

It will not mean the network host behaves, that the site's materialized skills are accurate, or that anything was audited beyond the four captured artifacts. Conformance is claimed only when a real participant's captured artifacts pass, and the claim names the artifacts, the date, and the extension version.

Implementations passing: none. The first will be author-operated, which advances the use-alone step and is explicitly not a second-implementer signal.