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]

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]

s/payload/payloads/ & s/is/are/
or
s/payload/a payload/
but I prefer the former

[duglin]

s/payload is/payloads are/

[duglin]

s/recommended/RECOMMENDED/

[duglin]

anal but... since it's a string with commas that need to be parsed, we may want to add something like "leading and trailing spaces around each entry MUST be ignored. Spaces within an entry MAY exist but MUST be reduced down to a single space for comparison purposes". Are spaces allowed in the entries?

[rob-sessink-kramp]

Correct spaces are not allowed

[duglin]

s/MUST/need to/ since this isn't a normative section, it's just examples.

[duglin]

Not an expert in this space but it LGTM with the minor edits I just commented on.
Thanks for the work on this!

[duglin]

@rob-sessink while not 100% necessary, can you rebase this on the latest 'main' branch so that the tests will run successfully for you?

[duglin]

woo hoo - tests again! thanks for the rebase.
still LGTM

Ping @jskeet for another look

[JemDay]

I realize this potentially goes down a rabbit-hole of trying to maintain catalogs but is there value is formalizing some of the regulation codes or referencing some well-known external catalog (if one exists).

In addition, does the applicability of some of these regulations vary by jurisdiction? if so, does that need to be represented in some fashion ?

[jskeet]

I think Jem's concerns are reasonable, but I don't know an appropriate resolution. (It may be that there's already a standards body defining these.)

[jskeet]

What should a client do if they know "support" this extension, but see values they don't know about (e.g. a new dataregulation value)? We may want to adjust this to say "if you don't know you can meet requirements, you should assume you can't".