diff --git a/README.md b/README.md index 4f0dbae..8c07123 100644 --- a/README.md +++ b/README.md @@ -38,41 +38,41 @@ See [docs/decisions.md](docs/decisions.md) for the decision record and | Identifier | Status | What it specifies | Reference implementation(s) | | :--- | :--- | :--- | :--- | -| [`io.modelcontextprotocol/trust-annotations`](specification/draft/trust-annotations.mdx) | Draft skeleton | **Headline.** A small, scheme-agnostic client-facing data-classification vocabulary (`sensitive`, `untrusted`) on result `_meta`, plus an optional `evidenceRef` pointer slot that carries richer payloads out-of-band. | Python SDK: [`kapil8811/mcp-trust-annotations`](https://github.com/kapil8811/mcp-trust-annotations) (138-test suite, healthcare demo, LLM usability study). | +| [`io.modelcontextprotocol/trust-annotations`](specification/draft/trust-annotations.mdx) | Draft skeleton | **Primary extension.** A small, scheme-agnostic client-facing data-classification vocabulary (`sensitive`, `untrusted`) on result `_meta`, plus an optional `evidenceRef` pointer slot that carries richer payloads out-of-band. | Python SDK: [`kapil8811/mcp-trust-annotations`](https://github.com/kapil8811/mcp-trust-annotations) (138-test suite, healthcare demo, LLM usability study). | | [`io.modelcontextprotocol/action-metadata`](specification/draft/action-metadata.mdx) | Draft skeleton | `inputMetadata` / `returnMetadata` / outcome classifiers (incl. `requires_review`) on `ToolAnnotations`, describing where inputs go, where outputs originate, and what real-world effects a tool can cause. | Carries forward [SEP-2061 (Action Security Metadata)](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2061) by [@rreichel3](https://github.com/rreichel3); reference impl per that proposal (`read_drafts` / `list_inbox` / `send_email`). | | [`io.modelcontextprotocol/ifc-fides`](specification/draft/ifc-fides.mdx) | Draft skeleton | A **profile** of the `trust-annotations` `evidenceRef` slot: `type: "ifc.fides.v1"` carrying an integrity + confidentiality label for deterministic information-flow control, following the FIDES paper ([arXiv:2505.23643](https://arxiv.org/abs/2505.23643)). | Emitter candidate: [`github-mcp-server`](https://github.com/github/github-mcp-server) (does not emit IFC labels today — closing that gap is the proof point). | -### Why FIDES is a profile, not the headline +### Why FIDES is a profile, not a top-level extension -An earlier sketch made information-flow control the top-level extension. That -was the wrong cut: it bakes one academic model (an integrity × confidentiality -lattice) into the namespace root and silently forecloses the other enforcement -models reviewers raised — capability tokens, caller/tool cosigning, and -sequence-shape audit records. As one reviewer put it, IFC "fits relatively well -if you use annotations" — an endorsement of IFC *as a profile*, not as the wire -root. Demoting it to a `type` value under `trust-annotations`'s open-ended -`evidenceRef` slot keeps the FIDES work first-class while leaving room for every -other model to occupy the same slot. +Information-flow control is modelled as a profile rather than the namespace +root because IFC (an integrity × confidentiality lattice) is one enforcement +model among several that reviewers raised — capability tokens, caller/tool +cosigning, and sequence-shape audit records. A top-level `ifc/` root would bake +one academic model into the namespace and foreclose the others. As one reviewer +put it, IFC "fits relatively well if you use annotations" — an endorsement of +IFC *as a profile*, not as the wire root. As a `type` value under +`trust-annotations`'s open-ended `evidenceRef` slot, the FIDES work stays +first-class while every other model can occupy the same slot. ## Relationship to SEP-1913 SEP-1913 remains the canonical place to discuss the overall problem framing. -This repo carves the schema-bearing parts of that proposal into independently -shippable pieces. When an extension here is ready to graduate, an Extensions -Track SEP can reference this repo as the prior art and the working +This repository develops the schema-bearing parts of that proposal as +independently shippable extensions. When an extension here is ready to graduate, +an Extensions Track SEP can reference this repo as the prior art and the working implementation that SEP-2133 [requires](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2133-extensions.md#creation). For the full per-SEP plan — what happens to SEP-1913, SEP-2061, SEP-1862 and others, and the SEP-2127 refactor precedent — see [docs/sep-disposition.md](docs/sep-disposition.md). -**Deliberately not carved here** (see [docs/open-questions.md](docs/open-questions.md)): +**Out of scope for these extensions** (see [docs/open-questions.md](docs/open-questions.md)): - **`maliciousActivityHint`** — reviewer concerns are structural (it fires at `tools/resolve` before execution can produce evidence; a boolean is the wrong granularity for client UX; clients won't trust server self-attestation). If it - returns, it is per-`ContentBlock` with spans, on a different clock. Parked on - the SEP-1913 umbrella as a known cut item. + returns, it is per-`ContentBlock` with spans, on a different clock. It stays + on the SEP-1913 umbrella rather than in an extension here. - **Propagation rules** — sensitivity escalation across session boundaries, and the sequence-shape gap (an annotation surface for "this was call N in a flagged sequence") remain open. Likely a future extension once the taxonomy diff --git a/docs/decisions.md b/docs/decisions.md index ff4e23b..33ecb8b 100644 --- a/docs/decisions.md +++ b/docs/decisions.md @@ -3,7 +3,7 @@ Append-only record of design decisions for the Tool Annotations IG's trust / privacy extension work. Newest at the bottom. -## 2026-06-10 — Carve SEP-1913 into independent extensions +## 2026-06-10 — Split SEP-1913 into independent extensions **Decision.** Split the schema-bearing parts of SEP-1913 into separate experimental extensions, each with its own `io.modelcontextprotocol/…` @@ -17,13 +17,13 @@ clock and avoid hard-to-remove schema. ## 2026-06-10 — Three initial extensions -**Decision.** `trust-annotations` (headline), `action-metadata`, `ifc-fides`. +**Decision.** `trust-annotations` (primary), `action-metadata`, `ifc-fides`. **Rationale.** These are the three pieces with either a reference implementation or an existing SEP behind them: Kapil's SDK, SEP-2061 (Reichel), and the FIDES model respectively. -## 2026-06-10 — FIDES is a profile, not the headline +## 2026-06-10 — FIDES is a profile, not a top-level extension **Decision.** Information-flow control is `type: "ifc.fides.v1"`, a profile of the `trust-annotations` `evidenceRef` slot — not a top-level `io.modelcontextprotocol/ifc` @@ -65,7 +65,7 @@ change. ## 2026-06-10 — Parked: maliciousActivityHint, propagation rules -**Decision.** Neither is carved into an extension now; both stay on the SEP-1913 +**Decision.** Neither becomes an extension now; both stay on the SEP-1913 umbrella. **Rationale.** `maliciousActivityHint` has unresolved structural objections diff --git a/docs/intent-comment.md b/docs/intent-comment.md index c85350e..ecc3bca 100644 --- a/docs/intent-comment.md +++ b/docs/intent-comment.md @@ -12,14 +12,14 @@ Kept here so it can be reviewed and stays in sync with ## For SEP-1913 > **Intent: split this SEP and migrate to the Extensions Track** -> +> > > A note on direction for everyone following this thread. When SEP-1913 was > first framed, the **Extensions Track** (SEP-2133) and the `experimental-ext-*` > incubation process didn't exist in their current form. They now do, and > they're a better fit for this work than a single Standards Track SEP. -> +> > > Two things pushed us here: -> +> > > - @localden's review ask for a **narrower first cut** — the concern that a > broad taxonomy with array-or-scalar polymorphism is hard to remove or change > once it lands. @@ -27,26 +27,26 @@ Kept here so it can be reviewed and stays in sync with > [May 28 decision](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/2820) > to pursue trust/privacy as an **experimental extension first**, gather > adoption evidence, then ask core maintainers to absorb anything. -> -> So the plan is to **carve this proposal into a few small, -> independently-shippable extensions**, each with its own +> > +> So the plan is to \*\*split this proposal into a few small, +> independently-shippable extensions\*\*, each with its own > `io.modelcontextprotocol/…` identifier, reference implementation, and path to > an Extensions Track SEP. Incubation is in > [`experimental-ext-tool-annotations`](https://github.com/modelcontextprotocol/experimental-ext-tool-annotations). -> +> > > Kicking off with a few draft extensions in the tool annotations repo — not > sure yet whether they'd each need separate repos eventually, or whether > grouping them in one is fine. That's part of what incubation is for. -> +> > > | Extension | Scope | > |---|---| > | `trust-annotations` | The narrow data-classification taxonomy (`sensitive`, `untrusted`) + an open-ended `evidenceRef` pointer for richer, out-of-band evidence. | > | `action-metadata` | Tool I/O + outcome contract (folds in @rreichel3's SEP-2061). | > | `ifc-fides` | Information-flow control ([arXiv:2505.23643](https://arxiv.org/abs/2505.23643)) as **one profile** of `evidenceRef`, not a wire root — the public/private-repo confidentiality case, with github-mcp-server as an emitter example. | -> +> > > Deliberately removed: `maliciousActivityHint` (the structural concerns raised > here are unresolved) and session-level propagation rules. -> +> > > This follows the same Standards-Track → Extensions-Track refactor pattern as > SEP-2127 (#2893). This PR will eventually pivot to the `trust-annotations` > piece itself, with the other schema-bearing pieces moving out into their own @@ -58,4 +58,4 @@ Kept here so it can be reviewed and stays in sync with ## For SEP-2061 (coordination note) -> @rreichel3 — carving this out into an independent extension as discussed: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-4675047154 +> @rreichel3 — splitting this out into an independent extension as discussed: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-4675047154 \ No newline at end of file diff --git a/docs/open-questions.md b/docs/open-questions.md index c4747c7..57deb26 100644 --- a/docs/open-questions.md +++ b/docs/open-questions.md @@ -36,7 +36,7 @@ Tracked here rather than in the spec drafts, so the drafts stay non-temporal. - GitHub Enterprise `internal` repo visibility → public/private/reader-set mapping (audience is the whole org, broader than collaborators). -## Parked (SEP-1913 umbrella, not carved) +## Parked (SEP-1913 umbrella) - **`maliciousActivityHint`** — if it returns, it is per-`ContentBlock` with spans, driven by the host's own detection, not a server-attested boolean. diff --git a/docs/related-work.md b/docs/related-work.md index c8c6e16..f5717fe 100644 --- a/docs/related-work.md +++ b/docs/related-work.md @@ -5,7 +5,7 @@ annotation work. Several were surfaced in IG meetings (notably 2026-05-28). ## SEPs -- [SEP-1913 — Trust and Sensitivity Annotations](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913) — the umbrella this work carves from. +- [SEP-1913 — Trust and Sensitivity Annotations](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913) — the umbrella proposal these extensions derive from. - [SEP-2061 — Action Security Metadata](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2061) — carried forward as `action-metadata`. - [SEP-1862 — Tool Resolution / pre-flight checks](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1862) — core-protocol, composes with these extensions. - [SEP-2133 — Extensions](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2133-extensions.md) — the framework this repo incubates under. diff --git a/docs/sep-disposition.md b/docs/sep-disposition.md index f930340..ab22421 100644 --- a/docs/sep-disposition.md +++ b/docs/sep-disposition.md @@ -25,7 +25,7 @@ form. Two inputs since then point at a different shape: adoption/evidence base, and only then ask core maintainers to absorb anything into the protocol. -The result: carve the schema-bearing parts into small, independent extensions, +The result: split the schema-bearing parts into small, independent extensions, each able to graduate on its own clock. ## The precedent: SEP-2127 (Server Cards) @@ -50,7 +50,7 @@ We apply the same playbook below. ### SEP-1913 — Trust and Sensitivity Annotations **Proposed:** becomes the **umbrella / problem-framing** thread. The schema- -bearing content is carved out into the extensions below. Options, in order of +bearing content moves into the extensions below. Options, in order of preference: - **(A, preferred)** Keep the PR open as the framing umbrella; add an intent @@ -62,8 +62,8 @@ preference: - **(C)** Close 1913 outright and open three fresh Extensions Track SEPs. Loses the discussion history's continuity; not preferred. -**Carved out:** `trust-annotations`, `action-metadata`, `ifc-fides`. -**Parked on the umbrella (not carved):** `maliciousActivityHint`, +**Moved into extensions:** `trust-annotations`, `action-metadata`, `ifc-fides`. +**Parked on the umbrella:** `maliciousActivityHint`, session-level propagation rules. See [open-questions.md](./open-questions.md). ### SEP-2061 — Action Security Metadata @@ -73,7 +73,7 @@ extension. SEP-2061 is by [@rreichel3](https://github.com/rreichel3), who is also an IG co-facilitator and SEP-1913 co-author, so this is a fold-in, not a collision. Disposition mirrors 1913 option (A): keep the thread as the field- semantics discussion, add a pointer comment linking it to the -`action-metadata` carve, refactor to Extensions Track when ready. +`action-metadata` extension, refactor to Extensions Track when ready. ### SEP-1862 — Tool Resolution (pre-flight checks) @@ -86,8 +86,8 @@ with it if it lands, but do not block on it. ### Other related SEPs (not owned here) - **SEP-1984 (Comprehensive Tool Annotations)**, **SEP-2417 (Model Preferences - for Tools)** — tracked by the IG as discussion items; not part of this carve. - Cross-link only. + for Tools)** — tracked by the IG as discussion items; not part of these + extensions. Cross-link only. - **SEP-2787 (Tool Call Attestation)** and the various attestation/evidence threads — these are natural `evidenceRef` *profile* candidates rather than competitors. Coordinate so the `evidenceRef.type` registry can list them. @@ -96,7 +96,7 @@ with it if it lands, but do not block on it. | SEP | Title | Proposed disposition | Extension home | | :-- | :-- | :-- | :-- | -| 1913 | Trust & Sensitivity Annotations | Umbrella thread; carve schema out | `trust-annotations` (+ `ifc-fides`) | +| 1913 | Trust & Sensitivity Annotations | Umbrella thread; schema moves to extensions | `trust-annotations` (+ `ifc-fides`) | | 2061 | Action Security Metadata | Fold into extension | `action-metadata` | | 1862 | Tool Resolution (pre-flight) | Stays core / Standards Track | — (composes, no dependency) | | 1984 | Comprehensive Tool Annotations | IG discussion item | — | diff --git a/specification/draft/ifc-fides.mdx b/specification/draft/ifc-fides.mdx index 5895d0a..eb1ea83 100644 --- a/specification/draft/ifc-fides.mdx +++ b/specification/draft/ifc-fides.mdx @@ -26,17 +26,16 @@ protocol or into the `trust-annotations` wire surface. ## Why a profile -An earlier sketch proposed information-flow control as a top-level extension -(`io.modelcontextprotocol/ifc`). That was the wrong cut. IFC is **one** -enforcement model among several that reviewers of SEP-1913 raised — capability -tokens, caller/tool cosigning, and sequence-shape audit records were all put -forward. Making the FIDES integrity × confidentiality lattice the namespace -root would silently foreclose those. +Information-flow control is one enforcement model among several that reviewers +of SEP-1913 raised — capability tokens, caller/tool cosigning, and +sequence-shape audit records were all put forward. A top-level extension +(`io.modelcontextprotocol/ifc`) would make the FIDES integrity × confidentiality +lattice the namespace root and silently foreclose those other models. -Carrying it as a `type` value under the open-ended `evidenceRef` slot keeps the -FIDES work first-class while leaving the slot free for every other model. One -reviewer's framing captured it: IFC "fits relatively well *if you use -annotations*" — an endorsement of IFC as a profile, not as the wire root. +As a `type` value under the open-ended `evidenceRef` slot, the FIDES label is +first-class while the slot stays free for every other model. One reviewer's +framing captured it: IFC "fits relatively well *if you use annotations*" — an +endorsement of IFC as a profile, not as the wire root. ## Motivation diff --git a/specification/draft/trust-annotations.mdx b/specification/draft/trust-annotations.mdx index d43200c..f9fc4bb 100644 --- a/specification/draft/trust-annotations.mdx +++ b/specification/draft/trust-annotations.mdx @@ -20,9 +20,10 @@ related: This extension defines a small, stable, scheme-agnostic vocabulary for classifying **data in transit** through MCP tool results, plus an optional `evidenceRef` pointer that lets a deployment attach richer, out-of-band -evidence without growing the on-wire schema. It is the headline extension of -the Tool Annotations IG's trust work; other extensions (information-flow -control, action metadata) compose with it rather than duplicating it. +evidence without growing the on-wire schema. It is the primary +data-classification extension in the Tool Annotations IG's trust work; other +extensions (information-flow control, action metadata) compose with it rather +than duplicating it. The design follows the [@localden](https://github.com/localden) review steer on SEP-1913 — take a *narrow first cut* of the taxonomy and avoid hard-to-remove