Storage of events

Description

Comment by in Internal Workflow section:

And it also implies that Publisher should be able to store and promptly recover the original events (i.e. an event storage mechanism at source). This might be a big deal for producers of ephemeral events, as they might not necessarily want to keep hold of sensitive information. I'm thinking of some sort of ad-hoc transactions where at the moment of transaction, PII has to be transmitted (e.g. result of a credit check), but where the transaction origin is not allowed to keep hold of the information. In this case, a mechanism is required to safely store that PII within the event, perhaps without exposing it to anyone able to subscribe to the room. Maybe :)

Activity

Show:

Aleksander ReitsakasApril 17, 2023 at 9:40 AM

The case behind this scenario is like this:
Publisher publishes newBirth event. For the Publisher, this event has two attribute sets name and medical details. Since medical details set is restricted information that shall be available for medical institutions only, then the event itself is newBirth with the name part only. This data is available to all Subscribers. Now, for medical institutions, there is the possibility to request medical data directly from Publisher using event id. This request passes all needed usual authorization rules.
The assumption here is that medical data is not ephemeral and will be stored anyway.
My suggestion is that we do not cover ephemeral restricted attributes in the current version.
do you agree?

Aleksander ReitsakasApril 16, 2023 at 4:53 PM

Comment by : And published messages should have configurable finite life time in the room

Aleksander ReitsakasApril 16, 2023 at 4:52 PM

Comment by : I think IM should hold transaction log and not the payload.

Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Priority

Checklist

Created April 16, 2023 at 4:51 PM
Updated April 17, 2023 at 9:40 AM