Proposal for updating Consent concepts

Fixing issues, and enabling specific concepts in different jurisdictions
published:
by Harshvardhan J. Pandit
is part of: Data Privacy Vocabulary (DPV)
is about: Data Privacy Vocabulary (DPV)
consent DPV DPVCG semantic-web

Sent to DPVCG mailing list: https://lists.w3.org/Archives/Public/public-dpvcg/2022Jul/0003.html

1. 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'

2. 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" ; ] .

3. 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.

4. Sources