Action Receipts in Shared Signals

[iamseanodentity]

This is playing off of this Issue and subsequent PR: Issue 267

Context:
Prescriptive Security Event Tokens (SET's) are essential and SSF can support this. This is now about 2 things: being prescriptive to inform the receiver to perform said action indicated on the event (i.e. session revoke) AND it functions as a feedback loop, indicating success or failure (and why), post action being taken that emulates a real world scenario of a person going to a store with the purpose of purchasing something. The "action receipt" in this analogy is the receipt printed out or sent to your personal device.

How is this different from the ack? This is meant to be a prescriptive action, in the event, the transmitter sends to the reciever to say "now go to (i.e. go revoke sessions for said subject in the token)...it is not a suggestion, it is a must.

Proposed Implementation

• All events in both CAEP, RISC and SCIM are in scope for action receipt generation / return.
• There will be an optional endpoint the Transmitter would have for a receiver to send the action receipt to.

Security / Privacy
PII will be handled the same way it has been handled in other Profiles / Events.

Acceptance Criteria

• Shared Signals offers an event that can correlate an initial purpose, like a session revoked event, with an async event called an action receipt with traceable metadata and actioned metadata from the result.
• A SSF Receiver can send an action receipt to the optional endpoint in the SSF Transmitter.

Schema
This will be handled outside of the Issue here and in markdown. It will mimic an actual receipt from stores where goods are purchased, as an example.

[thomasdarimont]

I think it would help to add some more concrete usage examples here.

[jischr]

in terms of error scenarios, i'm assuming an action receipt could be returned as FAILED.
If so, are you expecting failures would be addressed in a machine readable way or automatically? could a receiver trigger resenting events based on this?

[vatsalgupta]

This is an interesting direction.

One thing that may need to be clarified is the distinction between delivery-level receipts and action-level receipts.

Acknowledging that an event was received, validated, and accepted for processing seems clearly in scope for SSF. However, acknowledging that an action (for example, session revocation) has been applied starts to depend on receiver-specific authorization and enforcement behavior.

Since SSF is primarily a delivery and stream management framework, it may be useful to explicitly separate:

1. transport / processing acknowledgments, and
2. any higher-level action outcomes that may be implementation-specific.

Without that distinction, there is a risk that “successful receipt” could be interpreted as “successful enforcement,” which may not always hold in practice.