0be45d9b95Enrich the base extension docs so the early review history is preserved rather than erased by the narrow first cut: - trust-annotations.mdx: add a normative subsection distinguishing result-level untrusted from tool-definition openWorldHint (the SEP-1913 #711 distinction). - open-questions.md: capture the sensitivity-field shape debate, enforcement-vs- advisory risk, per-block byte ranges, taint persistence, and sequence-shape, each attributed to the reviewer who raised it; add a Naming (under review) section for the contested field/extension names. - related-work.md: add verified FIDES alternatives (Permissive IFC 2410.03055, AirGapAgent 2405.05175, CaMeL 2503.18813) and a schemes-vs-host-architectures distinction. - decisions.md: log the scheme/architecture boundary and the feedback-capture decision. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
98 lines
6.1 KiB
Markdown
98 lines
6.1 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 profile
|
|
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
|
|
([@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?
|
|
- **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).
|