Research agenda
What the discipline has not yet answered
Each problem below is named in a specification's disclosed gaps or in a design note, not invented for this page. Stating them is part of the work: a field that cannot say what it does not know cannot be checked. Responses, objections and partial answers are welcome on the linked discussions.
01
Can someone who did not write the specifications reproduce their verdicts from the text alone?
Every implementation so far is by the authors. A specification is proven when a stranger reproduces it; until then SPEC-007 to -010 remain Drafts.
Open. The build order, every vector set and the rules most often misread are published for exactly this.
02
What gives a root key the standing to certify institutions for relying parties that never chose it?
Every chain ends at a root the relying party pins. Each institution can run its own today; a root shared across institutions is a governance question, not a cryptographic one, and the specifications deliberately do not answer it.
Open. A candidate model has been red-teamed against web PKI, DNSSEC, RPKI, Certificate Transparency, accreditation and treaty recognition.
03
How does one service that hosts many systems of record, each with its own audience and pinned root, publish discovery for all of them?
A relying-party document describes one relying party and the roots it pins, at one well-known path per origin. A platform hosting many ledgers cannot describe them all in one such document.
Open. Found while preparing a hosted relying party; it needs a specification decision (per-path documents, or one document listing several relying parties).
SourceSPEC-009 §3.1 ↗
04
How does a relying party with no revocation source of its own establish that a witness's or approver's key is still unrevoked?
Freshness staples are specified for keys on an artifact's chain. For statement keys, revocation freshness follows the chain-of-trust rules unchanged, and staples are not yet specified.
Open, disclosed in SPEC-008's known gaps.
SourceSPEC-008 §10 ↗
05
Where is the relying party for sending a message or publishing a statement, which no system of record can refuse?
Every guarantee depends on the system that makes the change refusing changes that do not arrive as a verified Act. An outbound effect needs a gateway that inherits those duties; this is not yet specified.
Open, disclosed in SPEC-008's known gaps and security considerations.
SourceSPEC-008 §10–§11 ↗
06
How should an artifact declare a constraint that depletes, such as an annual budget, so that every evaluator can enforce it?
A per-request limit can be enforced by any evaluator. A cumulative one depends on state no stateless evaluator can verify, and SPEC-001's budget constraint does not distinguish the two.
Partly answered. A state layer beside evaluation (reserve, settle, release) is built; how artifacts declare such constraints, and who defines the ledger, remain open.
Cite this
This is a field in formation; this page will be revised. Cite the version date below, not the day you happen to be reading this.
Suggested citation
SafeHaven (2026). Open Problems. Computable Authority, version of 2026-10-28. https://www.computableauthority.com/open-problems
BibTeX
@misc{computableauthority-open-problems,
author = {SafeHaven},
title = {Open Problems},
howpublished = {Computable Authority},
year = {2026},
note = {Version of 2026-10-28},
url = {https://www.computableauthority.com/open-problems},
}