<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
openid/sharedsignals event <br>
<br>
Issue Comment created on issue 255 <br>
Issue Title: SSF Events not just informational <br>
https://github.com/openid/sharedsignals/issues/255 <br>
<br>
Comment: Folks are referring to the statement in [Security Event Token (SET) RFC 8417](https://www.rfc-editor.org/rfc/rfc8417#section-1) 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 ](https://www.rfc-editor.org/rfc/rfc8417#section-3) 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 a command to me. 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.
</body>
</html>