As I discussed during community time it seems that there is a certain assumption of transience in this specification and the discussions occurring. In other words, that relevant concerns are resolved within the context of the connection over which the CloudEvent content is sent and not addressed by CloudEvents. Concrete examples include authentication as a property of an HTTP connection and event transmission fidelity validated by a TCP checksum.
This issue is opened to facilitate some discussion about the topic.
Certainly some of these concerns should not be solved by CloudEvents and It may be best not to solve for some others given that they comprise a good deal of complexity as well as an ever evolving set of best practices. That acknowledged, if a CloudEvent is to be written without alteration to a producer and consumer intermediary such as a Kafka or Kinesis the producer's connection context, without event augmentation, is not available to consumers that may have requirements necessitating that information.
A concrete example of this might involve a Kafka stream operated and archived by a banking organization that is used to record, analyze, and actuate inter-account transfers of capital. While it would be appropriate for me to place an authorization of capital transfer from my account to another, it would be inappropriate for another account holder to have placed the same event on the topic. Whereas I would be unlikely to directly place events onto such a log, a transfer authorizations service may well do so while a personal information storage service should not. As an example solution mechanism, a user-specific (and, perhaps, additionally a system-specific) private key signed hash of the CloudEvent could be validated using the associated public key(s) by consumers of the event that required some guarantee of the identity and authorization of the producer.
Obviously any such information could be added to the CloudEvent's data attribute or added as an extension. However, these needs are present across domains. Possible alternatives to addressing these concerns within CloudEvents include adding envelopes around persisted CloudEvents or custom solutions within appropriate attribute values of CloudEvents.
Potential questions:
If any, what contextual attributes from connections should be considered for inclusion?
What bases would be helpful in distinguishing between context attributes that should or should not be included?
What adverse outcomes would adding context attributes to the CloudEvents specification cause?
As I discussed during community time it seems that there is a certain assumption of transience in this specification and the discussions occurring. In other words, that relevant concerns are resolved within the context of the connection over which the CloudEvent content is sent and not addressed by CloudEvents. Concrete examples include authentication as a property of an HTTP connection and event transmission fidelity validated by a TCP checksum.
This issue is opened to facilitate some discussion about the topic.
Certainly some of these concerns should not be solved by CloudEvents and It may be best not to solve for some others given that they comprise a good deal of complexity as well as an ever evolving set of best practices. That acknowledged, if a CloudEvent is to be written without alteration to a producer and consumer intermediary such as a Kafka or Kinesis the producer's connection context, without event augmentation, is not available to consumers that may have requirements necessitating that information.
A concrete example of this might involve a Kafka stream operated and archived by a banking organization that is used to record, analyze, and actuate inter-account transfers of capital. While it would be appropriate for me to place an authorization of capital transfer from my account to another, it would be inappropriate for another account holder to have placed the same event on the topic. Whereas I would be unlikely to directly place events onto such a log, a transfer authorizations service may well do so while a personal information storage service should not. As an example solution mechanism, a user-specific (and, perhaps, additionally a system-specific) private key signed hash of the CloudEvent could be validated using the associated public key(s) by consumers of the event that required some guarantee of the identity and authorization of the producer.
Obviously any such information could be added to the CloudEvent's data attribute or added as an extension. However, these needs are present across domains. Possible alternatives to addressing these concerns within CloudEvents include adding envelopes around persisted CloudEvents or custom solutions within appropriate attribute values of CloudEvents.
Potential questions:
If any, what contextual attributes from connections should be considered for inclusion?
What bases would be helpful in distinguishing between context attributes that should or should not be included?
What adverse outcomes would adding context attributes to the CloudEvents specification cause?