data_qualifiers → Move away from strict hierarchy

[RobertKeyser]

Most of the hierarchies in Fideslang go from general → specific, comprising a subsumptive hierarchy.

For example for data_categories, user.provided.identifiable.contact.city is a subset of user.provided.identifiable.contact, which is a subset of user.provided.identifiable data.

In data_qualifiers, fully identifiable information is aggregated.anonymized.unlinked_pseudonymized.pseudonymized.identified, but that suggests that identified data is a subset of pseudonymized data and so forth. Instead of adopting a strict hierarchy that represents least identifiable → most identifiable information, we should move to a subsumptive hierarchy that goes from general categories → most specific. Essentially creating is-a relationships.

[NevilleS]

I also find this one awkward, and do agree that flipping it around (e.g. identified.pseudonymized.unlinked_pseudonymized.anonymized.aggregated) would at least feel more consistent. FWIW the core reason we did this is because for the main use case, writing REJECT policies, all the other hierarchies start from least risky -> most risky. So for consistency there, we made it easy to say "reject all user data that is aggregated.anonymized" and that means we'll also reject user.provided data that is aggregated.anonymized.unlinked_pseudonymized

[NevilleS]

IMO I think a more intuitive solution would be to not treat qualifiers as a hierarchy, but instead more of a linear scale. They don't "branch" into subcategories in the same way, so they are more like a label.

Something to consider as we collect additional user feedback, etc.

[NevilleS]

For example, simply use data_qualifier: aggregated and have that map to an enum like [identified, pseudonymized, unlinked, anonymized, aggregated] where identified = 0 and aggregated = 4.

There are a few other privacy declarations that I think fit this type of mold of enums / risk-scores / etc. more naturally than hierarchies. Today we effectively have two types: nested hierarchies, and flat strings. There are other types that make sense for modelling too!