[Openid-specs-risc] openid/sharedsignals: New Issue opened

[github at oidf.org]

openid/sharedsignals event

Issue opened
Issue Title: Section 4.5: reference for "condition-bounded credentials", and a wording refinement
https://github.com/openid/sharedsignals/issues/345

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 is the language of the short-lifetime mechanism, and I think it misdescribes the third one. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20260727/a0e9cb22/attachment.htm>