<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body>

openid/sharedsignals event <br>

<br>

Issue opened <br>

Issue Title: Preventing replay attacks in PUSH streams <br>

https://github.com/openid/sharedsignals/issues/257 <br>

<br>

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.

</body>

</html>