Stream: fhircast-github
Topic: docs / Issue #51 Need to address Security/Privacy Audit
Github Notifications (FHIRcast) (Dec 11 2018 at 20:50):
JohnMoehrke opened Issue #51
as part of a security&privacy considerations section the specification should address security/privacy audit logging. A definitive specification would be nice, but this might be too hard. Thus some approaches could be discussed.
We discussed today two approaches:
a) The hub is responsible for recording all session create, and all session changes.
b) An authorized participant that is there simply to record session changes. This might be more modular, but might also be harder to manage from an OAuth authorizing app workflow.use of AuditEvent would be recommended... A pattern of how to fill out the AuditEvent when a context change is made would be good to define. (much like IHE does)
Github Notifications (FHIRcast) (Feb 05 2019 at 17:00):
isaacvetter commented on Issue #51
Hey @JohnMoehrke ,
I see the use of FHIRcast for audit logging as a potential, secondary use-case for the specification.
I don't think that it makes sense to explicitly call out this secondary usecase until/unless it has seen some experimentation, prototyping and validation.
Additionally, qudit logging notably differs from the primary usecase of context synchronization in the importance of old, failed event notifications. I don't know if this difference will prove critical or not.
(Related: PR #53).Since we've already published the related Security Considerations guidance in PR #60, I'm going to close this issue until there are more implementors looking to use FHIRcast for audit logging.
Respond/re-open if you disagree.
Isaac
Github Notifications (FHIRcast) (Feb 05 2019 at 17:00):
isaacvetter closed Issue #51
as part of a security&privacy considerations section the specification should address security/privacy audit logging. A definitive specification would be nice, but this might be too hard. Thus some approaches could be discussed.
We discussed today two approaches:
a) The hub is responsible for recording all session create, and all session changes.
b) An authorized participant that is there simply to record session changes. This might be more modular, but might also be harder to manage from an OAuth authorizing app workflow.use of AuditEvent would be recommended... A pattern of how to fill out the AuditEvent when a context change is made would be good to define. (much like IHE does)
Github Notifications (FHIRcast) (Feb 05 2019 at 17:00):
isaacvetter assigned Issue #51(assigned to isaacvetter)
as part of a security&privacy considerations section the specification should address security/privacy audit logging. A definitive specification would be nice, but this might be too hard. Thus some approaches could be discussed.
We discussed today two approaches:
a) The hub is responsible for recording all session create, and all session changes.
b) An authorized participant that is there simply to record session changes. This might be more modular, but might also be harder to manage from an OAuth authorizing app workflow.use of AuditEvent would be recommended... A pattern of how to fill out the AuditEvent when a context change is made would be good to define. (much like IHE does)
Last updated: Apr 12 2022 at 19:14 UTC
