Repository navigation
2026‐05‐05
Mike Kiser edited this page May 7, 2026
·
1 revision
When: Tuesday, 2026-05-05 — 10:00 Pacific / 13:00 Eastern (Meetings wiki)
-
Carry-over — Interop profile: status of Jen’s proposed email on dropping OPRM from the interop profile and requiring
ssf.read+ssf.manage- PR review — SSF / OAuth narrative: [#325 — Update OAuth Section (non-normative + ASCII)]
-
Carry-over — CAEP device signals: reconcile device compliance vs management semantics; review
unmanaged/current_statusapproach (GitHub #131, PR #329). - Conformance / interop testing (if time): SSF test suite rollout—vendor feedback toward finalization (per 2026-04-21 notes).
-
Any other business
- Shared signals profile for IPSIE SL2-
- Shared signals necessary for IPSIE SL3
- Mike Kiser (SailPoint)
- George Fletcher (Practial Identity LLC)
- Sahil Mukhija (CVS Health)
- Yair Sarig (Omnissa)
- Tushar Raibhandare (Google)
- Jen Schreiber (Crowdstrike)
- (Yair) - last meeting we decided to add unmanaged (but then you woudn't know what the previous value) - so we wanted to add unknown
- comment from martin that it is not symetrical, but that he saw value in marking it unknown
- (George) from a security perspective, if the status goes from "managed" to anything else, the enterprise would want to know. Quesion is there value in knowing that it was explicitly unamanged (maybe in a BYOD scenario?) I would hesitate to not send a signal...
- (Yair) - unknown is only in the previous status, not the current one... (because it is a required status / state) ... and the previous state may not be known accurately...
- George agreed with that....
- (Thomas) Does that mean that unknown is only allowed for previous status?
- (Yair) - yes, exactly. that's why they're not symetrical. it would have been better, perhaps, to make the previous status optional, but this works with the current approach.
- Editors to review this week...
-
Jen - was going to remove OPRM ref, asked for clarity from the group at large, will update this later on this week
-
**Conformance / interop testing
-
(Thomas) no additional feedback yet. Atul ran it with Caep.dev.
-
(Yair) ran the test without any problem
-
(Mike) I'll gtry to get my side to test this week as well.
- (George) Two things that came up today ... George was the assigned SSF correspondent.
- They're trying to finalize SL2; a profile of SSF that is covering the two cases that have been added between the IDP and the relying party (IDP can send two events: "resestablish session" sanity check - send the user to the IDP to reconnect / resuse ("session assurance"), event b: KILL ALL THE THINGS - and all subsequent refresh tokens, etc.) (is this session_revoked?)
- Action receipts might be in play here -that confirms that the actions were taken... (like nuking a user from orbit, basically)... do we need a brand new event, or will one of the others work?
- "Need a profile for SSF for SL2 in IPSIE"
- (Yair) - we don't specify what happens (receiver decides normally). What is the message is the real question... Receiver interprets it how it wants to ...
- (Mike) feels like account disabled....
- (George) but it's not that either . . . the message from the transmitter to the receiver is more of a command than a status... (hence action receipts)
- if I had an MDM device that reports that it's jailbroken, I want to force a new flow; but it's still an enabled flow ...
- (Yair) most receivers do a full logout. (kill refresh tokens, etc.) But it's not demanded by the spec / event per se...
- (George) - in an enterprise environment, then the event needs to be proscriptive...
- (Yair) a profile is a good option here.
- (Mike) - Sean and I will take a stab at this...
- Sahil and Yair will also help as they have time....
- (George) SL3 ... supposed to be a higher security profile. Questions:
- (1) what should the relying party be required to do? (processing of signals for session assurance)
- what does it need to send from a signal perspective?
- is it as simple as "user did this"
- or is it a caep-related event?
- Are there more nuanced signals that deal with sessions that the IDP should be sending the RP if it's SL3
- (Basically, SL3 implies the equivalent of debug mode, but for events - increased and more detailed communication between the IDP and the RP)
- (1) what should the relying party be required to do? (processing of signals for session assurance)
- (George) one potential requirement is the PR to send activity signals to the IDP and then when the IDP determines that something needs to happen, it would send one of the events from SL2 (reestablish or nuke the session)
- (SL3 therefore potentially builds on SL2) ... assurance levels switch between SL2 and SL3, so what does that mean is under discussion ... (show up and be present at IPSIE meetings for the discussion of SSF-related topics) "Are there other things that the IDP could send to the RP that could be useful for a high risk user / env?" (this doesn't demand SSF, but SSF could be used / have input into the discussion)
- SL2 is a created doc at the moment, not sure if SL3 has much content
- (Thomas) brief note that he asked the group to provide feedback on the current state of tests (we need at least 3 positive reviews to publish... ) . We now how receiver tests as well - some have tried the transmitter tests, but the receiver tests need examination as well - please try them as well.
- (Yair) is there any particular profile that needs another? if the transmitter is ready first, can we release that?
- (Thomas) yes, but would prefer to do both at the same time...so far has tried caep.dev and keycloak.
- (Thomas) - been working on adding SSF to keycloak. Reached the milestone that it's ready for primetime... is anyone interested in seeing the demo that fulfills everything (like subject management)
- Jen to update the PR , and then review will happen
- Yair's PR (device) should be fine, will enter review this week
- Kiser to have SailPoint take a look at the current conformance tests
- Kiser, Sahil, Yair, Sean to work on a profile for SL2 / IPSIE (action receipt related as well)
- IPSIE would benefit from input in discussions around SL2 and SL3 interactions with SSF
- Thomas to eventually do a demo of keycloak and full SSF functionality if people are interested....