Add a Cross-Category Slector

[milstan]

The problem

PRVI defines a selector as being a subcategory of one and only one data category.
Selectors are used to map to data in the storage, for techning data, modifying and deleting data.

We've encountered an issue with a data field (a file - CV in particular) that contains a lot of data of multiple categories. Having it declared as a selector - subcategory of OTHER-DATA, would be wrong as it contains mutliple categories of AFFILAITION, DEMOGRAPHIC, CONTACT, IMAGE data.

So if we use OTHER-DATA.CV, when the user asks for the categories of data we have on him, we can't be precise. When the user wants to access AFFILIATION data, it would't match (although AFFILIATION data is in it)

The proposed solution

Define a specific notion of cross-category selector. The selector is then considered to be the subcategory, not of one category, but of a set of categories.

The selector behaves in the following way:
For ACCESS requests, the slector passes if one of the categories is given in the privacy scope of the request.
e.g. We have {AFFILAITION, DEMOGRAPHIC, CONTACT, IMAGE}.CV
for ACCESS dc:CONTACT it is slected and the whole data it points to is given (even though it contains other data too)

For TRANSPARENCY.CATEGORIES all the {AFFILAITION, DEMOGRAPHIC, CONTACT, IMAGE} are given.

For MODIFY, DELETE requests containing one of the categories under which the selector is defined, nothing happens. To MODIFY or DELETE data that this selector points to, one needs to cover all of its categories.

Retention policies of type NO-LOGNER-THAN (behave like DELETE/MODIFY - they only affect the selector if they are defined over the total set of categories (or larger scope) of the cross-category selector. Retention policies of type NO-LESS-THAN affect the selector if at least of the categories matches (like ACCESS).

Alternatives

An alternative would be to make the Data Category tree a graph, where OTHER-DATA.CV can be declared a supercategory of each of the needed categories. This would include risks of creating cyclical graphs, where in order to use such a system the user would need to become a logician .

[TheKinrar]

Could data fragments have multiple selectors instead? Do we need a *.CV selector, or could we "simply" have both a DEMOGRAPHIC and a CONTACT selector on the data fragment?
It's basically the same idea but the inheritance is somewhere else.

If having all possible data fragments defined as a selector is important, I agree that multiple parents on a selector looks like the best alternative.

[milstan]

@TheKinrar the issue is, I think, that we want to separate the notion of selectors from the notion of data fragments (as we currently do not support data fragments, but will do so only in later versions of devkit).

[TheKinrar]

I think we emulate data fragments in a way with our current storage system: when a user requests CONTACT data, we essentially return what would be the data part of a data fragment.

I agree though that having precise selectors (like *.CV) is probably the easier for 3rd-party devs (and for me) as this puts the burden of resolving selectors on the PCE instead of storage.