Stacked on the trust-annotations base. Declarative inputMetadata / returnMetadata
+ outcome classifiers (incl. requires_review) on ToolAnnotations. Carries forward
the field semantics from SEP-2061 (Action Security Metadata, @rreichel3), closed
2026-06-13 in favour of this extension.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Per 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>
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>
Enrich 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>
ifc-fides:
- lead Label semantics with the load-bearing wire/host split (wire markers are
advisory hints; reader-set semantics are host-resolved)
- state the join asymmetry as principled, not incidental: integrity join is
total/wire-computable (small closed lattice); confidentiality join is partial
because public is the only wire-computable case (reader set = top), while
private join is the intersection the opaque markers don't carry
- frame wire opaqueness as a property of the security model, not a spec limitation
- add fail-closed handling when resolution is unavailable (ref absent, digest-only,
source unreachable): never treat opaque labels as equal or as public; unknown/
mixed provenance classifies private; resolved reader sets are not durable grants
trust-annotations:
- show jcs/rfc8785 alongside cbor/rfc8949 so canonicalization reads as a
per-reference envelope choice rather than a default
- note type/digest/canonicalization as the local-re-derivation minimum
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
ifc-fides (review by @JoannaaKL):
- confidentiality is public/private only on the wire; drop the reader-list
(logins aren't uniform across servers, are themselves access-restricted,
and reader sets can be huge)
- add Reader-set resolution section: two private markers aren't equal, the
confidentiality join is the intersection and isn't computable from opaque
wire markers, so hosts resolve to concrete reader sets at decision time
- integrity join is total/wire-computable; confidentiality join is not
- emitter MUST classify per resource, not per repository (public repos serve
non-world-readable sub-resources), making github-mcp-server a real proof point
action-metadata / docs:
- SEP-2061 closed 2026-06-13 in favour of this extension; this draft is now the
canonical home. Updated action-metadata.mdx, README, sep-disposition,
related-work, and intent-comment status accordingly.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Official extension specs (ext-auth) use only `title:` in frontmatter
plus an <Info> protocol-revision marker. Remove the invented
extension_identifier / status / maintainers / related / profile_of
fields and restate the identifier and profile relationship in the body
prose where they belong.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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>
Carve the schema-bearing parts of SEP-1913 into three independent
experimental extensions, per @localden's "narrower first cut" ask and
the Tool Annotations IG's 2026-05-28 extension-first decision:
- io.modelcontextprotocol/trust-annotations (headline): narrow
data-classification taxonomy (sensitive, untrusted) + open-ended
evidenceRef pointer.
- io.modelcontextprotocol/action-metadata: carries forward SEP-2061
(inputMetadata/returnMetadata/outcomes + requiresReview).
- io.modelcontextprotocol/ifc-fides: FIDES information-flow control as
a profile of evidenceRef, not a wire root.
Adds repo meta (README, MAINTAINERS, CONTRIBUTING, LICENSE) and docs
(sep-disposition, intent-comment, decisions, open-questions,
trust-model, related-work). FIDES demoted to a profile; DataClass and
requiresReview rehomed; maliciousActivityHint and propagation parked on
the SEP-1913 umbrella. Citations index on public sources only.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
