WG Meeting: 2024-12-03

# WG Meeting: 2024-12-03 ## Agenda - [Risk level change event](https://github.com/openid/sharedsignals/pull/205) - [Permanence of streams](https://github.com/openid/sharedsignals/issues/211) - Combine CAEP and CAEP Interop Profile specs? - Issues marked/labeed for v1Final ## Attendees - Atul Tulshibagwale (SGNL) - Sean O'Dell (Disney) - Yair Sarig (Omnissa) - Apoorva Deshpande (Okta) - Stan Bounev (VeriClouds) - Shayne Miel (Cisco) - Erik Gomez (JGSW) - Thomas Darimont (OIDF) - Brian Soby (AppOmni) - Tushar Raibhandare (Google) - Martin Gallo (Individual) - Jen Schreiber (Workday) ## Notes ### [Risk Level Change](https://github.com/openid/sharedsignals/pull/205) - (Stan) Does this event represent something different? - (Atul) I agree it is a separate event - (Shayne) I agree - (Yair) I agree - (Sean) Thumbs up - (Stan) Does anyone have a concern that the levels won't mean the same and won't incorporate the same contributing factors in producing the same event - (Apoorva) This could be the same issue in device compliance change, assurance level change, etc. This is not different. - (Stan) I agree it isn't new, but if the precedent isn't the right one, then should we continue this? - (Sean) In the absence of knowing what we don't know, not doing this doesn't make sense - (Sean) We might get this wrong a few times, but we can improve it - (Stan) But at a higher level, if there is a "capture-all" event, then it is difficult for that capture-all event to be consistent across the vendors - (Yair) If different vendors provide different reasons, then... - (Stan) For example, we provide threat intelligence, and this conversation always comes up, and customers are not sure what the "high", "medium", "low" means. - (Stan) This makes it difficult to adopt the specs - (Stan) If we provide some way for customers to get alignment, then the adoption improves - (Atul) Can we put some wording into what the "high", "medium" or "low" means. - (Apoorva) This is an event that is complementary to "assurance level" or "device compliance" change - (Stan) I don't believe it is complementary. If someone sends this event, they don't need to send any device compliance / assurance level change events - (Yair) We are not here to decide what is the "high", "medium" or "low" risk means. - (Atul) CAEP should allow more specialized and more general events, receivers can request the specific events they are capable / interested in. - (Atul) We should have definite meanings in terms of what "high", "medium" and "low" mean in terms of session security as asserted by the transmitter - (Stan) Transmitters should send more specific events, rather than sending a high level "risk change" event - (Atul) I don't feel we should prevent one way or the other - (Adam) Mastercard would like to inject fraud signals based on insights from ATO detection / Payment fraud events - (Shayne) Why is the risk reason required? - (Apoorva) Its to indicate to the receiver the rationale of the Transmitter in sending the event. It could become an enum specific to the Tx and Rx. So the localization may not be required. - (Shayne) Why is it required? - (Apoorva) Without the reason, it won't make sense to the receiver - (Yair) Most of the time, the risk level change is sufficient, the reason may not always be needed - (Atul) I agree it should not be required - (Apoorva) I can step it down to "recommended" - (Atul) Sounds good - (Shayne) SG - (Shayne) The examples need updating ### Performance of Streams - (Tushar) When a Transmitter has created a stream and the receiver doesn't receive anything for a long duration. There is nothing required in the spec that the Transmitter or Receiver can use to determine when to expire the stream - (Tushar) This is captured in [PR #222](https://github.com/openid/sharedsignals/pull/222) - (Atul) Were there other aspects to it? - (Tushar) For a "poll" stream, if the Tx generates a large number of events, and the Receiver never polls, then the Tx has to hold a lot of data for the Rx - (Tushar) So there should be another way to indicate how many events / how much data the Tx has to hold - (Yair) This is the same issue with polling - (Shayne) This could be specified in the stream configuration - (Apoorva) I support the way Shayne suggested: Stream configuration rather than metadata configuration. Some streams may be more frequent than others - (Tushar) The TTL is independent of the optimization - (Brian) This is something I would want a negotiation - the requester could request something and the Transmitter can determine its own - (Stan) We need to also provide a way for the Tx to know that the Rx has expired the stream (and vice versa) - (Tushar) The spec already has a "stream updated" event, which can be used - (Brian) The receiver invalidating the stream is interesting. The status codes can be used, but some way to indicate the expiration from the receiver is interesting. - (Shayne) The Tx can pause or disable the stream by sending a "stream updated" event. - (Brian) But the Tx doesn't indicate why it is doing it - (Jen) The Tx doesn't need to justify - (Sean) It's how much you want to hold for a specific receiver. - (Yair) This is about a stream that is dead. The Tx may be sending events to someone who doesn't care about it. - (Sean) I don't think you can automate stream deletion? If you use a status code, you can draw wrong conclusions. You need to have metadata about the receiver. There are too many variables - (Apoorva) The original PR / issue was proposed to handle the authorization problem (Rx loses the token, but the streams are active), so if we are talking about this use case, then it's different. - (Tushar) The TTL gives time for the Rx to fix the temporary issues. But if the Rx cannot recover in the TTL period, then the Tx can expire the stream. - (Sean) If you are offering a streaming service, how do you reconcile a lapse(?) An ack doesn't mean that the Rx has processed it. - (Thomas) Does this mean that receivers have to periodically request a verification event to make sure that the transmitter can still send a push? - (Atul) Is the TTL inactivity or absolute? - (Tushar) Inactivity - (Tushar) For the amount of data, does it need to be configured per stream? Can the Tx make a blanket statement across receivers? - (Atul) It needs to be per stream - (Tushar) But if the volume of events far exceeds the limit, then anyway they can't do anything about it. So is it even worth having it in the spec - (Sean) Verifying a stream is a good way to keep a stream active. But an "ack" is also sufficient - (Atul) I was saying in the context of inactivity - (Brian) Are we talking about "poll" or "push" too? - (Tushar) The way the PR is written, - (Yair) The original discussion was about what happens if the stream live or not. Regardless of push or poll. - (Yair) That's why the Receiver needs to do something in order to indicate that it is using the stream. - (Yair) polling is different, because the Receiver is actually reaching out to you. But the push doesn't require the Rx to do anything. - (Yair) About the data, it's not just about polling. There needs to be a limit either way. There needs to be a way for the Tx or Rx to negotiate a limit. The way the spec says it, the Tx has some obligation to keep messages for a very long time - (Apoorva) Might be a digress, but if the short lived stream is an objective, then can we just have an absolute expiry. - (Yair) It's not about short-lived. It's about whether the Receiver still interested. - (Apoorva) It's not about whether the Rx is interested, but whether they still have the token. If they had the token the Rx can delete the stream. - (Atul) It could be other reasons, like the Rx has gone down - (Tushar) We could think of it as: Tx doesn't need to depend on a well-behaved Rx. ## Action Items - (All) Please review [PR #222](https://github.com/openid/sharedsignals/pull/222)