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.../schemes/README.md
Sam Morrow 41211a8107
 Add FIDES as a data-labelling scheme under schemes/ 
Move the FIDES information-flow-control draft out of
specification/draft/ and into schemes/ifc-fides.md, reframed from a
sibling extension into one data-labelling scheme that fills the
trust-annotations evidenceRef slot (type ifc.fides.v1). FIDES is not an
extension and not a peer of the extensions; it is one interchangeable
filler of the slot.

Add schemes/README.md as the index for the folder: it states what a
scheme is, lists FIDES as the worked example, records the range of
candidate schemes raised in SEP-1913 review (data classification,
design-pattern controls, ShardGuard, capability tokens, cosigning,
sequence-shape, attestation), and sets the bar a scheme doc must meet.

The reviewed normative body (label payload, semantics, reader-set
resolution, reference implementation, open questions) is preserved
verbatim from the JoannaaKL / Rul1an review rounds.

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

2.9 KiB
Raw Blame History

Data-labelling schemes

A scheme is a concrete data-labelling or tool-annotation approach that fills the trust-annotations evidenceRef slot under an evidenceRef.type value. The extension defines a small, stable wire vocabulary and an open type pointer; a scheme defines the richer, out-of-band record that pointer resolves to.

Schemes are not extensions and not siblings of the extensions. They are interchangeable: a deployment can adopt one, several, or none, and can swap them without changing the extension. Modelling each labelling approach as a scheme keeps any single academic model out of the wire root, which is the reason FIDES lives here rather than as a top-level extension.

Schemes here

Scheme evidenceRef.type Status Source
FIDES information-flow control ifc.fides.v1 Draft skeleton arXiv:2505.23643

Candidate schemes (not yet drafted)

The open type slot is designed to carry the range of models raised in the SEP-1913 review and the surrounding literature. Each is a candidate for its own scheme doc:

Approach Likely type Source
Coarse data classification (level + regulatory scope) data-class.v1 SEP-1913 taxonomy (e.g. confidential:hipaa shape)
Design-pattern controls (Plan-Then-Execute, Dual LLM, Map-Reduce) — arXiv:2506.08837
ShardGuard — cited in SEP-1913
Capability-token constraints (SINT) — SEP-1913 review thread
Caller/tool cosigning — SEP-1913 review thread
Sequence-shape audit records — SEP-1913 review thread
Tool-call attestation (in-toto / OVERT envelopes) — SEP-2787, in-toto, OVERT

These are leads, not commitments. A candidate becomes a scheme when someone drafts it to the bar below; until then the slot simply stays open for it.

Bar for adding a scheme

A scheme doc should state:

  1. Identity — the evidenceRef.type value it claims, and that it is selected by evidenceRef.type == "<value>" on a trust-annotations annotation.
  2. Payload — the shape of the record the evidenceRef resolves to.
  3. Graceful degradation — how a client that does not implement the scheme ignores it safely (the trust-annotations booleans and digest/canonicalization pair remain meaningful regardless).
  4. Producer/consumer — at least a candidate emitter and consumer, so the scheme is validated against real implementations rather than asserted.

type values are coordinated through the non-binding evidenceRef.type registry noted in trust-annotations so they don't collide.