-
Notifications
You must be signed in to change notification settings - Fork 19
WG‐Meeting‐2025‐11‐11
Atul Tulshibagwale edited this page Nov 11, 2025
·
1 revision
- Interop events
- New features
- Terminology question
- Externally managed streams
- Atul Tulshibagwale (SGNL)
- Kenn Chong (RSA)
- Stefan Duernberger (Cisco)
- John Marchesini (Jamf)
- Sean Miller (RSA)
- Ashish Kedia (Google)
- Tushar Raibhandare (Google)
- Mike Kiser (Sailpoint)
- Thomas Darimont (OIDF)
- (Sean Miller) How do we know about future interop events
- (Atul) None planned right now, but I will record your interest and bring it to the OIDF. The possibilities I see are:
- RSAC
- IIW
- Identiverse
- We haven't spoken to anyone yet about this, but we can start looking if there is sufficient interest.
- (Atul) Please email me separately if you are interested in a future interoperability event.
- (Ashish) Interop is fine, but there are many companies who don't even know about all this. How can we make partners and IdPs aware of these standards, not by way of participation in the SSWG, but as implementers of the standards.
- (Atul) Talks and content as co-chair
- (Tushar) Should we start with GitHub issues?
- (Tushar) Should we start with writing PRs?
- (Atul) You should, because we don't expect the files to change.
- (Thomas) Do we have a specific term for events that are "SSF events", e.g. status updated or verification
- (Thomas) We discussed "foundational events", "core events", "basic events", or "admin events"
- (Atul) I like core events (Thomas agrees)
- (Vatsal) What is the concern with calling them "SSF events"?
- (Thomas) SSF events could mean any event, including those that are defined in CAEP, for example
- (Stefan) I like "SSF infrastructure events"
- (Thomas) We don't actually define the verification event in the spec, it appears only as a part of the verification section.
- (Thomas) It seems there is a section, but it could be easier to discover.
- (Thomas) When I use SSF, I can implement SSF receiver in a "full blown" style, where the receiver manages the full lifecycle, or I could have a separate component to manage the stream, and the receiver only has the functionality in the receiver.
- (Thomas) Do we support a lightweight receiver, which can support just the event receiving functionality, and have another component that manages the stream.
- (Atul) This sounds like an implementation detail that we shouldn't worry about it in the spec.
- (Thomas) Should such components that don't manage their own streams be allowed?
- (Atul) How do they pass conformance tests?
- (Thomas) They use a command line tool to do the stream setup and deletion, but the actual automated code only does the event receiving part.
- (Thomas) Receivers must support verification events in any case.
- (Ashish) Not sure I understand the concern. If you are managing the stream via curl, it's still stream management. I don't think the spec says it has to be programmatic.
- (Thomas) I just wanted to know if there's anything that the SSF spec allows - for example the transmitter might already create a stream. I don't have to do any stream management at all.
- (Atul) Is there a simpler way to implement a receiver than the spec allows today?
- (Thomas) That's kind of what I was getting at.
- (Ashish) Google is conducting a very big UX study on this - complexity of setting it up. The early feedback is that it is a bit hard for customers to understand what is happening behind the scenes. I don't have a proposal yet, but receiver creation seems to be more complex than necessary. One option we have considered is whether we can pre-create the streams.
- (Ashish) Once the study concludes, we can come back to this group with a concrete proposal. This might take a few weeks.