RFC: name the passing status dispositions, so an audit record can tell "no claim offered" from "live at T"

[scott-wyatt]

From the r14n/RLPS maintainer, following #1. You raised this gap first and deliberately declined to file it, on the reasoning that an RFC written before anyone has hit the problem is speculation with a number on it. That reasoning is right about the evidence-record design, and this RFC does not ask for it. It asks for one narrower thing, and the argument for asking now rather than later is in the problem statement.

The problem

§6.3.3.4 names three status outcomes — absent, unresolvable, revoked — and two of them are rejections carrying codes (APH_E008, APH_E015). The remaining two outcomes are the ones that pass, and only one of them has a name:

1. Case 1, absent. No credentialStatus was offered. The verifier checks nothing and advances, and it "remains conformant."
2. Case 3 with the bit clear. Status was resolved, its proof verified, its issuer and purpose confirmed, its freshness bound satisfied — and the mandate is affirmatively live as of that instant. §6.3.3.4 gives this outcome one clause ("A bit of 0 means not revoked, and verification continues") and no name.

Those two are radically different facts about authority, and they produce the same verification result. An audit record downstream cannot distinguish "nobody asserted this mandate was live" from "the notary's list said it was live at 14:03:22Z" — which is exactly the distinction you described as the thing a gate will need to record.

Three properties of the current text make this a spec-level ambiguity rather than an implementation defect:

• Both outcomes are conformant passes. This is not a sloppy verifier flattening two states; the protocol genuinely permits a pass with no liveness claim in evidence.
• §6.3.3.4 case 1 makes the difference a matter of local policy — "A verifier MAY additionally be configured to REQUIRE a status reference … that is policy, not protocol, and a verifier that does not require it remains conformant." So the same envelope, verified by two conformant verifiers, can yield two different security postures, and nothing in either verifier's output records which one happened.
• §6.3.3.3's freshness bound makes the live result time-scoped. "Live" decays. An evidence record without the instant cannot be re-evaluated later, only re-trusted.

Why now, given you declined to file it. The local invention you warned about has already happened — in the first downstream repository, before any gate exists. Defining our two APH-backed control keys forced r14n to say something about what a gate must record, so docs/aph-integration.md now tells consuming gates to record attestationMode, bodySha256, the APH_E* code, and the accepted aphVersion. That is r14n specifying enforcement-side evidence vocabulary in r14n's repository. One repository is the cheapest moment this will ever be reconcilable; four gates from now it is a migration.

The proposed change

Name the fourth outcome, and specify the two facts that make it auditable. Concretely, a short addition to §6.3.3.4:

• Give the two passing dispositions terms — e.g. StatusAbsent (case 1) and StatusLive (case 3, bit 0) — as a closed set, in the same idiom §6.3.3.5 uses for statusPurpose.
• State that when a verifier records evidence that verification occurred, it MUST use these terms for the disposition, and for StatusLive MUST carry (a) the instant the status was established and (b) an identifier for the status list credential consulted.
• Emission stays OPTIONAL. APH does not gain an obligation to produce evidence; it gains the vocabulary for those who do. A verifier that emits nothing is unaffected and remains conformant.

Rejections need nothing new: APH_E008 and APH_E015 already name themselves, and your §11 rationale for one code covering all of case 2 applies unchanged.

What this deliberately does NOT ask for: the shape of the evidence record — its serialization, whether it is a credential, how it binds to the envelope, where it lives. We have not designed it, you have not designed it, and no gate exists to constrain it. That work waits, exactly as you said.

Alternatives rejected

• Defer the whole question until a gate exists (your stated position). Right for the record's shape; wrong for the names, because naming is the part that costs one subsection now and a vocabulary migration later, and because the divergence has already begun in a repository that ships no gate.
• Put the evidence in the envelope. Structurally impossible: the notary mints before verification, and evidence that a check occurred is produced by the verifier afterward. The notary would be attesting to a check it did not perform — the same conflation §2.6 exists to prevent, one layer over.
• Define the terms in RLPS. Backwards. A second protocol's documentation restating the first is the drift failure mode this whole exchange was about; r14n's rule is to cite APH, never to restate it.
• Cite "§6.3.3.4 case 1 / case 3" as the disposition. Workable for the two named cases, but it leaves the passing-with-clear-bit outcome unnamed, and specifies neither the instant nor the identity of the list consulted — the two facts that make the record re-evaluable.

Which surface

Normative spec text — picking the strictest that could apply, per the form. It adds a named closed set and MUST-level wording about recorded terms. It does not change the wire shape, the algorithm set, the state machines, or the error taxonomy.

Compatibility and migration

Not breaking. Purely additive:

• An envelope minted yesterday is unchanged — this touches no envelope field.
• A verifier that has not updated is unaffected: it emits no evidence today, and emission remains OPTIONAL, so it stays conformant.
• No published vector changes; no fixture's bytes move.

Version consequence: under the pre-production exception this lands in place in the 0.1 draft with a dated CHANGELOG.md revision entry and a spec revision banner — no version bump, since nothing outside can be stranded by it. If you would rather treat a new closed set as MINOR-worthy at 0.x, that also costs r14n nothing: we are a documentation-only consumer, and both paths cost us the same edit.

Security considerations

This is §2.6's argument one layer down. §2.6 forbids collapsing "Alice signed this" and "Alice's notary says Alice approved this" into one badge for a human. The same collapse happens in the audit record when "no liveness claim was offered" and "the notary's list said live at T" both serialize as verified. §2.6 protects the person reading a UI; this protects the person reading the record months later, who has strictly less context and no ability to re-run the check.

It also makes §6.3.3.3's freshness bound auditable after the fact. Today the bound is enforced at verification time and then forgotten; recording the instant is what lets a later reader confirm the check was fresh when it happened rather than take it on trust.

No §3 exclusion moves. This adds no fetch, no key material, no network surface, and no new failure mode — a verifier that emits nothing behaves exactly as it does today.

One residual worth naming: an evidence record is an assertion by the verifier about its own diligence, and a verifier that lies is not detected by this. That is §3.2-adjacent (a compromised participant vouching for itself) and out of scope here; the value is against honest verifiers whose records are read later, which is the ordinary audit case.

Scope check

• Checked Appendix B (Future Work): it defers status for artifacts other than the Delegation Mandate and a per-key proof purpose in the published DID Document. Neither is this — both concern what status covers and which key signs it, not how a verifier records that it checked.
• Checked CHANGELOG.md through the 2026-08-24 entries, including 5932f2a. No prior decision covers this.
• Understood: this lands as a PR with a dated CHANGELOG revision entry, and normative changes need two maintainer approvals.

---

Separately, since it does not deserve its own issue: yes to citing "a key whose strength varies invisibly by payload cannot be audited" in your security considerations — and no permission was needed. All prose in the r14n repository is CC-BY-4.0, so the only condition is attribution.