[dinakarjs]

Current closure refresh - 30 October 2026

Published head: e749901. Tested tree: 646a8970636003840171e2b10ec5b2ea5aa38192. Current-main history is merged without rewriting earlier contributors' commits; DCO trailers are present on this refresh commit.

Full reference suite: 5274 passed / 98 skipped; focused corpus: 227 passed; Ruff over src/tests/scripts, strict mypy (17 files) and dash checks pass. Added two real appraiser grant-boundary controls; changing each lower/upper comparison independently changes its expected verdict. Re-pinned the comparison to b938790, and TW-09/TW-10 explicitly identify existing configuration-removal semantics without choosing the future withdrawal protocol or final placement.

The published tree equals the locally tested tree. Whitespace checks on the contribution delta against current main pass (existing CRLF documentation is preserved). Returned current-head technical workflows now succeed, including CI, Conformance CI, Docs and Review bar. Independent maintainer acceptance and status/placement decisions remain pending; no merge, production deployment or hardware result is claimed. Earlier measurements below describe their original revisions. Prepared with OpenAI Codex.

---

What this changes

Related to #442. Adds an informative leaf-appraiser withdrawal review profile and ten planned acceptance pairs. No status protocol, result code, schema or verifier changes. Maintainers still decide leaf scope, status authority, freshness/rollback assumptions and component/composite outcome mapping.

Type of change

• Non-breaking spec change: informative addition only.

Spec section

No normative spec section changes. Compares experimental composite-component-appraisal RFC §§5–6 and its existing explicit grants.

Tests for a fix

The withdrawal protocol and the ten-pair acceptance matrix remain proposed. The existing appraiser-grant boundary half of TW-07 is executable in this revision: two controls test equality at valid_from and valid_until, and each comparison was independently mutation-checked. This does not execute the remaining withdrawal/status scenarios or select their policy.

Literature and limits

RFC 9334 §10 informs role/freshness separation. RFC 6960 §§2.2, 2.4, 4.2.2 informs authenticated status/time distinctions as prior art; this does not adopt OCSP, certificate chains or its good-status semantics. The document pins the existing RFC to base b938790 and records each reference's relevance and limitations.

Validation and fresh-reader review

Checked relative links, table structure, whitespace, absence of normative keywords and repository dash style on the changed documents. The initial prose review did not rerun the runtime suite; the 30 October refresh above records the later full reference-suite and boundary-control validation. A fresh agent reader identified that current kid is already a public-key digest and that a withdrawal observation must be distinguished from cache propagation. Corrected key/grant rotation language and explicitly bypassed caches in TW-01; TW-05 now requires retained authenticated withdrawal. This is not independent implementation validation or maintainer acceptance.

Checklist

• DCO-signed refresh commit retained.
• Normative changelog/change markers/backward compatibility: not applicable; no normative change.
• Acceptance matrix execution and maintainer design decisions remain open.

Prepared with Codex.

[github-actions]

🟡 Contributor Check: MEDIUM

Check	Result
Profile	MEDIUM
Credential	LOW
Overall	MEDIUM

Automated check by AgenTrust Contributor Check.

[dinakarjs]

Refreshed the existing proposal onto main da69b31, published head 4e65f82. Its tree e6a7f34eba34c1cfa294b173262781cfeca5851b equals the locally tested merged tree. Full root suite: 4,786 passed / 48 skipped. The workflow-style assembled docs build passes with strict mode enabled. The only net change against main remains the informative proposal page. Draft retained; all ten acceptance pairs remain planned and unexecuted, and no status service or normative profile is implemented. Maintainer scope decisions and final-head CI remain open. Prepared with OpenAI Codex; DCO sign-off included.

[dinakarjs]

Final-head hosted follow-up at 4e65f82: Docs, Conformance CI and CodeQL pass. Ordinary root tests pass, but CI's non-UTF-8 portability step reproduces the existing test_the_javascript_side_agrees UnicodeDecodeError. Separate passing repair #624 is awaiting independent review/integration. This page does not change that test or bypass its job; the proposal remains draft.

[lywinged]

Read at 4e65f82, against the composite RFC on main at b938790. Comment, not a verdict: the page binds nothing and asks for decisions, so this is what I can settle from the text that exists and what I would do with the rest.

• Leaf-only first slice: agreed. Delegated appraisers: chains and revocation before valid_until #442 itself puts "no, configure the leaf" forward as the simpler answer to chains, so that scope is the Project Lead's to confirm, not to design.
• The RFC does not define appraiser revocation (section 9), so the mapping is a decision, and I would take the smallest one the text allows: treat an authenticated withdrawal as the appraiser leaving the configuration. Section 5 step 4 then makes the component unverifiable, not a rejection, as it does for an entry that is absent or whose now is outside its validity interval, and section 6 recomputes the composite by the worst-status rule, missing above unverifiable. Delegated appraisers: chains and revocation before valid_until #442 proposes the token's status mechanism instead, whose two outcomes, status_not_active and status_unavailable, refuse the whole token. The two differ for an optional component and in the code reported; that is the decision for Delegated appraisers: chains and revocation before valid_until #442's assignee and the Project Lead who opened it, and TW-09 and TW-10 should name the rule they measure rather than wait for one.
• The boundary half of TW-07 is executable today. The reference holds the appraiser to valid_from <= now < valid_until (prototype/verifier_token.py line 450 at b938790); COMP-AUTH-012 puts valid_from one second after now, and no vector in examples/verifier-token-conformance/ evaluates an appraiser at either boundary. Two vectors, now equal to valid_from accepted and now equal to valid_until refused, would pin the comparison and need no status design.
• Baseline: the page pins the RFC at 53e347c. Since then docs: fold evidence resolution into composite RFC and test ER01 #577 added section 11.1 and a sentence to open question 4; sections 5 and 6 are byte for byte the same, so every reference here still holds. Worth re-pinning on the next refresh.
• Placement: on docs: fold evidence resolution into composite RFC and test ER01 #577 the Project Lead asked for the evidence-resolution answer to be folded into the RFC under section 11 rather than kept as a sibling page, and that is how it merged. A section 11.2 for question 5 would follow the same pattern, keep the plan next to the text it measures, and leave mkdocs.yml alone, whose nav names every RFC page and not this one.

Draft stays a draft until the status decision above is taken, which is not mine. Nothing here asks for a change before then.

[dinakarjs]

Closure request to @rajnisht7 / @imran-siddique on current head e749901: the existing grant-boundary half of TW-07 is now executable and each bound is independently caught by a mutation; the full reference suite passes. Please confirm the first withdrawal slice and final placement. TW-09/TW-10 explicitly measure existing configuration-removal/unverifiable recomposition, while #442's token-status proposal refuses the whole token; I have not silently chosen between those distinct policies. The remaining withdrawal/status acceptance pairs need that owner decision and a selected authority/freshness/rollback model before implementation. The draft does not introduce new wire fields or claim those pairs are executed. Prepared with OpenAI Codex.

[dinakarjs]

@rajnisht7 @imran-siddique — decision follow-through updated 1 November 2026 at e749901931eea730e641082c3c2554d48808b9c0.

Please record the choices needed to complete this draft:

1. Confirm the first slice is explicit configured leaf appraisers, with chains deferred.
2. Select whole-token status_not_active/status_unavailable refusal, or authenticated configuration-removal semantics with component unverifiable and existing composite recomputation. State required/optional component behavior.
3. Name the owner of key/grant identity, status authority, freshness/effective-time and anti-rollback assumptions.
4. Select informative placement in composite RFC section 11.2, or retain a separate page.

My recommendation remains leaf-only scope and placement beside the RFC it measures. Existing grant-boundary controls and the configuration-removal baseline do not select the future status protocol. All returned current-head technical workflows pass. I own the resulting bounded revision/tests once these choices are recorded; draft retained meanwhile. No normative protocol, completed withdrawal matrix, new local rerun or independent acceptance is claimed. Prepared with OpenAI Codex.