SSF Events as Directives?

[dhs-BI]

In #60 we discussed how to issue directives from the identity services to the RP. On the March 25, 2025 call we discussed #60 and deteremined we do not have consensus on how to handle directives beyond the session time out at SL1.

One idea that comes to mind is whether an IPSIE profile can specify the the action that a receiver is required to take in response to an event received via SSF. In other words, can IPSIE profiles turn these events into directives when implementing an IPSIE level? In my mind, this would resolve the issue of having to create yet another mechanism for issuing directives by profiling an existing set of specifications.

I would love to hear thoughts from others working with SSF RISC and CAEP whether this is a reasonable idea or not. @openid/wg-sharedsignals-chairs

[tulshi]

IMO It's fine for other specifications / consortia (e.g. IPSIE) to require specific actions as a result of receiving specific events. For example, an IdP may require their SPs to sign an agreement that if they send a session revoked and the SP acknowledges it, the SP is required to have terminated the user's session before acknowledging the event. It should not in any way affect the standards here though.

[deansaxe]

Thank you, @tulshi.

There was a good chat on slack (https://oidf.slack.com/archives/C02Q0762E83/p1743199121972539) which I'll summarize:

@tulshi and @iamseanodentity think this is a reasonable idea. There has to be an agreed upon set of event for the receiver to take specific actions upon, but the action likely depends on the recipient. For example, if the recipient is an app, the event may be a directive with a specific outcome at SL3. However, if the event is to a SIEM, it is simply an event to be noted by the SIEM.

@tulshi, you mentioned "action receipts" in the slack thread. Do you have anything to share about them?

(edited to fix reference to @iamseanodentity)

[iamseanodentity]

That was actually me :) And they are still just something we are discussing and poking holes in. I’ll be adding my slack convo to the issue.

…

-Sean Sent from [Proton Mail](https://proton.me/mail/home) for iOS

On Sun, Mar 30, 2025 at 6:26 PM, Dean H. Saxe ***@***.***(mailto:On Sun, Mar 30, 2025 at 6:26 PM, Dean H. Saxe <<a href=)> wrote: Thank you, ***@***.***(https://github.com/tulshi). There was a good chat on slack (https://oidf.slack.com/archives/C02Q0762E83/p1743199121972539) which I'll summarize: ***@***.***(https://github.com/tulshi) and @fragslegs think this is a reasonable idea. There has to be an agreed upon set of event for the receiver to take specific actions upon, but the action likely depends on the recipient. For example, if the recipient is an app, the event may be a directive with a specific outcome at SL3. However, if the event is to a SIEM, it is simply an event to be noted by the SIEM. ***@***.***(https://github.com/tulshi), you mentioned "action receipts" in the slack thread. Do you have anything to share about them? — Reply to this email directly, [view it on GitHub](#66 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/BEUC2IQMI65MOGXPEPQGKL32XBVPRAVCNFSM6AAAAAB2AQKJHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRUG43TKMZXGA). You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***> [deansaxe] deansaxe left a comment [(openid/ipsie#66)](#66 (comment)) Thank you, ***@***.***(https://github.com/tulshi). There was a good chat on slack (https://oidf.slack.com/archives/C02Q0762E83/p1743199121972539) which I'll summarize: ***@***.***(https://github.com/tulshi) and @fragslegs think this is a reasonable idea. There has to be an agreed upon set of event for the receiver to take specific actions upon, but the action likely depends on the recipient. For example, if the recipient is an app, the event may be a directive with a specific outcome at SL3. However, if the event is to a SIEM, it is simply an event to be noted by the SIEM. ***@***.***(https://github.com/tulshi), you mentioned "action receipts" in the slack thread. Do you have anything to share about them? — Reply to this email directly, [view it on GitHub](#66 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/BEUC2IQMI65MOGXPEPQGKL32XBVPRAVCNFSM6AAAAAB2AQKJHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRUG43TKMZXGA). You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>

[FragLegs]

I don’t know if it has been mentioned already, but have you considered having the profile provide a way to make explicit what action should be taken? So perhaps it could send an SSF event that says, descriptively, what event was observed and also include an IPSIE action that tells the Receiver what it is supposed to do. @iamseanodentity mentioned the difference between sending to an RP vs a SIEM - that could be handled by having different actions in the messages. I’m picturing something like this

{
  "iss": "https://idp.example.com/",
  "jti": "756E69717565206964656E746966696572",
  "iat": 1520364019,
  "txn": 8675309,
  "aud": "636C69656E745F6964",
  "sub_id": {
    "format": "phone_number",
    "phone_number": "+1 206 555 0123"
  },
  "events": {
    "https://schemas.openid.net/secevent/risc/event-type/account-disabled": {
      "reason": "hijacking"
    }
  },
  "actions": {
    "https://schemas.openid.net/ipsie/event-type/password-reset": {}
  }
}

[ttripp]

According to https://datatracker.ietf.org/doc/html/rfc8417#section-2.2, the actions claim is not part of the Security Event Token spec. Additionally, RFC 8417 explicitly states, "Security events are not commands issued between parties. A SET describes statements of fact from the perspective of an issuer about a subject."

The RISC events don't seem to include any specific "actions" element either. https://openid.github.io/sharedsignals/openid-risc-profile-specification-1_0.txt

So, I think any contract of remediation action would have to be described external to SSF. Please let me know if I've missed something.

[dhs-BI]

According to https://datatracker.ietf.org/doc/html/rfc8417#section-2.2, the actions claim is not part of the Security Event Token spec. Additionally, RFC 8417 explicitly states, "Security events are not commands issued between parties. A SET describes statements of fact from the perspective of an issuer about a subject."

This is correct. However, we can prescribe responses to SETs as a profile in the same way RISC and CAEP profile SETs to add context to the events.

The RISC events don't seem to include any specific "actions" element either. https://openid.github.io/sharedsignals/openid-risc-profile-specification-1_0.txt

So, I think any contract of remediation action would have to be described external to SSF. Please let me know if I've missed something.

As I recall the discussion, actions have not been defined yet. In my mind, the path forward is to continue watching the developments in the SSF group. When we start writing profiles that include SSF, we'll look more deeply at how we can require a specific response to an event in IPSIE profiles. That may require deeper engagement with the SSF group in addition to IPSIE specific work.