SSF Events not just informational

[gffletch]

Whenever I bring up the use of SSF for managing session state or changes to deployed systems, I quite often get a response that SSF Events are "just informational". In my conversations with a number of people this isn't strictly true. Instead, the SSF specifications are silent on the behavioral rules in play for any given deployment when an event is received.

I'm wondering if makes sense to clearly call this out in the specification as a non-normative information statement. Something like...

The Shared Signals Framework does not define explicit processing behavior for receipt of events specifically to allow for each deployment to define the behaviors that make sense for that environment. These behaviors can range from treating the event as informational input to additional processing, to mandatory enforcement of the specified state change (e.g. session revoke).

[mcguinness]

Folks are referring to the statement in Security Event Token (SET) RFC 8417 that states

Security events are not commands issued between parties. A SET
describes statements of fact from the perspective of an issuer about
a subject (e.g., a web resource, token, IP address, the issuer
itself). These statements of fact represent a logical event that
occurred directly to or about a security subject, for example, a
statement about the issuance or revocation of a token on behalf of a
subject.

Requirements for SET Profiles also just provides how to process the token, not what actions should be taken.

Profiling specifications of this specification define actual SETs to
be used in particular use cases. These profiling specifications
define the syntax and semantics of SETs conforming to that SET
profile and rules for validating those SETs. Profiling
specifications SHOULD define syntax, semantics, subject
identification, and validation.

Describing required behaviors when processing events in a profile can be interpreted a command depending on how its described.

It's currently fair game to require transmitters to send specific events and receivers to accept specific events but currently ambiguous as to whether a transmitter can require specific behaviors when receiving an event as events are just "statements of fact from the perspective of an issuer about a subject".

We would need language that doesn't turn the event into a command to allow this. The phrase "mandatory enforcement of the specified state change" sounds like it could be a command to me (its nuanced). There are often several failure conditions when "enforcing the state change" that may need resolved in a workflow that would need to sent back to transmitter. These are not SET delivery/receipt errors as the processing of the "behavior" is not the same as confirming receipt and validating the SET.

Curious to see what the working group can propose here that can resolve this ambiguity and enable the use cases you are after.

[timcappalli]

It definitely isn't in the spec, but we had been talking about that being a business decision/agreement based on the relationship between a transmitter and receiver.

That could also be in a consortium-like relationship (e.g. in this network, if you get session revoked, you're expected to send the user back to the IdP).

But this was always just verbal/positioning and nothing normative outside of what Karl highlighted from SET.

[tulshi]

In the last paragraph in Section 1 of RFC8417 "SETs cannot be assumed to be commands or requests", I would have added the word "automatically". That's how I interpret it. In section 3, I assume the word "Semantics" to include the kind of command semantics we are talking about here, even though the example provided is about the format.

In conclusion, in Section 1, or Section 3 (or anywhere else in RFC8417), I don't see language that prohibits the use of SETs as commands, so although they are defined to be informational, using them for commands is not ruled out.

[mcguinness]

Command is flipping "may interpret for their own purposes" in the last paragraph in Section 1 of RFC8417 to "MUST interpret as X". SETs are defined as informational as to not prescribe how the consumer MUST interpret the event. This decoupling was why they were modeled as events. Its just an observable.

[xmlgrrl]

FWIW, in authorization policy (ref. XACML!), informational info would be labeled "advice", contrasting with "obligations".

[dhs-BI]

See this thread from the IPSIE WG as well.

My interest is in using profiles to define how the recipient of an event takes action on that event. In other words, we can further constrain the existing profiles and assign an action to event receipt if, and only if, both parties are agreeing to be bound by the requirements of the profile.

IPSIE will tackle this issue sometime down the road, most likely no earlier than 2026 given the work that remains to be completed between now and our proposed interop event in December 2025.

[tulshi]

closed by PR: #267