Add data-classification.md extension

[rob-sessink]

Provides an extension where an event source can annotate an event with
information around data classification of an event and its payload. CloudEvents
may contain payload which is subjected to data protection regulations like GDPR
or HIPAA. For intermediaries and consumers knowing how event payload is
classified enables compliant processing of an event.

Adds an extension with attributes:

• dataclassification (Required). Data classification level of an event and
  payload within the context of a data protection regulation.
• dataregulation (Optional). Applicable data protection regulation.
• datacategory (Optional). Data category of the event payload within the
  context of data classification and data protection regulation.

[duglin]

Can you elaborate on what this "SHOULD" means? What does someone need to do (from a coding perspective) to adhere to this "SHOULD"?

[rob-sessink]

The SHOULD statement is merely meant as an indication towards event producers that the data classification label should have its origin within the applicable data-regulation. But maybe this is stating the obvious and from a coding perspective not relevant. Being already stated in the description, it does not add value. I will remove it

[duglin]

I wonder if this "SHOULD" should be a "MUST" instead? Should a consumer reject a request if it can't meet the data regulation requirements? Are clients expecting some kind of guarantee? Meaning, a non-error means "yup, got it and it'll be protected appropriately". Although, extensions can be ignored... maybe it would need to be worded like: "If an implementation supports this extension, then it MUST reject the event if it can not adhere to the requirements of the specified data classification attributes" ??

[jskeet]

This raises an interesting possibility, which is too late for v1 but could be interesting in a future version: if an event could say "consumers/intermediaries must understand extensions x, y and z, and must otherwise reject/ignore the event" then we could be stricter. (So that would be an attribute that's part of the main spec, but the values of which would be names of extension attributes.)

[duglin]

https://www.w3.org/TR/soap12/#soapmu :-)

[rob-sessink]

Yes changing this section to be more prescriptive towards consumers is warranted. When an implementation supports this extension, an event MUST be handled in a compliant manner or otherwise MUST be rejected/ignored.

I will adjust the phrasing.

[duglin]

Can you update the README in the "extensions" dir too?

[duglin]

I suspect these values are probably defined by the data regulations being adhered to, but since dataregulation is optional, should this spec define some recommended values for cases where it's missing to provide some consistency?

[rob-sessink]

Yes I feel that is a good approach. I did not want to make the dataregulation attribute required as I feel this is supportive information and not directly mandatory for processing. My intent is that usage of this extension should be as light as possible, meaning less required attributes as possible.

What do you think of:

Description: Data classification level for the event payload within the context of a dataregulation. In a situation where dataregulation is undefined, recommended labels are: public, internal, confidential, or restricted.

[jskeet]

Is a redacting intermediary a valid use case? (I'm guessing not - that they'd end up effectively being a new event producer, as it's no longer the same event really if a bunch of information has been removed. But I thought I'd mention it as a possibility.)

[rob-sessink]

I agree that when an intermediary changes an event or payload it becomes a new event. Than also the role of the intermediary shifts to that of event producer and it has responsibility/freedom to define the classification attributes.

Reading the CloudEvents specification, intermediaries forward/route messages and don´t redact them, so I would want to leave it this way.

[jskeet]

This raises an interesting possibility, which is too late for v1 but could be interesting in a future version: if an event could say "consumers/intermediaries must understand extensions x, y and z, and must otherwise reject/ignore the event" then we could be stricter. (So that would be an attribute that's part of the main spec, but the values of which would be names of extension attributes.)