678f846e23Restructure 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>
2.8 KiB
Trust model
A single statement of the enforcement model shared across this repository's extensions and data-labelling schemes, so individual specs don't re-litigate it.
Annotations are claims, not guarantees
An annotation on a tool result or definition is a claim made by whoever produced it. Nothing in these extensions assumes the producer is honest or competent. The value of an annotation comes from two things:
- Verifiability. Where a claim needs to be trusted, the
evidenceRefpointer (seetrust-annotations) lets a consumer resolve and check the evidence behind it — re-hash the referenced record, verify a signature, check an inclusion proof — rather than taking the claim on faith. - Accountability. Enforcement lives with the parties that can impose consequences: registries and marketplaces that admit servers, hosts/clients that gate actions, and operators that set policy. The annotation gives those parties a machine-readable surface to act on.
This mirrors the framing repeated throughout the SEP-1913 discussion: trust comes from the ecosystem verifying annotations, not from developer good faith. A server that lies in its annotations is a server a registry can refuse to list and a host can refuse to trust — the same accountability model as any other declared capability.
Defense in depth, not a single gate
As framed in the IG's inaugural meeting, these annotations are defense in depth: they reduce the likelihood of unintended actions (unnecessary destructive operations, data crossing a boundary it shouldn't), they don't claim to be a complete security boundary. A host SHOULD combine them with its own checks (its own injection detection, its own policy engine) rather than treating any single annotation as authoritative.
Human-in-the-loop on the risky edges
A recurring pattern from the IG research (Joanna's "phases" work, and the
SEP-1913 thread): rather than blanket-blocking flows a policy engine is unsure
about, flag the specific call for user confirmation. This preserves utility
while keeping a human on the genuinely risky edges, and is the recommended
default for requiresReview (action-metadata)
and for IFC policy violations (the ifc-fides scheme).
Cross-domain is the hard case
Policy engines work well inside a single user/organization universe and struggle across universes (cross-org, cross-domain flows). These extensions provide the signal (where data came from, how sensitive it is, what a tool does with it); they do not solve cross-domain enforcement on their own. That remains an open question and a likely area for future work (e.g. asymmetric crypto for domain integrity verification).