W3C home > Mailing lists > Public > public-dpvcg@w3.org > July 2022

Proposal and notes for Consent Concepts

From: Harshvardhan J. Pandit <me@harshp.com>
Date: Sat, 16 Jul 2022 00:07:30 +0100
Message-ID: <924bc105-1316-e030-af38-28fc41cad601@harshp.com>
To: "public-dpvcg@w3.org" <public-dpvcg@w3.org>
Hi. Please see below some proposals for overhauling the consent concepts in DPV, including specific issues and suggestions. If for some reason, reading this is difficult, please let me know and I will share the text in another more readable format (md, html, pdf).

I didn't get the time to turn this into a proper fully realised proposal specification, so its still in 'notes form'. Sources are provided in the last section.


# Table of Contents

1.  [Summary](#orgee58091)
2.  [Examples](#org567ae4f)
3.  [Issues and Suggestions for Consent concepts in DPV](#org176cd15)
4.  [Sources](#org4ebacf2)

# Summary

  **Information**                  | **currently in DPV**        | **proposed change**
----------------------------------|-----------------------------|-------------------------------------
  Consent Information              | Consent                     | ConsentRecord
  Notice                           | hasConsentNotice            | hasNotice
  Duration                         | hasExpiry                   | hasDuration
  Refresh/Reaffirm                 | N/A                         | hasReaffirmationPeriod
  Given by Person                  | hasProvisionBy              | isIndicatedBy
  Given how?                       | hasProvisionMethod          | hasIndicationMethod
  Given by someone else?           | hasProvisionByJustification | hasRelationWithDataSubject
  Given when? Time?                | hasProvisionTime            | isIndicatedAtTime
  Withdrawal by Person             | hasWithdrawalBy             | isIndicatedBy
  Withdrawal how?                  | hasWithdrawalMethod         | hasIndicationMethod
  Withdrawal by someone else?      | hasWithdrawalJustification  | hasRelationWithDatasubject
  Withdrawal when? Time?           | hasWithdrawalTime           | isIndicatedAtTime
  Status? Given, Refused, etc.     | N/A                         | hasConsentStatus
  Consent condition? Explicit?     | isExplicit                  | hasConsentExpression
  Consent condition? Not-explciit? | N/A                         | hasConsentExpression
  GDPR Explicit vs other Explicit? | N/A                         | dpv-gdpr:ExplicitlyExpressedConsent

**New Concepts**

1.  ConsentRecord subtype of DataProcessingRecords
2.  ConsentStatus subtype of Status, with subtypes Unknown, Requested, Refused,
     Given, Expired, Invalidated, Revoked, Reaffirmed
3.  ConsentExpression with subtypes UninformedConsent, and InformedConsent - which
     has more subtypes as ImpliedConsent, and ExpressedConsent - which has more
     subtypes as ExplicitlyExpressedConsent.

**Breaking backwards compatibility**

-   IF there are strong considerations for existing use of these properties, we
     can offer a "sunset period" where the current concepts/properties will
     continue to be in DPV for a period of time after which they will be
     retired, with a note to this effect in the spec. The new concepts will be
     added now and will be indicated as the preferred ones.
-   It is no longer possible to express both 'given time' and 'withdrawal time'
     over the same instance of consent. However, this loss has made awy to indicate
     a wider range of 'states' such as refused and reaffirmed which need their own
     timestamps (such as under GDPR and EU-DSA)
-   There will no longer be a separation between 'consent properties' and those
     that can be used elsewhere. Most of the consent specified properties will be
     possible to use elsewhere as required, for example - notice, indication (of a
     decision), relation with data subject. The consent specific properties will
     have 'consent' in their name, e.g. 'hasConsentExpression'

# Examples

     ex:101 a dpv:ConsentRecord ;
         dpv:hasPersonalDataHandling ex:PDH_with_processing_details ;
         # PDH can contain Data Subject
         # PDH can also directly specify notice i.e. ex:PDH dpv:hasNotice
         dpv:hasNotice ex:NoticeShown ;
         dpv:hasConsentStatus dpv:ConsentGiven ;
         dpv:isIndicatedAtTime "2022-07-15" ;
         dpv:hasIndicationMethod "consent dialogue on website" ;
         dpv:hasConsentExpression dpv-gdpr:ExplicitlyGivenConsent ;
         dpv:hasReaffirmationPeriod "2023-07-14" ;
         dpv:hasDuration "2 years" .
     
     ex:102 a dpv:ConsentRecord ;
         # optional provenance
         # using PROV-O - prov:wasDerivedFrom ex:101
         # using DCT - dct:isVersionOf ex:101
         dpv:hasPersonalDataHandling ex:PDH_with_processing_details ;
         dpv:hasConsentStatus dpv:ConsentWithdrawn ;
         dpv:isIndicatedAtTime "2022-07-15" ;
         dpv:hasIndicationMethod "consent dialogue on website" .
     
     ex:103 a dpv:ConsentRecord ;
         # IF we want to integrate "events" as a concept, but separately
         #    from DPV, e.g. in an extension, alongside other 'events',
         #    that relate to processing, compliance, etc.
         #    WARNING: this will result in complexity, sever overlap with
         #    other vocabularies such as PROV-O, and definite confusion.
         #    This example intentionally avoids PROV-O for brevity.
         # The record will contain the 'common stuff for this record'
         dpv:hasPersonalDataHandling ex:PDH_with_processing_details ;
         dpv:hasNotice ex:NoticeShown ;
         # IF there is a need to know consent status at record level
         dpv:hasConsentStatus dpv:ConsentWithdrawn ;

         event:hasEvent [
     	a event:ConsentEvent ;
     	dpv:hasConsentStatus dpv:ConsentRequested ;
     	dpv:isIndicatedAtTime "2022-07-15" ; ] ;

         event:hasEvent [
     	a event:ConsentEvent ;
     	dpv:hasConsentStatus dpv:ConsentGiven ;
     	dpv:isIndicatedAtTime "2022-07-15" ; ] ;

         event:hasEvent [
     	a event:ConsentEvent ;
     	dpv:hasConsentStatus dpv:ConsentWithdrawn ;
     	dpv:isIndicatedAtTime "2022-12-31" ; ] .

         # P.S. Such "annotations" of events and timestamps can be
         # easily integrated across DPV using "hasRecord" and "Record"

# Issues and Suggestions for Consent concepts in DPV

-   `hasConsentNotice`
     -   issue: Consent is not the only legal basis or concept that needs a
         notice. We have `Notice` and `PrivacyNotice` as concepts within organisational
         measures which are useful in places other than consent.
     -   suggestions: remove this relation, and provide the generic `hasNotice`
         relation that can be used anywhere, not just for consent
-   `hasExpiry`
     -   issue: "Expiry" indicates consent is not valid after this time, which is not
         always the case. For example, EDPB guidelines on Consent 05/2020 pt.111 uses
         the term "refresh" to indicate a time when consent should be asked or
         confirmed again. This does not necessarily mean that consent expires or
         becomes invalid at that point.
     -   issue: "Expiry" is a broad concept that can be applied to other concepts,
         such as other legal bases, processing, personal data, etc. DPV already has
         `Duration` concepts to specify contextual information on the temporal duration
         of processing activities. The same can be applied for consent instead of
         expiry to ensure consistent application of terms.
     -   suggestions:
         1.  remove the relations `hasExpiry`, `hasExpiryCondition`, `hasExpiryTime` - and
             replace these with use of `hasDuration` and `Duration` concepts
         2.  for expressing when consent should be refreshed, the term "reaffirm" is
             more clear than "refresh", to express this add relation
             `hasReaffirmationPeriod` which can then be used with a temporal timestamp
             or duration, or a condition. The relation can also be used to reaffirm
             other concepts, such as contracts, so that's an added benefit.
-   `hasProvisionBy` and `hasProvisionMethod`
     -   issue: "provision" can also be applicable for other concepts, such as
         providing data, accepting contracts, acknowledging receipts. The information
         we want to represent here relates to "who has given their consent", or
         rather the more correct question "who has expressed their consent".
     -   suggestion: Remove the provision relations, and use "express" or
         "indication" - these are preferred over "give" because it works for when
         consent is refused. For example, `indicatedBy` could be for any decision,
         whether it was giving consent or refusing consent or withdrawing
         consent. The relations here would then be `indicatedBy`. For the provision
         method, it would be `hasIndicationMethod` to specify the method by which a
         decision was indicated.
-   `hasProvisionByJustification`
     -   issue: This relation was meant to enable representing information when the
         data subject was not the one indicating their decision, for e.g. a parent
         expressing consent in lieu of their child. So instead of justification of
         provision as a complicated way of expressing this information, what is
         needed is to express the relationship between the Data Subject and whoever
         has provided the consent. This relationship, i.e. some other entity having a
         relationship with the Data Subject, can also occur at other places, such as
         contracts, or for expressing relationship between Controller and Data
         Subject.
     -   suggestion: remove this relation, and replace it with a broader relation as
         `hasRelationWithDataSubject` that can be used to indicate a parent is related
         to the child as the data subject, or a controller is the employer of the
         data subject. Note that the use of this relation would be to provide a
         description of the relationship since the other properties would be used to
         express the entities involved. For example, `hasDataSubject` and
         `indicatedBy` to specify the two entities, and `hasRelationWithDataSubject`
         as "parent" or "employer". We can provide the concept
         `RelationWithDataSubject` since its a common concept in use-cases, and also
         provide examples for commonly occuring relationships.
-   `hasProvisionTime` and `hasWithdrawalTime`
     -   issue: These are timestamps associated with consent as "events" i.e. when
         consent was given and when it was withdrawn. There are two issues here -
         first, consent can be given multiple times such as when being refreshed or
         when withdrawing and giving it again. But it can also have a timestamp for
         when it was refused, or requested, or expired/invalidated/etc. - any other
         types of 'events' that are not covered by 'provisioned' and
         'withdrawn'. Second, consent is not the only concept that has an associated
         timestamp. For example, contract has a timestamp too. It is typically up to
         the use-case whether they want to represent these different 'events' as
         separate instances (e.g. one for given, one for withdrawn), or to express
         all information over a single instance (e.g. what we have now in DPV where
         the same instance has both given and withdrawn).
     -   suggestion: remove provision timestamp, and replace with `indicatedAtTime`
         to bring it in line with other 'indication' relations and to enable its use
         anywhere where there is a need to represent timestamp for some
         decision. Because withdrawal is just one type of revocation, others being
         that consent has 'expired' or been 'invalidated', the intention of recording
         this timestamp is to represent when that consent has stopped being suitable
         to be used to justify processing. Therefore, this can be represented through
         the relation `revokedAtTime`
-   `ConsentRecord` and `hasStatus`
     -   issue: Consent as a term almost always refers to the textbook definition as
         the agreement of the individual i.e. "given consent". However, when dealing
         with consent as an artefact, i.e. a piece of information, we want to specify
         things about something that is supposed to be 'given consent', but can be
         other things - such as a request for given consent, or refusal to give
         consent, or an invalidated given consent. Rather than create more and more
         concepts to represent these (which is possible as an alternate model),
         technological concepts almost always specify this as "Consent" or
         "GivenConsent" and leave it at that. The issue here is that this causes
         confusion (has caused, will cause) between 'consent' and its 'record'.
     -   suggestion: Create a new concept called `ConsentRecord` as a subtype of
         `DataProcessingRecords` to represent the information associated with consent
         regardless of what 'status' it has i.e. given, refused, etc. This also helps
         fulfil compliance obligations associated with maintaining information about
         consent records. To indicate what the state of that consent is within the
         consent record, the existing DPV relation `hasStatus` can be used with
         creation of `ConsentStatus` and its subtypes - `Unknown`, `Requested`, `Given`,
         `Refused`, `Withdrawn`, `Revoked`, `Invalidated`, `Expired`, and `Reaffirmed`. For more
         clarity, the relation `hasStatus` can be specialised to `hasConsentStatus`.
-   `isExplicit` as a boolean
     -   issue: Currently, the DPV indicates consent is explicitly given using the
         relation `isExplicit` which only offers three possible states being a
         boolean - True, False, and Unknown. This makes it impossible to specify
         other conditions, such as non-explicit or implied consent without creating
         additional properties, and which is not a good design since it can result in
         Explicit + Implied consent being expressed in the same instance. It also
         does not facilitate separation between different definitions or conditions
         of 'explicit' consent such as between ISO/IEC 29184 vs GDPR where they are
         non-compatible.
     -   suggestion: Remove the existing `isExplicit` Property. Add
         `hasConsentExpression` property to clearly indicate that this is the criteria
         for how consent is expressed. Create `ConsentExpression` as a concept, with
         subtypes `InformedConsent` and `UninformedConsent` as being the two broad types
         (note: being informed is not strictly a type of expression, however here we
         consider the response to information as being the expression and a way to
         shoehorn the legally defined concept into the taxonomy). For informed, we
         have more subtypes: `ImpliedConsent` and `ExpressedConsent` where 'express'
         means the data subject specifically and directly expresses their consent
         such as through a button, with implied meaning they do some other action
         from which the consent is implicit or assumed such as browsing the website
         or walking into a CCTV-equipped store. `ExplicitlyExpressedConsent` is a
         specialised subtype where there is a further specific criteria for how the
         expression (direct) of consent should be carried out. In ISO/IEC, this means
         clicking a button for that specific consent, but under GDPR the requirement
         is much higher. To reflect this, DPV-GDPR will contain another definition of
         `ExplicitlyExpressedConsent` as the subtype of its corresponding concept in
         DPV to indicate GDPR level of explicit expression.

# Sources

-   PAECG deliverable for Consent Receipt <https://doi.org/10.5281/zenodo.5076603>
     -   outlines consent concepts with analysis of Consent Receipt v1.1 and GDPR
         requirements ;
     -   provides recommendation for semantic vocabulary and use
-   gconsent ontology <http://w3id.org/GConsent>
     -   provides semantic concepts for consent and modelling of 'states' and 'actors'
-   FHIR consent codes <https://www.hl7.org/fhir/valueset-consent-state-codes.html>
     -   comprehensive standard for 'codes' representing use of consent (similar to
         states in GConsent) and its management within systems
     -   primarily intended for Health records
-   DUO <http://purl.obolibrary.org/obo/duo.owl>
     -   another health-oriented vocabulary about consent
     -   outlines permissions and prohibitions for use-cases related to
         health/medical data sharing in terms of practical use-cases
-   sem-web + consent survey paper
     <https://content.iospress.com/articles/semantic-web/sw210438>
-   georg: consent 'expiry' as a concept is not liked by clients, instead they
     prefer the term 'refresh' which indicates that consent needs to be confirmed
     again after this time
-   ISO/IEC AWI TS 27560 Privacy technologies — Consent record information
     structure <https://www.iso.org/standard/80392.html>
-   <https://github.com/w3c/dpv/issues/21>
-   EDPB guidelines on Consent, DPA guidance on consent, case law, etc.

Regards,
-- 
---
Harshvardhan J. Pandit, Ph.D
Research Fellow
ADAPT Centre, Trinity College Dublin
https://harshp.com/
Received on Friday, 15 July 2022 23:07:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 15 July 2022 23:07:47 UTC