The Authority Handshake, Built

R-08 named the one link in the authority chain that didn't already exist. Section 6.5 of that paper put it precisely: verifying that a specific issuer is one the relying system has reason to recognize, via a trust-anchor mechanism rather than a hand-configured allowlist, was the step every other mechanism in the paper existed to eventually support, and the one step nothing yet implemented. This entry reports what happened when that step was actually built: NOMOS-SPEC-007, a chain-of-trust verification mechanism, checked the same way R-13 checked conserved-state authority against R-12 — item by item against the source paper's own claims, not summarized from a distance.

1. What was built

A delegation chain, verified entirely offline: one key certifies another to sign, within an optional scope, until an expiry — the same pattern certificate authorities have used for web trust for decades, applied here to institutional authority instead of domain names, exactly as R-08 §6.5 proposed rather than a new cryptographic primitive. The relying system pins the root it trusts itself. There is no default root, anywhere in the implementation.

When a chain doesn't resolve, the failure is one of four specific reasons, not one generic rejection: the signing key was never certified, a certificate that was once valid has expired, a certified key has since been revoked, or the artifact itself has been tampered with after sealing. Revocation is keyed on the revoked key itself, not on any one certificate that named it — a revoked key is dead on every path a presenter might construct to it, not just the one path a narrower check happens to catch. Malformed input fails closed rather than crashing. A real, signed delegation cycle terminates rather than looping. All of this is covered by a real test suite, not asserted from the design.

Only once a chain resolves to a recognized, unrevoked issuer does the artifact's own rules get evaluated against supplied facts — a real AUTHORIZED, DENIED, or ESCALATED verdict, not merely "the chain checks out." "The rules say no" and "we never established who's asking" are kept as genuinely different outcomes, because they call for genuinely different next steps: re-presenting a better chain fixes the second. It never fixes the first.

2. R-08's own decomposition, checked

Section 6.4 of R-08 listed exactly what NOMOS's existing mechanisms each covered, and precisely where each one stopped. Adding the row that didn't exist yet:

R-08, §6.5: "The second step — verify issuer... is the one link in this chain that does not exist today." It exists now.

3. R-08's nine open questions, checked

R-08 §11 named nine questions as foundational, not incidental. Checked against what SPEC-007 actually does, not what it was hoped to do:

• Authority recognition — resolved. A relying system decides via the certificate chain to its own pinned root, not a hand-configured allowlist.
• Trust anchors, and their governance — open. SPEC-007 answers how verification works once a root exists. Who should operate one, and under what governance, is R-09's question, and stays R-09's question.
• Delegation without a delegate exceeding the issuer's authority — partial. Certificates carry an optional scope and an expiry, a real structural limit. Whether that fully prevents over-delegation in every case is not something this mechanism alone settles.
• Revocation propagation speed — partial. The check itself is real, keyed on the key, checkable offline against a published, signed list. How fast that list reaches every relying system that might still be relying on a now-revoked key is a distribution problem no specification can fully close by itself.
• Offline operation — resolved. This is the mechanism's central property: no call back to an issuer or to any central catalog is required to verify a chain.
• Cross-jurisdiction recognition — open. Not addressed by this mechanism.
• Conflict between two recognized authorities — open. Not addressed by this mechanism.
• Sufficiency of context before evaluation — open. A rule-evaluation question, separate from establishing who's asking.
• Liability when a valid authority's action causes harm — open. Outside what a verification protocol can settle; a legal and institutional question, not a cryptographic one.

Two resolved. Two see real, partial progress. Five stay open — named precisely, the same way R-08 named the handshake itself, rather than left to be discovered by whoever tries to rely on this next.

4. What this does not answer

Whether a chain that resolves is a chain that should have been trusted in the first place — the root-governance question — is untouched by this entry. NOMOS-SPEC-007 is published as Draft for exactly that reason among others: one implementation exists, and no claim of interoperability with an independent second one is being made. Draft describes the standard's maturity, not whether the mechanism works; the chain verification itself is real, tested code, not a proposal. What Draft honestly flags is narrower and more specific: nobody outside this work has yet built a second, independent implementation to prove the specification travels.

R-09 remains the place the root-governance question is actually argued, deliberately red-teamed against web PKI, DNSSEC, RPKI, Certificate Transparency, and other precedents, rather than assumed. This entry only reports what got built in response to the part of R-08 that was ready to be built.