docs: drop jargon, make repo docs descriptive
Replace 'carve'/'headline' throughout; reframe the front-facing docs (README, spec drafts, related-work) to describe what the repo contains and link to it rather than narrate the process. Process framing stays in the decision log and the intent-comment/sep-disposition planning docs. Live SEP-1913/SEP-2061 comments updated to match. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
Sam Morrow
parent
8a867d4bb9
commit
70ec91c5f7
8 changed files with 56 additions and 56 deletions
34
README.md
34
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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 | — |
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in a new issue