search

openid / sharedsignals

OpenID Shared Signals Working Group Repository
45 stars 11 forks source link

Explicit event retention policy in event stream metadata #107

Open ysarig1 opened 10 months ago

ysarig1 commented 10 months ago

Related to: https://github.com/openid/sharedsignals/issues/106. The SSF spec include two cases where events may be queued in an event stream:

  1. When an event stream is paused (see section 7.1.2)
  2. When a poll delivery method is used (see section 7.1.1)

In both cases, there is a possibility of many events queueing by the transmitter to the point that it is not practical for the transmitter to retain. We should consider adding an explicit limit to the number of events (or time?) that can be retained by the transmitter to event stream metadata.

tulshi commented 9 months ago

Does the new language in section 7.1.2 address this issue?

independentid commented 9 months ago

The Transmitter MUST NOT transmit events over the stream. The transmitter will hold any events it would have transmitted while paused, and SHOULD transmit them when the stream’s status becomes "enabled". If a Transmitter holds successive events that affect the same Subject Principal, then the Transmitter MUST make sure that those events are transmitted in the order of time that they were generated OR the Transmitter MUST send only the last events that do not require the previous events affecting the same Subject Principal to be processed by the Receiver, because the previous events are either cancelled by the later events or the previous events are outdated.

This language seems problematic for many transmitters. It would require that events be transformed cumulatively. Then the question would be how often and when. A transmitter that is detached from a generator would likely have no such ability.

Regarding "retention policy" I don't think the matter has been addressed. At minimum, there should be some considerations that spell out that it may be impossible for a transmitter to "retain" events indefinitely. The pause state should be temporary (hours) not days or more.

ysarig1 commented 9 months ago

@tulshi I don't see any recent relevant update in 7.1.2 that addresses the event retention issue (as @independentid pointed out). This is something that need to be addressed before 1_0-ID2. Also note that the same issue exists when doing polling (i.e., there is no guarantee that the receiver will actually do the polling which mean the transmitter will just accumulate events that need to be polled).

tulshi commented 9 months ago

Ok. I see the problem. The status values are repeated in 7.1.2.1, whereas they were cleaned up in 7.1.2. I will remove the ambiguity and problematice language from 7.1.2.1, since they are already specified in 7.1.2

tulshi commented 2 months ago

@ysarig1 is this issue closed in the latest spec? If so, could you please close this? Thanks