From Static Sessions to Continuous Trust: Implementing SSF and CAEP for Zero Trust Identity [Intermediate]

Thank you very much. Okay, hi everyone. I'm Sachin. I'm one of the DIF awardees in last year and I spent years building IAM system at my previous company WS2. I want to talk about problem I lived with from inside those systems and what finally changed in 2026.

So, mainly seven topics. We just have only have 20 minutes, so quick sets up. If you worked with like earlier CAEP drafts, like three new event types appeared in the final spec that most implementation doesn't handle it. That's probably the most useful thing today. Traditional IAM validates trust once at login, then walks away. Your SAML assertions and OIDC tokens freeze at issuance. Whatever the world looks like then, that's what the token says. Users get compromised mid-session. Token is still valid. Role gets changed. Token doesn't even know.

But now, back-channel logout exits. With RLC 7009, revocation exits. Scheme exits. The problem isn't a missing standard, but the problem is like it's none of these are considered valid. These are consistently wired across all your federated apps. That's the main gap we are facing now.

So, that's exactly what SSF and CAEP solve. So, SSF, which is a shared signal framework, it has main three roles. Transmitter, publisher, security event tokens. Then receiver consumes them and decides what to do. Any system can play either role or both simultaneously. The set is a JWT. A few things is the package of event payload. A few things worth knowing. Subject ID must be a top-level thing. The JWT subject claim must be not present. And then JTA supports the replay detections. Receiver has to implement the tracking of that. And then no exception claims. No expiry claims.

This isn't a bare token. It's an event statement. And then mainly we have eight event types. Fiverr in earlier drafts. These are like brand new in 1.0 final. The original file where the session revoked, token change, credential change, as you see, and then the assurance level change, device compliance change, all those things.

So, if you are built against an earlier draft, these are like familiar. But the couple of nonsense, the session revoked doesn't mandate the termination.

So, what happens is receiver acts per its own policy. Then in assurance level change, users are namespace feed. Supports like NIST, double L, and RFC 8176 kind of things. The three new ones are session established. And it notifies receiver new session startup. And session presented. Transmitter observes the session is still active. And then risk level change. Abstract risk level, not a score. It's like a low, medium, or high. The subject is called the principal. Can be user or device or session tenant or guinito or group or whatever it is. Then the claims come from three different places.

So, RFC 8417 for the base JW claims. And RFC 9493 supports for the subject ID. And the K profile for event specific claims. But it is mandated to remember these three things.

AUD, the audience is in the JSON. Receivers must validate they are the intended audience. And TXN in SSF specifically. Not a standard JWT registered claim. Then last one is the event timestamp. Is what the event, when the event has happened.

So, like IAT is when the set was issued. These can be very different. CAPE and RISC are like open ID final specs built on SSF. And SCIM event is different. It's an IET draft. Not an open ID final profile.

So, I'm showing like it for context. Not as an equal. CAPE is access layer. Not just like a session, credential, assurance, and risk level as well. RISC is account and security risk events. It supports eight event types.

IRS, login, governments, and IDME are show IRS RISC use cases in like in previous last year authenticate 2025 interrupt report as well. And when it comes to SCIM events, identity governance signaling using sets. The one we have discussed earlier. The set spell. IGA vendors exploring this not finalized. And SSF is transmitted to receiver one direction. It's kind of not peer-to-peer.

So, in last year authenticate 2025, which was there in Carlsbad, California. So, eight production ready implementations achieved cross vendor interoperability on final spec. That's the official number from OIDF announcement. The eight like signal two implementations, CAPE hub and CAPE dip. And Google, IBM, Verify Antenna, then JMF, Octa-ITP, Omnisa, SailPoint, all those things are involved. Google was the receiver. Apple participated in demo flow we'll see next, but not in the formal participation table.

These are the two flows that were demonstrated by Atul, the CTO of Signal, and Kocha of OIDV shared signal working group at authenticate 2025 last year. So, it's not a formal certification results.

So, first flow is that admin suspend a user in Octa. Octa builds a session reworked set. The payload pushes it to the registered streams. Apple business manager receives it, validates the signature, terminates the affected MDM sessions.

And then, if we go to flow two, the CrowdStrike Falcon detects malware and sends an alert to Signal. JMF sends a device compliance change event to Signal. And Signal emits session reworked downstream. Google Cloud terminates sessions. SailPoint reduces the access role and deprovision from JIRA.

So, one honest flag I need to mention here, using session rework to like drive SailPoint deprovision is like a semantic shortcut. Session rework is a session layer. Deprovisioning should be driven by the risk account. Disabled event like, oh, like a scheme operation. The demo showed the, like, plumbing working. The semantics were simplified.

So, these like, the building identity system at my previous company, WSO2, and the, as the audio product which we had, the main patterns I have identified is hub and fan works well for multi-vendor environments. And the direct transmitter to receiver is simpler, but trust bootstrapping is like not a trivial thing.

In demo, it's pre-configured. In production, it's a product. It's a project, actually.

Queue, you can queue your receiver endpoint. A policy change will be affecting many accounts produces a search, actually.

Test with, you can use the test, the cape.dev before going to the production, which was given from the SSF itself. And main challenges I want to mention here, like a subject identifier resolution. The same person is an email in your IDP and OPEC ID in your IGA system. And name ID in your legacy MLSP. You need to pre, like, agreed RFC 9493, subject identifier format across all parties before you spend the first asset. If you don't design, like, this upfront, you will spend months to identify a mapping that should never have existed.

Also, the cape doesn't tell your receiver what to do. Like, someone in your organization has to own that enforcement policy, usually not the engineers, but the lead level or the upper bound. What's the next steps? The three specs are final. SSF cape risk. It's published in August 29, approved in September 2025.

So, transmitter site, conformance tests are available on OpenID net. Full cell certification scope for SSF isn't confirmed yet. In February 2026, OID certification launch was for verifiable credential specs, not SSF. But cape interoperability profile is a working group draft. It's not confirmed yet, but there's no release date yet confirmed. The FIDO Alliance published a white paper in October 2025 on FIDO, the authentication plus SSF for continuous post authentication signals.

So, it's worth reading also. So, five main things I need you to have a look at.

So, SSF cape risk are final. Build on them now. Three new cape event types in the 1.0 draft.

So, session established, session presenter, risk level change. Check your implementations, get them done. Cape is a non-prescriptive by design, like transmitter signal, receiver designs. That's the intent. That's intentional.

So, eight production-ready implementation interrupted at authenticate 2025. Like, it's a cross-vendor boundary work. And without a consistent signaling layer, post-login enforcements depends on proprietary point solutions per vendor pair.

So, SSF and cape solves that. That's about it. Happy to take any questions you have. Thank you. First of all, I announced multiple times the QR code for asking questions. Maybe we can share it for a couple of seconds that you're able to scan it. Then I receive questions on the tablet.

So, here we go. Pick your iPhone, your Android, or whatever. Take a picture, and then you're able to ask questions that I receive here on my tablet. Or maybe open question in the room. Any questions? This time we have four minutes left. The ultimate chance to ask questions to this guy remotely. We can switch back. No questions. Okay.

Then, Stachin, thank you very much for joining us and talk to you soon. Thank you. Thank you very much. Thanks for having me.