WG Meeting: 2025-09-23

# WG Meeting: 2025-09-23 ## Agenda - New notes archive - Co-chair nomination - Interoperability spec next steps - PoC for SSF Receiver CAEP Interop Testing ## Attendees - Atul Tulshibagwale (SGNL) - John Marchesini (Jamf) - Thomas Darimont (OIDF) - Mike Kiser (SailPoint) - Tushar Raibhandare (Google) - Sean O'Dell (Disney) - Jen Schreiber (Workday) - Vatsal Gupta (Apple) ## Notes ### Co-chair nomination - (Sean) As you hear - Shayne is pulled into different things, so he has stepped down as co-chair - (Sean) Would like to nominate the "Dolphin Man" Mike Kiser - (Atul) Any objections / feedback / comments? (none heard) - Mike Kiser is now the third co-chair of SSWG (insert Dolphin Sound here ;) ### Interoperability Spec - Apporva is a bit busy, so updates may be slightly delayed - Atul had hoped to finish updates by end of September ; End of October is a new goal for interop spec - There are a lot of issues available to work on if members have any spare time - One area is clearly identifying what the receiver requirements are (transmitter is already more defined) - Vatsal notes that he is available to help (has some spare cycles) - Atul will make introductions - (Mike L usually sends the slack invites) - Thomas created a few issues for the interop - posted 2 issues about interop - https://github.com/openid/sharedsignals/issues/294 - https://github.com/openid/sharedsignals/issues/291 - we should use labels going forward for interop issues ### PoC for SSF Receiver CAEP Interop Testing - (Thomas) I came up with a way to do this. Would like to demo. - (Thomas) (Starting demo) - (Thomas) Tests generate a Transmitter and expects certain things from a Receiver - (Thomas) Transmitters expect: - Create stream - Read stream config - Read stream status - Trigger a stream verification - Acknowledge stream verification - Receive `session-revoked` and `credential-change` events ``` openid-ssf-receiver-stream-caep-interop: This test verifies the receiver stream management according to the capabilities listed in the CAEP Interop Profile 1.0. The test generates a dynamic transmitter and waits for a receiver to register a stream. The testsuite expects to observe the following interactions: * creating a stream * reading the stream configuration * reading stream status * trigger a stream verification * acknowledge the stream verification. * retrieve and acknowledge the CAEP events 'session-revoked' and 'credential-change' ``` - (Thomas) Is this what you had in mind? - (Atul) This is exactly what I was expecting to see - (Thomas) What other kind of interop testing do you expect? - (Mike) This isn't in the interop spec, but we should also do some testing around device compliance, because the use-case is fairly common. - (Thomas) Is there a way to return something that proves that the receiver understood / could read the event properly? - (Atul) Just the presence of the right acknowlegement is likely enough - it implies that the receiver can use the event and understand it properly - at the beginning of the test, the receiver should choose what type of event it wants to receive - (Mike) the stream config should be set up correctly for the selected event type as well - (Thomas) Does the receiver need to be able to do stream update? - (Atul) for now, it will be out of scope because of the interoperability spec - (Thomas) Can they be "may" options? - (Atul) The interop spec has to be definitive, so let's avoid the use of "may" - (Thomas) should the standard events be reported as supported events or are they implied? - (Atul) all events should be listed in the configuration ... - (Thomas) verification events and update events aren't listed in the examples . . - (Atul) Didn't we have a discussion about that? I know that there were differing opinions as to whether or not they were supposed to be in the metadata / config ### Google's SSF announcement - (Sean) Are you supporting all the event types in the conformance tests? - (Thomas) effectively, yes - all the events listed in RISC / CAEP are supported, with generic metadata and updated timestamps - (Tushar) actively looking for partners for the closed beta with Google - (Thomas) Do we need to have Google Workspace? - (Tushar) You can have Google Cloud to participate in the beta - (Tushar) Right now we have implemented only a Shared Signals Receiver, so partners will need to be Transmitters - (Sean) So if you have instances of GCP in your company, then we can interop, right? - (Sean) The use case is that "I want to kick someone out of their GCP session", will that work? - (Tushar) That might not work - (Tushar) It is a little open ended. We have implemented session revoked. We can revoke 3rd party IdP sessions. - (Tushar) You can sign up here: https://workspaceupdates.googleblog.com/2025/09/enhancing-security-outcomes-shared-signals-framework-beta.html - (Tushar) Two kinds of user sessions are revoked: All Google sessions, and sessions mapped from the IdP session-id. - (Sean) Do you support "alias" subjects? - (Tushar) It can either be email, or session id. - (Sean) In large orgs, you might need an alias subjects - (George) Doesn't using aliases have privacy issues? - (Sean) Because it is necessarily about employees, the privacy concerns are not high - (George) I agree it makes sense in the enterprise case, but you need to be careful in consumer use cases. - (Sean) The complexity of your org may change the type of subjects you use, which results in the need for aliases for employees (e.g. employee id, M&A resulting in multiple types of employee id, etc.) - (George) GDPR laws may prevent different organizations from sharing alias data. ## Action Items