-
Notifications
You must be signed in to change notification settings - Fork 19
Meeting on 2025‐09‐23
Atul Tulshibagwale edited this page Sep 23, 2025
·
3 revisions
- Video Transcript is available here.
- New notes archive
- Co-chair nomination
- Interoperability spec next steps
- PoC for SSF Receiver CAEP Interop Testing
- 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)
- (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 ;)
- 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
- we should use labels going forward for interop issues
- (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-revokedandcredential-changeevents
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
- (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.