Roadmap
Master index of planned future features with status, ADR links, and open design issues (I1–I4). Design material for these features lives under roadmap/.
This document indexes planned future features. Timing is uncertain — items represent direction, not commitments. Each entry links to where the design rationale lives. The current architecture is forward-compatible with these additions — extensible enums, the responseId field, and the capabilities array all anticipate them without requiring breaking changes.
Planned Features
| Feature | Status | Design Rationale |
|---|---|---|
| Transparency log — public, append-only Merkle tree of all trust signal responses for auditability | Design incomplete — open issues I1–I4 (see below) | ADR-007, security.md, openapi-experimental.yaml |
Access gates (mandatory identification) — a future revision may require did:web JWT on some or all requests. The current spec has no access gate (identification is optional per-request, authorities MUST NOT require it). Framing for any future gate is chosen deliberately rather than inherited. | Migration path defined | ADR-006 |
| Signed error responses — signed error envelope to prevent suppression attacks | Idea — revisit if attack surface proves significant | ADR-012 |
| URL minimization — structured scope objects or parameter stripping to reduce data agents expose | Idea — no design yet | security.md, api.md |
| Federated authorities — multiple independent authorities with mutual recognition | Deferred — premature without ecosystem demand | ADR-005 |
Signal envelope extensions — source and confidence metadata fields (useful once federation exists) | Deferred — adds no information in single-authority model | ADR-004 |
Well-known manifest — /.well-known/trstd.json as primary discovery with provider metadata, multi-entity matching, extension parameters, and VerifyEndpoint capability. The <link> tag becomes fallback. | Design complete — deferred to lower integration bar | ADR-001, integration-preview.md |
MCP discovery — trust authority operates an MCP server exposing a check_trust tool for agents that do not know the #trstd <protocol>. Requires a finalized MCP discovery standard (SEP-1649, SEP-1960, or IETF mcp: URI scheme). | Contingent on MCP discovery standard | mcp-discovery.md |
WebMCP discovery — service providers register check_trust via W3C WebMCP so any WebMCP-compliant agent discovers trust verification without trstd-specific knowledge. The imperative JS API (navigator.modelContext.registerTool) is near-stable; the declarative <form> API is still a TODO in the spec. | Imperative API: ready to prototype once agents ship WebMCP support. Declarative API: contingent on W3C spec stabilizing. | WebMCP spec, mcp-discovery.md |
| Detached-JWS alternative — JOSE-based signature verification alongside raw Ed25519 | Idea — no design yet | ADR-015 |
Extensibility Hooks (no specific roadmap design)
These are not committed features. The current architecture leaves room for them, and they may land in a future revision.
| Hook | Current State | Reference |
|---|---|---|
Assessment context values — new values beyond purchase, inquiry, high-value | Open string today — agents and authorities can use custom values now | ADR-010 |
Status enum values — new values beyond verified, lapsed, revoked, pending | Enum declared extensible | ADR-014 |
Capability types — new types beyond verify and mcp | Capabilities array extensible | ADR-001 |
| Field selection — query parameter filtering of signal categories | Backward-compatible enhancement if signal count grows | ADR-002 |
Explicitly Out of Scope
| Feature | Why | Reference |
|---|---|---|
| Post-transaction feedback — agents report outcomes after transactions | Different threat model (Sybil attacks, fake reviews); different problem from pre-transaction verification | — |
Open Issues
Transparency Log
The transparency log is the largest planned feature. Issues are interdependent — resolving I1 (defer the log) simplifies I2–I4.
| ID | Issue | Chosen Resolution | Reference |
|---|---|---|---|
| I1 | Log design is unfinished — ADR-007 contains literal "This needs discussion" text | Mark log as a roadmap goal, remove normative dependencies. The core protocol stands without it. | ADR-007 |
| I2 | Replication lag — agents querying the log immediately after a verify response may not find the entry | Add eventual consistency note and recommended retry delay (e.g., 30 seconds) to integration guide. Becomes non-normative guidance once I1 defers the log. | integration-guide-agent.md |
| I3 | Tampering detection — a fully compromised authority can publish a false rootHash with no detection mechanism | Document the limitation: the log deters but cannot prevent authority-wide compromise. Cross-authority verification can be explored later. | security.md |
| I4 | No consistency proofs — /v1/log/entries/{responseHash}/proof provides inclusion proofs only, no endpoint for verifying consistency between two tree roots | Defer. Consistency proofs require agents to persist previous tree roots — a stateful requirement most early agents will not implement. | security.md |
External Dependencies
| ID | Issue | Chosen Resolution | Reference |
|---|---|---|---|
| G2 | TSAI protocol is an external dependency — agent identity depends on it. Spec source: github.com/awslabs/tsai-protocol. Still missing a pinned version and a defined minimum required subset. | Add a normative reference with version and minimum required subset (DID resolution, JWT format, key types). Keep specs decoupled rather than inlining TSAI requirements. | api.md, ADR-006 |