Re: Proposal and notes for Consent Concepts

Hi Harsh, 

This is pretty good.  I have a few comments but not a lot of time to make good ones. 

The ANCR Record Part 1 - Specification should be posted tomorrow.   It focuses on assess a notice by creating  a record of Data Controller Identifiers, legal contexts to assess the operational transparency of the controller prior to consent.     It is defined for any privacy stakeholder to use (not just PII Controllers) and it also defines a spectrum of consent which is assessed from the individuals understanding and perspective, utilizing consent types that are found in law. 

Although in data protection law, explicit, informed, and meaningful consent is defined. This represents one data governance risk vector but doesn’t actually address the individuals governance risk vector or a shared/community  governance risk frameworks. 

This paper provided below - is a short summary of decentralized data governance risk vectors, with each vector having 3 tiers of risk assurance.     Then it provides a short summary of a consent receipt token architecture. 

I have also provided some comments below..  But haven’t the time to provide as many as I would like.   Good work.. 

- Mark

> On Jul 15, 2022, at 7:07 PM, Harshvardhan J. Pandit <me@harshp.com> wrote:
> 
> 
> **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.

# 3 seems very complicated -

From the human centric perspective everything can be interpreted as sometype of consent .

e.g. implied, implicit, explicit, directed or even altruistic - the quality of the consent provided can be informed, meaningful and explicit, and all of these indicate a state of consent.  But not it’s status - which is missing - and I like 



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

Which properties ? 

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

Does re-affirmed = renewed?

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

>