- From: Harshvardhan J. Pandit <me@harshp.com>
- Date: Sat, 16 Jul 2022 00:07:30 +0100
- 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