Roadmap to OpenTDF v1

[jrschumacher]

Purpose

Track the fixes, features, and enhancements that move OpenTDF toward a stable platform v1: reliable service lifecycle, explicit extension contracts, governed shared infrastructure, and predictable SDK interoperability across deployment topologies and federation.

This is a proposed release-readiness roadmap, not an announced release date, a TDF format version, or a commitment to land every improvement before v1. Preserve existing supported SDK/service contracts while evolving internals.

How we decide v1 versus v1.1

Every child should state its proposed release class, evidence, acceptance criteria, dependencies, and the reason it cannot—or can—wait.

Hard gate

A demonstrated security/correctness defect in a supported workflow, a broken supported compatibility contract, or an explicitly accepted release dependency is a v1 gate candidate regardless of score. Confirm against current source/tests first; an old architecture finding is not proof that the current release is affected.

Prioritization score

For work without a hard gate, use this small rubric:

Dimension	Range	Higher score means
Correctness / reliability	0–3	Stronger evidence of failure in supported workflows
Compatibility	0–3	Greater risk to supported SDKs, extensions, upgrades, or federation
Operability	0–2	Needed to deploy, diagnose, or recover supported configurations reliably
Explicit v1 dependency	0–2	Directly enables an agreed v1 capability or acceptance criterion

• 7–10: strong v1 requirement candidate; release owner confirms the requirement.
• 4–6: explicit scope decision; may be v1 assurance/enabling work or a v1.1 follow-up.
• 0–3: normally post-v1 unless new evidence changes the case.

These are prioritization judgments, not measured performance scores. Record the four component scores and a short rationale; avoid false precision. Complexity does not justify deferring a demonstrated security defect—split the work or escalate the release decision instead.

Release classes

• v1: an accepted release requirement with evidence and objective exit criteria.
• v1-assurance: tests, diagnostics, or additive contracts that reduce v1 risk; not automatically blocking.
• post-v1: enhancements and experiments that can wait unless evidence establishes a v1 requirement.

The score helps decide promotion to v1; it does not approve a release requirement by itself. It measures release necessity, not the potential value of the work.

An experimental IPC v2 pilot does not automatically block v1. A performance change becomes a release gate only when measured evidence connects it to an agreed requirement.

Work chunks

Classes below are provisional; each child records its component scores, scope, and acceptance criteria. Current-source and duplicate checks were completed against upstream 5173b4c5. No explicit v1 release dependency has been assumed.

A. Reliability and security fixes

Work / issue	Release class	Why	Evidence
#3997 — Error-return registration (first adopter follows separately)	v1-assurance	Makes startup failures recoverable before extension contracts stabilize. Retaining the legacy callback avoids forcing every service to migrate before v1.	Failure/cleanup tests and agreement on the supported v1 registration contract.
#3998 — Audit principal end-to-end assurance	v1-assurance	PR #3900 already fixed verified-principal handling. The remaining work is full-chain regression assurance, not another report of that bug.	Auth → audit → SDK → IPC/remote tests extending #3900.
#3999 — Config reload / partial activation	v1-assurance	A supported reload must not silently leave inconsistent active state. A generalized configuration control plane can wait.	Tests for invalid reloads, failed activation hooks, and the documented supported reload contract.

B. Compatibility and operational assurance

Work / issue	Release class	Why	Evidence
#4000 — Health and readiness compatibility	v1-assurance	Protects existing deployment probes and rollout behavior. A new typed health registry is not automatically a v1 requirement.	Current probe semantics and compatibility tests for supported deployments.
#4001 — Authorization-cache refresh visibility	post-v1	Helps diagnose stale or failed refreshes without changing decisions. Full cache administration and distributed invalidation can wait.	Demonstrated diagnostic gaps; any explicit v1 operational requirement.
#4002 — Registration / discovery / SDK compatibility	v1-assurance	Basic operations must work within the supported old/new SDK-platform window. Generalized capability negotiation can be delivered separately.	An agreed support window and passing basic-operation/metadata compatibility tests.

C. Performance and topology enhancements

Work / issue	Release class	Why	Evidence
#3994 — opt-in uncompressed IPC v1	post-v1	Potential efficiency improvement, but no demonstrated release-blocking performance requirement yet. Existing behavior remains the default.	Reproducible benchmarks and an agreed performance requirement before treating it as a gate.
#3995 — experimental IPC v2	post-v1	A larger transport experiment; v1 can retain existing SDK/Connect behavior while alternatives are evaluated downstream.	Candidate comparison, semantic parity, reliability pilot, and measured benefit before expansion.

D. Internal authority and shared authentication

Work / issue	Release class	Why	Evidence
#4003 — Internal caller/service/delegated authority	v1-assurance	Make the internal trust contract explicit; propagating identity is not granting every service permission.	Current IPC/public middleware differences and a local/remote/nested-call acceptance matrix.
#4004 — Shared auth/KAS verification primitives	post-v1	Reduce duplicate security code without removing required verification or conflating different token types.	KAS's mirrored asymmetric allowlist; artifact-specific signature, claims and binding tests.

Longer-horizon direction includes scoped capabilities, central cache/audit/config governance, database identity isolation, and policy-governed identity enrichment. Create bounded child issues as contracts and acceptance gates become concrete rather than treating these themes as one required rewrite.

Impact flags on each child

• Requires downstream changes: source adaptation versus configuration coordination versus optional adoption. Required adaptation means high coordination impact.
• Feature flag not supported: distinguish a gate that exists today from one the issue must add. Binary rollback or disabling an entire service is not an old/new behavior flag; runtime flags cannot repair removed APIs.
• High complexity: reserve human review for semantic and failure-path changes.
• High coupling: name service/SDK/operations boundaries that require coordinated review.

Dependency and release tracking

Native sub-issues express scope; they do not imply that one child blocks another. Record actual dependencies explicitly. Keep independently useful fixes independently mergeable; use stacks only for real shared contracts or code dependencies.

Release readiness is the status of the approved v1 gate set, not the percentage of all roadmap sub-issues closed. Before a v1 release decision:

• Confirm the supported SDK/platform/deployment compatibility window and basic-operation acceptance matrix.
• Give every child a release class, evidence-based rationale, impact flags, and objective acceptance criteria.
• Resolve approved v1 gates or document an explicit owner-approved release decision.
• Validate current behavior and preserve migration/rollback paths; do not equate documentation with passing runtime tests.
• Move or link deferred enhancements into the post-v1 plan without making them implicit release blockers.

Keep issue descriptions readable. Link public source and focused evidence appendices where needed; never upload private downstream implementation details into this public tracker.