Proposal for Exercising Rights

Hi.
As we discussed in last week 
(https://www.w3.org/2022/10/05-dpvcg-minutes.html#t02), we want to have 
concepts to indicate what rights exist, where to exercise them, what is 
needed, and the actual instances of rights being exercised.

---

# Indicate what rights exist

dpv:Right and dpv:hasRight are used here to indicate what right(s) exist 
and are applicable in a given context

---

# Indicate where to exercise right

Proposed concept RightExercise denoting information about rights 
exercise and relation isExercisedAt to indicate where to exercise it. 
For example,

# Company's SAR implementation
ex:RightToAccess a dpv-gdpr:A15 ;
     dpv:isExercisedAt ex:SARPoint .

# SAR is submitted through url
ex:SARPoint a dpv:RightExercise ;
     # what rights are handled by this service/page
     dpv:hasRight dpv-gdpr:A15 ;
     # who is the controller(s)
     dpv:hasDataController ex:Controller ;
     # who implements the right
     dpv:isImplementedByEntity ex:Controller ;
     # the location of exercising the right
     dpv:hasLocation "https://example.com/SAR" ;
     # what data/processing is needed to exercise
     # e.g. express ID is Needed for Identity Verification
     dpv:hasPersonalDataHandling [ ... ] .

---

# Instances of rights being exercised

The concept RightExerciseActivity to model an exercising of right and 
track its provenance - using the PROV-O standard i.e. subclassing 
concepts. This allows expressing activities, artefacts (entities in 
PROV), and entities (agents in PROV), along with information such as who 
did what, generated what, timestamps, and so on. Below are examples of 
some of the back and forth that can happen in SAR requests.

ex:SAR1 a dpv:RightExerciseActivity, prov:Activity ;
     dct:description "Data Subject makes a SAR request"@en ;

     # what rights this exercise is about
     dpv:hasRight dpv-gdpr:A15 ;

     # where this was exercised
     dpv:isExercisedAt ex:SARPoint ;

     # who exercised this
     # --> this can be a third party representative
     prov:wasAssociatedWith ex:DataSubject ;

     # who is the data subject
     dpv:hasDataSubject ex:DataSubject ;

     # when was this done
     prov:wasStartedAtTime "timestamp" ;

     # what is the status of this exercise
     # more on statuses later
     dpv:hasStatus right:Requested ;

     # scope of right (optionally provided)
     # scope can be anything, so described as a string, or
     # a concept e.g. Purpose, or combinations using PDH
     dpv:hasScope [ a dpv:PersonalDataHandilng ... ] ;

     # what personal data was processed for this
     # e.g. provide Driver License for identity verification
     dpv:hasPersonalData [ ... ] .

# some (distinct) controller follow up scenarios

ex:SAR2A a dpv:RightExerciseActivity, prov:Activity;
     dct:description "Controller acknowledges the request"@en ;
     prov:wasStartedAtTime "timestamp" ;
     prov:wasAssociatedWith ex:DataController ;
     dpv:hasStatus right:Acknowledged ;
     # link to previous activity
     prov:wasInfluencedBy ex:SAR1 .

ex:SAR2B a dpv:RightExerciseActivity, prov:Activity;
     dct:description "Controller refuses the request"@en ;
     prov:wasStartedAtTime "timestamp" ;
     prov:wasAssociatedWith ex:DataController ;
     dpv:hasStatus right:Rejected ;
     # reason of rejection
     dpv:hasJustification "We are not the controller ...."@en ;
     # link to previous activity
     prov:wasInfluencedBy ex:SAR1 .

ex:SAR2C a dpv:RightExerciseActivity, prov:Activity;
     dct:description "Controller asks for more info"@en ;
     prov:wasStartedAtTime "timestamp" ;
     prov:wasAssociatedWith ex:DataController ;
     dpv:hasStatus right:ActionRequired ;
     # explain what more needs to be done
     dpv:hasPersonalDataHandling [ ... ] ;
     # where to provide information?
     dpv:hasLocation "url" ;
     # link to previous activity
     prov:wasInfluencedBy ex:SAR1 .

# follow up from data subject

ex:SAR3 a dpv:RightExerciseActivity, prov:Activity;
     dct:description "Data Subject provides more info"@en ;
     prov:wasStartedAtTime "timestamp" ;
     prov:wasAssociatedWith ex:DataSubject ;
     dpv:hasStatus right:ActionPerformed ;
     # explain what more has been done
     dpv:hasPersonalDataHandling [ ... ]
     # link to previous activity
     prov:wasInfluencedBy ex:SAR2C .

# controller fulfils the right

ex:SAR4 a dpv:RightExerciseActivity, prov:Activity;
     dct:description "Please access your document"@en ;
     prov:wasStartedAtTime "timestamp" ;
     prov:wasAssociatedWith ex:DataController ;
     dpv:hasStatus right:Fulfilled ;
     # where to find the requested data
     prov:generated ex:SARCopyX123 ;
     # link to previous activity
     prov:wasInfluencedBy ex:SAR3 .

# To express artefacts or conditions associated with fulfilment
# e.g. providing some information, or a dataset,
# or confirming data has been deleted or rectified
# or processing has been objected,
# the concept RightFulfilment is used.

# for information provided as part of SAR
# below can be a PDH instance for machine-readable information
# or it can be a url webpage, or a PDF
# or, for other rights such as right to object, just a confirmation
# or, for portability, describe a dataset (e.g. DCAT)

ex:SARCopyX123 a dpv:RightFulfilment, prov:Entity ;
     prov:wasGeneratedBy ex:SAR4 ;
     dpv:hasRight dpv-gdpr:A15 ;
     prov:atLocation "url" ;
     prov:generatedAtTime "timestamp" .

---

# Statuses

To express different kinds of statuses, we need to have concepts that 
express (specifically for rights) the back and forth communications that 
can happen. So, something like:

- Exercised - Data subject has exercised a right
- Acknowledged - the exercise has been acknowledged
- Rejected - the request has been rejected or refused
- Fulfilled - the exercise obligations have been fulfilled
- Unfulfilled - the exercise obligations have not been fulfilled
- AwaitingResponse - the exercise is awaiting response (from an entity)
- ActionRequired - the exercise requires some action (from an entity)
- ActionPerformed - the required action has been perfomed

---

# Additional concepts if needed

- format of request/response: prov:Entity + dct:format
- Lawfulness - propose to add Lawfulness as a sub type of 
ComplianceStatus, with types as Lawful, Unlawful, and LawfulnessUnknown. 
This is then replicated for Laws, as GDPRLawfulness with types 
GDPRLawful, GDPRUnlawful, and so on ...
- Common reasons to refuse exercise such as Identity could not be 
verified, or scope unclear, or excessive, or controller was not the 
correct entity, etc. would be modelled as RightRefusalJustifications and 
provided as a taxonomy to help with use-cases
- delegation or representation where someone else exercises a right on 
behalf of the data subject - <Entity> prov:actedOnBehalfOf <Entity>

---

# Implementing each GDPR Right

The above just used SAR (GDPR A.15) as an example to show how the right 
exercise process would be modelled using DPV and PROV. Once we get 
consensus on what the common way to exercise and record rights should 
be, we would need to provide guidance for each GDPR right using the 
above framework. In most cases, only the Right Fulfilment concept would 
change, e.g. as A.20-CopyOfPersonalData, or A.15-SARInfo, or something 
like that.

---

P.S. Thanks to Georg for doing the requirements collection and to 
Beatriz for assisting with the discussion on technical flows.

Regards,

-- 
---
Harshvardhan J. Pandit, Ph.D
Research Fellow
ADAPT Centre, Trinity College Dublin
https://harshp.com/

Received on Friday, 14 October 2022 20:57:05 UTC