search

uropa-project / uropa

Universal record of processing activities (UROPA) standardized protocol.
21 stars 4 forks source link

Add Purpose Type to Purpose Objects #8

Open milstan opened 2 years ago

milstan commented 2 years ago

Currently, legalBases and dataCategories are properties of Purpose.

Consider the following: I process contact data (dataCategory: priv:CONTACT), for purposes of priv:MARKETING, and priv:SERVICES. For MARKETING purposes I ask the user for consent (legalBases: priv:CONSENT), but for purposes of providing services to the user, I don't need consent, and I can process this same data with legalBases: priv:CONTRACT.

As thigs stand in UROPA, to represent this, I'd need to create two Purpose objects: Purpose 1 - name: priv:MARKETING, dataCategory: priv:CONTACT, legalBases: priv:CONSENT Purpose 2 - name: priv:SERVICES, dataCategory: priv:CONTACT, legalBases: priv:CONTRACT

I have to use the name of the Purpose object to specify the type of the purpose in fact.

The type of purpose is important because the user can make a request to stop all processing of their data for marketing pruposes (while they still allow processing for purpose of providing services to them).

If I am using the name property to indicate the type of Pupropse, then I might end up having muptiple purposes with the same name. E.g. If I also have some other data I process for marketing purposes: Purpose 3 - name: priv:MARKETING, dataCategory: DEMOGRAPHIC.GENDER, legalBases: priv:LEGITIMATE-INTEREST

My Purpose 1 and Purpose 3 would have the same name.

This does not seem to be a problem in your model, but it is not very elegant.

I would suggest adding purposeType.

fxcao commented 2 years ago

Hi We propose to include a new field on the purpose called purposeType. This would be an enum field, whose filling is not required. This enum's values will defined later, we'll look for standards, including the one you mentioned (Priv).

milstan commented 2 years ago

Sounds great

coolharsh55 commented 1 year ago

Hi. DPV has a more exhaustive and hierarchically structured taxonomy for purposes (and other concepts) - https://w3c.github.io/dpv/dpv/#vocab-purpose. I think the PRIV one does a nice job of representing the 'top concepts', and DPV then goes into details for each of these - e.g. service optimisation and then for whom - controller or user. Of note, in PRIV, the purpose "TRACKING" is not a valid purpose as per GDPR. The tracking should have some goal, i.e. a purpose. This can be analytics or personalisation or recommendations or whatever - which is what should be stated. The actual tracking is a means to achieve this, therefore it should be a type of processing (similar to how profiling is not a valid purpose but a processing operation that enables some purpose).