Authors:
(1) Harshvardhan J. Pandit, ADAPT Centre, Dublin City University, Dublin, Ireland, and Cybersecurity and Data Protection Group, National Standards Institute, Ireland ([email protected])
(2) Jan Lindquist, Privacy and Security Group, Institute for Standards, Sweden ([email protected]);
(3) Georg P. Krog, Signatu AS, Oslo, Norway ([email protected]).
Table of Links
Abstract and 1 Introduction
2 Overview of ISO/IEC TS 27560:2023
3 Comparing ISO-27560, ISO-29184, and GDPR
4 Consent Records and Receipts using DPV
5 Supporting GDPR and DGA
6 Implementation Considerations and Future Work
6.1 Trust and Security
6.2 Using Records and Receipts with eIDAS and EUDI Wallet
6.3 Standard for PII Processing Record Information and 6.4 Technical Considerations in Managing Records and Receipts
6.5 IEEE P7012 Machine-Readable Privacy Terms
7 Conclusion and References
A Example of Consent Record with both required and optional fields
B Example of Consent Receipt with required fields from consent record
4 Consent Records and Receipts using DPV
ISO-27560 only defines the information fields and does not prescribe how they should be technically represented in practice. To implement ISO-27560, the information therefore must be represented in a format such as JSON which is widely supported and easy to use. However, the use of JSON requires a strict agreement on how the information should be structured and how it should be interpreted. The JSON-LD (JSON for Linked Data) format enables use of JSON with linked data so that the ontologies and vocabularies defined using W3C standards can be exchanged as JSON data. For this reason, ISO-27560 Annex C provides examples of consent records and receipts for both JSON and JSON-LD. Implementing ISO-27560 in a machine-readable manner using JSON-LD requires agreement on the schema or ontology to represent the fields. The Annex C JSON-LD example uses the Data Privacy Vocabulary[5] (DPV) [14,12] which is maintained by the W3C Data Privacy Vocabularies and Controls Community Group[6] (DPVCG).
DPV is a state of the art resource that provides the necessary ontology to represent concepts such as purpose, processing operations, personal data, legal roles, as well as a rich and extensive taxonomy expanding on each of these concepts to enable representing of practical use-cases. For example, using DPV, it is possible to exchange ISO-27560 records and receipts in JSON-LD which specify the Purpose is Marketing in an interoperable manner. In addition, DPV also features extensions through which different jurisdiction specific concepts can be represented, and for which it provides extensions for EU regulations such as the GDPR, DGA, and the upcoming AI Act. This enables flexibility of expression general requirements such as the legal basis should be consent, as well as specific requirements such as explicit consent as per GDPR Art.9-1a.
DPV was initiated as part of the SPECIAL H2020 project and has been developed for over 6 years with a multi-disciplinary community made up of computer scientists, legal experts, sociologists, data protection officers, industry stakeholders, and authorities. It has been actively used in several projects at national and international (e.g. Horizon Europe) levels, is being used by the industry, and has been acknowledged by within standards (including ISO-27560) [12]. As such, it represents the best resource currently available for representing consent records and receipts as well as other legally relevant information in a machine-readable form that is based on open (free and non-proprietary) interoperable standards.
To support the implementation of use of DPV in implementing consent records and receipts in conformance with ISO-27560 and the GDPR, we have developed a technical specification which can be accessed online at https: //w3id.org/dpv/guides/consent-27560. The specification describes how the required fields in ISO-27560 and GDPR are represented using DPV (summarised below) and provides illustrative examples for each (see online). Consent records are represented as instances of the concept dpv:ConsentRecord and receipts are represented as instances of the concept dpv:ConsentReceipt. For reviewers convenience: complete examples of a consent record and a consent receipt are provided in the annexes at the end of this article.
Profiles: To support implementing ISO-27560 as well as its use to comply with GDPR, DPVCG defines 4 schemas or profiles defined under the namespace https://w3id.org/dpv/schema/dpv-27560# (prefixed as dpv-27560:).
-
dpv-27560:record: Consent Records conforming with ISO-27560.
-
dpv-27560:record-eu-gdpr Consent Records conforming with ISO-27560 and containing information as required by EU GDPR.
-
dpv-27560:receipt-record Consent Receipts conforming with ISO-27560 and providing information from consent record(s).
-
dpv-27560:receipt-eu-gdpr Consent Receipts conforming with ISO-27560 and providing information from consent record(s) as required by EU GDPR.
Metadata Fields: (see table 4) to describe the generic metadata fields associated with records and receipts, we utilise the DCMI Metadata Terms standard[7] (prefixed as dct:). A consent record or receipt indicates use of the DPV profiles by using dct:conformsTo with one of the profiles described above.
Processing Fields: (see table 4) 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 where each ’process’ represents a distinct processing activity with its own fields e.g. purposes, personal data, recipients. Thus a consent record and receipt may cover multiple processes (and purposes) which permits an unambiguous and exact representation e.g. which purpose, implemented by which entity, with what data, recipient, etc.
Entity Fields: (see table 4) DPV uses the term Entity for what ISO-27560 refers to as Party. Entities are expressed using instances of dpv:Entity and associated using dpv:hasEntity. DPV also distinguishes between Entities and Legal Entities – and their representatives or agents, through which it can be accurately represented whether a party in a consent record acted on their own or it was someone acting on their behalf. This is of relevance for implementations such as consent for children which involves parents or guardians, or even data intermediaries under DGA which can act to support individuals in consent decision making.
Consent Event Fields: (see table 4) These fields are used to indicate the type of consent (e.g. Implicit, Expressed, Explicit) as expressed by the data subject. In DPV, dpv:ConsentType represents consent types to be used as a legal basis and has the following different types: Informed with specialisations for Implied when implied or given by an indirect action (e.g. merely browsing a website), Expressed for direct expressed action (e.g. a checkbox), and ExplicitlyExpressed for direct action concerning solely the consent in context. To indicate consent types as defined in GDPR, the DPV’s GDPR extension is used e.g. eu-gdpr:A6-1-a for expressed consent and eu-gdpr:A9-2-a for explicit consent.
In addition to the type of consent, these fields also enable expressing the status of consent, such as whether it has been requested, given, refused, expired, terminated, invalidated, or re-affirmed. Each event can contain metadata to indicate when it took place (e.g. date when consent was given), how it was expressed (e.g. in the account dashboard), its duration (e.g. validity of given consent), and by whom (e.g the data subject).
Consent Receipts: (see table 4) 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/optionality requirements. Therefore, a consent receipt only has three mandatory fields with the rest of the information being present as instances of consent record(s).
[5] https://w3id.org/dpv [6] https://www.w3.org/groups/cg/dpvcg/ [7] https://dublincore.org/specifications/dublin-core/dcmi-terms/
