The ISO/IEC TS 27560:2023 Privacy technologies — Consent record information structure provides guidance for the creation and maintenance of records regarding consent as machine-readable information. It also provides guidance on the use of this information to exchange such records between entities in the form of 'receipts'. This document provides a guide for the implementation of machine-readable consent records and receipts as defined in ISO/IEC TS 27560:2023 by using the Data Privacy Vocabulary (DPV). Additionally, this document also provides guidance on using ISO/IEC TS 27560:2023 for meeting EU GDPR requirements regarding consent.
Contributing: The DPVCG welcomes participation to improve the DPV and associated resources, including expansion or refinement of concepts, requesting information and applications, and addressing open issues. See contributing guide for further information.
DPV and Related Resources
[[[DPV]]]: is the base/core specification for the 'Data Privacy Vocabulary', which is extended for Personal Data [[PD]], Locations [[LOC]], Risk Management [[RISK]], Technology [[TECH]], and [[AI]]. Specific [[LEGAL]] extensions are also provided which model jurisdiction specific regulations and concepts . To support understanding and applications of [[DPV]], various guides and resources [[GUIDES]] are provided, including a [[PRIMER]]. A Search Index of all concepts from DPV and extensions is available.
[[DPV]] and related resources are published on GitHub. For a general overview of the Data Protection Vocabularies and Controls Community Group [[DPVCG]], its history, deliverables, and activities - refer to DPVCG Website. For meetings, see the DPVCG calendar.
The peer-reviewed article “Creating A Vocabulary for Data Privacy” presents a historical overview of the DPVCG, and describes the methodology and structure of the DPV along with describing its creation. An open-access version can be accessed here, here, and here. The article Data Privacy Vocabulary (DPV) - Version 2, accepted for presentation at the 23rd International Semantic Web Conference (ISWC 2024), describes the changes made in DPV v2.
Profiles
The following profiles are provided by DPVCG for the implementation of [[ISO-27560]] in different use-cases. They are defined under the namespace: https://w3id.org/dpv/schema/dpv-27560#, prefixed hereafter as dpv-27560:
(Informed) Consent is an important legal basis as it provides control and empowerment to data subjects or users based on the ability to choose and make decisions. Privacy and data protection laws such as [[EU-GDPR]] regulate this process by defining conditions for when consent should be considered Valid Consent. The process of Informed Consent requires information be provided in the form of a Consent Notice to inform the data subject about the processing that will occur based on the consent and to enable them to make an informed choice or decision.
In order to assess whether an instance of given consent is valid thus requires keeping records of information regarding how the consent was obtained i.e. using the notice, and how the consent is being utilised i.e. the processing enabled through that consent. This same information is also required for the organisation to determine whether its processing activities should continue, e.g. depending on whether a particular user has given consent and whether it is still valid (e.g. hasn't expired or wasn't withdrawn). Such information that is documented and maintained regarding consent is called a Consent Record.
Where the information is to be communicated to another entity, it can be provided in the form of a Consent Receipt, which is an authoritative copy of the consent record - similar to how a shopping transaction involves a merchant's copy and a receipt provided to the customer. Such receipts may provide only an acknowledgement of the transaction or also involve specifics of the contents of that transaction. Consent records have been a common practice within organisations for a while now, especially given their requirement in laws such as GDPR Article 7 - however the issuing of consent receipts is a relatively new and under explored activity.
[[[ISO-27560]]] is a Technical Specification (TS) that "specifies an interoperable, open and extensible information structure" for recording the data subject's consent to processing of their personal data i.e. as consent records, and to provide this information i.e. as consent receipts. The specification lists information fields that represent specific information associated with consent, and requirements over the form this information can take e.g. format, number of values, and whether it is mandatory or optional to be present. A [[ISO-27560]] conformant implementation is one that fulfils all requirements by either storing information in the form prescribed by [[ISO-27560]], or by storing information in a form that can be converted or transformed to fulfil its requirements.
[[ISO-27560]] allows for changes to made to the fields, for example to suit and match domain-specific labels or descriptions, or to introduce additional fields or information types that are needed. Such changes, expressed as schemas or profiles, are still required to be compatible with the requirements of [[ISO-27560]], such as by requiring the same fields to be mandatory. This document, referred to as [[DPV-27560]], is a schema or profile of [[ISO-27560]], and is intended to enable the use of [[DPV]] to represent information for the implementation of consent records and receipts.
Lifecycle of Consent
Processing of personal data utilises Consent as one of the possible legal bases. In the current regulatory environment, such consent has to be valid according to several criterion such as being informed, freely given, and being unambiguous. For consent to be informed, the data subject must have been provided or be aware of relevant information regarding the processing of personal data, typically through a Consent Notice, which describes the effect of their decision i.e. if consent is given which processing activities will take place, over which data, and who is involved in terms of entities. Other criterion, such as freely given and being unambiguous is determined through the manner in which this information is presented to request consent and how that consent is expressed.
Once a consent has been given by the individual, they may also have the ability to regulate its use by withdrawing it at a later time. Such termination of consent results in the halting of its associated processing activities. Other causes of termination can be the expiry of duration for which the consent would be considered valid, termination by the Controller, or the consent being declared invalid by an authority such as the court.
Based on these, a lifecycle can be charted regarding the various states that 'consent' can be stated to be in, which is essential to understand which states can be considered 'valid' for the processing of personal data. In the diagram below, consent states begin with a notice being shown to inform the individual and request their consent. Following this, the individual may make the decision to give or grant their consent, or to refuse it. If consent has been given, it can be re-confirmed or re-affirmed to assert its validity, or it can be terminated for several reasons such as its withdrawal by the individual. In all these, only when consent continues to be in a 'given' state can it be used to justify processing.
Lifecycle of Consent, or 'states' associated with consent
Therefore, when creating records of consent - such as to demonstrate compliance, it is essential to not only have information regarding the processing activities governed by that consent, but to also have information which relates to determination of it being valid at a given time. This includes how the notice was provided, the type of consent that was expressed, and to associate these with relevant regulatory requirements that dictate the requirements for validity. In addition, changes to consent must also be recorded, whether they relate to an update to information resulting in a new notice, or the confirmation of an existing consent, or the termination of consent for reasons such as being withdrawn.
Objectives
The following are the objectives of this document:
To introduce [[ISO-27560]] for [[DPV]]] audiences.
To provide a mapping of [[ISO-27560]] to [[DPV]] concepts.
To define [[DPV-27560]] as a schema or profile of [[ISO-27560]] that uses [[DPV]] concepts to represent information.
To provide examples and guidance for the use of [[DPV-27560]].
Scope
The scope of this document is defined as follows:
The implementation of [[DPV-27560]] is limited to information represented within a consent record, and the information on how a notice is provided (beyond a link to the notice) or matching the contents of a notice to that of a consent record is outside the scope of this work. Those interested in notices should refer to the work being developed under [[[DPV-29184]]].
[[DPV-27560]], like [[ISO-27560]] and [[DPV]] is intended to be jurisdiction-agnostic. Use of specific jurisdictional concepts and requirements such as those provided in this document for [[EU-GDPR]] require the use of appropriate DPV extensions such as [[EU-GDPR]].
[[DPV-27560]] is limited to the representation of information as defined by [[ISO-27560]]. The security, communication, and maintenance of this information is outside the scope of this document.
[[DPV-27560]], like [[ISO-27560]], is intended to facilitate interoperability of information and to ensure the required information is available in a form that can be used for its verification of conformance and compliance. Information described using [[DPV-27560]] can be maintained in a compatible form by an organisation for purposes such as alignment with internal terminology, processes, and technologies. Describing such compatible implementations beyond the guidance provided is outside the scope of this document.
Terminology
The terminology used in [[ISO-27560]], [[EU-GDPR]], and [[DPV]] differ in terms or labels used, but largely represent similar semantic concepts. For example, ISO terminology uses PII for Personally Identifiable Information, which is similar to personal data in GDPR and DPV. This guide uses the [[DPV]] terminology unless referring to specific fields or terms used in a particular document. To assist with understanding and applying the terminologies across these three sources, [[[#terms]]] provides a summary table mapping the terms.
Overview of Consent in DPV
The concepts `Consent Record` and `Consent Receipt` are defined in [[DPV]] as `Organisational Measures` to indicate their use in activities involving processing of personal data. This follows the principles of transparency and accountability based on diligent record keeping.
`Consent Status` represents information regarding the stage at which the process of obtaining, using, and maintaining consent is currently at. DPV provides categories of statuses based on practical requirements, for example - `Consent Requested`, `Consent Given`, and `Consent Withdrawn`. To indicate the status of consent, the relation `has Consent Status` is used with the appropriate consent status concept.
To express how consent or an action associated with consent was indicated (or given or obtained), the relation `has Indication Method` is used. To express the time, the relation `is Indication Time` is used. To express the entity expressing the action, the relation `is Indicated By` is used.
To indicate details about the consent, such as which data subject it is about, or the processing activities and entities associated with it, the relevant concepts and relations are to be reused. For example, `has Data Subject` relation with `Data Subject` concept indicates the data subject or individual who is the subject of the consent. Similarly, `has Purpose` with `Purpose` indicates the purpose of processing personal data, and `has Data Controller` with `Data Controller` indicates the entity responsible for the processing. Further information on the concepts and relations relevant to [[ISO-27560]] is summarised in [[[#terms]]], and is provided in [[DPV]] specification.
Overview of 27560
Goals & Scope
[[[ISO-27560]]] has two broad goals: to guide the recording of information about consent for processing of personal data in a form that is interoperable, open, and extendable, and to provide information to individuals. To supplement this, it defines several requirements (as controls in ISO terminology) for ensuring the required information is maintained and is supported by appropriate processes within the organisation. [[ISO-27560]] is stated as a supplement to the earlier [[[ISO-29184]]], where [[ISO-29184]] defines how information is provided via notices in order to request consent, and [[ISO-27560]] defines how information is recorded for given consent and provided back to the individual (as receipts).
The objective of [[ISO-27560]] is to define an information structure for consent record which contains: (1) Information about the processing of personal data; (2) Privacy notices where this information was provided; (3) Sources of data; and (4) Events related to consent (giving, withdrawing, etc.). It also defines an information structure providing all of some of this information to the data subject in the form of a consent receipt. To support implementations, Annex A provides examples of consent records and receipts using [[DPV]], and Annex B provides an overview the different states or stages in 'consent lifecycle' - which are similar to DPV's consent states.
Specific guidance on implementation such as the choice of technologies is not in the scope of [[ISO-27560]], though its Annexes provide informative guidance on related topics. Annex C describes performance and efficiency considerations, Annex D describes format and encoding structures, Annex E describes security of records and receipts, and Annex G describes application in Privacy Information Management Systems (PIMS). Further uses of consent records or receipts, such as how data subjects can obtain consent receipts or maintain their own consent records is not described in [[ISO-27560]].
Consent Records
[[[ISO-27560]]] defines Consent Record as the documentation of information about a data subject's consent for the processing of their personal data in terms of the details about the processing as well as the interactions related to consent (e.g. giving or withdrawing it). Consent Records are an essential part of keeping records regarding whether consent has been obtained and is valid for processing, and to keep this information for correctly conducting processing relying on it. [[ISO-27560]] as well as regulatory requirements such as [[EU-GDPR]] Article 7-1 require maintaining consent records where consent is used as the legal basis. While GDPR Article 7-1 only states that consent should be demonstrable, [[ISO-27560]] provides an information structure for how this information should be maintained and what processes should exist within an organisation in connection with it.
It is important to distinguish between a Consent Record with several relevant but distinct concepts. A consent record only refers to the information recorded regarding consent, whereas a Consent Notice refers to the notice and information provided to the data subject in order to inform them about the processing - such as while requesting consent. While there is a significant overlap between a consent record and a consent notice, there are key differences such as notices orienting information for human consumption (e.g. layering of dialogues to provide summaries and detailed descriptions) and dictating the manner in which consent is expressed (e.g. checkboxes for options and confirmation by clicking a button). In contrast, a consent record is not required to accurately reflect the manner in which this information was presented to the user, but to only record it in a manner that enables assessing whether the consent is given and if so for which processing activities.
This distinction is evident in [[[ISO-29184]]] being the standard for consent notices - which specifies what information should be present in a notice and the manner in which it is presented. In turn, [[ISO-27560]] only refers to notices to limit its scope to representing information necessary within a consent record. Therefore a consent record, despite containing a link to the notice, is not by itself sufficient to determine the validity of consent, and instead acts as the primary record containing information or links to information for conducting such assessments. Its primary purpose is therefore limited to provide an indication of the state of consent (e.g. request, given, terminated) for specific processing activities (e.g. which purpose, what recipients) and to document where additional information can be found on specific matters such as the notice shown when requesting consent.
A [[ISO-27560]] conformant consent record typically has the following sections representing relevant information:
metadata about the consent record such as its identifier
the individual associated with the consent i.e. data subject
the subject of consent i.e. specifics of the processing of personal data
entities involved e.g. data controller and third parties
relevant contextual information e.g. notice, rights, restrictions
provenance of events associated with the consent e.g. given, withdrawn
Under GDPR, the obligation to maintain records of consent is explicitly stated in Article 7-1 and Recital 42. This information includes, at a minimum, the identity of the Controller and the purposes of processing (Recital 42). Further Articles 13 and 14 dictate the information that must be provided to the data subject which includes recipients, transfers to third countries, data storage periods and conditions, existence of rights (including consent withdrawal), and specific information regarding processing such as the use of automated decision making or profiling.
Consent Receipts
[[ISO-27560]] defines a consent receipt as an authoritative document that is used to communicate the existence of a consent record or to provide information contained within it. It is effectively an 'authoritative copy' of a consent record provided by one entity to another, where it may contain all, some, or no information from the consent record regarding the consent and its relevance to processing activities. Such receipts may be useful to communicate the existence of consent decisions, or enable entities to exercise of rights or raise issues and complaint regarding processing activities.
Consent receipts are a relatively newer and under-utilised practice, with no legal requirements existing that refer to the concept (or receipts) or state how they should be used. [[ISO-27560]] follows this by leaving it up to the organisations to decide how they want to implement receipts and what information is be provided through it. It defines a minimal structure consisting of some fields representing the receipt metadata, but does not have any requirements on the information within the receipt or its correspondence to fields within the record.
A [[ISO-27560]] conformant consent receipt only requires a metadata section providing information about the consent receipt such as its identifier. Deciding on which additional information is to be provided and in what forms and using which structures is left up to implementing entities. In this guide, we presume that the consent receipt is intended for providing a copy of all information within the consent record.
According to [[ISO-27560]], records are generated and maintained by organisations (Controller, Third Party), and are utilised to provide receipts to a Data Subject. In contrast, the Kantara Consent Receipt Specification v1.1.0, upon which [[ISO-27560]] is based, defines Consent Receipts as being provided by a Data Subject to a Controller.
For this document and the general use of DPV, we make no presumptions or enact restrictions on the use of records and receipts. Any entity, be it a Controller or a Data Subject, can maintain their own consent record or issue receipts. Though the phrasing of some sections may imply the Controller as the implementing entity, it does not preclude another entity from also implementing [[[ISO-27560]]].
Structure
A Consent Record contains four sections as described below and depicted visually in the figure:
Header: metadata about the record e.g. its unique identifier and timestamp of creation.
Processing: information about the processing activities e.g. purposes, personal data.
Parties: information about entities involved in the processing e.g. controllers.
Events: information about consent events e.g. consent given, consent withdrawn.
Summary of fields in ISO/IEC TS 27560:2023. The field names have been modified for alignment with DPV concepts. Field names in bold are mandatory.
Each section contains fields which describe the information that must be represented along with the form (e.g. timestamp format) and its necessity (e.g. required or optional). Certain fields are expressed as references to other fields (e.g. 'Controller' in 'Processing' section is a reference to an instance or record in 'Parties' section).
The Consent Receipt in [[ISO-27560]] contains only two required fields representing a unique identifier for the receipt and the schema version used for the structuring of information. The information and contents are undefined and left to each implementer to specify. A receipt can optionally contain the entirety of the information within a consent record or can also contain multiple consent records or other information not within a particular consent record. Similarly, a receipt can be made to contain only references to information within a record without containing the information itself e.g. providing only the consent record identifier without the contents of the record itself.
Considering the practical application of consent receipts require them to provide information to data subjects. For the implementation described in this document, it is assumed that the consent receipt provides all information contained within a consent record i.e. a receipt is a copy of the record provided to another entity. This is in line with [[ISO-27560]] guidance which states that the receipt may contain the same fields as that of a consent record, and that the mandatory fields in a consent record are also mandatory in a consent receipt. Further, [[ISO-27560]] allows creating different 'schemas' (which we call 'profiles') to indicate changes in requirements and their interpretations.
Mappings of Terms
ISO 29100:2011 and EU GDPR
The below table provides a mapping between DPV, ISO, and GDPR terminology regarding the basic concepts associated with personal data processing.
The table below provides a comparison between the terms and concepts used in [[ISO-27560]], [[EU-GDPR]], and [[DPV]]. It is neither exhaustive nor authoritative, and is provided as an informative resource to better understand and apply the concepts as they are expressed in the two normative documents ([[ISO-27560]] and [[EU-GDPR]]). The column req.? reflects whether maintaining information on the concept is mandatory or optional. Where the value of this is expressed as a dash (-) it means not applicable to reflect the concept is not present or is covered by another term in the table. Note that for GDPR, the table only reflects the information to be maintained - either directly associated with the consent or elsewhere, and does not cover any specific requirements such as the validity of consent as per Art.4-11 or application of principles in Art.6 as these are outside the scope of [[ISO-27560]].
4-2 processing; 30-2b processing categories; 13-2f, 14-2g, 151-h automated decision making, logic, consequences; 35-1b large scale processing of special categories; 35-1c large scale of processing
The specific version of the schema (`schema_version` in [[ISO-27560]]) used to interpret the record and its information, indicated using dct:conformsTo with the corresponding IRI from [[[#namespaces]]]. Future changes to the schema will result in suffixes to this IRI e.g. `dpv-27560-v2`. To indicate conformance with specific requirements such as from GDPR, a separate schema or profile IRI must be utilised, as seen in [[[#profiles]]].
Record Identifier
This field MUST be present.
The unique identifier (`record_id` in [[ISO-27560]]) associated with this record, indicated using dct:identifier. This can be a [[ISO-27560]] recommended UUID-4 string or an IRI.
Even if the IRI or `@id` field represents a unique identifier, this information must be specified using `dct:identifier` as the IRI may refer to a copy or alternate location of the same record.
Data Subject
This field MUST be present.
The data subject (`pii_principal_id` in [[ISO-27560]]) associated with the consent (record), indicated using dpv:hasDataSubject. The data subject can be represented by an instance of dpv:DataSubject or an identifier.
Additional Metadata
Information such as who maintains or published the record, when was it created or modified, and its provenance is not covered by [[ISO-27560]] as it is considered "implementation detail". To assist in maintaining this information, the following fields from [[DCT]] are suggested for documenting this information in an optional and non-normative manner:
dct:accessRights: information on who can access the consent record.
dct:contributor: entity or entities that have contributed to the information within the consent record.
dct:created: date/time for when the consent record was created.
dct:creator: entity that created the consent record. NOTE: this entity may be different from the publisher of the consent record, e.g. a processor (creator) manages the record for a controller (publisher).
dct:hasPart (with inverse dct:isPartOf): to associate with a part of the consent record, e.g. where the information in a consent record may be maintained separately or partitioned based on common information for efficiency.
dct:hasVersion (with inverse dct:isVersionOf): to associate one consent record with its updated version, e.g. where each event in a consent record results in a new consent record.
dct:replaces (with inverse dct:isReplacedBy): to associate the consent record which is being replaced, e.g. where the other consent record is no longer in use and this is a new consent record intended to replace it.
dct:issued: date/time associated with 'formal issuance' of the consent record, e.g. where dct:created is a timestamp for when the record was generated by a machine agent and where dct:issued captures its formal acceptance as a legally relevant record.
dct:modified: date/time for when the consent record was modified.
dct:provenance: information about the provenance of the consent record, e.g. where the record has been transferred between entities.
dct:publisher: entity or entities that 'publish' the consent record i.e. make it available within some contextual sense, e.g. to produce it within an audit or legal investigation.
dct:source: information on the sources used within the consent record, e.g. other records or logs that should be associated to record the provenance of information.
dct:valid: date/time until when this record can be considered valid. NOTE: this refers to assessing validity of the record as a whole and does NOT refer to validity of consent events or the processing specified within the record.
Further, the use of [[[vocab-dcat-3]]] is also recommended to store consent records and receipts as it assists with metadata fields (see above) as well as expressing relations between collections of records/receipts (i.e. catalogues) and relations between datasets (e.g. latest version). See technical considerations.
Notice Fields
These fields refer to information about the notice that has been shown to request consent. In [[ISO-27560]], these fields are part of the Processing section.
Reference to the specific version of the notice (`privacy_notice` in [[ISO-27560]]) associated with consent, indicated using `dpv:hasNotice` and a reference to the notice or an instance of `dpv:ConsentNotice`. If there are multiple notices - then each must be indicated separately. Multiple notices can be associated where such notices are part of the same context e.g. shown one after the other, or where they are associated over time, e.g. one notice shown initially when requesting and another when re-confirming it at a later time.
In DPV, the concepts `dpv:PrivacyNotice` and `dpv:ConsentNotice` have different intended meanings - a consent notice is a specific privacy notice associated with consent, most commonly providing information in order to request consent. Whereas, a privacy notice can also refer to other documents providing information, such as what is commonly called as 'privacy policy'. For the purposes of the consent record, both documents can be included, but `dpv:ConsentNotice` MUST be used when referring to the notice used for providing information for consent.
Notice Language
This field MUST be present.
The language used in the communications regarding consent, such as the information provided within a notice. The language is indicated using `dct:language`, and it is recommended to use standardised notations for representing languages such as the ISO 639.
For examples, please refer to [[[#notice]]] section.
Processing Fields
[[ISO-27560]] contains 22 fields related to processing activities, and 5 additional fields regarding personal data involved in processing. The structuring of these fields within [[ISO-27560]] is of the form where the "PII Processing" section contains an array of "purposes" where each "purpose" is expressed with its own fields regarding legal basis, collection method, storage locations, and so on. Within the DPV implementation, this is replaced with dpv:Process so that each instance represents a distinct processing activity with its fields e.g. purposes, personal data, recipients.
`dpv:Process` is a concept that represents a process or 'unit' for combining relevant details such as purposes, processing, personal data categories, recipients, and so on. Instances of `dpv:Process` can be used to differentiate between information regarding processing - such as where different purposes are used or that lead to different recipients. Such instances can also be nested within other instances to create a 'modular' structuring of processing activities.
Following the [[ISO-27560]] model requires creating a concept called 'purposes' and to utilise an array or a list to hold the associated 'purpose' instances. Given that DPV prefers a strict taxonomy expressed in a graph representation, following the same model would lead to non-intuitive structures. Further, other similar lists such as those for 'pii_type' also require creation of new concepts to represent groups or collections of the actual intended concepts.
Purpose
This field MUST be present.
The purpose of processing personal data, expressed in DPV using hasPurpose as an instance of Purpose.
[[ISO-27560]] has an additional field called 'purpose_type' that describes the category of the purpose. This is expressed using `skos:broader`. For additional information, such as descriptions, relevant DCT relations should be used.
Where multiple purposes are present within the same or single context, for example the consent record or a personal data handling instance, the interpretation is that they are all applicable for that context. For example, if a personal data handling instance contains 3 purposes - then it is presumed that the consent is for carrying out each of the 3 purposes.
To declare that ALL purposes must occur together i.e. they cannot be carried out independently, the appropriate semantic relations should be used to express this information - for e.g. by declaring the 3 required purposes as the 'type' for a new combined purpose.
Caution is advised when modelling consent as jurisdictional requirements such as those from GDPR e.g. Recital 32 states "Consent should cover all processing activities carried out for the same purpose or purposes. When the processing has multiple purposes, consent should be given for all of them.". This means all purposes listed within a record pertaining to a single consent are to be used with that single consent as the legal basis.
Personal Data
This field MUST be present.
The personal data ('pii information' in [[ISO-27560]]) involved in processing activities, associated using dpv:hasPersonalData and instances of dpv:PersonalData.
In [[ISO-27560]], the personal data fields are used to describe aspects of personal data as - type, identifier, optionality, being sensitive and being special category. In the DPV implementation, these are described as annotations or additional relations over the personal data instance.
Personal Data Type
This field MUST be present.
The type or category of personal data ('pii type' in [[ISO-27560]]), expressed in DPV using `skos:broader`, and optionally using concepts from the [[PD]] taxonomy. The value for this field must use a data category from DPV either through an explicit declaration i.e. using `skos:broader` or through an implicit definition e.g. [[PD]] taxonomy.
Personal Data Identifier
This field MAY be present.
The identifier representing the data values or instances e.g. within a database, expressed in DPV using dct:identifier.
Personal Data Necessity
This field MAY be present.
The necessity or optionality of this data ('pii optional' in [[ISO-27560]]) for the processing, expressed in DPV using hasNecessity and one of the provided instances of Necessity. If this field is absent, it should be inferred as the data being necessary.
Sensitive and Special Category
This field MAY be present.
Indicates whether the personal data is considered sensitive ('sensitive pii category' in [[ISO-27560]]), and separately whether it is also of special category ('special pii category' in [[ISO-27560]]). Declaring either in DPV is done using `skos:broader` with value SensitivePersonalData or SpecialCategoryPersonalData. Its absence indicates the data does not belong to either sensitive or special categories.
Processing Operations
This field MAY be present.
Indicates the processing operations or activities carried out over the specific personal data, and indicated using dpv:hasProcessing with instances of dpv:Processing. In [[ISO-27560]], this field also represents information about automated decision making - which is represented in DPV through the dpv:AutomationOfProcessing concepts and associated with dpv:hasProcessingAutomation, as well as large scale of processing which is represented through dpv:ScaleOfProcessing and associated using dpv:hasScale.
Data Source(s)
This field MAY be present.
This field represents the source of data being processed. In [[ISO-27560]], this field is called collection method and can be about The data provided by or observed from activities of the data subjects, be inferred from existing data, or be collected from another entity or third party. In DPV, this information is represented using dpv:DataSource and associated using dpv:hasDataSource.
Concepts within the DPV taxonomy have an exact meaning - for example data being obtained through observation should not be stated as being collected, but as observed - even if the data source is still the same data subject. Therefore, it is best to separate the data source entity and the processing operation.
Storage Condition(s)
This field MUST be present.
Indicates information about the storage of personal data such as regarding its duration, location, and erasure, represented using dpv:StorageCondition and associated using dpv:hasStorageCondition. The existence of Storage Condition implies storing data as a processing operation. In [[ISO-27560]], this information is represented through two fields - storage locations and retention period - both of which are required to be present.
Processing Condition(s)
This field MAY be present.
Indicates information about conditions regarding the processing operations, such as regarding its duration and location, represented using dpv:ProcessingCondition and associated using dpv:hasProcessingCondition. Given that storing data is a specific type of processing operation, this field is useful for other processing activities such as collection of data. In [[ISO-27560]], the field only relates to processing locations.
Geographic Restriction(s)
This field MAY be present.
Geographic restrictions are defined in [[ISO-27560]] as restrictions related to geo-locations or jurisdictions. While DPV prefers a declarative interpretation where, for e.g., if processing location is mentioned as EU then it implies that processing will only take place within EU since no other locations are mentioned. If the intention is to explicitly state this as a restriction, it can utilise the dpv:Rule concept which provides (simplified) Permissions, Prohibitions, and Obligations. For further expressiveness of complexity, specifications such as [[[odrl-model]]] should be considered.
Note that while [[ISO-27560]] only considers restrictions over geographic locations for processing (including storing), DPV (and ODRL)support specifying information and restrictions over a much wider range of concepts. In theory, restrictions can be expressed over any concept or combination of concepts.
Data Controller(s)
This field MUST be present.
Indicates the Data Controllers (pii controllers in [[ISO-27560]]) responsible for the specified processing activities, expressed in DPV using hasDataController with instances of DataController.
Note that the notion of a 'Controller' is regarding accountability, and does not necessarily correlate with who performs the processing or has access to data - for example in GDPR. To indicate who performs the processing, DPV provides dpv:isImplementedByEntity.
Information about the Data Controller, such as its name or address, is described through the Entity Fields later in the document based on a similar structure in [[ISO-27560]].
Legal Basis
This field MAY be present.
The legal basis (lawful basis in [[ISO-27560]] for processing of personal data. Though the lawful basis for a consent record would always be consent, the presence of the field enables extensions of the record to other legal bases (e.g. contract) in the future. In DPV, the legal basis is associated using hasLegalBasis with a concept from the LegalBasis taxonomy.
In addition to defining consent as a legal basis, DPV also provides a taxonomy to express various categories of consent - such as InformedConsent and ExpressedConsent which provide a more granular and accurate definition of the legal basis being utilised. For expressing specific consent based on specific jurisdictions and regulations, the appropriate extended concept should be used, for e.g. [[EU-GDPR]] extension defines consent as a legal basis based on the specific clauses and requirements of the [[GDPR]].
Recipients
This field MUST be present.
Indicates the recipients of personal data associated with the specific processing activities, expressed as dpv:Recipient and associated using dpv:hasRecipient. In [[ISO-27560]], this field is only limited to Recipients who are Third Parties, which excludes the Data Controllers and Processors. In DPV, recipients can be any of Data Controllers, or Processors, or Third Parties.
Note that recipients can be specific entities i.e. their identity is known, or groups or categories of entities - for example as in GDPR's Article 13-1e. However, [[ISO-27560]] only considered explicitly indicated third parties for the recipients field.
In [[ISO-27560]], the recipient field is also associated with information regarding the geo-location of data being transferred to the recipient third party's and whether this constitutes a jurisdictional change. To represent this in DPV, the location of the transfer should be indicated within the processing information along with the recipient entity. The jurisdiction can also be represented in the same context - to indicate the transfer to that jurisdiction, or it can be specified in association with the recipient entity.
Consent Change & Withdrawal
This field MUST be present.
Indicates the information on how the data subject can change or withdraw the specified consent. This is done by expressing information using `dpv:ConsentControl` and `dpv:hasConsentControl`. DPV provides specific involvement controls for consent as `dpv:ProvideConsent`, `dpv:WithdrawConsent`, `dpv:ObtainConsent`, and `dpv:ReaffirmConsent`. To indicate how the data subject should take action, the relation isExercisedAt is to be used.
In [[ISO-27560]], this field is specific to the withdrawal method or a link to the information on withdrawal. It also allows this field to be associated with the Data Controller (in the Party/Entity section) rather than per-processing activity.
Jurisdiction(s)
This field MUST be present.
Indicates the applicable jurisdiction for the processing indicated within the receipt. The acknowledgement of jurisdiction(s) is necessary to convey applicable laws and requirements regarding consent validity and applicable rights as well as indicating the obligations on parties involved. To indicate the jurisdiction, the concept Location is to be associated using hasJurisdiction. The [[LOC]] extension can be used for this which provides a list of locations based on ISO-3166.mm
In [[ISO-27560]], this field can also be associated with the Data Controller (in the Party/Entity section) rather than per-processing activity.
Rights
This field MUST be present.
Indicates the applicable rights and provides information on how to avail or exercise them. The rights are indicated using DataSubjectRight and associated using hasRight. To indicate how to exercise them, the relation isExercisedAt is to be used. To indicate provision of information regarding rights exercise, the concept RightExerciseNotice is to be used and associated using hasNotice.
In [[ISO-27560]], this field is optional, and is used to provide a link to information on how to exercise rights. It also allows this field to allow changes to the consent conditions such as the retention period. In [[ISO-27560]], this field can also be associated with the Data Controller (in the Party/Entity section) rather than per-processing activity.
Service(s)
This field MAY be present.
Indicates the services the described processing activities are a part of or assist with, expressed as an instance of dpv:Service and associated using dpv:hasService.
In [[ISO-27560]], a Service can be as broad or granular as desired. A service is related to a purpose by providing a context through which the specific purpose can be understood within their context, and also to enable related purposes and activities to be associated and explained with a common service being provided.
Code of conduct(s)
This field MAY be present.
Indicates the applicability of a Code of Conduct for the specified processing activity. A code of conduct is a voluntary set of rules and responsibilities undertaken by an organisation. It is indicated using an instance of dpv:CodeOfConduct and associated using dpv:hasOrganisationalMeasure.
In [[ISO-27560]], this field is described as providing information regarding the name of the code of conduct and a publicly accessible reference to it. A code of conduct can also be associated with the Data Controller (in the Party/Entity section) rather than per-processing activity.
Impact assessment(s)
This field MAY be present.
Indicates the existence of an Impact Assessment for the specified processing activity. An impact assessment in this record refers to the impact of the specified processing activities on the data subject. Impact assessments are indicated using instances of dpv:ImpactAssessment and associated using dpv:hasAssessment. DPV provides concepts for specific types of impact assessments, such as dpv:PIA for Privacy Impact Assessment and dpv:DPIA for Data Protection Impact Assessment.
In [[ISO-27560]], this field is limited to assessments of privacy risks and potential impacts of "non-compliance" on the data subjects, whereas in common practice assessments such as PIA and DPIA concern the impact of the processing on the data subject - which is what DPV and this specification considers. Impact assessments can also be associated with the Data Controller (in the Party/Entity section) rather than per-processing activity.
Entity Fields
[[ISO-27560]] refers to Entity as Party.
Entities are expressed using instances of dpv:Entity and associated using dpv:hasEntity.
Indicates the legal name and identity of the Entity, expressed using dpv:hasLegalName and a string.
Identifier
This field MUST be present.
Indicates the unique identifier for the entity within the record. In linked data and semantic web methods of expressing information, the IRI already acts as an unique identifier. To support interoperability, the IRI identifier MUST be declared explicitly using dpv:hasIdentifier. To denote other (unique or otherwise) identifiers as a reference to the entity, dct:identifier should be used.
In this specification and in [[ISO-27560]], the (IRI) identifier is used to associate the entity with specific processing roles, which is described in the next section.
Role
This field MUST be present.
Indicates the role of the entity within the process activities, indicated using `rdf:type` and an appropriate role such as dpv:DataController, dpv:DataProcessor, dpv:ThirdParty, dpv:Authority, and dpv:DataSubject.
In [[ISO-27560]], the entity (party) fields are separate from the processing section and therefore the role of the entity is expressed separate from processing. In DPV, the role MUST be expressed contextually within the processing fields by using an appropriate property e.g. dpv:hasDataController and the identifier of the entity. Optionally, the entity description field can also contain an explicit acknowledgement of the role by stating the entity is of type e.g. dpv:DataController.
Contact
This field MUST be present.
Indicates the contact for an entity for communication purposes, indicated using schema:contactPoint and an instance of schema:ContactPoint.
NOTE: As in [[ISO-27560]], this field MUST be present for all entities EXCEPT data subjects as in a record it may not be necessary to record the contact for data subjects. This follows best practices regarding data minimisation and purpose limitation.
Postal Address
This field MUST be present.
Indicates the potal address of the entity, expressed using schema:address and an instance of schema:PostalAddress.
NOTE: As in [[ISO-27560]], this field MUST be present for all entities EXCEPT data subjects as in a record it may not be necessary to record the postal address of data subjects. This follows best practices regarding data minimisation and purpose limitation.
Email
This field MAY be present.
Indicates the email of the entity, expressed using schema:email.
Phone
This field MAY be present.
Indicates the telephone of the entity, expressed using schema:telephone.
URL
This field MAY be present.
Indicates the URL of the entity, expressed using schema:url. The type of the page can be expressed using appropriate concepts, such as dpv:PrivacyNotice.
Consent Event Fields
[[ISO-27560]] contains 5 fields to describe events associated with consent.
Indicates the type of consent (e.g. Implicit, Expressed, Explicit) expressed by the data subject. In [[ISO-27560]], this field is called event type.
In DPV, dpv:ConsentType represents consent types to be used as a legal basis (dpv:hasLegalBasis) and has the following different types:
dpv:InformedConsent and dpv:UninformedConsent to indicate whether the consent is informed or not. Informed consent is further specialised as: dpv:ImpliedConsent for consent indicated through an implied or indirect action (e.g. merely browsing a website), dpv:ExpressedConsent for consent indicated through a direct expressed action (e.g. a checkbox), and dpv:ExplicitlyExpressedConsent for consent indicated through a direct action concerning solely the consent in context.
Consent types are also dependent on jurisdictional requirements, such as GDPR's various consent types. These can be represented by expanding on the relevant DPV concepts. For GDPR, the following consent types are provided in [[EU-GDPR]]: eu-gdpr:A6-1-a expressed consent and eu-gdpr:A9-2-a explicit consent.
Best practice for choosing appropriate consent types concern expressing the correct legal basis for a specific jurisdiction where possible (e.g. GDPR A.6-1a) or to indicate the type of consent (e.g. Expressed Consent) where the jurisdiction is explicitly provided or is understood from available context. Following this, the most appropriate consent types for most cases would be dpv:ExpressedConsent and dpv:ExplicitlyExpressedConsent.
Consent State
This field MUST be present.
Indicate the state or status of consent reflecting its applicability or suitability to be used as a legal basis to justify the specified processing. In DPV, it is represented through dpv:ConsentStatus and associated using dpv:hasConsentStatus. Instances of consent states represent specific events concerning the use of consent as a legal basis, e.g. requesting consent, giving consent, withdrawing consent. Each event may have corresponding processes, such as giving consent enables the processing to take place and withdrawing consent stops the processing taking place.
DPV provides several states broadly categorised under those valid for processing and those that are not. These are:
The consent states that are considered valid for processing (dpv:ConsentStatusValidForProcessing) are: dpv:ConsentGiven, dpv:RenewedConsentGiven.
The consent states that are NOT considered valid for processing (dpv:ConsentStatusInvalidForProcessing) are: dpv:ConsentUnknown, dpv:ConsentRequested, dpv:ConsentRequestDeferred, dpv:ConsentRefused, dpv:ConsentWithdrawn, dpv:ConsentExpired, dpv:ConsentTerminated, dpv:ConsentInvalidated.
Event Time
This field MUST be present.
The time of the associated event (e.g. giving consent, withdrawing consent), indicated using dpv:isIndicatedAtTime. [[ISO-27560]] defines this field as the time the event was expressed or exercised by the specified entity (e.g. when data subject gave consent), and requires this field use a value as per [[ISO-8601]] UTC time to declare the timestamp associated with the event.
Event Duration
This field MUST be present.
Indicates the duration or the condition for determining validity of the duration for the event. It is indicated using dpv:Duration and associated using dpv:hasDuration. DPV provides the following duration concepts:
TemporalDuration for indicating a relative temporal duration, e.g. 6 months from the indicated event date.
UntilTimeDuration for indicating duration that occurs until the end of specified time, e.g. until 31 DEC 2023.
UntilEventDuration for indicating duration that occurs until the end of specified event, e.g. until account is closed.
FixedOccurrencesDuration for a duration that is based on number of occurrences, e.g. using it 3 times
EndlessDuration for indicating a duration without an end condition or temporal notation. Note that endless duration is not considered best practice and is considered invalid in several jurisdictions.
[[ISO-27560]] specifies that where the duration relates to the validity of given consent, the duration also indicates that the Data Controller should request the data subject to confirm or 'refresh' their consent without which the consent cannot be valid for processing.
Expression by Entity
This field MUST be present.
Indicates which entity or agent (party in [[ISO-27560]]) exercised or expressed the specified event. For example, if it was the data subject or their guardian who expressed the given consent. In DPV, this is indicated using the appropriate dpv:Entity concept and associated using dpv:isIndicatedBy.
In [[ISO-27560]], this field is called entity id and is used to link to the relevant entity through their identifier (e.g. data subject identifier or to an entry in the party section). As this field MUST be present in [[ISO-27560]], the most common value expected here will be a reference to the data subject. In DPV, this can also be indicated using dpv:DataSubject instead of the identifier.
Expression Method
This field MAY be present.
Indicates how the specified entity expressed or exercised the indicated event, e.g. a data subject clicked the button to give consent. This field is not present in [[ISO-27560]], but is considered best practice to document so as to record information relevant to the assessment of consent validity and legal compliance. In DPV, it is associated using dpv:hasIndicationMethod.
Examples
DPV-27560 Consent Receipts
[[ISO-27560]] only defines the schema version and receipt identifier fields for consent receipts. For other fields, it recommends using the same fields as that of a consent record. In its guidance, it states that the mandatory fields in consent records should also be mandatory in receipts. Based on this, we only define the additional fields for consent receipts and suggest reusing the consent record fields with their necessity/conditionality as indicated in the document.
The specific version of the schema (`schema_version` in [[ISO-27560]]) used to interpret the record and its information, indicated using dct:conformsTo with the corresponding IRI from [[[#namespaces]]]. Future changes to the schema will result in suffixes to this IRI e.g. `dpv-27560-v2`. To indicate conformance with specific requirements such as from GDPR, a separate schema or profile IRI must be utilised, as seen in [[[#namespaces]]].
Record Identifier
This field MUST be present.
The unique identifier (`record_id` in [[ISO-27560]]) associated with this consent receipt, indicated using dpv:hasIdentifier. This can be a ([[ISO-27560]] recommended) UUID-4 string or an IRI.
Associated Consent Record
This field MUST be present.
The information to be provided within a consent receipt is in the form of consent records, which are associated using dpv:hasRecordOfActivity.
Creation Timestamp
This field MUST be present.
Indicates the date/time for when the receipt was generated, indicated using dct:created. NOTE: This field is not present in [[ISO-27560]].
Additional Metadata
Information such as who maintains or published the receipt, when was it created or modified, and its provenance is not covered by [[ISO-27560]] as it is considered "implementation detail". To assist in maintaining this information, the following fields from [[DC-TERMS]] are suggested for documenting this information in an optional and non-normative manner:
dct:audience: information on entity or entities for whom the receipt is intended or produced for - this will typically be the Data Subject.
dct:accessRights: information on who can access the consent receipt, or to specify information regarding the security measures in place restricting access to information within the receipt.
dct:contributor: entity or entities that have contributed to the information within the consent receipt.
dct:creator: entity that created the consent receipt. NOTE: this entity may be different from the publisher of the consent receipt, e.g. a processor (creator) manages the receipt for a controller (publisher).
dct:hasPart (with inverse dct:isPartOf): to associate with a part of the consent receipt, e.g. where the information in a consent receipt may be maintained separately or partitioned based on common information for efficiency.
dct:hasVersion (with inverse dct:isVersionOf): to associate one consent receipt with its updated version, e.g. where each event in a consent receipt results in a new consent receipt.
dct:replaces (with inverse dct:isReplacedBy): to associate the consent receipt which is being replaced, e.g. where the other consent receipt is no longer in use and this is a new consent receipt intended to replace it.
dct:issued: date/time associated with 'formal issuance' of the consent receipt, e.g. where dct:created is a timestamp for when the receipt was generated by a machine agent and where dct:issued captures its formal acceptance as a legally relevant receipt.
dct:modified: date/time for when the consent receipt was modified.
dct:provenance: information about the provenance of the consent receipt, e.g. where the receipt has been transferred between entities.
dct:publisher: entity or entities that 'publish' the consent receipt i.e. make it available within some contextual sense, e.g. to produce it within an audit or legal investigation.
dct:source: information on the sources used within the consent receipt, e.g. other receipts or logs that should be associated to receipt the provenance of information.
dct:valid: date/time until when this receipt can be considered valid. NOTE: this refers to assessing validity of the receipt as a whole and does NOT refer to validity of consent events or the processing specified within the receipt.
Further, the use of [[[vocab-dcat-3]]] is also recommended to store consent records and receipts as it assists with metadata fields (see above) as well as expressing relations between collections of records/receipts (i.e. catalogues) and relations between datasets (e.g. latest version). See technical considerations.
Information in Receipt
[[ISO-27560]] states the receipt can contain and provide the same information as the consent record it is associated with. It also states that the fields indicated as required for consent records are also required within consent receipts. Since receipts are intended to provide information already documented within a consent record, the same fields and information can also be used to create and provide a receipt. However, to enable the receipt to be a broader communication mechanism also capable of providing relevant information in future (e.g. exercised rights), the DPV's receipts are instead a 'wrapper' around a consent record.
Examples
Considerations
Security and Privacy
Security considerations are extremely important in the implementation
of consent records and receipts, with ISO-27560 Annex E providing
guidance for implementations. Consent records are intended to be
maintained internally by an entity, and require measures to ensure they
maintain their consistency and correctness, and are not tampered with.
This includes best practices for information management such as using
cryptographic hashes to ensure information has not changed, or using
access control to ensure only authorised modifications are permitted.
Current internationals standards such as [[[DID-core]]] and [[[VC-data-model-2.0]]] allow for implementations
compatible with the implementation of ISO-27560 using DPV as all are
based on interoperable semantic web standards.
For consent receipts to be utilised in a verifiable and trustworthy
manner, the information provided within the receipt may require
cryptographic measures to provide assurance to prove its immutability
and non-repudiation. Further, receipts are intended to be information
provided or exchanged between different entities, which may necessitate
a mechanism to demonstrably verify the provenance (e.g. a receipt was
provided by A to B) and its immutability (e.g. receipt contained X
exactly). Cryptography techniques such as digital signatures and
certificates can support such applications based on their current
utilisation in internet-enabled applications and documentations. Prior
work such as Consent Receipts for a Usable And Auditable Web of Personal Data by Jesus and Pandit (2022) and project outcomes such as NGI funded Privacy as Expected: Consent Gateway have explored such considerations,
but effective implementation requires consensus amongst stakeholders to
create an interoperable ecosystem.
Given the role of consent records and receipts in demonstrating
consent decisions, they may end up with potentially sensitive
information. ISO-27560 recommends not putting such information directly
in records and receipts, and if necessary then implementations should
utilise techniques such as information masking or pseudonymisation to
avoid directly exposing sensitive information. - though this has to be
balanced with the purpose of receipts in providing data subjects with
information about their consent.
Supporting GDPR and DGA
Using ISO-27560 and ISO-29184 within the EU legal
framework: ISO-27560 and ISO-29184 are developed and governed
by the International Standards Organisation (ISO), and are not specific
to EU’s regulations and terminology. To support their use in the legal
frameworks, they need to be approved as ‘Euronorm’ (EN) through an EU
standardisation body such as CEN, CENELEC, or ESO. At the moment,
ISO-29184 has already been approved as EN, and we are working on a
proposal with the Irish and Swedish national bodies to recommend the
adoption of ISO-27560 as EN. Further, we have also submitted a proposal
to the relevant ISO committees to make ISO-27560 standard freely
accessible as its guidance is valuable for responsible innovation.
Having these standards as EN provides a strong framework for their
utilisation in regulations, such as for notice and consent under GDPR.
However, merely adopting the standards on an ‘as-is’ basis will not be
sufficient. For example, the terminology in 29184 and GDPR has crucial
differences which must be identified and appropriate guidance developed
to enable using ISO-29184 with GDPR. Similarly, to address current
issues regarding consent
and further studies are required to assess the extent of these standards
in solving existing issues and what additional measures need to be
adopted beyond conformance with the standards.
Demonstrating consent under GDPR: GDPR Article 7-1
creates an obligation for data controllers to maintain consent
information and to keep it up to date with the goal of demonstrating
where consent was given, refused, or withdrawn. ISO-27560 provides a
standard for a common technical structure to support implementing this
obligation. In addition to this, GDPR Article 13 and Article 14, amongst
others, also require record keeping for what information was provided to
individuals in order to implement informed consent. ISO-29184 provides a
standard for describing privacy notices, and together with ISO-27560
enables maintaining records of what information was provided and the
resulting consent decisions. Based on the analysis provided in this
article that demonstrates applicability of ISO-27560 and ISO-29184 to
GDPR, we recommend authorities to suggest using these standards to
support GDPR compliance.
Receipts to support rights under GDPR: ISO-27560
contains fields for acknowledging which rights exist, and with DPV we
can express how/where to exercise them and what information will be
required (e.g. identity verification). Further, consent decisions (e.g.
given, withdrawn) are themselves also personal data about the data
subject, and therefore subject to rights such as Art.20 data
portability. This can be a way to enable the use of receipts under GDPR
even where it is not explicitly defined as a concept by considering
consent information as personal data. Considering consent
information as personal data makes it subject to the right to data
portability under Article 20 which requires providing information “in a
structured, commonly used and machine-readable format”. Further, Article
20 also allows “ the right to transmit those data to another
controller”, which can be utilised to transfer consent decisions from
one controller to another - a crucial mechanism for the implementation
of data reuse and altruism under DGA.
Common consent form under DGA: Article 25 of the DGA
requires the Commission to produce a common consent form that will
provide information in both human- and machine-readable forms. ISO-27560
with ISO-29184, based on the analysis in this article demonstrating
their usefulness to meet GDPR requirements, should be used to define
what information should be present in these forms. ISO-29184 as the
standard for privacy notices provides the human-oriented representation
of information in the consent form, and ISO-27560 and the DPV
implementation provide the machine-readable representation. The
advantage of using these standards is that the resulting solution would
be useful not only in EU but globally due to the global scope of ISO.
The advantage of using DPV here is in providing common semantics based
on W3C standards that support extensions for specific jurisdictions
(like EU with GDPR and DGA) and its extensive taxonomy supporting
practical use-cases which promote interoperability. Through
direct meetings, we have presented this work to the EU Commission’s Unit
G.1 which looks after GDPR and DGA implementations.
Data Intermediaries under DGA: We are also working
on further implementations to support DGA by developing specific
technical specifications that define how data intermediaries should
maintain consent records and issue receipts, and support them in their
duties by providing a way to express data reuse requests in a
machine-readable form that can be matched with the consent to ensure the
purposes are compatible in accordance with the GDPR. This will be based
on existing work that utilises the
W3C Open Digital Rights Language [[ODRL-model]] standard for representing
policies and agreements, and using it in combination with DPV to create
DGA specific offers for data subjects and data intermediaries
to indicate which data is available for reuse and under what conditions,
requests for data users to indicate what data they are
looking for, and agreements to represent the conditions under
which data reuse has been approved. We have already demonstrated the
feasibility of using ODRL and DPV for such an approach in a manner that
improves both technical and organisational processes for the use-case of
sharing genomic health datasets.
Data Reuse and Altruism under DGA: To support the
DGA’s goals of reusing data for altruism, we are working on creating a
taxonomy of altruistic purposes within DPV and developing a framework to
express them in a manner that is compatible with GDPR’s requirements for
consent and information keeping based on ISO-27560. We are also working
on novel approaches such as assessing the compatibility of ISO-27560
defined consent records with information required in a Data Protection
Impact Assessment (DPIA), through which we aim to enable data subjects
or data intermediaries to conduct their own DPIAs based on a common
registry of risks and mitigations provided through the DPV. Through this
we aim to establish responsible practices while promoting data reuse and
altruism.
Using Records and Receipts with eIDAS and EUDI Wallet
Following the launch of projects for using European Digital Identity
wallet (EUDI) wallet for travel, health, banking,
education and other sectors, CEN TC224 WG20,
which is the EU standardisation body’s technical committee for personal
identification, has initiated a new standards project to provide
guidance on when personal data (attributes) are shared from the wallet
in compliance with eIDAS and its proposed revision.
In this, [[ISO-27560]] and [[ISO-29184]] can be used to create an
interoperable and standards based mechanism to structure information and
ensure the mandatory fields needed to comply with GDPR are present.
Further, the use of these standards also enables a consistent approach
for creating common privacy dashboards that can work across EU. Such
privacy dashboards would allow a wallet holder to have an overview of
all their consent transactions, including any pending requests as well
as provide a centralised mechanism for controlling their rights and
withdrawing consent by using the eIDAS and eID mechanisms to establish
identity and proof of past engagement.
ISO-27560 and ISO-29184 are also crucial as being the only standards
regarding consent records and receipts, and privacy notices
respectively. Using the analysis and implementations described in this
article, a ISO-27560 solution that is also conformant with the GDPR can
be used to store consent records and receipts in wallets, which enables
data subjects to have a copy of their decision and agreement to process
personal data.
Having this information made available to the data subject in a
machine-readable format further enables its use in innovative
applications that promote reuse of data while ensuring adequate
adherence to the EU’s values and regulations. For example, by looking at
past consent records or receipts, preferences can be identified for how
the individual makes decisions and these can be used to create a
template or pattern that will make future consent decisions more
efficient and simpler for the individual. ISO-27560 Annex F provides
guidance on how such preferences used as ’privacy signals’ can be
represented within consent records and receipts.
Another powerful paradigm is also made possible when combining
ISO-27560 with eID, eIDAS, and EUDI - where the data subject initiates
the consent process by providing a specific consent to use or reuse
their personal data, for example to access a particular service. In this
scenario, the data subject decides the extent and limit of what their
consent will cover, provides their consent to the service provider, and
maintains a consent record within their wallet with a signed receipt
provided to the service provider as proof of consent.
Technical Considerations in Managing Records and Receipts
We can use the [[[vocab-dcat-3]]], a W3C standard, to represent the records as datasets and receipts as a catalogue of records. By doing so, the metadata fields provided by DCAT can be readily used to represent information that supports in maintenance and exchange of consent records and receipts, including using existing infrastructure to manage them. DCAT is a widely used standard that supports implementing (open) data portals and has tooling for discovery and management of information. The EU has developed the [[[DCAT-AP]]] [[DCAT-AP]] which extends DCAT to support the EU Open Data Portals.
Through these records and receipts can be readily communicated as interoperable datasets between relevant entities - for example controller to data subject, or between controllers and third parties. This is a crucial technical enabler for the principle of increasing data value through utilisation within the Data Governance Act and Data Spaces. In particular, the use of DCAT(-AP) also supports the addition of further policies and measures to support the implementation of data intermediaries which will be required to maintain consent records under the obligations of the DGA.
Changelog and Errata
15 August 2024
Changed InvolvementControl (which doesn't exist) to ConsentControl (which is what was added in DPV 2.0). This change affects ISO 27560:2023, EU GDPR, and DPV comparison table, Processing Fields table, Consent Change & Withdrawal section, Example 19: Example specifying change and withdrawal of consent, Example 39: Example of a Consent Record with only the required fields, Example 40: Example of a Consent Record with both required and optional fields, Example 46: Example of a Consent Receipt with information from required fields in a consent record.
Removed `dct:type` in favour of `rdf:type` and directly using the DPV concepts following changes made in DPV 2.0.
Added note in Purpose field section describing use of `rdf:type` and `skos:broader` with a link to the Primer.
Updated examples to use `skos:broader` and concepts as per DPV 2.0
Added sentence to storage duration field regarding there being two examples - one showing the value used directly and another one with the type explicitly declared.
01 July 2024 First version published
Funding Acknowledgements
Funding Sponsors
The DPVCG was established as part of the SPECIAL H2020 Project, which received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 731601 from 2017 to 2019.
Harshvardhan J. Pandit was funded to work on DPV from 2020 to 2022 by the Irish Research Council's Government of Ireland Postdoctoral Fellowship Grant#GOIPD/2020/790.
The ADAPT SFI Centre for Digital Media Technology is funded by Science Foundation Ireland through the SFI Research Centres Programme and is co-funded under the European Regional Development Fund (ERDF) through Grant#13/RC/2106 (2018 to 2020) and Grant#13/RC/2106_P2 (2021 onwards).
Funding Acknowledgements for Contributors
The contributions of Harshvardhan J. Pandit have been made with the financial support of Science Foundation Ireland under Grant Agreement No. 13/RC/2106_P2 at the ADAPT SFI Research Centre.
