Consent Tracking

Introduction

Storing and processing of personally identifiable data (PID) may require explicit consent by the person in question. The Consent Tracking framework provides the means to request and track such consent.

Data Model

Types of Data Processing

The auth_processing_type table records types of data processing that require consent. Each processing type is identified by a unique code, which can be used to hard-code filters and consent checks throughout the application.

Consent Options

The auth_consent_option table holds a short title for each processing type (e.g. "Store my personal data") and an explanation what exactly that means. These two are used to request consent from the user, so formulations may be subject to legal requirements and guidelines.

Once a user has consented (or declined to consent) to a consent option, title and explanations can no longer be changed.

If they must be changed, e.g. for legal reasons or because the application has changed with regard to this type of data processing, then a new consent option for this processing type must be created, and the old version be marked as obsolete. Consent recorded for obsolete consent options will no longer be valid, thus, after such a change, the user must be asked for their consent again.

Consent Record

The auth_consent table records the user response to a consent option (yes or no). Each consent record refers to a specific consent option, hence type of data processing.

A consent record will be created even if the user declines to consent (in this case with the consented-flag set to False). Therefore, the absence of a consent record for a processing type does not mean the user has declined, but rather that they have not been asked.

Consent records can expire after a certain date, and will always expire when a new consent response of the same user for the same processing type is recorded.

Managing Consent Options

Types of Data Processing and Consent Options can be managed by Administrators through the Web GUI.

To enable the corresponding sub-menu in the Admin section, the template must set:

settings.auth.consent_tracking = True

Typically, however, consent options (or at least processing types) would be pre-populated by the template - for the CSV structure see static/formats/s3csv/auth.

Requesting Consent

For the implementation of consent tracking, the framework provides the auth_Consent class which is available through s3db:

consent = s3db.auth_Consent()

The constructor can be given a list of processing type codes to limit it to these types of data processing, e.g.:

consent = s3db.auth_Consent(processing_types=["STOREPID", "SHAREPID"])

Embedding the Widget

The auth_Consent instance can generate a form widget with consent options. To embed it into a form, inject an additional string field like this:

# Instantiate auth_Consent (limit to certain processing types if required)
consent = s3db.auth_Consent()

# Produce a Field instance with the consent widget
consent_field = Field("consent_question",
                      label = T("Consent"),
                      widget = consent.widget,
                      )
formfields.append(consent_field)

Mandatory Consent Options

[tbd]

Post-processing the Widget

[tbd]

Checking for Consent

has_consented

[tbd]

consent_query

[tbd]

consent_filter

[tbd]

Consent Expiry

[tbd]

Verifying Integrity

[tbd]