From d0733ef8e6b6a1117f3cfa594027c89834c78d7f Mon Sep 17 00:00:00 2001 From: Sam Morrow Date: Tue, 16 Jun 2026 10:06:40 +0200 Subject: [PATCH] Frame 'sensitive' as the lowest-common-denominator floor; recommend emitting both MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Per Sam: the coarse 'sensitive' boolean exists to give a universal, 'better than nothing' policy-enforcement floor every client can act on — a basic/general scheme — not a competitor to richer schemes. It is not either/or with the taxonomy; servers are encouraged to do both. - trust-annotations.mdx: reframe the coarse-vs-rich section around the LCD floor; add a SHOULD-emit-both recommendation (boolean + richer evidenceRef scheme); point Motivation at it; reframe the in-spec open question accordingly; changelog row. - decisions.md: log the LCD-floor + emit-both decision; correct two entries mis-dated 2026-06-17 to today (2026-06-16). - open-questions.md: reframe the sensitivity item from 'is the boolean right' to the narrower residual (is boolean + data-class scheme enough, or is a wire escape hatch needed); current lean: no escape hatch. - terminology: profile -> scheme in forward-looking text (open-questions registry line, sep-disposition SEP-2787 row); historical log entries left as-is. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- docs/decisions.md | 23 +++++++++++++++-- docs/open-questions.md | 31 +++++++++++++---------- docs/sep-disposition.md | 2 +- specification/draft/trust-annotations.mdx | 31 ++++++++++++++++++----- 4 files changed, 63 insertions(+), 24 deletions(-) diff --git a/docs/decisions.md b/docs/decisions.md index e3a574b..e3cdd5a 100644 --- a/docs/decisions.md +++ b/docs/decisions.md @@ -118,7 +118,7 @@ that extension's `evidenceRef` slot. clock. FIDES stacks on `trust-annotations` because a scheme has no meaning without the slot it fills. -## 2026-06-17 — Schemes carry data labels; host architectures do not +## 2026-06-16 — Schemes carry data labels; host architectures do not **Decision.** `schemes/` holds **data-labelling** approaches a server attaches to a result (FIDES, Permissive IFC, AirGapAgent, `data-class`, attestation @@ -131,7 +131,7 @@ one. Conflating them would invite a `schemes/camel.md` that has no per-result payload to define. A capability token such an architecture issues can still be *referenced* through `evidenceRef`, but the architecture itself is not a scheme. -## 2026-06-17 — Early SEP-1913 feedback recorded as cited open questions +## 2026-06-16 — Early SEP-1913 feedback recorded as cited open questions **Decision.** The substantive concerns from the original issue (#711) and SEP (#1913) review — the set-theoretic critique of linear sensitivity, org-defined @@ -145,3 +145,22 @@ lot of debated design. Recording *why*, with links to the people who raised each point, keeps the history visible and gives each parked item a home to graduate from (a scheme, an `action-metadata` field, or a future extension) instead of being re-litigated from scratch. + +## 2026-06-16 — `sensitive` is a lowest-common-denominator floor; emit both + +**Decision.** The coarse `sensitive` boolean is intentionally a +lowest-common-denominator signal — a universal, always-actionable floor that +supports a basic "better than nothing" egress/consent policy even against a +barely-known server. It is the basic, general scheme every participant +understands, **not** a competitor to richer schemes. Servers SHOULD emit **both** +the boolean and a richer `evidenceRef` scheme (e.g. `data-class.v1`, +`ifc.fides.v1`) where they can; `sensitive` MUST NOT be dropped merely because a +scheme is present. + +**Rationale.** Clarifies the original purpose of the boolean (raised by Sam): the +point of keeping it on the wire was never to *replace* richer classification but +to guarantee a floor any client can act on. Richer schemes are strictly more +capable but are not universally implemented, so they cannot be the floor — +layering the two gives universal actionability without capping what advanced +hosts can do. This also answers the "boolean vs. richer taxonomy" tension from +SEP-1913 review: it is not either/or, it is both, at different layers. diff --git a/docs/open-questions.md b/docs/open-questions.md index 8432a37..86898e7 100644 --- a/docs/open-questions.md +++ b/docs/open-questions.md @@ -10,27 +10,30 @@ Tracked here rather than in the spec drafts, so the drafts stay non-temporal. - **Cross-domain integrity verification** — is asymmetric crypto for domain identity in scope for a future extension, or out of scope entirely? CLI tools remain a persistent gap for enforcing these constraints. -- **`evidenceRef.type` registry** — who curates the list of well-known profile +- **`evidenceRef.type` registry** — who curates the list of well-known scheme types, and how do we coordinate with attestation SEPs (e.g. SEP-2787) so values don't collide? ## trust-annotations -- **Shape of the sensitivity signal.** Is `sensitive: boolean` the right single - coarse signal, or does the narrow cut overcorrect? The SEP-1913 thread rejected - a linear `sensitiveHint: low|medium|high` because sensitivity is set-theoretic, - not a scale ([@JustinCappos](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/711#issuecomment-2967516811): - medical results to a mail MCP *and* a card number to a payment MCP, but neither - crossed). Reviewers then pushed for org-defined vocabularies +- **Sensitivity beyond the floor.** The `sensitive` boolean is settled as the + **lowest-common-denominator floor** — a basic, general signal every client can + act on, "better than nothing," with servers encouraged to *also* emit a richer + scheme (see the [decision log](./decisions.md) and the "emit both" guidance in + the spec). The residual open question is narrower: is "coarse boolean + richer + `evidenceRef` scheme" sufficient for regulated flows, or do some hosts need the + classification expressible *on the wire* without a scheme? Current lean: **no + wire escape hatch** — keep the wire floor un-rottable and push the taxonomy + into [`data-class.v1`](../schemes/data-class.md). Background on why a single + scalar/enum was rejected: sensitivity is set-theoretic not linear + ([@JustinCappos](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/711#issuecomment-2967516811)), + reviewers wanted org-defined vocabularies ([@olaservo](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/711#issuecomment-2968743154), [@Mossaka](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/711#issuecomment-2971788308)) - and a class+regulatory pairing such as `confidential:hipaa` - ([@krubenok](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#discussion_r3103485194)). - Against that, [@localden](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-4037623595) - warned a baked-in taxonomy is hard to remove. Open: keep the boolean and let - the [`data-class.v1` scheme](../schemes/data-class.md) carry the taxonomy, or - also expose a structured escape hatch on the wire so regulated flows are - expressible without a scheme? + and a class+regulatory pairing + ([@krubenok](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#discussion_r3103485194)), + and a baked-in taxonomy is hard to remove + ([@localden](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-4037623595)). - **Enforcement vs. advisory.** A self-declared `sensitive: true` from a poorly-configured or malicious server could create a false sense of security ([@localden](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-4037623595)). diff --git a/docs/sep-disposition.md b/docs/sep-disposition.md index 7fe65d0..7a1fe83 100644 --- a/docs/sep-disposition.md +++ b/docs/sep-disposition.md @@ -105,7 +105,7 @@ with it if it lands, but do not block on it. | 1862 | Tool Resolution (pre-flight) | Stays core / Standards Track | — (composes, no dependency) | | 1984 | Comprehensive Tool Annotations | IG discussion item | — | | 2417 | Model Preferences for Tools | IG discussion item | — | -| 2787 | Tool Call Attestation | Candidate `evidenceRef` profile | (future) | +| 2787 | Tool Call Attestation | Candidate `evidenceRef` scheme | (future) | ## Intent comment diff --git a/specification/draft/trust-annotations.mdx b/specification/draft/trust-annotations.mdx index 4ed0689..6fe939e 100644 --- a/specification/draft/trust-annotations.mdx +++ b/specification/draft/trust-annotations.mdx @@ -40,7 +40,10 @@ broadly-applicable signals cover the majority of client-actionable cases: Drives prompt-injection defenses. Anything richer than these two booleans is deliberately **not** on the wire; it -hangs off `evidenceRef` (see below). +hangs off `evidenceRef` (see below). These two signals are a +**lowest-common-denominator floor**, not a ceiling: servers are encouraged to +*also* attach a richer scheme via `evidenceRef` — see +[Coarse vs. rich](#coarse-vs-rich-classification-dataclass). ## Specification @@ -113,7 +116,7 @@ SEP-1913 carried a four-level data classification (`public` / `personal` / `confidential` / `highly_confidential`) plus a regulatory scope (e.g. `confidential:hipaa`). **This extension deliberately keeps only the coarse `sensitive` boolean on the wire.** Richer classification -is recovered as an `evidenceRef` profile: +is recovered as an `evidenceRef` scheme: ```jsonc "evidenceRef": { @@ -124,9 +127,19 @@ is recovered as an `evidenceRef` profile: } ``` -This is an explicit scope decision: the binary lives on the wire for universal -client actionability; the taxonomy lives behind a profile so it can evolve -without a breaking schema change. +This is an explicit scope decision. The boolean is the **lowest-common- +denominator signal**: a universal, always-actionable floor that lets any client +apply a basic egress/consent policy that is *better than nothing*, even against a +server it knows little about. It can be thought of as the basic, general scheme +that every participant understands. Richer schemes are strictly more capable but +are not universally implemented, so they cannot be the floor. + +Servers SHOULD therefore emit **both** when they can: the coarse `sensitive` +boolean for universal actionability, **and** a richer `evidenceRef` scheme (e.g. +`data-class.v1`, `ifc.fides.v1`) for hosts that implement it. The two are +layered, not alternatives — a client that understands the scheme uses it; one +that does not still has the boolean. `sensitive` MUST NOT be omitted merely +because a richer scheme is present. ### Attachment point @@ -189,8 +202,11 @@ and `evidenceRef` is how that claim is made checkable. ## Open questions -- Is `sensitive` the right single coarse signal, or do we need `sensitive` + - the `data-class.v1` profile from day one? +- `sensitive` is settled as the lowest-common-denominator floor; servers are + encouraged to emit it **and** a richer scheme. Residual: is the + [`data-class.v1` scheme](../../schemes/data-class.md) enough, or do some + regulated flows need the classification *on the wire*? See + [docs/open-questions.md](../../docs/open-questions.md). - Exact required-vs-recommended split on `evidenceRef` fields. - Whether content-block-level annotation needs a worked multi-result example before the draft is implementable. @@ -201,3 +217,4 @@ and `evidenceRef` is how that claim is made checkable. | ---------- | ------------------------------------------------------------- | | 2026-06-10 | Initial draft skeleton. Narrowed to `sensitive` + `untrusted` + `evidenceRef`; DataClass demoted to a profile; `requires_review` moved to `action-metadata`. | | 2026-06-16 | Show `jcs/rfc8785` alongside `cbor/rfc8949` so canonicalization reads as a per-reference envelope choice, not a default; note the `type`/`digest`/`canonicalization` triple as the local-re-derivation minimum. (Review: @Rul1an.) | +| 2026-06-16 | Add `untrusted` vs `openWorldHint` relationship subsection; frame `sensitive` as the lowest-common-denominator floor and recommend servers emit both the boolean and a richer `evidenceRef` scheme. |