modelcontextprotocol/experimental-ext-tool-annotations
Watch
1
0
Fork
You've already forked experimental-ext-tool-annotations
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
experimental-ext-tool-annot.../docs/open-questions.md
Sam Morrow 678f846e23
 repo: make trust-annotations the base; FIDES becomes a scheme, not a sibling 
Restructure the incubation into two extensions plus interchangeable data-labelling
schemes, shipped as a stack of three PRs:

- This PR (base): shared scaffolding + the trust-annotations extension.
- action-metadata moves to its own stacked PR.
- The IFC/FIDES work moves out of specification/draft/ entirely — it is one
  data-labelling scheme (ifc.fides.v1) that fills the trust-annotations
  evidenceRef slot, not an extension and not a sibling. It lands in a schemes/
  folder built to hold alternative approaches (data-class, capability tokens,
  cosigning, sequence-shape, attestation) so no single academic model is baked
  into the wire.

README, sep-disposition, related-work, trust-model, open-questions and the
decision log are reframed accordingly (two extensions + a schemes folder; the
range of candidate schemes drawn from the SEP-1913 thread and cited literature).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-06-16 10:29:11 +02:00

2.3 KiB
Raw Blame History

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

  • Is sensitive the right single coarse signal, or do we need the data-class.v1 profile from day one?
  • Content-block-level vs. result-level attachment — does the draft need a worked multi-result example before it's implementable?
  • list_changed: confirmed response-level annotations don't participate; revisit only if trust vocabulary ever attaches to tool definitions.

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 — if it returns, it is per-ContentBlock with spans, driven by the host's own detection, not a server-attested boolean.
  • 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).