[Openid-specs-risc] openid/sharedsignals: New Issue opened
github at oidf.org
github at oidf.org
Wed Oct 9 20:45:25 UTC 2024
openid/sharedsignals event
Issue opened
Issue Title: Verification request should return a 400 response if the stream is not enabled
https://github.com/openid/sharedsignals/issues/214
Context: Yair Sarig (Omnissa) Yesterday at 4:16 PM Hello everyone. I'm looking for opinions on what should be the behavior of requesting a verification event for a stream that is disabled. The transmitter can't send the event to the receiver (per section 7.1.2) so it can either silently ignore the request or return a 400 (error) response to the caller. I'm leaning toward the second option (as it is usually better to be explicit) but I want to see if others have other opinions. Rajvardhan Deshmukh (Cisco) Yesterday at 4:19 PM Good question. I would lean towards the 2nd option too. Don't know if this is addressed in any spec. Brian Soby (AppOmni) [Yesterday at 4:36 PM](https://ssfinteropdec24.slack.com/archives/C07JZBETJCE/p1728430568985539?thread_ts=1728429373.832649&cid=C07JZBETJCE) 400 seems correct to me Apoorva Deshpande Yesterday at 6:02 PM Should this be extended to paused streams as well, since in the paused case the expectation from the Tx is the same as disabled. The Transmitter MUST NOT transmit events over the stream Shayne Miel (Cisco) [Today at 7:59 AM](https://ssfinteropdec24.slack.com/archives/C07JZBETJCE/p1728485964722569?thread_ts=1728429373.832649&cid=C07JZBETJCE) This seems reasonable. Will you put up a PR to make it explicit in the SSF spec? Or at least an Issue so we can track it Swathi Kollavajjala (Cisco) [Today at 10:33 AM](https://ssfinteropdec24.slack.com/archives/C07JZBETJCE/p1728495200961049?thread_ts=1728429373.832649&cid=C07JZBETJCE) Agree with returning 400 for paused and disabled streams. Do we need to support this for interop? (edited) Ask: Add a clarification in section 7.1.4.2 that the response should be 400 if the stream status is disabled or pasued.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20241009/53846e98/attachment.html>
More information about the Openid-specs-risc
mailing list