Open questions

June 16, 2026 · View on GitHub

Tracked here rather than in the spec drafts, so the drafts stay non-temporal.

Cross-cutting

  • Where does the policy-enforcement engine live across different user universes (cross-org, cross-domain)? Engines work well within one universe; cross-domain is the hard case. (IG 2026-05-28.)
  • Cross-domain integrity verification — is asymmetric crypto for domain identity in scope for a future extension, or out of scope entirely? CLI tools remain a persistent gap for enforcing these constraints.
  • evidenceRef.type registry — who curates the list of well-known scheme types, and how do we coordinate with attestation SEPs (e.g. SEP-2787) so values don't collide?

trust-annotations

  • Sensitivity beyond the floor. The sensitive boolean is settled as the lowest-common-denominator floor — a basic, general signal every client can act on, "better than nothing," with servers encouraged to also emit a richer scheme (see the decision log and the "emit both" guidance in the spec). The residual open question is narrower: is "coarse boolean + richer evidenceRef scheme" sufficient for regulated flows, or do some hosts need the classification expressible on the wire without a scheme? Current lean: no wire escape hatch — keep the wire floor un-rottable and push the taxonomy into data-class.v1. Background on why a single scalar/enum was rejected: sensitivity is set-theoretic not linear (@JustinCappos), reviewers wanted org-defined vocabularies (@olaservo, @Mossaka) and a class+regulatory pairing (@krubenok), and a baked-in taxonomy is hard to remove (@localden).
  • Enforcement vs. advisory. A self-declared sensitive: true from a poorly-configured or malicious server could create a false sense of security (@localden). docs/trust-model.md puts verification in registries; is that enough without a normative client-side check path?
  • Content-block-level vs. result-level attachment — does the draft need a worked multi-result example before it's implementable? Per-block annotation with byte/codepoint ranges was requested so clients can highlight the flagged span, not just the whole result (@connor4312).
  • list_changed: confirmed response-level annotations don't participate; revisit only if trust vocabulary ever attaches to tool definitions.

Naming (under review)

These are explicitly unsettled and are being reviewed against the SEP-1913 record before any rename lands:

  • Umbrella name. The original SEP was "Trust & Sensitivity Annotations" — two axes (integrity and confidentiality). trust-annotations reads as the integrity half; does the name hide the sensitive (confidentiality) half?
  • untrusted vs openWorldHint. Same concept, different layer (result vs. tool definition). Share a name/vocabulary, or keep them deliberately distinct?
  • evidenceRef.type vs evidenceRef.scheme. The repo calls these values "schemes" (schemes/); the selector field is type. Align the field name?
  • evidenceRef itself. Its ancestor is @pshkv's decision_ref / attestation_ref / policy_profile. Is evidenceRef the clearest umbrella, or should the pointer name the kind of thing it references?

action-metadata

  • Coexistence vs. replacement of legacy destructiveHint / readOnlyHint / idempotentHint / openWorldHint.
  • Open strings vs. closed enums for destination / source / sensitivity.
  • Does requiresReview need a machine-readable reason for good client UX?

ifc-fides (scheme)

  • Inline _meta.ifc for low-friction adoption vs. always behind evidenceRef.
  • GitHub Enterprise internal repo visibility → public/private mapping (audience is the whole org, broader than collaborators; resolved host-side).
  • Reader-set resolution is host-side by design — confidentiality join across two private sources needs the intersection, which the opaque wire marker can't express. Is the 3-step host resolution enough, or do some hosts need a standard evidenceRef.ref shape to locate the originating system?

Parked (SEP-1913 umbrella)

  • maliciousActivityHint — killed in review on three grounds (@connor4312): it can't be resolved before execution for dynamic tools; a boolean gives no UX or ranges; and clients won't trust a server's self-report of its own maliciousness. If it returns, it is per-ContentBlock with spans, driven by the host's own detection, not a server-attested boolean.
  • Taint persistence across the store boundary — a label must survive round-tripping through storage: write a card number to a file, read it back, and the sensitivity label must not silently disappear (@JustinCappos). This is a propagation property no single response annotation can guarantee on its own; it needs the taxonomy and evidenceRef stable first.
  • Session-level propagation rules — escalation semantics and the sequence-shape gap: "this was call N in a flagged sequence" has no response annotation surface today (marras0914). A candidate evidenceRef scheme could carry a sequence assertion; tracked in schemes/README.md.