WG Meeting: 2024-06-11

# WG Meeting: 2024-06-11 ## Agenda - Open items for SSF ID-3 candidate - Open items for interop spec - CAEP "session presented" event ## Attendees - Atul Tulshibagwale (SGNL) - Shayne Miel (Cisco) - Jay Leslie (Easy Dynamics) - Sean O'Dell (Disney) - Sean O'Neill (Easy Dynamics) - Stan Bounev (VeriClouds) - Steve Venema (**Microsoft**) - Apoorva Deshpande (Okta) - Alex Ilie (Veridium) - Jen Schreiber (Workday) ## Notes ### Open items for SSF ID-3 candidate - (Atul) Three cancdidate specs to possibly go out around June 15: - SSF - Interop-spec - CAEP - (Apoorva) Why is June 15 important? - (Atul) Working backwards from when we need a final spec (around Gartner IAM summit in Dec) - 3 Open PRs: - [#180](https://github.com/openid/sharedsignals/pull/180) - [#168](https://github.com/openid/sharedsignals/pull/168) ### Language for Txn Claim in SSF - (Shayne) This one is ready to go, just needs approval ### Default for subjects in a stream ([#168](https://github.com/openid/sharedsignals/pull/168)) - (Apoorva) Adding the field in the Transmitter Configuration Metadata pollutes it with stream-specific information - A transmitter may want different default behaviors for different streams - (Shayne) - (Atul) you can have a global level setting at the the trasmitter level and an override at the stream level...going forward - We can add it in later if we need to. (Shane echoed) - This could be expressed in the stream configuration response (for this stream this is my behavior) - (Sean) Would like to define the difference between a stream and a client from a mgmt level - (Shayne) We can move this field to the stream configuration instead of the Transmitter Configuration Metadata - (Apoorva) Why is this a priority for v3? SCIM doesn't spell this out - (Apoorva) SCIM is default all - (Shayne) That's how we started with this, because some want all and some want none - (Sean) This was also called out in the security review - (Shayne) How about doing both - in the TCM and in the stream config - That way we will know ahead of time (before stream creation), how the transmitter is going to behave - (Nancy) In either case, we need to be clear about the expected stream behavior, but I agree with Shayne that it can be in both places - (Apoorva) Why is it better? It could cause more confusion - (Nancy) It has clarification at both levels - (Apoorva) Adding it in both places is going to cause confusion - (Atul) We do not have a use case for overriding the default - (Steve) We just need t omake sure we don't break backward compatibility if we add it later - (Apoorva) Where would we put the status of the stream when it gets created - (Atul) I propose we keep it in the TCM - (Steve) If one stream has voluminous output and you don't want to get inundated, - (Apoorva) I've provided an example in the first comment (https://github.com/openid/sharedsignals/pull/168/files#r1612134035) - (Nancy) I see Apoorva's point, so you would need the flexibility for different streams - (Atul) Why have it both places? - (Shayne) A Transmitter may behave in a certain way for all streams, except where for particular streams it wants the other behavior - (Sean) Do you anticipate one audience per stream, or multiple audiences - (Apoorva) One audience per stream - (Sean) why? - (Apoorva) Our audience is tenant based - (Sean) Some people are viewing audience and stream both as first-class citizens - (Atul) The spec forbids having multiple audiences in the stream - (Sean) How many people would need different defaults per-stream? - (Apoorva) It also depends which partner you are implementing with - (Sean) I vote for putting it in both places - (Sean) I see use cases where a Transmitter could override for specific streams - (Apoorva) I'm not opposing adding it in the stream configuration - (Shayne) Should I rename the values? Instead of "all" or "none", we could clarify "receiver needs to add subjects" and "receiver doesn't need to add subjects" - (Shayne) Apoorva's original concern is that when Tx A creates streams with Rec B and Rec C, they want to send different user constituencies to Rec B and Rec C - (Apoorva) If we clarify what "all" or "none" means wrt a stream in the TCM, I am good with that - (Shayne) I can clarify that ### CAEP Session Presented event [#183](https://github.com/openid/sharedsignals/pull/183) - (Atul) Reason why I had "risk score" as a part of the "SEssion Presented" event is because generally, a risk score is computed as a part session presence - (Shayne) I don't associate risk scores with sessions - they are usually associated with devices or users. There are a lot of risk and security elements that we can add to a session, and it could be dissociated from the "Session Presented" event. We could have a session specific subject to a "risk score change" event - (Apoorva) I agree - (Sean) I wanted to propose something in SSF that indicates "confidence" in an event - (Apoorva) Should we also wait until the dictionary thing comes up before we introduce new events - (Atul) Since the "session established" event is already in, we should add the "session presented" event right now - (Apoorva) Should we defer other events until later? - (Atul) Yes, if we have a defined timeline for the new way of doing things - (Jen) We don't yet have a timeline for it - (Sean) In the "session presented" event, you have a lot of properties such as IP address, etc. So I would like to know the "risk score" as well. I get that it is subjective, but it is a good start. I like the "risk score" in the session presented event a lot - (Sean) All these claims are optional - (Shayne) But it might get in the way of doing things the right way - (Stan) What needs to happen if we say we need to add this event to the next version, how much work is that? - (Atul) Include it in the new draft that is sent for review - (Stan) It makes sense to have a session risk in general, but we need to think about how this fits with other types of risks. Think about session risk, device risk, credential risk, etc. How do they prioritize that? - ## Action Items - (Shayne) To update #168 to reflect audience scope language - (Atul) To separate the "Risk score" as a separate PR