Re: Proposal for Exercising Rights

Hi,

Harsh and I have been doing further work on this topic.

# To specify statuses of the request (these will not be right-specific, 
can be used for requests of any kind) we can add the following terms to 
the main vocab:

RequestStatus

RequestInitiated

RequestAcknowledged

RequestAccepted

RequestRejected

RequestFulfilled

RequestUnfulfilled

RequestRequiresAction

RequestRequiredActionPerformed

RequestActionDelayed

RequestStatusQuery

# 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

ex:PDH a dpv:PersonalDataHandling ;

     dpv:hasRight gdpr:A13, gdpr:A14, gdpr:A15 .

# 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 gdpr:A13, gdpr:A14, 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

      foaf:page "https://example.com/SAR [1]" ;

      # what data/processing is needed to exercise

      # e.g. express ID is Needed for Identity Verification

      dpv:hasPersonalDataHandling [

          a dpv:PersonalDataHandling ;

          dpv:hasPurpose dpv:IdentityVerification ;

          dpv:hasPersonalData dpv-pd:AccountIdentifier ;

          dpv:hasProcessing dpv:Collect, dpv:Store ;

          dpv:hasRecipient ex:Controller ;

      ] ;

      # resulting notice that will be provided to the user

      dpv:hasPersonalDataHandling [

          a dpv:PersonalDataHandling ;

          dpv:hasNotice ex:SARNotice ;

          dpv:hasProcessing dpv:MakeAvailable ;

          dpv:hasRecipient dpv:DataSubject ;

      ] ;

     # provide information on whether a fee needs to paid for the request 
to be acted on

     dpv:hasPersonalDataHandling [

         a dpv:PersonalDataHandling ;

         dpv:hasProcessing dpv:MakeAvailable ;

         dpv:hasPersonalData dpv:PersonalData ;

         dpv:hasRecipient dpv:DataSubject ;

         dpv:hasPolicy "info on payment, limitations, etc." ;

      ] ;

      rdfs:comment "Exercising point for GDPR A13, A14 and A15 rights" .

# 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 using the 
statuses defined above. Connected activities are linked using 
prov:wasInfluencedBy ex:PreviousActivity

ex:SAR1 a dpv:RightExerciseActivity, prov:Activity ;

      dct:description "Data Subject makes a SAR request"@en ;

      # what rights this exercise is about

      dpv:hasRight gdpr:A15, gdpr:A20 ;

      # where this was exercised

      dpv:isExercisedAt ex:SARPoint ;

      # who exercised this --> this can be a third party representative

      prov:wasAssociatedWith ex:DataSubject ;

     dpv:hasRecipient ex:Controller ;

      # who is the data subject

      dpv:hasDataSubject ex:DataSubject ;

      # when was this done

      dct:date "2022-11-02T11:08:05"^^xsd:dateTime ;

      # what is the status of this exercise

      dpv:hasStatus right:RequestInitiated ;

      # scope of right (optionally provided) - can be anything, so 
described as a string, or a concept e.g. Purpose, or combinations using 
PDH

      dpv:hasScope [

           a dpv:PersonalDataHandling ;

           dpv:hasPurpose dpv:Marketing ;

      ] ;

      # what personal data was processed for this

      # e.g. provide Driver License for identity verification

      dpv:hasPersonalDataHandling [

          a dpv:PersonalDataHandling ;

          dpv:hasPersonalData ex:User12345 ;

          dpv:hasProcessing dpv:Collect, dpv:Store ;

      ] .

# Request is acknowledged

ex:SAR2A a dpv:RightExerciseActivity, prov:Activity;

      dct:description "Controller acknowledges the request"@en ;

      dct:date "timestamp" ;

      prov:wasAssociatedWith ex:DataController ;

     dpv:hasRecipient ex:User12345 ;

      dpv:hasStatus right:RequestAcknowledged ;

      # link to previous activity

      prov:wasInfluencedBy ex:SAR1 .

ex:SAR2B a dpv:RightExerciseActivity, prov:Activity;

      dct:description "Controller refuses the request"@en ;

      dct:date "timestamp" ;

      prov:wasAssociatedWith ex:DataController ;

     dpv:hasRecipient ex:User12345 ;

      dpv:hasStatus right:RequestRefused ;

     # justifications for non-fulfilment will be provided in DPV

     dpv:hasJustification rights:IdentityVerificationFailure ;

      # link to previous activity

      prov:wasInfluencedBy ex:SAR1 .

#Further actions need to be perfomed by the data subject

ex:SAR2C a dpv:RightExerciseActivity, prov:Activity;

      dct:description "Controller requires further actions"@en ;

      dct:date "timestamp" ;

      prov:wasAssociatedWith ex:DataController ;

     dpv:hasRecipient ex:User12345 ;

      dpv:hasStatus right:RequestRequiresAction ;

     dpv:hasJustification rights:IdentityVerificationFailure ;

     dpv:hasPersonalDataHandling [

         a dpv:PersonalDataHandling ;

         dpv:hasPersonalData dpv-pd:OfficialID ;

         dpv:hasProcessing dpv:MakeAvailable ;

         dpv:hasPurpose dpv:IdentityVerification ;

         dpv:hasRecipient ex:Controller ;

         dpv:isImplementedByEntity ex:User12345 ;

         ] ;

      # 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 ;

      dct:date "timestamp" ;

      prov:wasAssociatedWith ex:DataSubject ;

      dpv:hasStatus right:RequestRequiredActionPerformed ;

      # explain what more has been done

      dpv:hasPersonalDataHandling [

         a dpv:PersonalDataHandling ;

         dpv:hasPersonalData dpv-pd:OfficialID ;

         dpv:hasProcessing dpv:MakeAvailable ;

         dpv:hasPurpose dpv:IdentityVerification ;

         dpv:hasRecipient ex:Controller ;

         dpv:isImplementedByEntity ex:User12345 ;

       ] ;

      # link to previous activity

      prov:wasInfluencedBy ex:SAR2C .

# controller fulfils the right - provides a notice and copy of the data 
using dcat:Dataset

ex:SAR4 a dpv:RightExerciseActivity, prov:Activity;

      dct:description "Please access your document"@en ;

      dct:date "timestamp" ;

      prov:wasAssociatedWith ex:DataController ;

      dpv:hasRecipient ex:User12345 ;

      dpv:hasStatus right:RequestFulfilled ;

      # where to find the requested data

      prov:generated ex:DataCopyX123, ex:SARNotice_User12345 ;

      # link to previous activity

      prov:wasInfluencedBy ex:SAR3 .

ex:SARNotice_User12345 a gdpr:SARNotice ;

     dct:date "timestamp" ;

     foaf:page "url for notice" .

ex:DataCopyX123 a dcat:Dataset ;

     # use existing vocabularies for format types

     dct:format "CSV" ;

     dct:accessRights "login required"@en ;

     dct:conformsTo "schema description" ;

     dct:issued "timestamp" ;

     dct:valid "valid until timestamp" ;

     dcat:landingPage "url for accessing data" .

The example above describes how to exercise GDPR A15 using DPV, feedback 
is welcome on missing terms. Once we have a common structure to record 
the right exercising then we can do the same for the other rights.

Beatriz

El 14/10/2022 a las 22:57, Harshvardhan J. Pandit escribió:

> 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/



Links:
------
[1] https://example.com/SAR