Attested Context — an MCP extension for server-vouched context¶

Extension identifier: org.webgcp/attested-context · Version: 0.1 (draft) Anchor: the Model Context Protocol, 2026-07-28 specification.

MCP standardises how a client calls tools and receives context. Nothing in it says what context the server is willing to assemble and vouch for. Attested Context is that missing assurance layer: the serving side assembles the context bundle under its own authority, serves it with an independently verifiable vouch, and keeps a receipt of what it served. The payload noun is the Attested Context Bundle.

1. The anchor, as published¶

What the anchor deliberately does not cover (verified against the ratified text, 2026-07-30)¶

The anchor holds on extension point plus governance, not coverage — which is exactly what an extension wants.

2. The delta¶

Four properties plus one precondition:

1. Provenance per item — every field of a served bundle names its source, evidence tier, retrieval mode, and (where vector-ranked) its embedding-space identity. (AC-2)
2. Absent, not masked — a denied field is omitted entirely; a response never discloses that denial occurred. (AC-3)
3. Audience-scoped tools — tools carry an audience class enforced server-side at call time and reflected in per-authorization listings. (AC-4)
4. The vouch and the receipt — the served bundle is content-addressed and signed, and the server retains a receipt. (AC-6)

The precondition (mediated assembly): the serving side queries its own substrate under its own identity. The client's credentials authorize the MCP call — they are never forwarded to, replayed against, or exchanged for access to the underlying substrate. A client never holds a substrate grant. (AC-5) This is what makes the vouch meaningful: a server that proxies the caller's credentials cannot attest to what it assembled.

3. Normative requirements¶

Key words MUST / MUST NOT / SHOULD / MAY per BCP 14.

AC-1 — Negotiation and degradation¶

• Servers MUST advertise org.webgcp/attested-context in their capabilities extensions; opting clients declare it in clientCapabilities.extensions per the anchor's negotiation rules.
• All wire surfaces are additive _meta entries: a response carrying them is a valid core-MCP response. Servers MAY emit the attestation _meta regardless of client opt-in.
• A deployment MAY make the extension mandatory for designated tools and reject non-declaring callers with an authorization failure; this fallback posture MUST be documented.

AC-2 — Provenance per item¶

A result serving an Attested Context Bundle MUST carry _meta["org.webgcp/attested-context"].provenance: a map from JSON Pointer into structuredContent to a provenance record:

The map MUST cover every leaf of structuredContent (a record on an ancestor pointer covers its descendants).

AC-3 — Absent, not masked¶

• A field the caller is not authorized to receive MUST be omitted from structuredContent.
• A server MUST NOT emit mask tokens, placeholders, redaction markers, or schema stubs for denied fields — in the bundle, in content, or in the provenance map (an omitted field has no provenance entry; presence in the map is itself disclosure).
• Denial evaluates before retrieval. Display-layer suppression — filtering what is shown while the underlying data was fetched, transmitted, or actioned — is expressly non-conformant.

AC-4 — Audience-scoped tools¶

• Every tool served under this extension carries an audience class: public or admin (deployments MAY define more; two classes are the floor), declared in the tool's _meta["org.webgcp/audience"].
• Enforcement is server-side at call time. A tools/call from a caller outside the tool's audience MUST fail authorization. Client-side hiding is display, not enforcement.
• tools/list MUST reflect the caller's audience: tools outside it are absent — never listed-but-disabled. Such responses MUST set cacheScope: "private".
• Do not confuse this with the anchor's content-annotation audience (user | assistant) — a display hint on content. They share a word and nothing else.

AC-5 — Mediated assembly¶

• The server MUST execute all substrate reads for bundle assembly under its own identity.
• The server MUST NOT forward, replay, or exchange the caller's MCP credentials against the substrate, and MUST NOT return substrate credentials or scoped substrate tokens to the caller.
• The invariant: the client never holds a substrate grant.

AC-6 — The vouch and the receipt¶

A result serving an Attested Context Bundle MUST carry _meta["org.webgcp/attested-context"].attestation:

• Because the anchor rules annotations untrusted, the vouch MUST be independently verifiable: a consumer verifies sig against the issuer's published key and bundle_hash against the received content, trusting neither serverInfo nor any annotation.
• The server MUST retain the receipt under its own custody. The receipt wire shape is the webGCP Receipts Protocol (v0.2 candidate) — one receipt genre, never a second format; receipt_ref is the receipt's own ledger identifier, so the reference resolves.
• The governed level (declared). At the governed level the ledger MUST durably accept the receipt before the result is served: a serving whose receipt cannot be retained is refused with a typed failure, never served carrying a receipt_ref the ledger never saw. The posture is declared in the extension settings (receipts: "governed" | "best-effort"), so a consumer can tell a guaranteed receipt from a best-effort one at the discovery surface. Retention follows the substrate's declared data-retention contract (≥1 year RECOMMENDED) and MUST NOT be silently bounded by storage-level expiry — TTLs are retention policy, declared, never incidental.

AC-7 — Two freshness planes, never conflated¶

ttlMs/cacheScope govern response caching; retrieved_at and staleness bounds in provenance govern content currency. An implementation MUST NOT derive one from the other. An attested bundle MAY be cached within ttlMs and remains verifiable — the vouch binds to content, not transport.

4. L0 conformance¶

Twelve assertions across three fixtures, with a stdlib-only runner, golden transcripts, and negative controls — published at /conformance/attested-context/:

• AC-L0-001 — negotiation + the vouch (extension declared; attestation present; hash matches the JCS canonical content; signature verifies against the published key)
• AC-L0-002 — provenance + absence (map present and covering; denied field absent with no mask token and no provenance entry)
• AC-L0-003 — audience + freshness (foreign-audience tool absent from the list; call denied server-side; cacheScope: private on varying lists; both freshness planes expressed)

The runner evaluates captured transcripts, never live endpoints, so verdicts are reproducible from artifacts. It is positive-controlled (a conformant golden transcript must pass 12/12), negative-controlled (eleven broken variants must each trip their declared assertions — no check in the suite is incapable of failing), and its embedded Ed25519 verifier is checked against RFC 8032 test vector 1 before any run. Run python3 runner.py --self-test first, then python3 runner.py --transcripts <your-captured-dir>.

AC-5 deliberately has no fixture assertion: mediation is not observable from the wire; it is verified by architecture review. The governed receipt posture is likewise declared and discoverable rather than L0-asserted.

5. Status — read the flags before citing this page¶

• DRAFT v0.1. This is a working draft at a suffixed URL; it will move through versioned permanent URLs as it matures and this page's content may change.
• One implementation exists — the reference substrate serves this extension in production at the public origin https://catalog.myparallel.dev. Its .well-known/webgcp descriptor enumerates the live endpoints; the attested discovery route it advertises returns this extension's declaration with receipts: "governed", and the issuer's verification key is served on the adjacent issuer-key route. Live-captured transcripts pass the L0 suite 12/12 (2026-07-30).
• An author-operated pass is not a second-implementer signal. The standard's next step is a second, independent implementation — the fixtures above are the invitation. If you build one, say hello via /contact/.
• Upstream path: the anchor's Extensions Track (SEP process), only after production soak and a second implementer exist — never before.

6. What this extension deliberately does not do¶

• No new wire protocol, no new methods — everything rides _meta and existing MCP messages.
• No retrieval-comparability rule — carried from the webGCP substrate property, not redefined.
• No reputation, settlement, or marketplace surface — those live in the webGCP Commerce Layer.
• No existence semantics for absent fields — an omitted field is indistinguishable from a nonexistent one, by design.

7. Open questions (v0.1)¶

1. Canonicalization is decided (RFC 8785 JCS; the L0 runner refuses content outside its integer-restricted subset rather than approximate); the request digest's argument normalizations remain open.
2. Per-item Merkle proofs (excerpt one item with proof) — deferred until a consumer exists.
3. Serving-cost budgets for server-side assembly — to be answered with measurements, not asserted.
4. Whether mixed public/audience deployments need a third cache posture.