Section 4.5: reference for "condition-bounded credentials", and a wording refinement

Section 4.5 is a useful addition, and I think the framing is right. Three mechanisms, complementary rather than competing, is the correct picture. The statement that a locally observable condition cannot see externally originated changes — issuer policy withdrawal, trust anchor rotation, cross-domain incident response — is accurate, and it is the reason an event channel is needed alongside it. No disagreement with the conclusion.

Two suggestions on the text.

1. Add a reference for the term.
   The term "condition-bounded credentials" appears without a definition or explanation. Readers unfamiliar with the concept may find it difficult to follow, as there is no introduction or reference to help them understand it. It is defined in draft-winmagic-wimse-condition-bounded-credentials in the IETF WIMSE working group, covering the same mechanism this section describes: a key whose availability is gated by locally evaluated conditions, so that a condition failing prevents the next operation rather than shortening a validity period. An informative reference would give the term a definition. (Disclosure: I am the author of that draft.)
2. "Remove the local deprovisioning window."
   This wording describes the short-lifetime mechanism, but I do not think it accurately describes the condition-liveness mechanism. A shorter lifetime reduces a window. Condition-liveness does not produce a window at all for the conditions the endpoint can evaluate: the key is not available for the next operation, so there is nothing to deprovision and no message to deliver. The distinction matters because it is what lets the mechanism work in disconnected and intermittently connected deployments, where issuer-side signalling cannot reach.
   Suggested replacement for the first clause:
   Condition-bounded credentials remove the local deprovisioning window for conditions the endpoint can evaluate itself, but cannot observe externally originated changes: ...
   One limit worth keeping explicit either way, and the section already gestures at it with "administrative decisions to terminate an established connection": an established connection runs until its next proof, so the effect is on the next operation, not on traffic already in flight. That is the same gap the short-lifetime model has, and the same fix.

Start by locating Section 4.5 in the repository's specification document and review its use of “condition-bounded credentials.” Add an informative reference to the named IETF WIMSE draft and apply the suggested wording refinement, while preserving the stated limitation about established connections. Done means the term is introduced with a reference and the distinction from short lifetimes is accurate.