Trust & privacy extensions: scaffolding + the trust-annotations base

[SamMorrowDrums]

Trust & privacy extensions — scaffolding + the trust-annotations base

This is the base of a three-PR stack that splits SEP-1913 (Trust & Sensitivity
Annotations) into small, independently-shippable pieces, validating the shapes as
experimental extensions before asking the spec to commit. It follows the
2026-05-28 IG decision
to validate via extensions first, and the SEP-2127 (#2893) precedent of moving a
broad SEP onto the extensions track.

What's in this PR

• Repository scaffolding — README.md (front door + the extension/scheme map),
  CONTRIBUTING.md, MAINTAINERS.md, LICENSE, and the docs/ set:
  • docs/sep-disposition.md — what moved out of SEP-1913 and where it landed.
  • docs/related-work.md, docs/trust-model.md, docs/open-questions.md,
    docs/decisions.md — the shared model, prior art, open threads, and the
    append-only decision log.
• The first extension — specification/draft/trust-annotations.mdx
  (io.modelcontextprotocol/trust-annotations): a small client-facing vocabulary
  (sensitive / untrusted booleans) plus a bounded, open-type evidenceRef
  slot that richer records hang off without entering the wire root.

The stack

PR	Adds	Depends on
this	scaffolding + trust-annotations	—
#3	action-metadata extension	independent; stacked here for now
#4	FIDES scheme under schemes/	fills this PR's evidenceRef slot

The two extensions are independent of each other. The FIDES scheme depends on
trust-annotations because it fills its evidenceRef slot (type: "ifc.fides.v1"), and is deliberately not an extension or a sibling — it is one
of several interchangeable data-labelling schemes the slot can carry.

Merge order: this PR → #3 / #4. The stacked PRs target this branch and should be
retargeted to main once this merges. (The README links to
specification/draft/action-metadata.mdx and schemes/, which land in #3 and #4.)

Note: commits in this stack are currently unsigned due to a local signing
agent issue; they can be re-signed on request before merge.

[Rul1an]

This carve is the right shape, and the evidenceRef slot captures the small-annotation-on-the-wire / richer-evidence-out-of-band split well.

One small editorial point on trust-annotations.mdx: every evidenceRef example currently uses canonicalization: "cbor/rfc8949". Since canonicalization is per-reference precisely so different evidence producers can be re-derived, it would read more neutrally to show a second example with JSON canonicalization, for example jcs/rfc8785, alongside the CBOR one.

With only CBOR shown, implementers may treat it as the default rather than one valid envelope choice, which would quietly narrow the extension point the field is meant to keep open.

On the open questions, keeping type as an open string with a non-binding registry seems right. The minimum a client needs to do useful local checking is type, digest, and canonicalization; schema seems better as recommended, and ref as optional. That keeps digest-only references useful while letting deployments with an audit/evidence stream add a locator.

Happy to help exercise the shape with worked emitter/consumer cases for policy-decision and sequence types, especially the cases where the annotation stays small and the sequence or policy record remains out of band.

[Rul1an]

+1 to this direction — it's the precision that was missing behind keeping private opaque on the wire. The load-bearing part is that private must not collapse into one global bucket: two private sources can have different reader sets, and data derived from both may flow only to a sink valid for all of them, the intersection, which is exactly what an opaque token can't carry. Resolving each source host-side at decision time is the right shape.

One case worth adding to the section: when resolution isn't available — ref is optional, a label may be digest-only, or the originating system is unreachable at decision time — the host must not treat the opaque labels as equivalent or as public. It should deny, prompt, or apply its configured fail-closed policy; two private labels are equal only once resolution proves their sources are. Without that line the optional/digest-only reference can quietly become permissive. And reinforcing your "then discards them": the resolved set is a decision-time read under the host's own credentials, so it shouldn't be cached as a durable grant or serialized back into annotations/evidence unless a deployment explicitly opts in.

Net, the wire stays small and free of user identities while hosts still have enough to make a precise flow decision when they hold source provenance plus host-side credentials — the same small-marker-on-the-wire, richer-state-host-side split as evidenceRef.

[Rul1an]

+1 repository visibility is a default hint, not a classification boundary, so the emitter has to classify per resource returned (a public repo still serves things that aren't world-readable: draft advisories, the collaborator roster, authenticated-user fields), not per repo.

It divides cleanly: the label rides the actual resource (emitter-side), the host resolves the concrete reader set later only when it needs a precise decision (the reader-set-resolution section), and unknown or mixed provenance classifies private until the source is established, never defaulted to public from a repo-level shortcut, and without serializing reader sets. Happy to turn this into a small set of emitter conformance cases if useful, the public-repo-with-private-subresource ones especially.

[SamMorrowDrums]

Thanks @Rul1an — all three of these were actionable, not just +1s, so they're folded into the draft (4967a9e):

1. Second canonicalization example. trust-annotations.mdx now shows jcs/rfc8785 alongside cbor/rfc8949, with a line that canonicalization is a per-reference envelope choice (neither is the default) and that the type/digest/canonicalization triple is the local-re-derivation minimum — so digest-only references stay useful and CBOR doesn't read as canonical.

2. Fail-closed when resolution isn't available. The Reader-set resolution section now states that when ref is absent, the label is digest-only, or the source is unreachable, the host MUST NOT treat opaque labels as equal or as public — it denies/prompts/applies its fail-closed policy. Two private labels are equal only once resolution proves their sources are. Added your "resolved set is a decision-time read under the host's own credentials, not a durable grant" point too — hosts shouldn't cache it as a grant or serialize it back into annotations/evidence unless explicitly opted in.

3. Per-resource, unknown/mixed → private. The emitter section already classifies per resource returned (draft advisories, collaborator roster, etc.); I added the explicit rule that unknown or mixed provenance classifies private until the source is established, never defaulted to public from a repo-level shortcut.

Yes please on the worked emitter/consumer cases — the public-repo-with-private-subresource ones and the policy-decision / sequence evidenceRef types are exactly the cases that would prove the shape holds. That's the validation step the extensions track exists for.