59597f94dc- schemes/data-class.md: skeleton for the structured classification taxonomy the trust-annotations 'sensitive' boolean deliberately omits (class + regulatory scope + org labels), shaped as open questions and attributed to the SEP-1913 reviewers who pushed for it (JustinCappos, olaservo, Mossaka, krubenok, localden). - schemes/README.md: list data-class under 'Schemes here'; add verified label- scheme candidates (Permissive IFC 2410.03055, AirGapAgent 2405.05175); move CaMeL and the design-pattern catalogue into a new 'Not schemes: host architectures' section, since they govern host control-flow rather than producing a per-result data label. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
3.9 KiB
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 |
| Data classification | data-class.v1 |
Draft skeleton | SEP-1913 taxonomy (class + regulatory scope) |
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.
A scheme produces a per-result data label a server attaches:
| Approach | Likely type |
Source |
|---|---|---|
| Permissive information-flow labels (influence-based propagation) | ifc.permissive.v1 |
arXiv:2410.03055 |
| Contextual-integrity classification (per-task minimisation) | ci.airgap.v1 |
arXiv:2405.05175 |
| 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.
Not schemes: host architectures
Some models raised in the same discussion are host/client control-flow
architectures, not data labels — they decide what to do with information,
they don't produce a per-result record a server attaches. They are prior art (see
related-work.md), not entries here:
| Approach | Why it isn't a scheme | Source |
|---|---|---|
| CaMeL (capability-based control/data-flow) | A host runtime; a capability token it issues could be referenced via evidenceRef, but the architecture isn't a label |
arXiv:2503.18813 |
| Design-pattern controls (Plan-Then-Execute, Dual LLM, Map-Reduce) | Client-side execution patterns, nothing on the wire | arXiv:2506.08837 |
Bar for adding a scheme
A scheme doc should state:
- Identity — the
evidenceRef.typevalue it claims, and that it is selected byevidenceRef.type == "<value>"on atrust-annotationsannotation. - Payload — the shape of the record the
evidenceRefresolves to. - Graceful degradation — how a client that does not implement the scheme
ignores it safely (the
trust-annotationsbooleans anddigest/canonicalizationpair remain meaningful regardless). - 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.