Data Markings / Marking Definition Redaction patterns

[Stephen Russett <stephen@digitalstate.ca>]

Hi all

Looking to get some community feedback on common use cases for redaction patterns being used for Data Markings.

As I see the spec, there are two overall considerations:

1. Object redactions

2. Field level redactions

For #1, what are the most common needs for users? Complete removal/non-existant knowledge? or returning empty objects (if a array had 5 redacted items then there would be 5 empty objects.

For #2, where selectors are defining redactions, what are the common needs? Field Removal, Field masking (*****), common replacements like â__REDACTED__â.

And what about when fields are redacted that are a âRequiredâ property for that object? What are the common use cases and problems that you have run into for the consumer to receive non-spec match json (incorrect values and/or missing required fields)?

I am currently implementing the Java lib and want to quickly configure these various scenarios:

current prototype is as follows:

public interface SomeSDO extends ....... {

    @NotBlank
    @JsonProperty(âsome_property")
    @Redacted(processor=SomeRedactionProcessor.class, mask="__REDACTED__")
    String getSomeProperty();
...

Where @Redacted will be a configurable annotation. Basically you can globally, per class/object type and per property. Where each is about define the redaction schemes for Object Marking Refs and Granular Refs. Â

The way this works is during serialization, the processor looks at each property and determines if redaction is defined. If so, then it reprocesses that property based on the redaction scheme. Before all this occurs, the call for json serialization is given a input of Bundleable objects (SDO, SRO, Marking Definitions) that are used during evaluation of the redaction. Âbasically this is a comparison of the âsubjectâ (the consumer of the json) and the classifications applied at the producer side of the json; anywhere the subject is missing the required Object Markings, the redaction processor clean the data as defined by the processing rules.

The usage here is that the producer will have defined âfiltersâ that are groups of Marking Objects that are the âWhat Marking Objects the Consumer will haveâ, and the JSON is generated based on the rules that are passed and not passed. (of course lots of different variations can be applied as well).

It would be great if some of the community can share the common scenarios they have been seeing and hopefully we can adjust the redaction based on this!

Thanks!

Steve