d0733ef8e6Per 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>
101 lines
6.2 KiB
Markdown
101 lines
6.2 KiB
Markdown
# Open questions
|
|
|
|
Tracked here rather than in the spec drafts, so the drafts stay non-temporal.
|
|
|
|
## Cross-cutting
|
|
|
|
- **Where does the policy-enforcement engine live** across different user
|
|
universes (cross-org, cross-domain)? Engines work well within one universe;
|
|
cross-domain is the hard case. (IG 2026-05-28.)
|
|
- **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 scheme
|
|
types, and how do we coordinate with attestation SEPs (e.g. SEP-2787) so
|
|
values don't collide?
|
|
|
|
## trust-annotations
|
|
|
|
- **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
|
|
([@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)).
|
|
[docs/trust-model.md](./trust-model.md) puts verification in registries; is
|
|
that enough without a normative client-side check path?
|
|
- Content-block-level vs. result-level attachment — does the draft need a
|
|
worked multi-result example before it's implementable? Per-block annotation
|
|
with **byte/codepoint ranges** was requested so clients can highlight the
|
|
flagged span, not just the whole result
|
|
([@connor4312](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-3849207989)).
|
|
- `list_changed`: confirmed response-level annotations don't participate; revisit
|
|
only if trust vocabulary ever attaches to tool definitions.
|
|
|
|
## Naming (under review)
|
|
|
|
These are explicitly unsettled and are being reviewed against the SEP-1913
|
|
record before any rename lands:
|
|
|
|
- **Umbrella name.** The original SEP was "Trust *& Sensitivity* Annotations" —
|
|
two axes (integrity *and* confidentiality). `trust-annotations` reads as the
|
|
integrity half; does the name hide the `sensitive` (confidentiality) half?
|
|
- **`untrusted` vs `openWorldHint`.** Same concept, different layer (result vs.
|
|
tool definition). Share a name/vocabulary, or keep them deliberately distinct?
|
|
- **`evidenceRef.type` vs `evidenceRef.scheme`.** The repo calls these values
|
|
"schemes" (`schemes/`); the selector field is `type`. Align the field name?
|
|
- **`evidenceRef` itself.** Its ancestor is [@pshkv](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-4196867926)'s
|
|
`decision_ref` / `attestation_ref` / `policy_profile`. Is `evidenceRef` the
|
|
clearest umbrella, or should the pointer name the kind of thing it references?
|
|
|
|
## action-metadata
|
|
|
|
- Coexistence vs. replacement of legacy `destructiveHint` / `readOnlyHint` /
|
|
`idempotentHint` / `openWorldHint`.
|
|
- Open strings vs. closed enums for `destination` / `source` / `sensitivity`.
|
|
- Does `requiresReview` need a machine-readable *reason* for good client UX?
|
|
|
|
## ifc-fides (scheme)
|
|
|
|
- Inline `_meta.ifc` for low-friction adoption vs. always behind `evidenceRef`.
|
|
- GitHub Enterprise `internal` repo visibility → `public`/`private` mapping
|
|
(audience is the whole org, broader than collaborators; resolved host-side).
|
|
- Reader-set resolution is host-side by design — confidentiality join across two
|
|
`private` sources needs the intersection, which the opaque wire marker can't
|
|
express. Is the 3-step host resolution enough, or do some hosts need a
|
|
standard `evidenceRef.ref` shape to locate the originating system?
|
|
|
|
## Parked (SEP-1913 umbrella)
|
|
|
|
- **`maliciousActivityHint`** — killed in review on three grounds
|
|
([@connor4312](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-3849207989)):
|
|
it can't be resolved before execution for dynamic tools; a boolean gives no
|
|
UX or ranges; and clients won't trust a server's self-report of its own
|
|
maliciousness. If it returns, it is per-`ContentBlock` with spans, driven by
|
|
the **host's** own detection, not a server-attested boolean.
|
|
- **Taint persistence across the store boundary** — a label must survive
|
|
round-tripping through storage: write a card number to a file, read it back,
|
|
and the sensitivity label must not silently disappear
|
|
([@JustinCappos](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/711#issuecomment-2967516811)).
|
|
This is a propagation property no single response annotation can guarantee on
|
|
its own; it needs the taxonomy and `evidenceRef` stable first.
|
|
- **Session-level propagation rules** — escalation semantics and the
|
|
**sequence-shape** gap: "this was call N in a flagged sequence" has no response
|
|
annotation surface today ([marras0914](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913)).
|
|
A candidate `evidenceRef` scheme could carry a sequence assertion; tracked in
|
|
[`schemes/README.md`](../schemes/README.md).
|