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

[github at oidf.org]

openid/sharedsignals event

Issue opened
Issue Title: Preventing replay attacks in PUSH streams
https://github.com/openid/sharedsignals/issues/257

I may be misunderstanding some things so please correct me if required. **Background** While there's language that suggests Transmitter endpoints will be behind e.g. OAuth, today neither the [SSF spec](https://openid.net/specs/openid-sharedsignals-framework-1_0-ID3.html) nor the [CAEP Interoperability Profile](https://openid.net/specs/openid-caep-interoperability-profile-1_0-ID1.html) talk about auth for Receiver (PUSH) endpoints. Receiver endpoints are likely to be left open or use simple auth (e.g. API_KEY). Since receivers are open, even signed SETs can be misused. **The Attack** AttackedReceiver creates a PUSH stream at the Transmitter, interested in subject S. MaliciousReceiver creates another PUSH stream at the Transmitter, for the same subject S. Transmitter sends event E to MaliciousReceiver. MaliciousReceiver replays E to AttackedReceiver, which looks like it's coming from the Transmitter since it has all the right claims and is signed. E.g. MaliciousReceiver can disrupt a customer by constantly sending session revoked events to the AttackedReceiver. **Prevention** The main idea is to ensure that an event is meant for a specific stream. Options: - Add stream_id as a claim to the SET - Include stream_id in the iss claim somehow. - Use stricter auth / OAuth, per-stream and per-Transmitter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250513/39bd913f/attachment-0001.htm>