From c5efe3f52aebe9d2484ed3eea8c231e0bdc0c012 Mon Sep 17 00:00:00 2001 From: Milan Date: Thu, 19 May 2022 13:48:41 +0200 Subject: [PATCH 001/204] Initiating work on schemas a formal representation of Rights Requests so systems and components cna share them @Clementinev please have a look and add the current work you're doing here. --- ...-rights-request-interoperability-format.md | 56 +++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 refs/schemas/RFC-rights-request-interoperability-format.md diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md new file mode 100644 index 00000000..a28a75ac --- /dev/null +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -0,0 +1,56 @@ +# Title of RFC + +| Status | draft | +| :------------ | :------------------------------------------------------------------------------------- | +| **PR #** | [NNN](https://github.com/blindnet-io/PROJECT/pull/NNN) (update when you have PR #) | +| **Author(s)** | milstan (milstan@blindnet.io), Clémentine VINCENT (clementine@blindnet.io) | +| **Sponsor** | Filip (filip@blindnet.io) | +| **Updated** | 2022-05-19 | + +## Objective + +We propose a simple, structured data format for representing [Rights Requests](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-conceptualization#data-capture--rights-requests). + +## Motivation + +Different systems, and different compontents of a single system, including different comnponents of blindnet devkit are likely to exchange information about Rights Requests. +Therefore, a common format is needed to facilitate exchange of information without loss of semantics. + +## Benefit + +**TBD** How will users (or other contributors) benefit from this work? What would be the +headline in documentation, release notes or blog post? + +## Proposal + +**TBD - Clémentine: you can imput your lists of request types, tratment types etc here.**This is the meat of the document, where you explain your proposal. If you have +multiple alternatives, be sure to use sub-sections for better separation of the +idea, and list pros/cons to each approach. If there are alternatives that you +have eliminated, you should also list those here, and explain why you believe +your chosen approach is superior. + +Make sure you’ve thought through and addressed the following sections. If a section is not relevant to your specific proposal, please explain why, e.g. your RFC addresses a convention or process, not an API. + +### Alternatives Considered + +**TBD**- Make sure to discuss the relative merits of alternatives to your proposal. + +### User Impact + +**TBD**- What are the user-facing changes? How will this feature be rolled out? + +## Detailed Design + +The proposed desing comes in two forms that are to be considered together: +(1) This reference document, definining key concepts, terms and relationships in a human-readable format +(2) A JSON Schema document (link soon), for machine-readable interpretation of Rights Requests + +The key requirements of the desing are to enable: +- Unambiguous expression of Rights Requests in a machine-readable form +- Integrity of Rights Requests semantics when exchanged between components and systems. +I.e. A system that has not directly collected the Rights Requests from the user, but has received in in JSON format from another system, can make the exact same interpretation of the request as if it had collected the request directly. +- A way of uniquely identifying one and the same Rights Request across systems and components concerned by it. + +## Questions and Discussion Topics + +**TBD** Seed this with open questions you require feedback on from the RFC process. From 66b2032ca668301a65432d60af10f28a35246ae1 Mon Sep 17 00:00:00 2001 From: Milan Date: Thu, 19 May 2022 14:03:37 +0200 Subject: [PATCH 002/204] link to IETF document about JSON schemas --- refs/schemas/RFC-rights-request-interoperability-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index a28a75ac..4f0c2862 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -43,7 +43,7 @@ Make sure you’ve thought through and addressed the following sections. If a se The proposed desing comes in two forms that are to be considered together: (1) This reference document, definining key concepts, terms and relationships in a human-readable format -(2) A JSON Schema document (link soon), for machine-readable interpretation of Rights Requests +(2) A JSON Schema document (link soon), for machine-readable interpretation of Rights Requests compliant with [v4 (or ideally lower) of IETF specification](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#:~:text=JSON%20Schema%20is%20a%20JSON,interaction%20control%20of%20JSON%20data.) The key requirements of the desing are to enable: - Unambiguous expression of Rights Requests in a machine-readable form From cb15e9f8549141046560193f98ce73f48cc987e0 Mon Sep 17 00:00:00 2001 From: Milan Date: Thu, 19 May 2022 15:07:12 +0200 Subject: [PATCH 003/204] added terminology --- .../schemas/RFC-rights-request-interoperability-format.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 4f0c2862..db620c3a 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -21,9 +21,15 @@ Therefore, a common format is needed to facilitate exchange of information witho **TBD** How will users (or other contributors) benefit from this work? What would be the headline in documentation, release notes or blog post? +## Terminology + +We use the terms "Rights Request" and "Data Rights Request" interchangeably. + ## Proposal -**TBD - Clémentine: you can imput your lists of request types, tratment types etc here.**This is the meat of the document, where you explain your proposal. If you have +**TBD - Clémentine: you can imput your lists of request types, tratment types etc here.** + +This is the meat of the document, where you explain your proposal. If you have multiple alternatives, be sure to use sub-sections for better separation of the idea, and list pros/cons to each approach. If there are alternatives that you have eliminated, you should also list those here, and explain why you believe From 1ce3ca2a2a9cb7165c99c923f3c6a5dc815cae39 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Fri, 20 May 2022 11:01:04 +0200 Subject: [PATCH 004/204] Update RFC-rights-request-interoperability-format.md --- ...-rights-request-interoperability-format.md | 68 ++++++++++++++++--- 1 file changed, 59 insertions(+), 9 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index db620c3a..6e30c940 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -27,15 +27,65 @@ We use the terms "Rights Request" and "Data Rights Request" interchangeably. ## Proposal -**TBD - Clémentine: you can imput your lists of request types, tratment types etc here.** - -This is the meat of the document, where you explain your proposal. If you have -multiple alternatives, be sure to use sub-sections for better separation of the -idea, and list pros/cons to each approach. If there are alternatives that you -have eliminated, you should also list those here, and explain why you believe -your chosen approach is superior. - -Make sure you’ve thought through and addressed the following sections. If a section is not relevant to your specific proposal, please explain why, e.g. your RFC addresses a convention or process, not an API. +### Requests list + +| Nb | Request | Description | Advised elements to provide| CNIL reference +| ---------- | ---- | ---- | ---- |---- | +| 01 | **Access to data organization has on me** | Access to all data the organization has on me | | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | +| 02 | **Modify data organization has on me** | Rectify incorrect data organization has on me | Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | +| 03 | **Rectify incomplete data organization has on me** | Rectify incomplete data organization has on me | Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | +| 04 | **Delete data organization has on me** | Deletion of data the organization has on me | Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | +| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | +| 06 | **Opposition to treatment of data organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | Reason of deletion | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | +| 07 | **Access to data financial organization has on me** | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me | Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | +| 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | Reason of deletion | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | +| 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** | Access to all data Fichier central des Chèques (FCC) has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | +| 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** | Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | +| 11 | **Access geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | "Device type, Date and time" | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | +| 12 | **Acces to video data on organization has on me** | Access to video data organization has on me on a specific period of time | Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | +| 13 | **Closing an online account** | "Closing online account, Deletion of all data the organization has on me " | Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | +| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | "URL of the pages with my data, Data to delete, Reason of deletion" | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet | +| 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | +| 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | +| 17 | **Know where is stored the data organization has on me** | | | | +| 18 | **Know who can access the data organization has on me** | | | | +| 19 | **Know the provenance of data organization has on me** | | | | +| 20 | **Know for how long the data organization has me will be kept** | | | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | +| 21 | **Know when my data will be deleted** | | | | +| 22 | **Know what is the policy of the organization to keep data it has on me** | | | | +| 23 | **Know the purpose of the treatment organization does on the data it has on me** | | | | +| 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | | Type of treatment (to choose from possible type of treatment list | | +| 25 | **Know what type(s) of treatment organization does on the data it has on me** | | | | +| 26 | **Know if a particular type of treatment is done by organisation on the data it has on me** | | Type of treatment (to choose from possible type of treatment list | | +| 27 | **Revoke consent** | | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | +| 28 | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | | | + +### Types of treatment list +| Nb | Treatment | Description | CNIL reference +| ---------- | ---- | ---- | ---- | +| 01 | **Collection** | Data collection | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 02 | **Recording** | Data recording | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 03 | **Organisation** | Data organisation | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 04 | **Retention** | Data retention | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 05 | **Adapation** | Data adaptation | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 07 | **Modification** | Data modification | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 08 | **Extraction** | Data extraction | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 09 | **Consultation** | Data consultation| https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 10 | **Usage** | Data usage | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 11 | **Communication** | Data communication by transmission or broadcast or any other form of data communication | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 12| *FR: "Rapprochement" -> EN: "Matching" or "Reconciliation" ?* | | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 13 | **Automatic Inference and Descisionmaking** | Any automatic inference made on the data | [GDPR chap3 art. 13 section 2. c)](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre3#Article13)| + +### Data categories list +| Nb | Data category | Description | CNIL reference +| ---------- | ---- | ---- | ---- | +| 01 | Name | Firstname, Surname | | +| 02 | Postal address | | | +| 03 | email address | | | +| 04 | ID number | | | +| 05 | Financial data | | | +| 06 | Login data | | | +| 07 | Location data | | | ### Alternatives Considered From 4072433879eda64ab498177f8176161c704de54c Mon Sep 17 00:00:00 2001 From: Milan Date: Fri, 20 May 2022 12:12:41 +0200 Subject: [PATCH 005/204] terminology --- ...-rights-request-interoperability-format.md | 31 +++++++++++++++---- 1 file changed, 25 insertions(+), 6 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 6e30c940..88f9d2c8 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -1,4 +1,4 @@ -# Title of RFC +# Rights Request Interoperability Format | Status | draft | | :------------ | :------------------------------------------------------------------------------------- | @@ -11,9 +11,14 @@ We propose a simple, structured data format for representing [Rights Requests](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-conceptualization#data-capture--rights-requests). +Rights Request exist within the relationship between an individual and software systems (and organisations operating them) treating data that concerns that individual. + +Systems MAY trat and respond to Rights Request by legal obligation, or as a simple courtesy in the pursuit of gaining and maintaining the individual's trust. + ## Motivation Different systems, and different compontents of a single system, including different comnponents of blindnet devkit are likely to exchange information about Rights Requests. + Therefore, a common format is needed to facilitate exchange of information without loss of semantics. ## Benefit @@ -23,7 +28,10 @@ headline in documentation, release notes or blog post? ## Terminology -We use the terms "Rights Request" and "Data Rights Request" interchangeably. +- We use the terms Rights Request, Data Subject, System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) +- We use the terms Rights Request and Data Rights Request interchangeably +- We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) + ## Proposal @@ -97,16 +105,27 @@ We use the terms "Rights Request" and "Data Rights Request" interchangeably. ## Detailed Design -The proposed desing comes in two forms that are to be considered together: -(1) This reference document, definining key concepts, terms and relationships in a human-readable format -(2) A JSON Schema document (link soon), for machine-readable interpretation of Rights Requests compliant with [v4 (or ideally lower) of IETF specification](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#:~:text=JSON%20Schema%20is%20a%20JSON,interaction%20control%20of%20JSON%20data.) +### JSON format + +In addition to this specification document we provide a JSON Schema document (link soon), for machine-readable interpretation of Rights Requests compliant with [v4 (or ideally lower) of IETF specification](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#:~:text=JSON%20Schema%20is%20a%20JSON,interaction%20control%20of%20JSON%20data.) -The key requirements of the desing are to enable: +The key requirements of the design are to enable: - Unambiguous expression of Rights Requests in a machine-readable form - Integrity of Rights Requests semantics when exchanged between components and systems. I.e. A system that has not directly collected the Rights Requests from the user, but has received in in JSON format from another system, can make the exact same interpretation of the request as if it had collected the request directly. - A way of uniquely identifying one and the same Rights Request across systems and components concerned by it. +### Authenticated exchanges + +Systems exchanging Rignts Requests MUST be able to do so in a way allowing them to very the integrity of their content, and the identity of the system having emitted the Rignts Request. + +For this purposes Rignts Requests MAY be embedded as 'Claims' in [JWTs (FRC7519)](https://datatracker.ietf.org/doc/html/rfc7519). + +### Golbaly Unique System and User IDs + +The identifyers used to refer to Systems and to Data Subjects MUST be globaly unique. + + ## Questions and Discussion Topics **TBD** Seed this with open questions you require feedback on from the RFC process. From 876abd8ec4a668861ce55aa74db2629d744a0418 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Fri, 20 May 2022 12:29:45 +0200 Subject: [PATCH 006/204] Update RFC-rights-request-interoperability-format.md --- .../RFC-rights-request-interoperability-format.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 88f9d2c8..164cc555 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -43,16 +43,16 @@ headline in documentation, release notes or blog post? | 02 | **Modify data organization has on me** | Rectify incorrect data organization has on me | Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | | 03 | **Rectify incomplete data organization has on me** | Rectify incomplete data organization has on me | Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | | 04 | **Delete data organization has on me** | Deletion of data the organization has on me | Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | -| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | +| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files, Propagation of request to other organizations the organization may have shared the data it has me with | Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | | 06 | **Opposition to treatment of data organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | Reason of deletion | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | | 07 | **Access to data financial organization has on me** | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me | Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | | 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | Reason of deletion | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | | 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** | Access to all data Fichier central des Chèques (FCC) has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | | 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** | Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | -| 11 | **Access geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | "Device type, Date and time" | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | +| 11 | **Access geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | Device type, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | | 12 | **Acces to video data on organization has on me** | Access to video data organization has on me on a specific period of time | Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | -| 13 | **Closing an online account** | "Closing online account, Deletion of all data the organization has on me " | Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | -| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | "URL of the pages with my data, Data to delete, Reason of deletion" | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet | +| 13 | **Closing an online account** | Closing online account, Deletion of all data the organization has on me | Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | +| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | URL of the pages with my data, Data to delete, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet | | 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | | 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | | 17 | **Know where is stored the data organization has on me** | | | | @@ -89,11 +89,13 @@ headline in documentation, release notes or blog post? | ---------- | ---- | ---- | ---- | | 01 | Name | Firstname, Surname | | | 02 | Postal address | | | -| 03 | email address | | | +| 03 | Email address | | | | 04 | ID number | | | | 05 | Financial data | | | | 06 | Login data | | | | 07 | Location data | | | +| 08 | Image, Video | | | +| 09 | Medical data | | | ### Alternatives Considered From 0fdd6c27abe113ed30838227d3272ec0a0ca27fd Mon Sep 17 00:00:00 2001 From: Milan Date: Fri, 20 May 2022 13:48:46 +0200 Subject: [PATCH 007/204] Alternatives - About Trasnced --- ...-rights-request-interoperability-format.md | 107 +++++++++++++++--- 1 file changed, 92 insertions(+), 15 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 164cc555..7bb8e6d7 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -1,4 +1,4 @@ -# Rights Request Interoperability Format +# Rights Request Interoperability Format (RRIF) | Status | draft | | :------------ | :------------------------------------------------------------------------------------- | @@ -11,7 +11,7 @@ We propose a simple, structured data format for representing [Rights Requests](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-conceptualization#data-capture--rights-requests). -Rights Request exist within the relationship between an individual and software systems (and organisations operating them) treating data that concerns that individual. +Rights Requests exist within the relationship between an individual and software systems (and organisations operating them) treating data that concerns that individual. Systems MAY trat and respond to Rights Request by legal obligation, or as a simple courtesy in the pursuit of gaining and maintaining the individual's trust. @@ -21,10 +21,11 @@ Different systems, and different compontents of a single system, including diffe Therefore, a common format is needed to facilitate exchange of information without loss of semantics. -## Benefit +## Design Considerations -**TBD** How will users (or other contributors) benefit from this work? What would be the -headline in documentation, release notes or blog post? +The goal of the desing of the format, is to enable Rights Request interoperability, while allowing the use of different protocols and tools for: +- user identity management and authentication, +- encryption. ## Terminology @@ -43,16 +44,16 @@ headline in documentation, release notes or blog post? | 02 | **Modify data organization has on me** | Rectify incorrect data organization has on me | Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | | 03 | **Rectify incomplete data organization has on me** | Rectify incomplete data organization has on me | Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | | 04 | **Delete data organization has on me** | Deletion of data the organization has on me | Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | -| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files, Propagation of request to other organizations the organization may have shared the data it has me with | Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | +| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | | 06 | **Opposition to treatment of data organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | Reason of deletion | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | | 07 | **Access to data financial organization has on me** | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me | Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | | 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | Reason of deletion | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | | 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** | Access to all data Fichier central des Chèques (FCC) has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | | 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** | Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | -| 11 | **Access geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | Device type, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | +| 11 | **Access geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | "Device type, Date and time" | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | | 12 | **Acces to video data on organization has on me** | Access to video data organization has on me on a specific period of time | Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | -| 13 | **Closing an online account** | Closing online account, Deletion of all data the organization has on me | Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | -| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | URL of the pages with my data, Data to delete, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet | +| 13 | **Closing an online account** | "Closing online account, Deletion of all data the organization has on me " | Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | +| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | "URL of the pages with my data, Data to delete, Reason of deletion" | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet | | 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | | 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | | 17 | **Know where is stored the data organization has on me** | | | | @@ -89,17 +90,70 @@ headline in documentation, release notes or blog post? | ---------- | ---- | ---- | ---- | | 01 | Name | Firstname, Surname | | | 02 | Postal address | | | -| 03 | Email address | | | +| 03 | email address | | | | 04 | ID number | | | | 05 | Financial data | | | | 06 | Login data | | | | 07 | Location data | | | -| 08 | Image, Video | | | -| 09 | Medical data | | | ### Alternatives Considered -**TBD**- Make sure to discuss the relative merits of alternatives to your proposal. +#### Transcend + +Transcend proposes the following [action (demand) types](https://github.com/transcend-io/privacy-types/blob/main/src/actions.ts): +| Demand Type | Description | Observation | +| -------------- | ----------------------------------------- | ------------------------ | +| ACCESS | Data Download request | | +| ERASURE | Erase the file completely | | +| ACCOUNT_DELETION | Run an account deletion instead of a fully compliant deletion | | +| AUTOMATED_DECISION_MAKING_OPT_OUT | Opt out of automated decision making | | +| CONTACT_OPT_OUT | A contact opt out request | | +| SALE_OPT_OUT | Opt-out of the sale of personal data | | +| TRACKING_OPT_OUT | A tracking opt out request | | +| RECTIFICATION | Make an update to an inaccurate record | | +| RESTRICTION | A restriction of processing request | | + +All of those can be modeled using our Demand Types. + +Transced proposes the following [treatment types](https://github.com/transcend-io/privacy-types/blob/main/src/objects.ts): +| Treatment Type | Description | Observation | +| -------------- | ----------------------------------------- | ------------------------ | +| ESSENTIAL | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality| | +| ADDITIONAL_FUNCTIONALITY | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | | +| ADVERTISING | To show ads that are either targeted to the specific user or not targeted | | +| MARKETING | To contact the user to offer products, services, or other promotions | | +| ANALYTICS | For understanding the product’s audience, improving the product, inform company strategy, or general research | | +| PERSONALIZATION | For providing user with a personalized experience | | +| OPERATION_SECURITY | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | +| LEGAL | For compliance with legal obligations | | +| TRANSFER | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | +| SALE | For selling the data to third parties | | +| HR | For personnel training, recruitment, payroll, management, etc. | corresponds to ongoing contract in our terminology| +| OTHER | Other specific purpose not covered above | | +| UNSPECIFIED | The purpose is not explicitly stated or is unclear | | + +All of those SHOULD be modeled using our Treatment Types. + +Transced proposes the following [data categories](https://github.com/transcend-io/privacy-types/blob/main/src/objects.ts): +| Data Category | Description | Observation | +| -------------- | ----------------------------------------- | ------------------------ | +| FINANCIAL | Financial information | | +| HEALTH | Health information | | +| CONTACT | Contact information | | +| LOCATION | Geo-location information | | +| DEMOGRAPHIC | Demographic Information | | +| ID | Identifiers that uniquely identify a person | | +| ONLINE_ACTIVITY | The user's online activities on the first party website/app or other websites/apps | | +| USER_PROFILE | he user’s profile on the first-party website/app and its contents | | +| SOCIAL_MEDIA | User profile and data from a social media website/app or other third party service | | +| CONNECTION | Connection information for the current browsing session, e.g. device IDs, MAC addresses, IP addresses, etc. | | +| TRACKING | Cookies and tracking elements | | +| DEVICE | Computer or device information | | +| SURVEY | Any data that is collected through surveys | | +| OTHER | A specific type of information not covered by the above categories | | +| UNSPECIFIED | The type of information is not explicitly stated or unclear| | + + ### User Impact @@ -123,9 +177,32 @@ Systems exchanging Rignts Requests MUST be able to do so in a way allowing them For this purposes Rignts Requests MAY be embedded as 'Claims' in [JWTs (FRC7519)](https://datatracker.ietf.org/doc/html/rfc7519). -### Golbaly Unique System and User IDs +### Golbaly Unique Data Subject IDs + +The identifyers used to refer to Data Subjects MUST be globaly unique. One Data Subject ID corresponds to one Data Subject. One Data Subject can have several Data Subject IDs. + +When refering to a Data Subject, Systems MUST use both of the following atributes: +- `dsid` - Data Subject ID +- `dsid-scheme` - A scheme allowign to dereference the Data Subject ID + +The (`dsid`,`dsid-scheme`) pair denotes a globaly unique reference to always the same Data Subject. + +### Data Subject ID Schemes + +Systems using RRIF MUST implement at least the following `dsid-scheme`: + +|`dsid-scheme` value | Interpretation of corresponding `dsid` value | +| ------------------ | ---- | +|`email-sha-256`| Indicates that the value of the corresponding `dsid` attribute is the result of the SHA-256 hashing function taking the e-mail of the Data Subject as argument | + +Additional Data Subject ID Schemes MAY be definied by convention. + + +### Data Subject MUST be authenticated + + -The identifyers used to refer to Systems and to Data Subjects MUST be globaly unique. +A System MAY use ## Questions and Discussion Topics From 60ae3bc1f82cf675f1e628990314b5c21e8a17fc Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Fri, 20 May 2022 14:18:50 +0200 Subject: [PATCH 008/204] Update RFC-rights-request-interoperability-format.md --- ...C-rights-request-interoperability-format.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 7bb8e6d7..b96034b6 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -56,17 +56,17 @@ The goal of the desing of the format, is to enable Rights Request interoperabili | 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | "URL of the pages with my data, Data to delete, Reason of deletion" | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet | | 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | | 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | -| 17 | **Know where is stored the data organization has on me** | | | | -| 18 | **Know who can access the data organization has on me** | | | | -| 19 | **Know the provenance of data organization has on me** | | | | -| 20 | **Know for how long the data organization has me will be kept** | | | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | -| 21 | **Know when my data will be deleted** | | | | -| 22 | **Know what is the policy of the organization to keep data it has on me** | | | | -| 23 | **Know the purpose of the treatment organization does on the data it has on me** | | | | +| 17 | **Where is stored the data organization has on me** | Know where is stored the data organization has on me | | | +| 18 | **Who can access the data organization has on me** | Know who can access the data organization has on m | | | +| 19 | **What is the provenance of data organization has on me** | Know the provenance of data organization has on me | | | +| 20 | **For how long the data organization has me will be kept** | Know for how long the data organization has me will be kept | | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | +| 21 | **When my data will be deleted** | Know when my data will be deleted | | | +| 22 | **What is the policy of the organization to keep data it has on me** | Know what is the policy of the organization to keep data it has on me | | | +| 23 | **What is the purpose of the treatment organization does on the data it has on me** | Know the purpose of the treatment organization does on the data it has on me | | | | 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | | Type of treatment (to choose from possible type of treatment list | | -| 25 | **Know what type(s) of treatment organization does on the data it has on me** | | | | +| 25 | **What type(s) of treatment organization does on the data it has on me** | Know what type(s) of treatment organization does on the data it has on me** | | | | 26 | **Know if a particular type of treatment is done by organisation on the data it has on me** | | Type of treatment (to choose from possible type of treatment list | | -| 27 | **Revoke consent** | | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | +| 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | | 28 | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | | | ### Types of treatment list From f304bc8b008e588105b8e61dc996c10c818edcd6 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Fri, 20 May 2022 16:14:46 +0200 Subject: [PATCH 009/204] Update RFC-rights-request-interoperability-format.md --- ...-rights-request-interoperability-format.md | 45 +++++++++++++++---- 1 file changed, 36 insertions(+), 9 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index b96034b6..c547f961 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -40,10 +40,10 @@ The goal of the desing of the format, is to enable Rights Request interoperabili | Nb | Request | Description | Advised elements to provide| CNIL reference | ---------- | ---- | ---- | ---- |---- | -| 01 | **Access to data organization has on me** | Access to all data the organization has on me | | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | -| 02 | **Modify data organization has on me** | Rectify incorrect data organization has on me | Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | +| 01 | **Access** | Access to all data the organization has on me | | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | +| 02 | **Modification** | Rectify incorrect data organization has on me | Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | | 03 | **Rectify incomplete data organization has on me** | Rectify incomplete data organization has on me | Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | -| 04 | **Delete data organization has on me** | Deletion of data the organization has on me | Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | +| 04 | **Deletion** | Delete the data the organization has on me | Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | | 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | | 06 | **Opposition to treatment of data organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | Reason of deletion | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | | 07 | **Access to data financial organization has on me** | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me | Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | @@ -51,7 +51,7 @@ The goal of the desing of the format, is to enable Rights Request interoperabili | 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** | Access to all data Fichier central des Chèques (FCC) has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | | 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** | Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | | 11 | **Access geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | "Device type, Date and time" | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | -| 12 | **Acces to video data on organization has on me** | Access to video data organization has on me on a specific period of time | Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | +| 12 | **Access to video data** | Access to video data organization has on me on a specific period of time | Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | | 13 | **Closing an online account** | "Closing online account, Deletion of all data the organization has on me " | Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | | 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | "URL of the pages with my data, Data to delete, Reason of deletion" | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet | | 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | @@ -68,6 +68,10 @@ The goal of the desing of the format, is to enable Rights Request interoperabili | 26 | **Know if a particular type of treatment is done by organisation on the data it has on me** | | Type of treatment (to choose from possible type of treatment list | | | 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | | 28 | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | | | +| 29 | **Opt out of automated decision making** | Opposition to automated decision making on the data organizatio has on me | | | +| 30 | **Opt out of sale of my data** | Opposition to sale of the data an organization has on me| | | +| 31 | **Opt out of tracking on my data** | Opposition to the tracking of my data from an organization | | | +| 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| | | ### Types of treatment list | Nb | Treatment | Description | CNIL reference @@ -84,17 +88,40 @@ The goal of the desing of the format, is to enable Rights Request interoperabili | 11 | **Communication** | Data communication by transmission or broadcast or any other form of data communication | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | | 12| *FR: "Rapprochement" -> EN: "Matching" or "Reconciliation" ?* | | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | | 13 | **Automatic Inference and Descisionmaking** | Any automatic inference made on the data | [GDPR chap3 art. 13 section 2. c)](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre3#Article13)| +| XX | **Essential/basic** | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality | | +| XX | **Additonal functionality** | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | | +| XX | **Advertising** | To show ads that are either targeted to the specific user or not targeted | | +| XX | **Marketing** | To contact the user to offer products, services, or other promotions | | +| XX | **Analytics** | For understanding the product’s audience, improving the product, inform company strategy, or general research | | +| XX | **Personnalisation** | For providing user with a personalized experience | | +| XX | **Operation security** | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | +| XX | **Legal** | For compliance with legal obligations | | +| XX | **Ongoing contract** | | | +| XX | **Transfer** | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | +| XX | **Sale** | Selling data to third parties | | +| XX | **Ongoing contract** | | | +| XX | **OTHER** | Other specific purpose not covered above | | +| XX | **UNSPECIFIED** | The purpose is not explicitly stated or is unclear | | ### Data categories list | Nb | Data category | Description | CNIL reference | ---------- | ---- | ---- | ---- | | 01 | Name | Firstname, Surname | | -| 02 | Postal address | | | -| 03 | email address | | | -| 04 | ID number | | | +| 02 | Postal address | *contact information* | | +| 03 | Email address | *contact information* | | +| 04 | Phone number | *contact information* | | +| 04 | ID data | Identifiers that uniquely identify a person | | | 05 | Financial data | | | -| 06 | Login data | | | -| 07 | Location data | | | +| 06 | Connection data | | | +| 07 | Location data | Geolocation information | | +| 08 | Health data | | | +| 09 | Online activity data | | | +| 10 | Tracking data | | | +| 11 | User profile | user’s profile on the first-party website/app and its contents | | +| 12 | Device data | | | +| 13 | Survey data | | | +| 14 | OTHER | A specific type of information not covered by the above categories | | +| 15 | UNSPECIFIED | The type of information is not explicitly stated or unclear| ### Alternatives Considered From 87b14fe588c9be43442fb03b8b91cc07b5b9085e Mon Sep 17 00:00:00 2001 From: Milan Date: Fri, 20 May 2022 16:46:34 +0200 Subject: [PATCH 010/204] on unique IDs --- ...-rights-request-interoperability-format.md | 112 +++++++++--------- 1 file changed, 54 insertions(+), 58 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index c547f961..96653473 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -13,13 +13,15 @@ We propose a simple, structured data format for representing [Rights Requests](h Rights Requests exist within the relationship between an individual and software systems (and organisations operating them) treating data that concerns that individual. -Systems MAY trat and respond to Rights Request by legal obligation, or as a simple courtesy in the pursuit of gaining and maintaining the individual's trust. +Systems MAY process and respond to Rights Request by legal obligation, or as a simple courtesy in the pursuit of gaining and maintaining the individual's trust. ## Motivation Different systems, and different compontents of a single system, including different comnponents of blindnet devkit are likely to exchange information about Rights Requests. -Therefore, a common format is needed to facilitate exchange of information without loss of semantics. +Therefore, a common format is needed to facilitate exchange of information without loss of semantics. + +Our goal is to establish a shared semantics of Rights Request so that their processing can be, as much as possible, automatised by the Systems. ## Design Considerations @@ -40,10 +42,10 @@ The goal of the desing of the format, is to enable Rights Request interoperabili | Nb | Request | Description | Advised elements to provide| CNIL reference | ---------- | ---- | ---- | ---- |---- | -| 01 | **Access** | Access to all data the organization has on me | | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | -| 02 | **Modification** | Rectify incorrect data organization has on me | Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | +| 01 | **Access to data organization has on me** | Access to all data the organization has on me | | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | +| 02 | **Modify data organization has on me** | Rectify incorrect data organization has on me | Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | | 03 | **Rectify incomplete data organization has on me** | Rectify incomplete data organization has on me | Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | -| 04 | **Deletion** | Delete the data the organization has on me | Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | +| 04 | **Delete data organization has on me** | Deletion of data the organization has on me | Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | | 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | | 06 | **Opposition to treatment of data organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | Reason of deletion | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | | 07 | **Access to data financial organization has on me** | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me | Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | @@ -51,27 +53,23 @@ The goal of the desing of the format, is to enable Rights Request interoperabili | 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** | Access to all data Fichier central des Chèques (FCC) has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | | 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** | Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | | 11 | **Access geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | "Device type, Date and time" | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | -| 12 | **Access to video data** | Access to video data organization has on me on a specific period of time | Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | +| 12 | **Acces to video data on organization has on me** | Access to video data organization has on me on a specific period of time | Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | | 13 | **Closing an online account** | "Closing online account, Deletion of all data the organization has on me " | Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | | 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | "URL of the pages with my data, Data to delete, Reason of deletion" | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet | | 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | | 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | -| 17 | **Where is stored the data organization has on me** | Know where is stored the data organization has on me | | | -| 18 | **Who can access the data organization has on me** | Know who can access the data organization has on m | | | -| 19 | **What is the provenance of data organization has on me** | Know the provenance of data organization has on me | | | -| 20 | **For how long the data organization has me will be kept** | Know for how long the data organization has me will be kept | | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | -| 21 | **When my data will be deleted** | Know when my data will be deleted | | | -| 22 | **What is the policy of the organization to keep data it has on me** | Know what is the policy of the organization to keep data it has on me | | | -| 23 | **What is the purpose of the treatment organization does on the data it has on me** | Know the purpose of the treatment organization does on the data it has on me | | | +| 17 | **Know where is stored the data organization has on me** | | | | +| 18 | **Know who can access the data organization has on me** | | | | +| 19 | **Know the provenance of data organization has on me** | | | | +| 20 | **Know for how long the data organization has me will be kept** | | | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | +| 21 | **Know when my data will be deleted** | | | | +| 22 | **Know what is the policy of the organization to keep data it has on me** | | | | +| 23 | **Know the purpose of the treatment organization does on the data it has on me** | | | | | 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | | Type of treatment (to choose from possible type of treatment list | | -| 25 | **What type(s) of treatment organization does on the data it has on me** | Know what type(s) of treatment organization does on the data it has on me** | | | +| 25 | **Know what type(s) of treatment organization does on the data it has on me** | | | | | 26 | **Know if a particular type of treatment is done by organisation on the data it has on me** | | Type of treatment (to choose from possible type of treatment list | | -| 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | +| 27 | **Revoke consent** | | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | | 28 | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | | | -| 29 | **Opt out of automated decision making** | Opposition to automated decision making on the data organizatio has on me | | | -| 30 | **Opt out of sale of my data** | Opposition to sale of the data an organization has on me| | | -| 31 | **Opt out of tracking on my data** | Opposition to the tracking of my data from an organization | | | -| 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| | | ### Types of treatment list | Nb | Treatment | Description | CNIL reference @@ -88,40 +86,17 @@ The goal of the desing of the format, is to enable Rights Request interoperabili | 11 | **Communication** | Data communication by transmission or broadcast or any other form of data communication | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | | 12| *FR: "Rapprochement" -> EN: "Matching" or "Reconciliation" ?* | | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | | 13 | **Automatic Inference and Descisionmaking** | Any automatic inference made on the data | [GDPR chap3 art. 13 section 2. c)](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre3#Article13)| -| XX | **Essential/basic** | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality | | -| XX | **Additonal functionality** | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | | -| XX | **Advertising** | To show ads that are either targeted to the specific user or not targeted | | -| XX | **Marketing** | To contact the user to offer products, services, or other promotions | | -| XX | **Analytics** | For understanding the product’s audience, improving the product, inform company strategy, or general research | | -| XX | **Personnalisation** | For providing user with a personalized experience | | -| XX | **Operation security** | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | -| XX | **Legal** | For compliance with legal obligations | | -| XX | **Ongoing contract** | | | -| XX | **Transfer** | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | -| XX | **Sale** | Selling data to third parties | | -| XX | **Ongoing contract** | | | -| XX | **OTHER** | Other specific purpose not covered above | | -| XX | **UNSPECIFIED** | The purpose is not explicitly stated or is unclear | | ### Data categories list | Nb | Data category | Description | CNIL reference | ---------- | ---- | ---- | ---- | | 01 | Name | Firstname, Surname | | -| 02 | Postal address | *contact information* | | -| 03 | Email address | *contact information* | | -| 04 | Phone number | *contact information* | | -| 04 | ID data | Identifiers that uniquely identify a person | | +| 02 | Postal address | | | +| 03 | email address | | | +| 04 | ID number | | | | 05 | Financial data | | | -| 06 | Connection data | | | -| 07 | Location data | Geolocation information | | -| 08 | Health data | | | -| 09 | Online activity data | | | -| 10 | Tracking data | | | -| 11 | User profile | user’s profile on the first-party website/app and its contents | | -| 12 | Device data | | | -| 13 | Survey data | | | -| 14 | OTHER | A specific type of information not covered by the above categories | | -| 15 | UNSPECIFIED | The type of information is not explicitly stated or unclear| +| 06 | Login data | | | +| 07 | Location data | | | ### Alternatives Considered @@ -204,34 +179,55 @@ Systems exchanging Rignts Requests MUST be able to do so in a way allowing them For this purposes Rignts Requests MAY be embedded as 'Claims' in [JWTs (FRC7519)](https://datatracker.ietf.org/doc/html/rfc7519). -### Golbaly Unique Data Subject IDs +### Globaly Unique Data Subject IDs The identifyers used to refer to Data Subjects MUST be globaly unique. One Data Subject ID corresponds to one Data Subject. One Data Subject can have several Data Subject IDs. When refering to a Data Subject, Systems MUST use both of the following atributes: - `dsid` - Data Subject ID -- `dsid-scheme` - A scheme allowign to dereference the Data Subject ID +- `dsid-schema` - A scheme allowign to dereference the Data Subject ID + +The (`dsid`,`dsid-schema`) pair denotes a globaly unique reference to always the same Data Subject. + +A Rights Request MAY include several (`dsid`,`dsid-schema`) pairs that refer to the same user, in order to facilitate the interoperability of Rights Requests across systems. + +### Data Subject ID Schemas -The (`dsid`,`dsid-scheme`) pair denotes a globaly unique reference to always the same Data Subject. +Systems using RRIF MUST implement at least the following `dsid-schema`: -### Data Subject ID Schemes +|`dsid-schema` value | Interpretation of the corresponding `dsid` value | +| ------------------- | ---- | +|`uuid`| Indicates that the value of the corresponding `dsid` attribute is a Universaly Unique ID in the sens of [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) | -Systems using RRIF MUST implement at least the following `dsid-scheme`: +Systems using RRIF SHOULD implement at the following `dsid-schema`: -|`dsid-scheme` value | Interpretation of corresponding `dsid` value | -| ------------------ | ---- | +|`dsid-schema` value | Interpretation of the corresponding `dsid` value | +| ------------------- | ---- | |`email-sha-256`| Indicates that the value of the corresponding `dsid` attribute is the result of the SHA-256 hashing function taking the e-mail of the Data Subject as argument | -Additional Data Subject ID Schemes MAY be definied by convention. +Additional Data Subject ID Schemes MAY be definied by convention. For example the following MAY be used: +|`dsid-schema` value | Interpretation of the corresponding `dsid` value | +| ------------------- | ---- | +|`global-id`| Indicates that the value of the corresponding `dsid` attribute is the `gid_name` - User's GlobaliD name - used to identify the Data Subject in [GlobalId](https://developer.global.id/documentation/api%2Fidentity.html)| -### Data Subject MUST be authenticated +### Data Subject SHOULD be Authenticated +In some cases, valid reasons MAY exist for Systems to respond to Rights Requests even from anonymous Data Subjects. This is the case, for example, with request relative to general data treatment practices practiced by the system. +However, in most cases, Systems SHOULD require the Data Subject to be authenticated as being indeed the person corresponding to the (`dsid`,`dsid-schema`) pair. -A System MAY use +When processing Rights Request, Systems MAY automatically disregard the (`dsid`,`dsid-schema`) paris for which they have not been able to establish Data Subject authentication. + +However, the authentication does not necessairly have to be performed during the collection of the Rights Request. It can be done separately. + +### Data Capture IDs, Data Capture Fragment IDs, Rights Request IDs, Demand IDs, Rights Request Respons IDs are Globally Unique + +All of the following identifiers `data-capture-id`, `fragment-id`, `rights-request-id`, `demand-id`, `rights-response-id` MUST be globally unique and be generated according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) in order for the corresponding objects to be easily identifiable across systems. ## Questions and Discussion Topics -**TBD** Seed this with open questions you require feedback on from the RFC process. +### Use UUID for identifying Data Subjects + +We chould immagine an alternative design, where we would force systems to use an [UUID]([uuid](https://en.wikipedia.org/wiki/Universally_unique_identifier)) (according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html)), to identify the users. That would require us to provide some way for systems to match UUIDs with their local IDs (usernames, or e-mails), and would ponteltially limit the ability of 3rd party systems to interprete Rights Request made at another system. This goal of proposed design is to allow for flexibility. However it is a very important aspect of the proposal, that deserves further debate. From 74d30f245225468672592c36cb4d557e91c84425 Mon Sep 17 00:00:00 2001 From: Milan Date: Fri, 20 May 2022 16:57:31 +0200 Subject: [PATCH 011/204] Design Considerations --- .../RFC-rights-request-interoperability-format.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 96653473..ac309186 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -25,9 +25,15 @@ Our goal is to establish a shared semantics of Rights Request so that their proc ## Design Considerations -The goal of the desing of the format, is to enable Rights Request interoperability, while allowing the use of different protocols and tools for: -- user identity management and authentication, -- encryption. +The design also aimes to maximise: +- Consistent Interpretation of Rights Request accorss different Systems +- Automatisation of Rights Request Processing +- Confidentialty of data +- Compatibility with the use of different protocols and tools for: + - user identity management and authentication, + - encryption. + + ## Terminology From d09ea5c2069f1cad55345ef60bf43b6a8ac9547f Mon Sep 17 00:00:00 2001 From: Milan Date: Fri, 20 May 2022 17:13:20 +0200 Subject: [PATCH 012/204] restoring changes from @Clementinev --- ...-rights-request-interoperability-format.md | 63 +++++++++++++------ 1 file changed, 45 insertions(+), 18 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index ac309186..78f81ff9 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -48,10 +48,10 @@ The design also aimes to maximise: | Nb | Request | Description | Advised elements to provide| CNIL reference | ---------- | ---- | ---- | ---- |---- | -| 01 | **Access to data organization has on me** | Access to all data the organization has on me | | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | -| 02 | **Modify data organization has on me** | Rectify incorrect data organization has on me | Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | +| 01 | **Access** | Access to all data the organization has on me | | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | +| 02 | **Modification** | Rectify incorrect data organization has on me | Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | | 03 | **Rectify incomplete data organization has on me** | Rectify incomplete data organization has on me | Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | -| 04 | **Delete data organization has on me** | Deletion of data the organization has on me | Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | +| 04 | **Deletion** | Delete the data the organization has on me | Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | | 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | | 06 | **Opposition to treatment of data organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | Reason of deletion | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | | 07 | **Access to data financial organization has on me** | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me | Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | @@ -59,23 +59,27 @@ The design also aimes to maximise: | 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** | Access to all data Fichier central des Chèques (FCC) has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | | 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** | Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | | 11 | **Access geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | "Device type, Date and time" | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | -| 12 | **Acces to video data on organization has on me** | Access to video data organization has on me on a specific period of time | Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | +| 12 | **Access to video data** | Access to video data organization has on me on a specific period of time | Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | | 13 | **Closing an online account** | "Closing online account, Deletion of all data the organization has on me " | Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | | 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | "URL of the pages with my data, Data to delete, Reason of deletion" | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet | | 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | | 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | -| 17 | **Know where is stored the data organization has on me** | | | | -| 18 | **Know who can access the data organization has on me** | | | | -| 19 | **Know the provenance of data organization has on me** | | | | -| 20 | **Know for how long the data organization has me will be kept** | | | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | -| 21 | **Know when my data will be deleted** | | | | -| 22 | **Know what is the policy of the organization to keep data it has on me** | | | | -| 23 | **Know the purpose of the treatment organization does on the data it has on me** | | | | +| 17 | **Where is stored the data organization has on me** | Know where is stored the data organization has on me | | | +| 18 | **Who can access the data organization has on me** | Know who can access the data organization has on m | | | +| 19 | **What is the provenance of data organization has on me** | Know the provenance of data organization has on me | | | +| 20 | **For how long the data organization has me will be kept** | Know for how long the data organization has me will be kept | | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | +| 21 | **When my data will be deleted** | Know when my data will be deleted | | | +| 22 | **What is the policy of the organization to keep data it has on me** | Know what is the policy of the organization to keep data it has on me | | | +| 23 | **What is the purpose of the treatment organization does on the data it has on me** | Know the purpose of the treatment organization does on the data it has on me | | | | 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | | Type of treatment (to choose from possible type of treatment list | | -| 25 | **Know what type(s) of treatment organization does on the data it has on me** | | | | +| 25 | **What type(s) of treatment organization does on the data it has on me** | Know what type(s) of treatment organization does on the data it has on me** | | | | 26 | **Know if a particular type of treatment is done by organisation on the data it has on me** | | Type of treatment (to choose from possible type of treatment list | | -| 27 | **Revoke consent** | | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | +| 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | | 28 | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | | | +| 29 | **Opt out of automated decision making** | Opposition to automated decision making on the data organizatio has on me | | | +| 30 | **Opt out of sale of my data** | Opposition to sale of the data an organization has on me| | | +| 31 | **Opt out of tracking on my data** | Opposition to the tracking of my data from an organization | | | +| 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| | | ### Types of treatment list | Nb | Treatment | Description | CNIL reference @@ -92,17 +96,40 @@ The design also aimes to maximise: | 11 | **Communication** | Data communication by transmission or broadcast or any other form of data communication | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | | 12| *FR: "Rapprochement" -> EN: "Matching" or "Reconciliation" ?* | | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | | 13 | **Automatic Inference and Descisionmaking** | Any automatic inference made on the data | [GDPR chap3 art. 13 section 2. c)](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre3#Article13)| +| XX | **Essential/basic** | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality | | +| XX | **Additonal functionality** | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | | +| XX | **Advertising** | To show ads that are either targeted to the specific user or not targeted | | +| XX | **Marketing** | To contact the user to offer products, services, or other promotions | | +| XX | **Analytics** | For understanding the product’s audience, improving the product, inform company strategy, or general research | | +| XX | **Personnalisation** | For providing user with a personalized experience | | +| XX | **Operation security** | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | +| XX | **Legal** | For compliance with legal obligations | | +| XX | **Ongoing contract** | | | +| XX | **Transfer** | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | +| XX | **Sale** | Selling data to third parties | | +| XX | **Ongoing contract** | | | +| XX | **OTHER** | Other specific purpose not covered above | | +| XX | **UNSPECIFIED** | The purpose is not explicitly stated or is unclear | | ### Data categories list | Nb | Data category | Description | CNIL reference | ---------- | ---- | ---- | ---- | | 01 | Name | Firstname, Surname | | -| 02 | Postal address | | | -| 03 | email address | | | -| 04 | ID number | | | +| 02 | Postal address | *contact information* | | +| 03 | Email address | *contact information* | | +| 04 | Phone number | *contact information* | | +| 04 | ID data | Identifiers that uniquely identify a person | | | 05 | Financial data | | | -| 06 | Login data | | | -| 07 | Location data | | | +| 06 | Connection data | | | +| 07 | Location data | Geolocation information | | +| 08 | Health data | | | +| 09 | Online activity data | | | +| 10 | Tracking data | | | +| 11 | User profile | user’s profile on the first-party website/app and its contents | | +| 12 | Device data | | | +| 13 | Survey data | | | +| 14 | OTHER | A specific type of information not covered by the above categories | | +| 15 | UNSPECIFIED | The type of information is not explicitly stated or unclear| ### Alternatives Considered From 8add70bebbde82ad09c867fe497eef6d03a379af Mon Sep 17 00:00:00 2001 From: Milan Date: Fri, 20 May 2022 17:19:23 +0200 Subject: [PATCH 013/204] adding consent ID as well --- refs/schemas/RFC-rights-request-interoperability-format.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 78f81ff9..c93ea87f 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -254,9 +254,9 @@ When processing Rights Request, Systems MAY automatically disregard the (`dsid`, However, the authentication does not necessairly have to be performed during the collection of the Rights Request. It can be done separately. -### Data Capture IDs, Data Capture Fragment IDs, Rights Request IDs, Demand IDs, Rights Request Respons IDs are Globally Unique +### Data Capture IDs, Data Capture Fragment IDs, Consent IDs, Rights Request IDs, Demand IDs, Rights Request Respons IDs are Globally Unique -All of the following identifiers `data-capture-id`, `fragment-id`, `rights-request-id`, `demand-id`, `rights-response-id` MUST be globally unique and be generated according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) in order for the corresponding objects to be easily identifiable across systems. +All of the following identifiers `data-capture-id`, `fragment-id`, `consent-id`, `rights-request-id`, `demand-id`, `rights-response-id` MUST be globally unique and be generated according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) in order for the corresponding objects to be easily identifiable across systems. ## Questions and Discussion Topics From 45e1cbd9c373d97591ac9c02ebdf07ade31ab13b Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Fri, 20 May 2022 17:25:13 +0200 Subject: [PATCH 014/204] Add "all" to treatments and data cat lists --- refs/schemas/RFC-rights-request-interoperability-format.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index c93ea87f..c1ae0e3f 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -110,6 +110,7 @@ The design also aimes to maximise: | XX | **Ongoing contract** | | | | XX | **OTHER** | Other specific purpose not covered above | | | XX | **UNSPECIFIED** | The purpose is not explicitly stated or is unclear | | +| XX | **ALL** | | | ### Data categories list | Nb | Data category | Description | CNIL reference @@ -130,6 +131,7 @@ The design also aimes to maximise: | 13 | Survey data | | | | 14 | OTHER | A specific type of information not covered by the above categories | | | 15 | UNSPECIFIED | The type of information is not explicitly stated or unclear| +| XX | **UNSPECIFIED** | | | ### Alternatives Considered From ddeeec33c0af44f5ebd1dd0a4afdf6b8ec452a7d Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Fri, 20 May 2022 17:28:33 +0200 Subject: [PATCH 015/204] Update RFC-rights-request-interoperability-format.md --- refs/schemas/RFC-rights-request-interoperability-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index c1ae0e3f..5cebeb38 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -131,7 +131,7 @@ The design also aimes to maximise: | 13 | Survey data | | | | 14 | OTHER | A specific type of information not covered by the above categories | | | 15 | UNSPECIFIED | The type of information is not explicitly stated or unclear| -| XX | **UNSPECIFIED** | | | +| XX | **ALL** | | | ### Alternatives Considered From 9578a68309f43589201ccb60f12d7350114d9ea9 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 23 May 2022 10:31:10 +0200 Subject: [PATCH 016/204] Update requests list --- refs/schemas/RFC-rights-request-interoperability-format.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 5cebeb38..c80ae5a8 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -61,7 +61,7 @@ The design also aimes to maximise: | 11 | **Access geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | "Device type, Date and time" | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | | 12 | **Access to video data** | Access to video data organization has on me on a specific period of time | Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | | 13 | **Closing an online account** | "Closing online account, Deletion of all data the organization has on me " | Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | -| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | "URL of the pages with my data, Data to delete, Reason of deletion" | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet | +| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | "URL of the pages with my data, Data to delete, Reason of deletion" | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet, https://www.cnil.fr/fr/webmaster-ou-responsables-de-sites-comment-repondre-aux-demandes-de-suppression-de-donnees | | 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | | 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | | 17 | **Where is stored the data organization has on me** | Know where is stored the data organization has on me | | | @@ -71,7 +71,7 @@ The design also aimes to maximise: | 21 | **When my data will be deleted** | Know when my data will be deleted | | | | 22 | **What is the policy of the organization to keep data it has on me** | Know what is the policy of the organization to keep data it has on me | | | | 23 | **What is the purpose of the treatment organization does on the data it has on me** | Know the purpose of the treatment organization does on the data it has on me | | | -| 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | | Type of treatment (to choose from possible type of treatment list | | +| 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | | 25 | **What type(s) of treatment organization does on the data it has on me** | Know what type(s) of treatment organization does on the data it has on me** | | | | 26 | **Know if a particular type of treatment is done by organisation on the data it has on me** | | Type of treatment (to choose from possible type of treatment list | | | 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | @@ -80,6 +80,8 @@ The design also aimes to maximise: | 30 | **Opt out of sale of my data** | Opposition to sale of the data an organization has on me| | | | 31 | **Opt out of tracking on my data** | Opposition to the tracking of my data from an organization | | | | 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| | | +| 33 | **Removal of my image online** | Remove photo or video of me that has been published without my consent| ID | https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne | +| 34 | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller | ID | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | ### Types of treatment list | Nb | Treatment | Description | CNIL reference From 44d4efa22ea2b9c5563298728209bd895d8ec21d Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 23 May 2022 10:34:33 +0200 Subject: [PATCH 017/204] about Data Subject Identities --- ...-rights-request-interoperability-format.md | 31 +++++++++++++++---- 1 file changed, 25 insertions(+), 6 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 5cebeb38..7b389912 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -4,7 +4,7 @@ | :------------ | :------------------------------------------------------------------------------------- | | **PR #** | [NNN](https://github.com/blindnet-io/PROJECT/pull/NNN) (update when you have PR #) | | **Author(s)** | milstan (milstan@blindnet.io), Clémentine VINCENT (clementine@blindnet.io) | -| **Sponsor** | Filip (filip@blindnet.io) | +| **Sponsor** | milstan (milstan@blindnet.io) | | **Updated** | 2022-05-19 | ## Objective @@ -37,9 +37,12 @@ The design also aimes to maximise: ## Terminology +>**TO BE Updated** once Lexicon and High Level Conceptualization are synchronised + - We use the terms Rights Request, Data Subject, System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) - We use the terms Rights Request and Data Rights Request interchangeably - We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) +- We use all the terms from the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) as defined there. ## Proposal @@ -214,9 +217,15 @@ Systems exchanging Rignts Requests MUST be able to do so in a way allowing them For this purposes Rignts Requests MAY be embedded as 'Claims' in [JWTs (FRC7519)](https://datatracker.ietf.org/doc/html/rfc7519). -### Globaly Unique Data Subject IDs +### Decentralized Identity of Data Subject + +The Systems are only able to provide control to Data Subjects if they can identify them. On the other hand, there is no cetnral authority to manage Data Subject identity globally. + +Therefore, we use a set of atributes to uniquely indenitfy one Data Subject. One and the same Data Subject can have multiple such identities. -The identifyers used to refer to Data Subjects MUST be globaly unique. One Data Subject ID corresponds to one Data Subject. One Data Subject can have several Data Subject IDs. +#### Globaly Unique Data Subject Identities + +The identifyers used to refer to Data Subjects MUST be globaly unique. One Data Subject identity corresponds to one Data Subject. One Data Subject can have several Data Subject Identity. When refering to a Data Subject, Systems MUST use both of the following atributes: - `dsid` - Data Subject ID @@ -224,9 +233,11 @@ When refering to a Data Subject, Systems MUST use both of the following atribute The (`dsid`,`dsid-schema`) pair denotes a globaly unique reference to always the same Data Subject. +We refer to (`dsid`,`dsid-schema`) pairs as Data Subject Identities. + A Rights Request MAY include several (`dsid`,`dsid-schema`) pairs that refer to the same user, in order to facilitate the interoperability of Rights Requests across systems. -### Data Subject ID Schemas +#### Data Subject ID Schemas Systems using RRIF MUST implement at least the following `dsid-schema`: @@ -246,16 +257,24 @@ Additional Data Subject ID Schemes MAY be definied by convention. For example th | ------------------- | ---- | |`global-id`| Indicates that the value of the corresponding `dsid` attribute is the `gid_name` - User's GlobaliD name - used to identify the Data Subject in [GlobalId](https://developer.global.id/documentation/api%2Fidentity.html)| -### Data Subject SHOULD be Authenticated +#### Data Subject SHOULD be Authenticated In some cases, valid reasons MAY exist for Systems to respond to Rights Requests even from anonymous Data Subjects. This is the case, for example, with request relative to general data treatment practices practiced by the system. -However, in most cases, Systems SHOULD require the Data Subject to be authenticated as being indeed the person corresponding to the (`dsid`,`dsid-schema`) pair. +However, in most cases, Systems MUST require the Data Subject to be authenticated as being indeed the person corresponding to the (`dsid`,`dsid-schema`) pair. When processing Rights Request, Systems MAY automatically disregard the (`dsid`,`dsid-schema`) paris for which they have not been able to establish Data Subject authentication. However, the authentication does not necessairly have to be performed during the collection of the Rights Request. It can be done separately. +#### Matching Multiple Data Subject Identities + +Systems MAY keep track of Data Subject Identities that refer to the same Data Subject. In some cases, valid reasons MAY exist for Systems to ignore such information. + +When Systems do know that one Data Subject Identity corresponds to the same user as another Data Subject Identity, then Systems SHOULD offer the Data Subject a possibility for their Rights Requests, expressed in relation to one Data Subject Identity to be automatically extended to include other equivalent Data Subject Identities. + +Systems SHOULD NOT imply Data Subject Identity equivalence from Rights Requests, especially when granding Rights Requests that require authentication. + ### Data Capture IDs, Data Capture Fragment IDs, Consent IDs, Rights Request IDs, Demand IDs, Rights Request Respons IDs are Globally Unique All of the following identifiers `data-capture-id`, `fragment-id`, `consent-id`, `rights-request-id`, `demand-id`, `rights-response-id` MUST be globally unique and be generated according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) in order for the corresponding objects to be easily identifiable across systems. From 22094e9b7dbd015455d2363c7e5765fa294b4f5f Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 23 May 2022 10:54:04 +0200 Subject: [PATCH 018/204] Update RFC-rights-request-interoperability-format.md --- ...-rights-request-interoperability-format.md | 52 +++++++++---------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index c80ae5a8..7ddf5112 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -48,38 +48,38 @@ The design also aimes to maximise: | Nb | Request | Description | Advised elements to provide| CNIL reference | ---------- | ---- | ---- | ---- |---- | -| 01 | **Access** | Access to all data the organization has on me | | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | -| 02 | **Modification** | Rectify incorrect data organization has on me | Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | -| 03 | **Rectify incomplete data organization has on me** | Rectify incomplete data organization has on me | Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | -| 04 | **Deletion** | Delete the data the organization has on me | Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | -| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | -| 06 | **Opposition to treatment of data organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | Reason of deletion | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | -| 07 | **Access to data financial organization has on me** | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me | Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | -| 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | Reason of deletion | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | +| 01 | **Access** | Access to all data the organization has on me | ID | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | +| 02 | **Modification** | Rectify incorrect data organization has on me | ID, Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | +| 03 | **Rectification** | Rectify incomplete data organization has on me | ID, Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | +| 04 | **Deletion** | Delete the data the organization has on me | ID, Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | +| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | ID, Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | +| 06 | **Opposition to treatment of all data an organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | ID, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | +| 07 | **Access to data a financial organization has on me** | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me | ID, Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | +| 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | ID, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | | 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** | Access to all data Fichier central des Chèques (FCC) has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | | 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** | Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | -| 11 | **Access geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | "Device type, Date and time" | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | -| 12 | **Access to video data** | Access to video data organization has on me on a specific period of time | Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | -| 13 | **Closing an online account** | "Closing online account, Deletion of all data the organization has on me " | Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | -| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | "URL of the pages with my data, Data to delete, Reason of deletion" | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet, https://www.cnil.fr/fr/webmaster-ou-responsables-de-sites-comment-repondre-aux-demandes-de-suppression-de-donnees | +| 11 | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | ID, Device type, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | +| 12 | **Access to video data** | Access to video data organization has on me on a specific period of time | ID, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | +| 13 | **Closing an online account** | Closing online account, Deletion of all data the organization has on me | ID, Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | +| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | ID, URL of the pages with my data, Data to delete, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet, https://www.cnil.fr/fr/webmaster-ou-responsables-de-sites-comment-repondre-aux-demandes-de-suppression-de-donnees | | 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | | 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | -| 17 | **Where is stored the data organization has on me** | Know where is stored the data organization has on me | | | -| 18 | **Who can access the data organization has on me** | Know who can access the data organization has on m | | | -| 19 | **What is the provenance of data organization has on me** | Know the provenance of data organization has on me | | | -| 20 | **For how long the data organization has me will be kept** | Know for how long the data organization has me will be kept | | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | -| 21 | **When my data will be deleted** | Know when my data will be deleted | | | -| 22 | **What is the policy of the organization to keep data it has on me** | Know what is the policy of the organization to keep data it has on me | | | -| 23 | **What is the purpose of the treatment organization does on the data it has on me** | Know the purpose of the treatment organization does on the data it has on me | | | +| 17 | **Where is stored the data organization has on me** | Know where is stored the data organization has on me | ID | | +| 18 | **Who can access the data organization has on me** | Know who can access the data organization has on m | ID | | +| 19 | **What is the provenance of data organization has on me** | Know the provenance of data organization has on me | ID | | +| 20 | **For how long the data organization has me will be kept** | Know for how long the data organization has me will be kept | ID | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | +| 21 | **When my data will be deleted** | Know when my data will be deleted | ID | | +| 22 | **What is the policy of the organization to keep data it has on me** | Know what is the policy of the organization to keep data it has on me | ID | | +| 23 | **What is the purpose of the treatment organization does on the data it has on me** | Know the purpose of the treatment organization does on the data it has on me | ID | | | 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | -| 25 | **What type(s) of treatment organization does on the data it has on me** | Know what type(s) of treatment organization does on the data it has on me** | | | -| 26 | **Know if a particular type of treatment is done by organisation on the data it has on me** | | Type of treatment (to choose from possible type of treatment list | | -| 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | +| 25 | **What type(s) of treatment organization does on the data it has on me** | Know what type(s) of treatment organization does on the data it has on me** | ID | | +| 26 | **Know if a particular type of treatment is done by organisation on the data it has on me** | | Type of treatment (to choose from possible type of treatment list), ID | | +| 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | Type of treatment (to choose from possible type of treatment list), ID | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | | 28 | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | | | -| 29 | **Opt out of automated decision making** | Opposition to automated decision making on the data organizatio has on me | | | -| 30 | **Opt out of sale of my data** | Opposition to sale of the data an organization has on me| | | -| 31 | **Opt out of tracking on my data** | Opposition to the tracking of my data from an organization | | | -| 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| | | +| 29 | **Opt out of automated decision making** | Opposition to automated decision making on the data organizatio has on me | ID | | +| 30 | **Opt out of sale of my data** | Opposition to sale of the data an organization has on me| ID | | +| 31 | **Opt out of tracking on my data** | Opposition to the tracking of my data from an organization | ID | | +| 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| ID | | | 33 | **Removal of my image online** | Remove photo or video of me that has been published without my consent| ID | https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne | | 34 | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller | ID | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | From 285daab29f48f96ba0d23cb437dd322c388a55ec Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 23 May 2022 11:01:20 +0200 Subject: [PATCH 019/204] Update RFC-rights-request-interoperability-format.md --- ...-rights-request-interoperability-format.md | 38 +++++++++++-------- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 7ddf5112..da71180d 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -48,22 +48,35 @@ The design also aimes to maximise: | Nb | Request | Description | Advised elements to provide| CNIL reference | ---------- | ---- | ---- | ---- |---- | +| XX | ACCESS TYPE | ---- | ---- |---- | | 01 | **Access** | Access to all data the organization has on me | ID | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | -| 02 | **Modification** | Rectify incorrect data organization has on me | ID, Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | -| 03 | **Rectification** | Rectify incomplete data organization has on me | ID, Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | -| 04 | **Deletion** | Delete the data the organization has on me | ID, Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | -| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | ID, Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | -| 06 | **Opposition to treatment of all data an organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | ID, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | +| 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | +| 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | | 07 | **Access to data a financial organization has on me** | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me | ID, Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | -| 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | ID, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | | 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** | Access to all data Fichier central des Chèques (FCC) has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | | 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** | Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | | 11 | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | ID, Device type, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | | 12 | **Access to video data** | Access to video data organization has on me on a specific period of time | ID, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | +| 34 | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller | ID | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | +| XX | MODIFICATION TYPE | ---- | ---- |---- | +| 02 | **Modification** | Rectify incorrect data organization has on me | ID, Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | +| 03 | **Rectification** | Rectify incomplete data organization has on me | ID, Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | +| XX | DELETION TYPE | ---- | ---- |---- | +| 04 | **Deletion** | Delete the data the organization has on me | ID, Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | +| 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | ID, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | | 13 | **Closing an online account** | Closing online account, Deletion of all data the organization has on me | ID, Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | | 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | ID, URL of the pages with my data, Data to delete, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet, https://www.cnil.fr/fr/webmaster-ou-responsables-de-sites-comment-repondre-aux-demandes-de-suppression-de-donnees | -| 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | -| 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | +| 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| ID | | +| 33 | **Removal of my image online** | Remove photo or video of me that has been published without my consent| ID | https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne | +| XX | OPPOSITION TO TREATMENT TYPE | ---- | ---- |---- | +| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | ID, Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | +| 06 | **Opposition to treatment of all data an organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | ID, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | +| 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | +| 29 | **Opt out of automated decision making** | Opposition to automated decision making on the data organizatio has on me | ID | | +| 30 | **Opt out of sale of my data** | Opposition to sale of the data an organization has on me| ID | | +| 31 | **Opt out of tracking on my data** | Opposition to the tracking of my data from an organization | ID | | +| 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | Type of treatment (to choose from possible type of treatment list), ID | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | +| XX | INFORMATIONNAL TYPE | ---- | ---- |---- | | 17 | **Where is stored the data organization has on me** | Know where is stored the data organization has on me | ID | | | 18 | **Who can access the data organization has on me** | Know who can access the data organization has on m | ID | | | 19 | **What is the provenance of data organization has on me** | Know the provenance of data organization has on me | ID | | @@ -71,17 +84,10 @@ The design also aimes to maximise: | 21 | **When my data will be deleted** | Know when my data will be deleted | ID | | | 22 | **What is the policy of the organization to keep data it has on me** | Know what is the policy of the organization to keep data it has on me | ID | | | 23 | **What is the purpose of the treatment organization does on the data it has on me** | Know the purpose of the treatment organization does on the data it has on me | ID | | -| 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | | 25 | **What type(s) of treatment organization does on the data it has on me** | Know what type(s) of treatment organization does on the data it has on me** | ID | | | 26 | **Know if a particular type of treatment is done by organisation on the data it has on me** | | Type of treatment (to choose from possible type of treatment list), ID | | -| 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | Type of treatment (to choose from possible type of treatment list), ID | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | +| XX | OTHER TYPE | ---- | ---- |---- | | 28 | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | | | -| 29 | **Opt out of automated decision making** | Opposition to automated decision making on the data organizatio has on me | ID | | -| 30 | **Opt out of sale of my data** | Opposition to sale of the data an organization has on me| ID | | -| 31 | **Opt out of tracking on my data** | Opposition to the tracking of my data from an organization | ID | | -| 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| ID | | -| 33 | **Removal of my image online** | Remove photo or video of me that has been published without my consent| ID | https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne | -| 34 | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller | ID | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | ### Types of treatment list | Nb | Treatment | Description | CNIL reference From 6b310311931e7cd543f1abfffd1b60cb3d132d8e Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 23 May 2022 11:57:53 +0200 Subject: [PATCH 020/204] Update RFC-rights-request-interoperability-format.md --- ...-rights-request-interoperability-format.md | 93 +++++++++---------- 1 file changed, 46 insertions(+), 47 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index da71180d..aeb49da0 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -48,7 +48,7 @@ The design also aimes to maximise: | Nb | Request | Description | Advised elements to provide| CNIL reference | ---------- | ---- | ---- | ---- |---- | -| XX | ACCESS TYPE | ---- | ---- |---- | +| -- | ACCESS TYPE | ---- | ---- |---- | | 01 | **Access** | Access to all data the organization has on me | ID | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | | 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | | 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | @@ -58,17 +58,17 @@ The design also aimes to maximise: | 11 | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | ID, Device type, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | | 12 | **Access to video data** | Access to video data organization has on me on a specific period of time | ID, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | | 34 | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller | ID | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | -| XX | MODIFICATION TYPE | ---- | ---- |---- | +| -- | MODIFICATION TYPE | ---- | ---- |---- | | 02 | **Modification** | Rectify incorrect data organization has on me | ID, Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | | 03 | **Rectification** | Rectify incomplete data organization has on me | ID, Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | -| XX | DELETION TYPE | ---- | ---- |---- | +| -- | DELETION TYPE | ---- | ---- |---- | | 04 | **Deletion** | Delete the data the organization has on me | ID, Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | | 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | ID, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | | 13 | **Closing an online account** | Closing online account, Deletion of all data the organization has on me | ID, Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | | 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | ID, URL of the pages with my data, Data to delete, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet, https://www.cnil.fr/fr/webmaster-ou-responsables-de-sites-comment-repondre-aux-demandes-de-suppression-de-donnees | | 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| ID | | | 33 | **Removal of my image online** | Remove photo or video of me that has been published without my consent| ID | https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne | -| XX | OPPOSITION TO TREATMENT TYPE | ---- | ---- |---- | +| -- | OPPOSITION TO TREATMENT TYPE | ---- | ---- |---- | | 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | ID, Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | | 06 | **Opposition to treatment of all data an organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | ID, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | | 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | @@ -76,17 +76,17 @@ The design also aimes to maximise: | 30 | **Opt out of sale of my data** | Opposition to sale of the data an organization has on me| ID | | | 31 | **Opt out of tracking on my data** | Opposition to the tracking of my data from an organization | ID | | | 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | Type of treatment (to choose from possible type of treatment list), ID | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | -| XX | INFORMATIONNAL TYPE | ---- | ---- |---- | -| 17 | **Where is stored the data organization has on me** | Know where is stored the data organization has on me | ID | | -| 18 | **Who can access the data organization has on me** | Know who can access the data organization has on m | ID | | -| 19 | **What is the provenance of data organization has on me** | Know the provenance of data organization has on me | ID | | -| 20 | **For how long the data organization has me will be kept** | Know for how long the data organization has me will be kept | ID | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | -| 21 | **When my data will be deleted** | Know when my data will be deleted | ID | | -| 22 | **What is the policy of the organization to keep data it has on me** | Know what is the policy of the organization to keep data it has on me | ID | | -| 23 | **What is the purpose of the treatment organization does on the data it has on me** | Know the purpose of the treatment organization does on the data it has on me | ID | | -| 25 | **What type(s) of treatment organization does on the data it has on me** | Know what type(s) of treatment organization does on the data it has on me** | ID | | -| 26 | **Know if a particular type of treatment is done by organisation on the data it has on me** | | Type of treatment (to choose from possible type of treatment list), ID | | -| XX | OTHER TYPE | ---- | ---- |---- | +| -- | INFORMATIONNAL TYPE | ---- | ---- |---- | +| 17 | **Storage information** | Know where is stored the data organization has on me | ID | | +| 18 | **Accessibility information** | Know who can access the data organization has on m | ID | | +| 19 | **Provenance information** | Know the provenance of data organization has on me | ID | | +| 20 | **Retention information** | Know for how long the data organization has on me will be kept | ID | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | +| 21 | **Deletion information** | Know when my data will be deleted | ID | | +| 22 | **Policy information** | Know what is the policy of the organization to keep data it has on me | ID | | +| 23 | **Purpose of treatment information** | Know the purpose of the treatment organization does on the data it has on me | ID | | +| 25 | **Treatment information** | Know what type(s) of treatment organization does on the data it has on me | ID | | +| 26 | **Particular type(s) of treatment information** | Know if a particular type of treatment is done by organisation on the data it has on me | Type of treatment (to choose from possible type of treatment list), ID | | +| -- | OTHER TYPE | ---- | ---- |---- | | 28 | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | | | ### Types of treatment list @@ -104,42 +104,41 @@ The design also aimes to maximise: | 11 | **Communication** | Data communication by transmission or broadcast or any other form of data communication | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | | 12| *FR: "Rapprochement" -> EN: "Matching" or "Reconciliation" ?* | | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | | 13 | **Automatic Inference and Descisionmaking** | Any automatic inference made on the data | [GDPR chap3 art. 13 section 2. c)](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre3#Article13)| -| XX | **Essential/basic** | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality | | -| XX | **Additonal functionality** | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | | -| XX | **Advertising** | To show ads that are either targeted to the specific user or not targeted | | -| XX | **Marketing** | To contact the user to offer products, services, or other promotions | | -| XX | **Analytics** | For understanding the product’s audience, improving the product, inform company strategy, or general research | | -| XX | **Personnalisation** | For providing user with a personalized experience | | -| XX | **Operation security** | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | -| XX | **Legal** | For compliance with legal obligations | | -| XX | **Ongoing contract** | | | -| XX | **Transfer** | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | -| XX | **Sale** | Selling data to third parties | | -| XX | **Ongoing contract** | | | -| XX | **OTHER** | Other specific purpose not covered above | | -| XX | **UNSPECIFIED** | The purpose is not explicitly stated or is unclear | | -| XX | **ALL** | | | +| 14 | **Basic service** | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality | | +| 15 | **Additonal service** | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | | +| 16 | **Advertising** | To show ads that are either targeted to the specific user or not targeted | | +| 17 | **Marketing** | To contact the user to offer products, services, or other promotions | | +| 18 | **Analytics** | For understanding the product’s audience, improving the product, inform company strategy, or general research | | +| 19 | **Personnalisation** | For providing user with a personalized experience | | +| 20 | **Operation security** | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | +| 21 | **Legal** | For compliance with legal obligations | | +| 22 | **Ongoing contract** | For ongoing contract purpose | | +| 23 | **Data transfer** | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | +| 24 | **Sale** | Selling data to third parties | | +| 25 | **OTHER** | Other specific purpose not covered above | | +| 26 | **UNSPECIFIED** | The purpose is not explicitly stated or is unclear | | +| 27 | **ALL** | | | ### Data categories list | Nb | Data category | Description | CNIL reference | ---------- | ---- | ---- | ---- | -| 01 | Name | Firstname, Surname | | -| 02 | Postal address | *contact information* | | -| 03 | Email address | *contact information* | | -| 04 | Phone number | *contact information* | | -| 04 | ID data | Identifiers that uniquely identify a person | | -| 05 | Financial data | | | -| 06 | Connection data | | | -| 07 | Location data | Geolocation information | | -| 08 | Health data | | | -| 09 | Online activity data | | | -| 10 | Tracking data | | | -| 11 | User profile | user’s profile on the first-party website/app and its contents | | -| 12 | Device data | | | -| 13 | Survey data | | | -| 14 | OTHER | A specific type of information not covered by the above categories | | -| 15 | UNSPECIFIED | The type of information is not explicitly stated or unclear| -| XX | **ALL** | | | +| 01 | **Name** | Firstname, Surname | | +| 02 | **Postal address** | *contact information* | | +| 03 | **Email address** | *contact information* | | +| 04 | **Phone number** | *contact information* | | +| 04 | **ID data** | Identifiers that uniquely identify a person | | +| 05 | **Financial data** | Financial information | | +| 06 | **Connection data** | Information associated to connection | | +| 07 | **Location data** | Geolocation information | | +| 08 | **Health data** | Health information | | +| 09 | **Online activity data** | The user's online activities on the first party website/app or other websites/apps | | +| 10 | **Tracking data** | Cookies and tracking information | | +| 11 | **User profile** | user’s profile on the first-party website/app and its contents | | +| 12 | **Device data** | Device (desktop, tablet, mobile...) information | | +| 13 | **Form data** | Information collected through forms | | +| 14 | **OTHER** | A specific type of information not covered by the above categories | | +| 15 | **UNSPECIFIED** | The type of information is not explicitly stated or unclear| +| 16 | **ALL** | | | ### Alternatives Considered From b00d85b2c746f3763298960995018f332e0d5fec Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 23 May 2022 12:07:19 +0200 Subject: [PATCH 021/204] about transitive requests --- ...-rights-request-interoperability-format.md | 40 ++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 7b389912..b0e2941c 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -47,6 +47,36 @@ The design also aimes to maximise: ## Proposal +### Rights Request + +A Rights Request is made by a Data Subject. +An array of one or more [Data Subject Identities](#decentralized-identity-of-data-subjects) MUST be provided in order to match the Data Subject with the data concerning them. + +The Data Subject can request several things (e.g. see the data the System has on me, and have it deleted). +A Rights Request includes an array of one or more Demands. + +#### Demands + +#### Transitive Rights Request + +A Rights Request can be transitive. +Transitive Rights Requests are usefull in a distributed context where System A gave information about the Data Subject to System B, and System B gave information about the Data Subject to System C. + +When a System receives a transitive Rights Request, it SHOULD not only respond to it, but also transfer it to corresponding Systems with which it exchnaged data about the Data Subject. + +Transitivity of Rights Requests can be `DOWNWARD` `UPWARD`, `BIDIRECTIONAL` or `INTRANSITIVE`. In the absence of any indication `INTRANSITIVE` SHOULD be assumed. + +When System B receives a `DOWNWARD` transitive Rights Request, it MUST also send it to all systems to which it tranfered data about the Data Subject (System C). +When System B receives a `UPWARD` transitive Rights Request, it MUST also send it to all systems from which it obtained data about the Data Subject (System A). +When System B receives a `BIDIRECTIONAL` transitive Rights Request, it MUST also send it to all systems from which it obtained data about the Data Subject or to which it gave information about the Data Subject (System A and System C). +When System B receives an `INTRANSITIVE` Rights Request, it SHOULD NOT transfer it to any other system. + +Systems should interpret the transitivity of Rights Request the same way regardless of the Rights Request being received directly from the Data Subject or from a corresponding System. + +> **Note** +> +> Systems that exchange Data Subject information with other Systems MUST expose an interface for receiving Rights Requests from those other Systems. + ### Requests list | Nb | Request | Description | Advised elements to provide| CNIL reference @@ -217,7 +247,7 @@ Systems exchanging Rignts Requests MUST be able to do so in a way allowing them For this purposes Rignts Requests MAY be embedded as 'Claims' in [JWTs (FRC7519)](https://datatracker.ietf.org/doc/html/rfc7519). -### Decentralized Identity of Data Subject +### Decentralized Identity of Data Subjects The Systems are only able to provide control to Data Subjects if they can identify them. On the other hand, there is no cetnral authority to manage Data Subject identity globally. @@ -279,6 +309,14 @@ Systems SHOULD NOT imply Data Subject Identity equivalence from Rights Requests, All of the following identifiers `data-capture-id`, `fragment-id`, `consent-id`, `rights-request-id`, `demand-id`, `rights-response-id` MUST be globally unique and be generated according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) in order for the corresponding objects to be easily identifiable across systems. +### Remembering Transfers + +When data about Data Subjects is transmitted from one system to another, in order to be able to process [Transitive Rights Requests](#transitive-rights-request), Systems MUST keep track of: +- System of destination/origin +- Categories of data being trasnfered +- Identifiers (`data-capture-id`s,`fragment-id`s) associated to the data being trasnfered +- Consents (`consent-id`) associated to the data being trasnfered +- Data Subject Identities (`dsid`,`dsid-schema`) pairs associated to the data being trasnfered ## Questions and Discussion Topics From d0c88fc091b24cb5c8de863cc66f55ed8066507e Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 23 May 2022 12:27:39 +0200 Subject: [PATCH 022/204] nested responses --- refs/schemas/RFC-rights-request-interoperability-format.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index b0e2941c..18710429 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -73,9 +73,6 @@ When System B receives an `INTRANSITIVE` Rights Request, it SHOULD NOT transfer Systems should interpret the transitivity of Rights Request the same way regardless of the Rights Request being received directly from the Data Subject or from a corresponding System. -> **Note** -> -> Systems that exchange Data Subject information with other Systems MUST expose an interface for receiving Rights Requests from those other Systems. ### Requests list @@ -318,6 +315,10 @@ When data about Data Subjects is transmitted from one system to another, in orde - Consents (`consent-id`) associated to the data being trasnfered - Data Subject Identities (`dsid`,`dsid-schema`) pairs associated to the data being trasnfered +> **Note** +> +> Systems that exchange Data Subject information with other Systems MUST expose an interface for receiving Rights Requests from those other Systems. They MUST aslo be able to gather Rights Request Responses from other Systems in the case of [Nested Responses Scenario](https://github.com/blindnet-io/product-management/tree/devkit-schemas/refs/high-level-architecture#different-rights-request-response-scenrarios). + ## Questions and Discussion Topics ### Use UUID for identifying Data Subjects From 285948a6ab364478cd266d1e8878636b1eb721e8 Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 23 May 2022 12:56:01 +0200 Subject: [PATCH 023/204] Enum of eligible values for TRANSITIVITY --- refs/schemas/dictionary/transitivity/en.transitivity.json | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 refs/schemas/dictionary/transitivity/en.transitivity.json diff --git a/refs/schemas/dictionary/transitivity/en.transitivity.json b/refs/schemas/dictionary/transitivity/en.transitivity.json new file mode 100644 index 00000000..31d80961 --- /dev/null +++ b/refs/schemas/dictionary/transitivity/en.transitivity.json @@ -0,0 +1,6 @@ +{ + "INTRANSITIVE": "Do not transfer this Rights Request to any other system", + "BIDIRECTIONAL": "Transfer this Rights Request to systems that gave or that received data about me", + "DOWNWARD": "Transfer this Rights Request to all the systems which you have shared my data with", + "UPWARD": "Transfer this Rights Request to all the systems that have shared my data with you" +} From 987d9dc79841478b2aa28b78f8a3f151bd4973fb Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 23 May 2022 15:02:16 +0200 Subject: [PATCH 024/204] Update RFC-rights-request-interoperability-format.md --- ...C-rights-request-interoperability-format.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index aeb49da0..06ebbe6a 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -52,12 +52,12 @@ The design also aimes to maximise: | 01 | **Access** | Access to all data the organization has on me | ID | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | | 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | | 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | -| 07 | **Access to data a financial organization has on me** | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me | ID, Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | +| 07 | **Access to data a financial organization has on me** | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me *(access+provenance info request)* | ID, Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | | 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** | Access to all data Fichier central des Chèques (FCC) has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | | 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** | Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | -| 11 | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time | ID, Device type, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | -| 12 | **Access to video data** | Access to video data organization has on me on a specific period of time | ID, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | -| 34 | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller | ID | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | +| 11 | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time *access request to geolocation data and device data* | ID, Device type, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | +| 12 | **Access to video surveillance data** | Access to video data organization has on me on a specific period of time *access request to video surveillance data* | ID, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | +| 34 | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller *access request + donwnload?* | ID | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | | -- | MODIFICATION TYPE | ---- | ---- |---- | | 02 | **Modification** | Rectify incorrect data organization has on me | ID, Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | | 03 | **Rectification** | Rectify incomplete data organization has on me | ID, Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | @@ -129,16 +129,18 @@ The design also aimes to maximise: | 04 | **ID data** | Identifiers that uniquely identify a person | | | 05 | **Financial data** | Financial information | | | 06 | **Connection data** | Information associated to connection | | -| 07 | **Location data** | Geolocation information | | +| 07 | **Geoocation data** | Location information | | | 08 | **Health data** | Health information | | | 09 | **Online activity data** | The user's online activities on the first party website/app or other websites/apps | | | 10 | **Tracking data** | Cookies and tracking information | | | 11 | **User profile** | user’s profile on the first-party website/app and its contents | | | 12 | **Device data** | Device (desktop, tablet, mobile...) information | | | 13 | **Form data** | Information collected through forms | | -| 14 | **OTHER** | A specific type of information not covered by the above categories | | -| 15 | **UNSPECIFIED** | The type of information is not explicitly stated or unclear| -| 16 | **ALL** | | | +| 14 | **Image data** | Photo or video | | +| 15 | **Video surveillance data** | Video from video surveillance | | +| 16 | **OTHER** | A specific type of information not covered by the above categories | | +| 17 | **UNSPECIFIED** | The type of information is not explicitly stated or unclear| +| 18 | **ALL** | | | ### Alternatives Considered From b737f59cbb78285b3ae0ffaa6cf27056f7492c20 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 23 May 2022 17:26:00 +0200 Subject: [PATCH 025/204] Update RFC-rights-request-interoperability-format.md --- ...-rights-request-interoperability-format.md | 60 +++++++++---------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 06ebbe6a..9102058d 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -52,15 +52,15 @@ The design also aimes to maximise: | 01 | **Access** | Access to all data the organization has on me | ID | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | | 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | | 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | -| 07 | **Access to data a financial organization has on me** | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me *(access+provenance info request)* | ID, Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | -| 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** | Access to all data Fichier central des Chèques (FCC) has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | -| 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** | Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | +| 07 | **Access to data a financial organization has on me** *-> to delete and let user make access request + provenance request to the financial organization* | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me *(access+provenance info request)* | ID, Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | +| 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** *-> to delete and let user make access request to the "Fichier central des Chèques (FCC)" ?*| Access to all data Fichier central des Chèques (FCC) has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | +| 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** *-> to delete and let user make access request to the "Fichier national des Incidents de remboursement de Crédit (FICP)" ?*| Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | | 11 | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time *access request to geolocation data and device data* | ID, Device type, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | | 12 | **Access to video surveillance data** | Access to video data organization has on me on a specific period of time *access request to video surveillance data* | ID, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | | 34 | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller *access request + donwnload?* | ID | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | | -- | MODIFICATION TYPE | ---- | ---- |---- | | 02 | **Modification** | Rectify incorrect data organization has on me | ID, Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | -| 03 | **Rectification** | Rectify incomplete data organization has on me | ID, Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | +| 03 | **Rectification** *to merge in one modification?* | Rectify incomplete data organization has on me | ID, Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | | -- | DELETION TYPE | ---- | ---- |---- | | 04 | **Deletion** | Delete the data the organization has on me | ID, Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | | 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | ID, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | @@ -71,10 +71,10 @@ The design also aimes to maximise: | -- | OPPOSITION TO TREATMENT TYPE | ---- | ---- |---- | | 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | ID, Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | | 06 | **Opposition to treatment of all data an organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | ID, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | -| 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | Type of treatment (to choose from possible type of treatment list | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | -| 29 | **Opt out of automated decision making** | Opposition to automated decision making on the data organizatio has on me | ID | | -| 30 | **Opt out of sale of my data** | Opposition to sale of the data an organization has on me| ID | | -| 31 | **Opt out of tracking on my data** | Opposition to the tracking of my data from an organization | ID | | +| 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | Type of treatment (to choose from possible type of treatment list) | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | +| 29 | **Opt out of automated decision making** *-> to delete to include in 24. Limit treatment* | Opposition to automated decision making on the data organizatio has on me | ID | | +| 30 | **Opt out of sale of my data** *-> to delete to include in 24. Limit treatment* | Opposition to sale of the data an organization has on me| ID | | +| 31 | **Opt out of tracking on my data** *-> to delete to include in 24. Limit treatment* | Opposition to the tracking of my data from an organization | ID | | | 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | Type of treatment (to choose from possible type of treatment list), ID | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | | -- | INFORMATIONNAL TYPE | ---- | ---- |---- | | 17 | **Storage information** | Know where is stored the data organization has on me | ID | | @@ -106,18 +106,19 @@ The design also aimes to maximise: | 13 | **Automatic Inference and Descisionmaking** | Any automatic inference made on the data | [GDPR chap3 art. 13 section 2. c)](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre3#Article13)| | 14 | **Basic service** | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality | | | 15 | **Additonal service** | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | | -| 16 | **Advertising** | To show ads that are either targeted to the specific user or not targeted | | -| 17 | **Marketing** | To contact the user to offer products, services, or other promotions | | -| 18 | **Analytics** | For understanding the product’s audience, improving the product, inform company strategy, or general research | | -| 19 | **Personnalisation** | For providing user with a personalized experience | | -| 20 | **Operation security** | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | -| 21 | **Legal** | For compliance with legal obligations | | -| 22 | **Ongoing contract** | For ongoing contract purpose | | -| 23 | **Data transfer** | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | -| 24 | **Sale** | Selling data to third parties | | -| 25 | **OTHER** | Other specific purpose not covered above | | -| 26 | **UNSPECIFIED** | The purpose is not explicitly stated or is unclear | | -| 27 | **ALL** | | | +| 16 | **Tracking** | Tracking information about user behavior and activity online | | +| 17 | **Advertising** | To show ads that are either targeted to the specific user or not targeted | | +| 18 | **Marketing** | To contact the user to offer products, services, or other promotions | | +| 19 | **Analytics** | For understanding the product’s audience, improving the product, inform company strategy, or general research | | +| 20 | **Personnalisation** | For providing user with a personalized experience | | +| 21 | **Operation security** | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | +| 22 | **Legal** | For compliance with legal obligations | | +| 23 | **Ongoing contract** | For ongoing contract purpose | | +| 24 | **Data transfer** | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | +| 25 | **Sale** | Selling data to third parties | | +| 26 | **OTHER** | Other specific purpose not covered above | | +| 27 | **UNSPECIFIED** | The purpose is not explicitly stated or is unclear | | +| 28 | **ALL** | | | ### Data categories list | Nb | Data category | Description | CNIL reference @@ -131,16 +132,15 @@ The design also aimes to maximise: | 06 | **Connection data** | Information associated to connection | | | 07 | **Geoocation data** | Location information | | | 08 | **Health data** | Health information | | -| 09 | **Online activity data** | The user's online activities on the first party website/app or other websites/apps | | -| 10 | **Tracking data** | Cookies and tracking information | | -| 11 | **User profile** | user’s profile on the first-party website/app and its contents | | -| 12 | **Device data** | Device (desktop, tablet, mobile...) information | | -| 13 | **Form data** | Information collected through forms | | -| 14 | **Image data** | Photo or video | | -| 15 | **Video surveillance data** | Video from video surveillance | | -| 16 | **OTHER** | A specific type of information not covered by the above categories | | -| 17 | **UNSPECIFIED** | The type of information is not explicitly stated or unclear| -| 18 | **ALL** | | | +| 09 | **Tracking data** | Cookies and tracking information about user behavior and activity online| | +| 10 | **User profile** | User’s profile on the first-party website/app and its contents | | +| 11 | **Device data** | Device (desktop, tablet, mobile...) information | | +| 12 | **Form data** | Information collected through forms | | +| 13 | **Image data** | Photo or video | | +| 14 | **Video surveillance data** | Video from video surveillance | | +| 15 | **OTHER** | A specific type of information not covered by the above categories | | +| 16 | **UNSPECIFIED** | The type of information is not explicitly stated or unclear| +| 17 | **ALL** | | | ### Alternatives Considered From c6480d7a95a9a5e0a12e16de27c2274c1a51d3ee Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 23 May 2022 17:52:45 +0200 Subject: [PATCH 026/204] Update RFC-rights-request-interoperability-format.md --- ...-rights-request-interoperability-format.md | 74 +++++++++---------- 1 file changed, 37 insertions(+), 37 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 9102058d..9596997e 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -46,48 +46,48 @@ The design also aimes to maximise: ### Requests list -| Nb | Request | Description | Advised elements to provide| CNIL reference -| ---------- | ---- | ---- | ---- |---- | -| -- | ACCESS TYPE | ---- | ---- |---- | -| 01 | **Access** | Access to all data the organization has on me | ID | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | -| 15 | **Access to my medical record** | Acces to my medical record | ID | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | -| 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ID | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | -| 07 | **Access to data a financial organization has on me** *-> to delete and let user make access request + provenance request to the financial organization* | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me *(access+provenance info request)* | ID, Account number | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | -| 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** *-> to delete and let user make access request to the "Fichier central des Chèques (FCC)" ?*| Access to all data Fichier central des Chèques (FCC) has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | -| 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** *-> to delete and let user make access request to the "Fichier national des Incidents de remboursement de Crédit (FICP)" ?*| Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ID, Birthdate | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | -| 11 | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time *access request to geolocation data and device data* | ID, Device type, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | -| 12 | **Access to video surveillance data** | Access to video data organization has on me on a specific period of time *access request to video surveillance data* | ID, Date and time | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | -| 34 | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller *access request + donwnload?* | ID | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | +| Nb | Request | Description | Associated treatment | Associated data category | Advised elements to provide | Legal ground | CNIL reference +| ---------- | ---- | ---- | ---- | ---- | ---- | ---- |---- | +| -- | ACCESS TYPE | ---- | ---- | ---- | ---- | ---- | ---- | +| 01 | **Access** | Access to all data the organization has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | +| 15 | **Access to my medical record** | Acces to my medical record | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | +| 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | +| 07 | **Access to data a financial organization has on me** *-> to delete and let user make access request + provenance request to the financial organization* | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me *(access+provenance info request)* | ---- | ---- | ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | +| 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** *-> to delete and let user make access request to the "Fichier central des Chèques (FCC)" ?*| Access to all data Fichier central des Chèques (FCC) has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | +| 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** *-> to delete and let user make access request to the "Fichier national des Incidents de remboursement de Crédit (FICP)" ?*| Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | +| 11 | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time *access request to geolocation data and device data* | ---- | ---- | ID, Device type, Date and time | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | +| 12 | **Access to video surveillance data** | Access to video data organization has on me on a specific period of time *access request to video surveillance data* | ---- | ---- | ID, Date and time | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | +| 34 | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller *access request + donwnload?* | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | | -- | MODIFICATION TYPE | ---- | ---- |---- | -| 02 | **Modification** | Rectify incorrect data organization has on me | ID, Information to modify, Information rectified (PF Access request + diff) | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | -| 03 | **Rectification** *to merge in one modification?* | Rectify incomplete data organization has on me | ID, Information to modify, Information rectified | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | +| 02 | **Modification** | Rectify incorrect data organization has on me | ---- | ---- | ID, Information to modify, Information rectified | ---- | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | +| 03 | **Rectification** *to merge in one modification?* | Rectify incomplete data organization has on me | ---- | ---- | ID, Information to modify, Information rectified | ---- | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | | -- | DELETION TYPE | ---- | ---- |---- | -| 04 | **Deletion** | Delete the data the organization has on me | ID, Information to delete*, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | -| 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | ID, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | -| 13 | **Closing an online account** | Closing online account, Deletion of all data the organization has on me | ID, Account name, Website name, URL of the pages with my data, Data to delete | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | -| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | ID, URL of the pages with my data, Data to delete, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet, https://www.cnil.fr/fr/webmaster-ou-responsables-de-sites-comment-repondre-aux-demandes-de-suppression-de-donnees | -| 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| ID | | -| 33 | **Removal of my image online** | Remove photo or video of me that has been published without my consent| ID | https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne | +| 04 | **Deletion** | Delete the data the organization has on me | ---- | ---- | ID, Information to delete*, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | +| 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | ---- | ---- | ID, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | +| 13 | **Closing an online account** | Closing online account, Deletion of all data the organization has on me | ---- | ---- | ID, Account name, Website name, URL of the pages with my data, Data to delete | ---- | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | +| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | ---- | ---- | ID, URL of the pages with my data, Data to delete, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet, https://www.cnil.fr/fr/webmaster-ou-responsables-de-sites-comment-repondre-aux-demandes-de-suppression-de-donnees | +| 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| ---- | ---- | ID | ---- | | +| 33 | **Removal of my image online** | Remove photo or video of me that has been published without my consent| ---- | ---- | ID | ---- | https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne | | -- | OPPOSITION TO TREATMENT TYPE | ---- | ---- |---- | -| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | ID, Account number | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | -| 06 | **Opposition to treatment of all data an organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | ID, Reason of deletion | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | -| 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | Type of treatment (to choose from possible type of treatment list) | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | -| 29 | **Opt out of automated decision making** *-> to delete to include in 24. Limit treatment* | Opposition to automated decision making on the data organizatio has on me | ID | | -| 30 | **Opt out of sale of my data** *-> to delete to include in 24. Limit treatment* | Opposition to sale of the data an organization has on me| ID | | -| 31 | **Opt out of tracking on my data** *-> to delete to include in 24. Limit treatment* | Opposition to the tracking of my data from an organization | ID | | -| 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | Type of treatment (to choose from possible type of treatment list), ID | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | +| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | ---- | ---- |ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | +| 06 | **Opposition to treatment of all data an organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | ---- | ---- | ID, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | +| 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | *Type of treatment (to choose from possible type of treatment list)* | ---- | | ---- | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | +| 29 | **Opt out of automated decision making** *-> to delete to include in 24. Limit treatment* | Opposition to automated decision making on the data organizatio has on me | ---- | ---- | ID | ---- | | +| 30 | **Opt out of sale of my data** *-> to delete to include in 24. Limit treatment* | Opposition to sale of the data an organization has on me| ---- | ---- | ID | ---- | | +| 31 | **Opt out of tracking on my data** *-> to delete to include in 24. Limit treatment* | Opposition to the tracking of my data from an organization | ---- | ---- | ID | ---- | | +| 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | *Type of treatment (to choose from possible type of treatment list)* | ---- | ID | ---- | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | | -- | INFORMATIONNAL TYPE | ---- | ---- |---- | -| 17 | **Storage information** | Know where is stored the data organization has on me | ID | | -| 18 | **Accessibility information** | Know who can access the data organization has on m | ID | | -| 19 | **Provenance information** | Know the provenance of data organization has on me | ID | | -| 20 | **Retention information** | Know for how long the data organization has on me will be kept | ID | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | -| 21 | **Deletion information** | Know when my data will be deleted | ID | | -| 22 | **Policy information** | Know what is the policy of the organization to keep data it has on me | ID | | -| 23 | **Purpose of treatment information** | Know the purpose of the treatment organization does on the data it has on me | ID | | -| 25 | **Treatment information** | Know what type(s) of treatment organization does on the data it has on me | ID | | -| 26 | **Particular type(s) of treatment information** | Know if a particular type of treatment is done by organisation on the data it has on me | Type of treatment (to choose from possible type of treatment list), ID | | +| 17 | **Storage information** | Know where is stored the data organization has on me | ---- | ---- | ID | ---- | | +| 18 | **Accessibility information** | Know who can access the data organization has on me | ---- | ---- | ID | ---- | | +| 19 | **Provenance information** | Know the provenance of data organization has on me | ---- | ---- | ID | ---- | | +| 20 | **Retention information** | Know for how long the data organization has on me will be kept | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | +| 21 | **Deletion information** | Know when my data will be deleted | ---- | ---- | ID | ---- | | +| 22 | **Policy information** | Know what is the policy of the organization to keep data it has on me | ---- | ---- | ID | ---- | | +| 23 | **Purpose of treatment information** | Know the purpose of the treatment organization does on the data it has on me | ---- | ---- | ID | ---- | | +| 25 | **Treatment information** | Know what type(s) of treatment organization does on the data it has on me | ---- | ---- | ID | ---- | | +| 26 | **Particular type(s) of treatment information** | Know if a particular type of treatment is done by organisation on the data it has on me | *Type of treatment (to choose from possible type of treatment list)* | ---- | ID | ---- | | | -- | OTHER TYPE | ---- | ---- |---- | -| 28 | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | | | +| 28 | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | ---- | ---- | | ---- | | ### Types of treatment list | Nb | Treatment | Description | CNIL reference From 3a8f3c47696c8c628af810e3d0300da5b343d3e8 Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 23 May 2022 20:58:18 +0200 Subject: [PATCH 027/204] about reply-to mode --- ...-rights-request-interoperability-format.md | 60 +++++++++++++++++-- 1 file changed, 55 insertions(+), 5 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 713f8a50..ed31ed6d 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -4,7 +4,7 @@ | :------------ | :------------------------------------------------------------------------------------- | | **PR #** | [NNN](https://github.com/blindnet-io/PROJECT/pull/NNN) (update when you have PR #) | | **Author(s)** | milstan (milstan@blindnet.io), Clémentine VINCENT (clementine@blindnet.io) | -| **Sponsor** | milstan (milstan@blindnet.io) | +| **Sponsor** | milstan (milstan@blindnet.io) | | **Updated** | 2022-05-19 | ## Objective @@ -49,10 +49,23 @@ The design also aimes to maximise: ### Rights Request -A Rights Request is made by a Data Subject. +Data Subjects is the author of a Rights Request. + +| Schema propery | JSON Type | Expected cardinality | Expected values | +| --------------- | ------------ | ------ | -------------------- | +| 'data-subject' | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | An array of objects, each containing a (`dsid`,`dsid-schema`) pair | + An array of one or more [Data Subject Identities](#decentralized-identity-of-data-subjects) MUST be provided in order to match the Data Subject with the data concerning them. +In addition, the Rights Request has other meta-data: + +| Schema propery | JSON Type | Expected cardinality | Expected values | +| --------------- | ------------ | ------ | -------------------- | +| 'date' | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | Date and Time when Rights Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| 'language' | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | **TBD format** Language of textual message associated with demands | + The Data Subject can request several things (e.g. see the data the System has on me, and have it deleted). + A Rights Request includes an array of one or more Demands. #### Demands @@ -64,6 +77,10 @@ Transitive Rights Requests are usefull in a distributed context where System A g When a System receives a transitive Rights Request, it SHOULD not only respond to it, but also transfer it to corresponding Systems with which it exchnaged data about the Data Subject. +| Schema propery | JSON Type | Expected cardinality | Expected values | +| --------------- | ------------ | ------ | -------------------- | +| 'transitivity' | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | One of {`DOWNWARD`, `UPWARD`, `BIDIRECTIONAL`, `INTRANSITIVE`} | + Transitivity of Rights Requests can be `DOWNWARD` `UPWARD`, `BIDIRECTIONAL` or `INTRANSITIVE`. In the absence of any indication `INTRANSITIVE` SHOULD be assumed. When System B receives a `DOWNWARD` transitive Rights Request, it MUST also send it to all systems to which it tranfered data about the Data Subject (System C). @@ -73,6 +90,19 @@ When System B receives an `INTRANSITIVE` Rights Request, it SHOULD NOT transfer Systems should interpret the transitivity of Rights Request the same way regardless of the Rights Request being received directly from the Data Subject or from a corresponding System. +Convenient tables of Transitivity vlaues and corresponding user-facing descriptions, in different languages, are provided [here](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/schemas/dictionary/transitivity/). + +#### Reply-to + +In a distributed context, where one System transmits the Rights Request to another System, a `reply-to` field MAY be specified. + +| Schema propery | JSON Type | Expected cardinality | Expected values | +| --------------- | ------------ | ------ | -------------------- | +| 'reply-to' | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | One of {`SYSTEM`, `USER`} | + +`SYSTEM` indicates that the [scenario of nested responses](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#scenario-1---nested-responses) is prefered. The System having registered the Rights Request from the Data Subject gathers responses and presents them to the Data Subject. + +`USER` indicated the [scenario of direct responses](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#scenario-2---direct-responses) is prefered. Each System having received a Rights Request is expected to reply directly to the Data Subject, using contact information it has. ### Requests list @@ -261,7 +291,7 @@ Therefore, we use a set of atributes to uniquely indenitfy one Data Subject. One #### Globaly Unique Data Subject Identities -The identifyers used to refer to Data Subjects MUST be globaly unique. One Data Subject identity corresponds to one Data Subject. One Data Subject can have several Data Subject Identity. +The identifiers used to refer to Data Subjects MUST be globaly unique. One Data Subject identity corresponds to one Data Subject. One Data Subject can have several Data Subject Identity. When refering to a Data Subject, Systems MUST use both of the following atributes: - `dsid` - Data Subject ID @@ -318,7 +348,7 @@ All of the following identifiers `data-capture-id`, `fragment-id`, `consent-id`, ### Remembering Transfers When data about Data Subjects is transmitted from one system to another, in order to be able to process [Transitive Rights Requests](#transitive-rights-request), Systems MUST keep track of: -- System of destination/origin +- System of destination/origin and addresses where their APIs can be reached - Categories of data being trasnfered - Identifiers (`data-capture-id`s,`fragment-id`s) associated to the data being trasnfered - Consents (`consent-id`) associated to the data being trasnfered @@ -326,10 +356,30 @@ When data about Data Subjects is transmitted from one system to another, in orde > **Note** > -> Systems that exchange Data Subject information with other Systems MUST expose an interface for receiving Rights Requests from those other Systems. They MUST aslo be able to gather Rights Request Responses from other Systems in the case of [Nested Responses Scenario](https://github.com/blindnet-io/product-management/tree/devkit-schemas/refs/high-level-architecture#different-rights-request-response-scenrarios). +> Systems that exchange Data Subject information with other Systems MUST: +> - expose an API for communicating with other systems about Rights Requests: +> - receiving Rights Requests from those other Systems, +> - receiving Rights Request Responses from other Systems in the case of [Nested Responses Scenario](https://github.com/blindnet-io/product-management/tree/devkit-schemas/refs/high-level-architecture#different-rights-request-response-scenrarios). + ## Questions and Discussion Topics ### Use UUID for identifying Data Subjects We chould immagine an alternative design, where we would force systems to use an [UUID]([uuid](https://en.wikipedia.org/wiki/Universally_unique_identifier)) (according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html)), to identify the users. That would require us to provide some way for systems to match UUIDs with their local IDs (usernames, or e-mails), and would ponteltially limit the ability of 3rd party systems to interprete Rights Request made at another system. This goal of proposed design is to allow for flexibility. However it is a very important aspect of the proposal, that deserves further debate. + +### Mandatory properties and value constrains + +Should we include rescritions in the schema according to the [JSON-schema-validation vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#page-4) in order to make certian properties mandatory and ensure to limit string values to the values we suppoort? + +In the curent proposal, this is the case for Transitivity, but not for request types, data categories, and user identity schemas. We might want to include more forma constraints there, or deliberately leave flexibility. This is a discussion we need to have. + +## References + +### Normative References + + +- **[RFC8259]** Bray, T., ["The JavaScript Object Notation (JSON) Data Interchange Format"](https://datatracker.ietf.org/doc/html/rfc8259), STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. + +### Informative References +- From 236b71fc9d15b25d07c817a1a4ff228ed1a09884 Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 23 May 2022 20:58:41 +0200 Subject: [PATCH 028/204] first draft of schema - many things still missing WIP --- refs/schemas/drrif.schema.json | 53 ++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 refs/schemas/drrif.schema.json diff --git a/refs/schemas/drrif.schema.json b/refs/schemas/drrif.schema.json new file mode 100644 index 00000000..9d7a8d5e --- /dev/null +++ b/refs/schemas/drrif.schema.json @@ -0,0 +1,53 @@ +{ + "$id": "https://blindnet.io/schemas/rights-request", + "$schema": "https://json-schema.org/draft/2020-12/schema", + + "title": "Data Rights Request", + "description": "This document defines a format for interoperability of Data Rights Requests", + + "type": "object", + "properties": { + "rights-request-id": { + "description": "Unique Identifier of the Rights Request", + "type": "string", + "format": "uuid" + }, + "transitivity": { + "description": "Transitivity of the Data Rights Request. One of {DOWNWARD,UPWARD,BIDIRECTIONAL,INTRANSITIVE}.", + "enum": ["DOWNWARD","UPWARD","BIDIRECTIONAL","INTRANSITIVE"] + }, + "date": { + "description": "Date and Time of the request", + "type": "string", + "format": "date-time" + }, + "reply-to": { + "description": "Mode of Reply - to the SYSTEM that the Rights Request was received from or to the USER Data Subject directly", + "enum": ["SYSTEM","USER"] + }, + }, + + "required": ["rights-request-id", "timestamp"], + + "definitions": { + + }, + + "$defs": { + "data-subject-identity": { + "$id": "/schemas/data-subject-identity", + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + + "properties": { + "dsid-schema": { "type": "string" }, + "dsid": { "type": "string" }, + }, + + "required": ["dsid-schema", "dsid"], + + }, + +} + + } From 64d68be62137427d1ceb2886ebd59dc4609a94cc Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 23 May 2022 21:22:10 +0200 Subject: [PATCH 029/204] request-id --- refs/schemas/drrif.schema.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/drrif.schema.json b/refs/schemas/drrif.schema.json index 9d7a8d5e..0151fbe5 100644 --- a/refs/schemas/drrif.schema.json +++ b/refs/schemas/drrif.schema.json @@ -7,7 +7,7 @@ "type": "object", "properties": { - "rights-request-id": { + "request-id": { "description": "Unique Identifier of the Rights Request", "type": "string", "format": "uuid" From d1e56ea7d916ab9dd34230a5d64b6f420a88336f Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 11:03:15 +0200 Subject: [PATCH 030/204] adding data categories --- ...-rights-request-interoperability-format.md | 38 ++++++++++++++++--- 1 file changed, 32 insertions(+), 6 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index ed31ed6d..4ca0e1c4 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -53,7 +53,7 @@ Data Subjects is the author of a Rights Request. | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | -| 'data-subject' | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | An array of objects, each containing a (`dsid`,`dsid-schema`) pair | +| `data-subject` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | An array of objects, each containing a (`dsid`,`dsid-schema`) pair | An array of one or more [Data Subject Identities](#decentralized-identity-of-data-subjects) MUST be provided in order to match the Data Subject with the data concerning them. @@ -61,15 +61,41 @@ In addition, the Rights Request has other meta-data: | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | -| 'date' | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | Date and Time when Rights Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| 'language' | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | **TBD format** Language of textual message associated with demands | +| `request-id` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique ID for referening to this request in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `date` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | Date and Time when Rights Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `language` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | **TBD format** Language of textual message associated with demands | -The Data Subject can request several things (e.g. see the data the System has on me, and have it deleted). +The Data Subject can request several things (e.g. see the data the System has on me, know the source from where you have got it, and have my data deleted). We call those 'Demands'. A Rights Request includes an array of one or more Demands. #### Demands +A Demand is a concrete action that the user requests. + +| Schema propery | JSON Type | Expected cardinality | Expected values | +| --------------- | ------------ | ------ | -------------------- | +| `demande-id` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique ID for referening to this demande in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `what` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | **TBD** | +| `data-category` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | **TBD**| +| `treatment` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | **TBD**| +| `legal ground`| [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | **TBD**| +| `message` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | Optional comment or explanation of Demand | + +A Demand MAY be restricted to one or more data categories. For example, a Data Subject can request to access to all data concerning his location. + +| Schema propery | JSON Type | Expected cardinality | Expected values | +| --------------- | ------------ | ------ | -------------------- | +| `data-category` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`NAME`,`CONTACT`,`CONTACT.EMAIL`,`CONTACT.ADDRESS`,`CONTACT.PHONE`,`UID`,`FINANCIAL`,`HEALTH`,`IMAGE`,`LOCATION`,`DEVICE`,`BEHAVIOR`,`BEHAVIOR.CONNECTION`BEHAVIOR.ACTIVITY`, `BEHAVIOR.PREFERENCE`,`PROFILING`,`OTHER`} | + +When several values are given, Systems MUST interpret the `data-category` restriction as a union of all the categories indicated. + +Categories are organised as a hierarchy, denoted with a full-stop ".", the more general category being written on the left. E.g. the following two `data-category` restrictions are equivalent: +- `CONTACT`,`CONTACT.EMAIL` +- `CONTACT` + +In the absence of indication of any `data-category` restriction, Systems MUST interpret the Demand as being related to all categories of data. + #### Transitive Rights Request A Rights Request can be transitive. @@ -79,7 +105,7 @@ When a System receives a transitive Rights Request, it SHOULD not only respond t | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | -| 'transitivity' | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | One of {`DOWNWARD`, `UPWARD`, `BIDIRECTIONAL`, `INTRANSITIVE`} | +| `transitivity` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | One of {`DOWNWARD`, `UPWARD`, `BIDIRECTIONAL`, `INTRANSITIVE`} | Transitivity of Rights Requests can be `DOWNWARD` `UPWARD`, `BIDIRECTIONAL` or `INTRANSITIVE`. In the absence of any indication `INTRANSITIVE` SHOULD be assumed. @@ -98,7 +124,7 @@ In a distributed context, where one System transmits the Rights Request to anoth | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | -| 'reply-to' | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | One of {`SYSTEM`, `USER`} | +| `reply-to` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | One of {`SYSTEM`, `USER`} | `SYSTEM` indicates that the [scenario of nested responses](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#scenario-1---nested-responses) is prefered. The System having registered the Rights Request from the Data Subject gathers responses and presents them to the Data Subject. From 28c65fc3ff3b8a72f59a4ac1c6d0c1a30e7cc6e4 Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 11:03:27 +0200 Subject: [PATCH 031/204] adding data categories to schema --- refs/schemas/drrif.schema.json | 59 +++++++++++++++++++++++++++++++--- 1 file changed, 54 insertions(+), 5 deletions(-) diff --git a/refs/schemas/drrif.schema.json b/refs/schemas/drrif.schema.json index 0151fbe5..d4ae5bf5 100644 --- a/refs/schemas/drrif.schema.json +++ b/refs/schemas/drrif.schema.json @@ -8,23 +8,35 @@ "type": "object", "properties": { "request-id": { - "description": "Unique Identifier of the Rights Request", "type": "string", "format": "uuid" }, + + "data-subject": { + "type": "array", + "items": { "$ref": "#/$defs/data-subject-identity" }, + "minItems": 1 + }, + + "demands": { + "type": "array", + "items": { "$ref": "#/$defs/demand" }, + "minItems": 1 + }, + "transitivity": { - "description": "Transitivity of the Data Rights Request. One of {DOWNWARD,UPWARD,BIDIRECTIONAL,INTRANSITIVE}.", "enum": ["DOWNWARD","UPWARD","BIDIRECTIONAL","INTRANSITIVE"] }, + "date": { - "description": "Date and Time of the request", "type": "string", "format": "date-time" }, + "reply-to": { - "description": "Mode of Reply - to the SYSTEM that the Rights Request was received from or to the USER Data Subject directly", "enum": ["SYSTEM","USER"] }, + }, "required": ["rights-request-id", "timestamp"], @@ -36,7 +48,7 @@ "$defs": { "data-subject-identity": { "$id": "/schemas/data-subject-identity", - "$schema": "http://json-schema.org/draft-07/schema#", + "$schema": "https://json-schema.org/draft/2020-12/schema#", "type": "object", "properties": { @@ -47,6 +59,43 @@ "required": ["dsid-schema", "dsid"], }, + + "demand": { + "$id": "/schemas/demand", + "$schema": "https://json-schema.org/draft/2020-12/schema#", + "type": "object", + + "properties": { + "demande-id": { + "type": "string" + }, + + "data-category": { + "enum": ["NAME", + "CONTACT", + "CONTACT.EMAIL", + "CONTACT.ADDRESS", + "CONTACT.PHONE", + "UID", + "FINANCIAL", + "HEALTH", + "IMAGE", + "LOCATION", + "DEVICE", + "BEHAVIOR", + "BEHAVIOR.CONNECTION", + "BEHAVIOR.ACTIVITY", + "BEHAVIOR.PREFERENCE", + "PROFILING", + "OTHER"] + }, + + + }, + + "required": ["dsid-schema", "dsid"], + + }, } From 7c74d71daa5a9c174689e4d43c082bd0efd430da Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 12:19:04 +0200 Subject: [PATCH 032/204] legal grounds --- refs/schemas/drrif.schema.json | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/refs/schemas/drrif.schema.json b/refs/schemas/drrif.schema.json index d4ae5bf5..c06163c8 100644 --- a/refs/schemas/drrif.schema.json +++ b/refs/schemas/drrif.schema.json @@ -36,6 +36,11 @@ "reply-to": { "enum": ["SYSTEM","USER"] }, + + "legal-grounds": { + "type": "array", + "items": { "type": "string" } + }. }, @@ -70,7 +75,7 @@ "type": "string" }, - "data-category": { + "data-categories": { "enum": ["NAME", "CONTACT", "CONTACT.EMAIL", @@ -90,10 +95,12 @@ "OTHER"] }, + + }, - "required": ["dsid-schema", "dsid"], + }, From 7874abf9183cc7256bb7ee0e0dccfe4cd0e74f6b Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 12:19:21 +0200 Subject: [PATCH 033/204] legal grounds spec --- .../RFC-rights-request-interoperability-format.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 4ca0e1c4..6e6d74a9 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -76,17 +76,19 @@ A Demand is a concrete action that the user requests. | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | | `demande-id` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique ID for referening to this demande in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `what` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | **TBD** | -| `data-category` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | **TBD**| +| `action` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | **TBD** | +| `data-categories` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | **TBD**| | `treatment` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | **TBD**| -| `legal ground`| [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | **TBD**| -| `message` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | Optional comment or explanation of Demand | +| `legal-grounds`| [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings represented legal grounds that support the Demand. E.g. "GDPR.13" indicates Article 13 of GDPR, "CCPA.C" indicates Section C of CCPA | +| `message` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | Optional comment, motivation or explanation of Demand | + +##### Demand Restrictions A Demand MAY be restricted to one or more data categories. For example, a Data Subject can request to access to all data concerning his location. | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | -| `data-category` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`NAME`,`CONTACT`,`CONTACT.EMAIL`,`CONTACT.ADDRESS`,`CONTACT.PHONE`,`UID`,`FINANCIAL`,`HEALTH`,`IMAGE`,`LOCATION`,`DEVICE`,`BEHAVIOR`,`BEHAVIOR.CONNECTION`BEHAVIOR.ACTIVITY`, `BEHAVIOR.PREFERENCE`,`PROFILING`,`OTHER`} | +| `data-category` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`NAME`,`CONTACT`,`CONTACT.EMAIL`,`CONTACT.ADDRESS`,`CONTACT.PHONE`,`UID`,`FINANCIAL`,`HEALTH`,`IMAGE`,`LOCATION`,`DEVICE`,`BEHAVIOR`,`BEHAVIOR.CONNECTION`,`BEHAVIOR.ACTIVITY`, `BEHAVIOR.PREFERENCE`,`PROFILING`,`OTHER`} | When several values are given, Systems MUST interpret the `data-category` restriction as a union of all the categories indicated. @@ -96,6 +98,7 @@ Categories are organised as a hierarchy, denoted with a full-stop ".", the more In the absence of indication of any `data-category` restriction, Systems MUST interpret the Demand as being related to all categories of data. + #### Transitive Rights Request A Rights Request can be transitive. From e8eb5707c61b83f4552cadd121e1e13e22713e15 Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 12:42:59 +0200 Subject: [PATCH 034/204] consent id and capture id spec --- refs/schemas/RFC-rights-request-interoperability-format.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 6e6d74a9..8d3e87c1 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -77,8 +77,10 @@ A Demand is a concrete action that the user requests. | --------------- | ------------ | ------ | -------------------- | | `demande-id` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique ID for referening to this demande in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `action` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | **TBD** | -| `data-categories` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | **TBD**| +| `data-categories` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings indicating particular categories of data to which the demand is limited to. See [Demand Restrictions](#demand-restrictions) for reserved values. | | `treatment` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | **TBD**| +| `consent-ids` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of consent ids to indicate that the Demand (e.g. a `REVOQUE-CONSENT` Demand) is restricted to particular consents. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `capture-ids` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of Data Capture IDs to indicate that the Demand (e.g. a `DELETE` Demand) is restricted to data captured within particular Data Captures. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `legal-grounds`| [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings represented legal grounds that support the Demand. E.g. "GDPR.13" indicates Article 13 of GDPR, "CCPA.C" indicates Section C of CCPA | | `message` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | Optional comment, motivation or explanation of Demand | @@ -88,7 +90,7 @@ A Demand MAY be restricted to one or more data categories. For example, a Data S | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | -| `data-category` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`NAME`,`CONTACT`,`CONTACT.EMAIL`,`CONTACT.ADDRESS`,`CONTACT.PHONE`,`UID`,`FINANCIAL`,`HEALTH`,`IMAGE`,`LOCATION`,`DEVICE`,`BEHAVIOR`,`BEHAVIOR.CONNECTION`,`BEHAVIOR.ACTIVITY`, `BEHAVIOR.PREFERENCE`,`PROFILING`,`OTHER`} | +| `data-category` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`NAME`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `UID`, `FINANCIAL`, `HEALTH`, `IMAGE`, `LOCATION`, `DEVICE`, `BEHAVIOR`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.PREFERENCE`, `PROFILING`, `OTHER`} | When several values are given, Systems MUST interpret the `data-category` restriction as a union of all the categories indicated. From 856675c5882f0a61b4f29abb01a93c1b509b0c4c Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 12:43:10 +0200 Subject: [PATCH 035/204] consent id and capture id schema --- refs/schemas/drrif.schema.json | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/refs/schemas/drrif.schema.json b/refs/schemas/drrif.schema.json index c06163c8..a39bcf11 100644 --- a/refs/schemas/drrif.schema.json +++ b/refs/schemas/drrif.schema.json @@ -40,7 +40,22 @@ "legal-grounds": { "type": "array", "items": { "type": "string" } - }. + }, + + "consent-ids": { + "type": "array", + "items": { + "type": "string", + "format": "uuid" + } + }, + "capture-ids": { + "type": "array", + "items": { + "type": "string", + "format": "uuid" + } + } }, From f6ae47d6324114e24a581bbbb0cab3eb1d9a2df4 Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 13:09:17 +0200 Subject: [PATCH 036/204] data categories in english json map --- .../data-categories/en.data-categories.json | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 refs/schemas/dictionary/data-categories/en.data-categories.json diff --git a/refs/schemas/dictionary/data-categories/en.data-categories.json b/refs/schemas/dictionary/data-categories/en.data-categories.json new file mode 100644 index 00000000..35a148db --- /dev/null +++ b/refs/schemas/dictionary/data-categories/en.data-categories.json @@ -0,0 +1,26 @@ +{ + "NAME": "First names, last names, nicknames, and other names", + "DEMOGRAPHIC": "All information related to + "DEMOGRAPHIC.GENDER": "Data related to gender and gender identity", + "DEMOGRAPHIC.AGE": "Data related to age, including date of birth", + "DEMOGRAPHIC.ORIGIN": "Data related ethnic origin and nationality", + "DEMOGRAPHIC.RACE": "Data related race", + "CONTACT": "Data allowing to contact the person", + "CONTACT.EMAIL": "E-mail address", + "CONTACT.ADDRESS": "Postal address" + "CONTACT.PHONE": "Phone number" + "UID": "Any data allowing to uniquely idnetify a person" + "FINANCIAL": "Data about the financial situation of a person" + "HEALTH": "Data about the health" + "IMAGE": "Any graphic representation (e.g., image, video) of the person" + "LOCATION": "Geographic location" + "DEVICE": "Data about the device used by a person" + "AFFILIATION": "Goups to which a person is a member of; Organisations the person is linked to through work, studies, or beliefs" + "RELATIONSHIPS": "Data about relationships of the person with others" + "BEHAVIOR": "Data about the person's behavior" + "BEHAVIOR.CONNECTION": "Times of connection" + "BEHAVIOR.ACTIVITY": "Activities perfomed online or off-line" + "BEHAVIOR.PREFERENCE": "Data about the person's preferences" + "PROFILING": "Any data establishing a degree of similarity of the person with others (e.g., clusters, user-profiles)" + "OTHER": "Other data" +} From 61e2a8bd182a5ce7fc5fe48568cd209671b0909b Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 13:10:08 +0200 Subject: [PATCH 037/204] typo --- refs/schemas/dictionary/data-categories/en.data-categories.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/dictionary/data-categories/en.data-categories.json b/refs/schemas/dictionary/data-categories/en.data-categories.json index 35a148db..0b320c57 100644 --- a/refs/schemas/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/dictionary/data-categories/en.data-categories.json @@ -1,6 +1,6 @@ { "NAME": "First names, last names, nicknames, and other names", - "DEMOGRAPHIC": "All information related to + "DEMOGRAPHIC": "All information allowing to class the person in a demographic category", "DEMOGRAPHIC.GENDER": "Data related to gender and gender identity", "DEMOGRAPHIC.AGE": "Data related to age, including date of birth", "DEMOGRAPHIC.ORIGIN": "Data related ethnic origin and nationality", From 11868e5bb9ee8dc68ee11a5b6c05dd59af6bb906 Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 13:59:04 +0200 Subject: [PATCH 038/204] Adding biometric, and gentic data to json map --- .../data-categories/en.data-categories.json | 38 ++++++++++--------- 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/refs/schemas/dictionary/data-categories/en.data-categories.json b/refs/schemas/dictionary/data-categories/en.data-categories.json index 0b320c57..3886441e 100644 --- a/refs/schemas/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/dictionary/data-categories/en.data-categories.json @@ -1,26 +1,28 @@ { - "NAME": "First names, last names, nicknames, and other names", + "AFFILIATION": "Goups to which a person is a member of; Organisations the person is linked to through work, studies, or beliefs", + "BEHAVIOR": "Data about the person's behavior", + "BEHAVIOR.CONNECTION": "Times of connection", + "BEHAVIOR.ACTIVITY": "Activities perfomed online or off-line", + "BEHAVIOR.PREFERENCE": "Data about the person's preferences", + "BIOMETRIC": "Biometric data", + "CONTACT": "Data allowing to contact the person", + "CONTACT.EMAIL": "E-mail address", + "CONTACT.ADDRESS": "Postal address", + "CONTACT.PHONE": "Phone number", "DEMOGRAPHIC": "All information allowing to class the person in a demographic category", "DEMOGRAPHIC.GENDER": "Data related to gender and gender identity", "DEMOGRAPHIC.AGE": "Data related to age, including date of birth", "DEMOGRAPHIC.ORIGIN": "Data related ethnic origin and nationality", "DEMOGRAPHIC.RACE": "Data related race", - "CONTACT": "Data allowing to contact the person", - "CONTACT.EMAIL": "E-mail address", - "CONTACT.ADDRESS": "Postal address" - "CONTACT.PHONE": "Phone number" - "UID": "Any data allowing to uniquely idnetify a person" - "FINANCIAL": "Data about the financial situation of a person" - "HEALTH": "Data about the health" - "IMAGE": "Any graphic representation (e.g., image, video) of the person" - "LOCATION": "Geographic location" - "DEVICE": "Data about the device used by a person" - "AFFILIATION": "Goups to which a person is a member of; Organisations the person is linked to through work, studies, or beliefs" - "RELATIONSHIPS": "Data about relationships of the person with others" - "BEHAVIOR": "Data about the person's behavior" - "BEHAVIOR.CONNECTION": "Times of connection" - "BEHAVIOR.ACTIVITY": "Activities perfomed online or off-line" - "BEHAVIOR.PREFERENCE": "Data about the person's preferences" - "PROFILING": "Any data establishing a degree of similarity of the person with others (e.g., clusters, user-profiles)" + "DEVICE": "Data about the device used by a person", + "FINANCIAL": "Data about the financial situation of a person", + "GENIC": "Generic data", + "HEALTH": "Data about the health", + "IMAGE": "Any graphic representation (e.g., image, video) of the person", + "LOCATION": "Geographic location", + "NAME": "First names, last names, nicknames, and other names", + "PROFILING": "Any data establishing a degree of similarity of the person with others (e.g., clusters, user-profiles)", + "RELATIONSHIPS": "Data about relationships of the person with others", + "UID": "Any data allowing to uniquely idnetify a person", "OTHER": "Other data" } From 28f3ec85124d749a78b7e58465559ab5999994f6 Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 14:33:29 +0200 Subject: [PATCH 039/204] Treatment Types --- refs/schemas/dictionary/treatments | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 refs/schemas/dictionary/treatments diff --git a/refs/schemas/dictionary/treatments b/refs/schemas/dictionary/treatments new file mode 100644 index 00000000..a403886f --- /dev/null +++ b/refs/schemas/dictionary/treatments @@ -0,0 +1,11 @@ +{ + "COLLECTION": "Collecting data about the person from the person or from another source, including ", + "STORING": "Storing data for further use, including adaptations and formating of the data", + "GENERATING": "Producing novel data related to the person, such as making photo, voice or video recordings, or reconding user actions such as making a log.", + "SHARING": "Sharing data in controled manner with clearly identified parties", + "PUBLISHING": "Making data publicly available", + "AUTOMATED-INFERENCE": "Automatically infering data about the person, including profiling and clustering", + "AUTOMATED-DECISION-MAKING": "Automated decision-making", + "ANONYMIZATION": "Using data to make data sets in which the person can no longer be identified", + "OTHER": "Other data" +} From 4f854c28a8ae347b0b187482a9071eea808f40fa Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 24 May 2022 14:36:21 +0200 Subject: [PATCH 040/204] file rename treatments --- .../dictionary/{treatments => treatments/en.treatments.json} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename refs/schemas/dictionary/{treatments => treatments/en.treatments.json} (100%) diff --git a/refs/schemas/dictionary/treatments b/refs/schemas/dictionary/treatments/en.treatments.json similarity index 100% rename from refs/schemas/dictionary/treatments rename to refs/schemas/dictionary/treatments/en.treatments.json From e5edb60d22770cc565c88bff27ff1607d5f93522 Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 14:38:32 +0200 Subject: [PATCH 041/204] sorting in a-z order --- refs/schemas/dictionary/treatments/en.treatments.json | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/refs/schemas/dictionary/treatments/en.treatments.json b/refs/schemas/dictionary/treatments/en.treatments.json index a403886f..7171a544 100644 --- a/refs/schemas/dictionary/treatments/en.treatments.json +++ b/refs/schemas/dictionary/treatments/en.treatments.json @@ -1,11 +1,11 @@ { + "ANONYMIZATION": "Using data to make data sets in which the person can no longer be identified", + "AUTOMATED-INFERENCE": "Automatically infering data about the person, including profiling and clustering", + "AUTOMATED-DECISION-MAKING": "Automated decision-making", "COLLECTION": "Collecting data about the person from the person or from another source, including ", - "STORING": "Storing data for further use, including adaptations and formating of the data", "GENERATING": "Producing novel data related to the person, such as making photo, voice or video recordings, or reconding user actions such as making a log.", - "SHARING": "Sharing data in controled manner with clearly identified parties", "PUBLISHING": "Making data publicly available", - "AUTOMATED-INFERENCE": "Automatically infering data about the person, including profiling and clustering", - "AUTOMATED-DECISION-MAKING": "Automated decision-making", - "ANONYMIZATION": "Using data to make data sets in which the person can no longer be identified", + "STORING": "Storing data for further use, including adaptations and formating of the data", + "SHARING": "Sharing data in controled manner with clearly identified parties", "OTHER": "Other data" } From fc109a7d117888d695cc4ea0bf54f71ffd5e26b0 Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 14:41:21 +0200 Subject: [PATCH 042/204] adding treatments to schema --- refs/schemas/drrif.schema.json | 35 +++++++++++++++++++++++++++------- 1 file changed, 28 insertions(+), 7 deletions(-) diff --git a/refs/schemas/drrif.schema.json b/refs/schemas/drrif.schema.json index a39bcf11..0b690435 100644 --- a/refs/schemas/drrif.schema.json +++ b/refs/schemas/drrif.schema.json @@ -91,25 +91,46 @@ }, "data-categories": { - "enum": ["NAME", + "enum": ["AFFILIATION", + "BEHAVIOR", + "BEHAVIOR.CONNECTION", + "BEHAVIOR.ACTIVITY", + "BEHAVIOR.PREFERENCE", + "BIOMETRIC", "CONTACT", "CONTACT.EMAIL", "CONTACT.ADDRESS", "CONTACT.PHONE", - "UID", + "DEMOGRAPHIC", + "DEMOGRAPHIC.GENDER", + "DEMOGRAPHIC.AGE", + "DEMOGRAPHIC.ORIGIN", + "DEMOGRAPHIC.RACE", + "DEVICE", "FINANCIAL", + "GENETIC", "HEALTH", "IMAGE", "LOCATION", - "DEVICE", - "BEHAVIOR", - "BEHAVIOR.CONNECTION", - "BEHAVIOR.ACTIVITY", - "BEHAVIOR.PREFERENCE", + "NAME", + "RELATIONSHIPS", "PROFILING", + "UID", "OTHER"] }, + "treatments": { + "enum": ["ANONYMIZATION", + "AUTOMATED-INFERENCE", + "AUTOMATED-DECISION-MAKING", + "COLLECTION", + "GENERATING", + "PUBLISHING", + "STORING", + "SHARING", + "OTHER"] + } + , From a873cc685c9389025b96c51a860bb1e21e6f4f7c Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 15:06:04 +0200 Subject: [PATCH 043/204] treatment types in spec --- ...-rights-request-interoperability-format.md | 37 +++++++++++++++++-- 1 file changed, 33 insertions(+), 4 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 8d3e87c1..b3039edb 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -78,19 +78,21 @@ A Demand is a concrete action that the user requests. | `demande-id` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique ID for referening to this demande in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `action` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | **TBD** | | `data-categories` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings indicating particular categories of data to which the demand is limited to. See [Demand Restrictions](#demand-restrictions) for reserved values. | -| `treatment` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | **TBD**| +| `treatment` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings represeting treatment types to which the Demand is limited to | | `consent-ids` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of consent ids to indicate that the Demand (e.g. a `REVOQUE-CONSENT` Demand) is restricted to particular consents. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `capture-ids` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of Data Capture IDs to indicate that the Demand (e.g. a `DELETE` Demand) is restricted to data captured within particular Data Captures. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `legal-grounds`| [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings represented legal grounds that support the Demand. E.g. "GDPR.13" indicates Article 13 of GDPR, "CCPA.C" indicates Section C of CCPA | +| `legal-grounds`| [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings representing legal grounds that support the Demand. E.g. "GDPR.13" indicates Article 13 of GDPR, "CCPA.1798.105" indicates Section 1798.105 of CCPA | | `message` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | Optional comment, motivation or explanation of Demand | ##### Demand Restrictions +###### Data Categories + A Demand MAY be restricted to one or more data categories. For example, a Data Subject can request to access to all data concerning his location. | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | -| `data-category` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`NAME`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `UID`, `FINANCIAL`, `HEALTH`, `IMAGE`, `LOCATION`, `DEVICE`, `BEHAVIOR`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.PREFERENCE`, `PROFILING`, `OTHER`} | +| `data-category` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER`} | When several values are given, Systems MUST interpret the `data-category` restriction as a union of all the categories indicated. @@ -98,7 +100,19 @@ Categories are organised as a hierarchy, denoted with a full-stop ".", the more - `CONTACT`,`CONTACT.EMAIL` - `CONTACT` -In the absence of indication of any `data-category` restriction, Systems MUST interpret the Demand as being related to all categories of data. +In the absence of indication of any `data-category` restriction, Systems MUST interpret the Demand as being related to all categories of data. [A list of eligible `data-category` values with corresponding user-facing descriptions is provided](./dictionary/data-categories/) for conveniance. + +###### Treatment Types + +A Demand can be restricted to particular kind of data Treatment. For example, a Data Subject can oppose to automatic inference but continue to accept their data beeing collected and stored. + +| Schema propery | JSON Type | Expected cardinality | Expected values | +| --------------- | ------------ | ------ | -------------------- | +| `treatment` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `OTHER`} | + +When several values are given, Systems MUST interpret the `treatment` restriction as a union of all the treatments indicated. + +In the absence of indication of any `treatment` restriction, Systems MUST interpret the Demand as being related to all kinds of data treatments. #### Transitive Rights Request @@ -376,6 +390,12 @@ Systems SHOULD NOT imply Data Subject Identity equivalence from Rights Requests, All of the following identifiers `data-capture-id`, `fragment-id`, `consent-id`, `rights-request-id`, `demand-id`, `rights-response-id` MUST be globally unique and be generated according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) in order for the corresponding objects to be easily identifiable across systems. +### Data Categories, Treatment Types, Actions, and Purposes SHOULD be Unambiguous and Complete + +The lists of Data Categories, Treatment Types, Actions, and Purposes SHOULD be desiged in such a way to be: +- **Unambiguous** : The developer using the schema knows without ambiguity which one (of which ones) to use in any given situation, AND +- **Complete** : They allow to exress the totality of possible needs in the context of a user wanting to [regulate their privacy/connectedness](https://github.com/blindnet-io/product-management/blob/dogma/refs/notion-of-privacy/notion-of-privacy.md), as well as the totality of requests defined by the [supported legilsation](#supported-legilsation). + ### Remembering Transfers When data about Data Subjects is transmitted from one system to another, in order to be able to process [Transitive Rights Requests](#transitive-rights-request), Systems MUST keep track of: @@ -414,3 +434,12 @@ In the curent proposal, this is the case for Transitivity, but not for request t ### Informative References - + +### Supported Legilsation +- [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) +- [CCPA](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5) + +### Yet to be Supported Legilsation +- [CPRA]([https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://vig.cdn.sos.ca.gov/2020/general/pdf/topl-prop24.pdf)) +- [HIPPA]([https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5](https://www.govinfo.gov/content/pkg/PLAW-104publ191/pdf/PLAW-104publ191.pdf)) + From 285cf84d30f890437eddbf88f3a29e863097a61a Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 18:02:11 +0200 Subject: [PATCH 044/204] changin treatment to "processing-categories" for conformity with GDPR in english --- refs/schemas/drrif.schema.json | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/refs/schemas/drrif.schema.json b/refs/schemas/drrif.schema.json index 0b690435..1cdf61e0 100644 --- a/refs/schemas/drrif.schema.json +++ b/refs/schemas/drrif.schema.json @@ -25,7 +25,8 @@ }, "transitivity": { - "enum": ["DOWNWARD","UPWARD","BIDIRECTIONAL","INTRANSITIVE"] + "enum": ["DOWNWARD","UPWARD","BIDIRECTIONAL","INTRANSITIVE"], + "default": "INTRANSITIVE", }, "date": { @@ -119,7 +120,7 @@ "OTHER"] }, - "treatments": { + "processing-categories": { "enum": ["ANONYMIZATION", "AUTOMATED-INFERENCE", "AUTOMATED-DECISION-MAKING", From 56e04380434aac1e2e9c33fc6aa68707957f7f3f Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 18:03:03 +0200 Subject: [PATCH 045/204] processing-categories --- ...-rights-request-interoperability-format.md | 41 ++++++++++++++++--- 1 file changed, 35 insertions(+), 6 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index b3039edb..09848fa6 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -77,10 +77,6 @@ A Demand is a concrete action that the user requests. | --------------- | ------------ | ------ | -------------------- | | `demande-id` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique ID for referening to this demande in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `action` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | **TBD** | -| `data-categories` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings indicating particular categories of data to which the demand is limited to. See [Demand Restrictions](#demand-restrictions) for reserved values. | -| `treatment` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings represeting treatment types to which the Demand is limited to | -| `consent-ids` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of consent ids to indicate that the Demand (e.g. a `REVOQUE-CONSENT` Demand) is restricted to particular consents. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `capture-ids` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of Data Capture IDs to indicate that the Demand (e.g. a `DELETE` Demand) is restricted to data captured within particular Data Captures. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `legal-grounds`| [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings representing legal grounds that support the Demand. E.g. "GDPR.13" indicates Article 13 of GDPR, "CCPA.1798.105" indicates Section 1798.105 of CCPA | | `message` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | Optional comment, motivation or explanation of Demand | @@ -102,18 +98,51 @@ Categories are organised as a hierarchy, denoted with a full-stop ".", the more In the absence of indication of any `data-category` restriction, Systems MUST interpret the Demand as being related to all categories of data. [A list of eligible `data-category` values with corresponding user-facing descriptions is provided](./dictionary/data-categories/) for conveniance. -###### Treatment Types +###### Categories of Processing A Demand can be restricted to particular kind of data Treatment. For example, a Data Subject can oppose to automatic inference but continue to accept their data beeing collected and stored. | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | -| `treatment` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `OTHER`} | +| `processing-categories` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `OTHER`} | When several values are given, Systems MUST interpret the `treatment` restriction as a union of all the treatments indicated. In the absence of indication of any `treatment` restriction, Systems MUST interpret the Demand as being related to all kinds of data treatments. +[A list of eligible `treatments` values with corresponding user-facing descriptions is provided](./dictionary/processing-categories/) for conveniance. + +###### Purposes of Processing + +A Demand can be restricted to particular purpose of Treatment. For example, a Data Subject can oppose to any treatment done for Marketing purposes, but still accept their data being treated for the sake of personalisation of their experience. + +| Schema propery | JSON Type | Expected cardinality | Expected values | +| --------------- | ------------ | ------ | -------------------- | +| `purposes` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `OTHER`} | + +When several values are given, Systems MUST interpret the `purposes` restriction as a union of all the purposes indicated. + +[A list of eligible `purposes` values with corresponding user-facing descriptions is provided](./dictionary/purposes/) for conveniance. + +###### Consent IDs + +A Demand can be restricted to particular Consent ID(s). For example, a Data Subject revoques a particular consent only (the one related to his data being shared with 3rd parties) but maintains other consents they may have given. + +| Schema propery | JSON Type | Expected cardinality | Expected values | +| --------------- | ------------ | ------ | -------------------- | +| `consent-ids` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of consent ids to indicate that the Demand (e.g. a `REVOQUE-CONSENT` Demand) is restricted to particular consents. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | + +When one or more `consent-ids` are idnicated, Systems MUST interpret the Demand as related to all Consents related to indicated `consent-ids`. + +###### Capture IDs + +A Demand can be restricted to particular Capture ID(s). For example, a Data Subject to delete a particular data, they indicate the data capture concerned by their Demand. + +| Schema propery | JSON Type | Expected cardinality | Expected values | +| --------------- | ------------ | ------ | -------------------- | +| `capture-ids` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of Data Capture IDs to indicate that the Demand (e.g. a `DELETE` Demand) is restricted to data captured within particular Data Captures. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | + +When one or more `capture-ids` are indicated, Systems MUST interpret the demande all related to all the data captured as part of those Data Captures. #### Transitive Rights Request From 91cc0b3764e0f0f1da63368fb27b6651239b1441 Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 24 May 2022 18:03:27 +0200 Subject: [PATCH 046/204] change name to processing-categories --- .../en.processing-categories.json | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 refs/schemas/dictionary/processing-categories/en.processing-categories.json diff --git a/refs/schemas/dictionary/processing-categories/en.processing-categories.json b/refs/schemas/dictionary/processing-categories/en.processing-categories.json new file mode 100644 index 00000000..a403886f --- /dev/null +++ b/refs/schemas/dictionary/processing-categories/en.processing-categories.json @@ -0,0 +1,11 @@ +{ + "COLLECTION": "Collecting data about the person from the person or from another source, including ", + "STORING": "Storing data for further use, including adaptations and formating of the data", + "GENERATING": "Producing novel data related to the person, such as making photo, voice or video recordings, or reconding user actions such as making a log.", + "SHARING": "Sharing data in controled manner with clearly identified parties", + "PUBLISHING": "Making data publicly available", + "AUTOMATED-INFERENCE": "Automatically infering data about the person, including profiling and clustering", + "AUTOMATED-DECISION-MAKING": "Automated decision-making", + "ANONYMIZATION": "Using data to make data sets in which the person can no longer be identified", + "OTHER": "Other data" +} From 428a12bd6531ca4e8503de4f08847e697f036032 Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 24 May 2022 18:06:57 +0200 Subject: [PATCH 047/204] add matching (plus delete old treatment file) --- refs/notion-of-privacy/notion-of-privacy.md | 0 .../en.processing-categories.json | 11 ++++++----- refs/schemas/dictionary/treatments/en.treatments.json | 11 ----------- 3 files changed, 6 insertions(+), 16 deletions(-) create mode 100644 refs/notion-of-privacy/notion-of-privacy.md delete mode 100644 refs/schemas/dictionary/treatments/en.treatments.json diff --git a/refs/notion-of-privacy/notion-of-privacy.md b/refs/notion-of-privacy/notion-of-privacy.md new file mode 100644 index 00000000..e69de29b diff --git a/refs/schemas/dictionary/processing-categories/en.processing-categories.json b/refs/schemas/dictionary/processing-categories/en.processing-categories.json index a403886f..a0cb2dc0 100644 --- a/refs/schemas/dictionary/processing-categories/en.processing-categories.json +++ b/refs/schemas/dictionary/processing-categories/en.processing-categories.json @@ -1,11 +1,12 @@ { + "ANONYMIZATION": "Using data to make data sets in which the person can no longer be identified", + "AUTOMATED-INFERENCE": "Automatically infering data about the person, including profiling and clustering", + "AUTOMATED-DECISION-MAKING": "Automated decision-making", "COLLECTION": "Collecting data about the person from the person or from another source, including ", - "STORING": "Storing data for further use, including adaptations and formating of the data", "GENERATING": "Producing novel data related to the person, such as making photo, voice or video recordings, or reconding user actions such as making a log.", - "SHARING": "Sharing data in controled manner with clearly identified parties", + "MATCHING": "Matching the data about the same person across multiple data sources", "PUBLISHING": "Making data publicly available", - "AUTOMATED-INFERENCE": "Automatically infering data about the person, including profiling and clustering", - "AUTOMATED-DECISION-MAKING": "Automated decision-making", - "ANONYMIZATION": "Using data to make data sets in which the person can no longer be identified", + "STORING": "Storing data for further use, including adaptations and formating of the data", + "SHARING": "Sharing data in controled manner with clearly identified parties", "OTHER": "Other data" } diff --git a/refs/schemas/dictionary/treatments/en.treatments.json b/refs/schemas/dictionary/treatments/en.treatments.json deleted file mode 100644 index 7171a544..00000000 --- a/refs/schemas/dictionary/treatments/en.treatments.json +++ /dev/null @@ -1,11 +0,0 @@ -{ - "ANONYMIZATION": "Using data to make data sets in which the person can no longer be identified", - "AUTOMATED-INFERENCE": "Automatically infering data about the person, including profiling and clustering", - "AUTOMATED-DECISION-MAKING": "Automated decision-making", - "COLLECTION": "Collecting data about the person from the person or from another source, including ", - "GENERATING": "Producing novel data related to the person, such as making photo, voice or video recordings, or reconding user actions such as making a log.", - "PUBLISHING": "Making data publicly available", - "STORING": "Storing data for further use, including adaptations and formating of the data", - "SHARING": "Sharing data in controled manner with clearly identified parties", - "OTHER": "Other data" -} From 89bb8a2463c36cb6c94772673df2ec5dbc4a37f9 Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 19:22:43 +0200 Subject: [PATCH 048/204] descriptions json file for purposes --- .../dictionary/purposes/en.purposes.json | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 refs/schemas/dictionary/purposes/en.purposes.json diff --git a/refs/schemas/dictionary/purposes/en.purposes.json b/refs/schemas/dictionary/purposes/en.purposes.json new file mode 100644 index 00000000..8fb473bf --- /dev/null +++ b/refs/schemas/dictionary/purposes/en.purposes.json @@ -0,0 +1,21 @@ +{ + "ADVERTISING": "To show ads that are either targeted to the specific user or not targeted", + "CONTRACT": "processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract", + "CONTRACT.BASIC-SERVICE": "Providing the basic service to the person", + "CONTRACT.ADDITIONAL-SERVICES": "Providing the services that the person requires that are not part of the basic service", + "MARKETING": "To contact the user to offer products, services, or other promotions", + "NECESSARY": "Processing is necessary for security reasons, legal reasons or protection of rights", + "NECESSARY.JUSTICE": "processing is necessary for the establishment, exercise or defence of legal claims or whenever courts are acting in their judicial capacity", + "NECESSARY.LEGAL": "Processing is necessary for compliance with a legal obligation", + "NECESSARY.MEDICAL": "Processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services", + "NECESSARY.PUBLIC-INTERESTS": "Processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority", + "NECESSARY.SOCIAL-PROTECTION": "Processing is necessary for the purposes of employment and social security and social protection", + "NECESSARY.VITAL-INTERESTS": "Processing is necessary in order to protect the vital interests of the data subject or of another natural person", + "PERSONNALISATION": "For providing user with a personalized experience", + "SALE": "Selling data to third parties", + "SECURITY": "For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. ", + "TRACKING": "Tracking information about user behavior and activity online", + "OTHER": "Other specific purpose", + "ANY": "Any purpose", +} + From f746bad759fc4e93404caebc9c6168d7c75a2ba1 Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 19:22:55 +0200 Subject: [PATCH 049/204] about purposes --- .../RFC-rights-request-interoperability-format.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 09848fa6..62e81290 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -108,9 +108,9 @@ A Demand can be restricted to particular kind of data Treatment. For example, a When several values are given, Systems MUST interpret the `treatment` restriction as a union of all the treatments indicated. -In the absence of indication of any `treatment` restriction, Systems MUST interpret the Demand as being related to all kinds of data treatments. +In the absence of indication of any `purpose` restriction, Systems MUST interpret the Demand as being related to all and any purpose of treatment. -[A list of eligible `treatments` values with corresponding user-facing descriptions is provided](./dictionary/processing-categories/) for conveniance. +[A list of eligible `treatments` values with corresponding user-facing descriptions is provided](./dictionary/purposes/) for conveniance. ###### Purposes of Processing @@ -118,10 +118,14 @@ A Demand can be restricted to particular purpose of Treatment. For example, a Da | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | -| `purposes` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `OTHER`} | +| `purposes` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`ADVERTISING`, `CONTRACT`, `CONTRACT.BASIC-SERVICE`, `CONTRACT.ADDITIONAL-SERVICES`, `NECESSARY`, `NECESSARY.JUSTICE`, `NECESSARY.LEGAL`, `NECESSARY.MEDICAL`, `NECESSARY.PUBLIC-INTERESTS`, `NECESSARY.VITAL-INTERESTS`, `NECESSARY.SOCIAL-PROTECTION`, `MARKETING`, `PERSONNALISATION`, `SALE`, `SECURITY`, `TRACKING`, `OTHER`, `ANY`} | When several values are given, Systems MUST interpret the `purposes` restriction as a union of all the purposes indicated. +Purposes are organised as a hierarchy, denoted with a full-stop ".", the more general category being written on the left. E.g. the following two `data-category` restrictions are equivalent: +- `NECESSARY`,`NECESSARY.LEGAL` +- `NECESSARY` + [A list of eligible `purposes` values with corresponding user-facing descriptions is provided](./dictionary/purposes/) for conveniance. ###### Consent IDs From 2278ab09b53308ffabfd8b7d118f8612081b5ad3 Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 19:23:05 +0200 Subject: [PATCH 050/204] purposes in schema --- refs/schemas/drrif.schema.json | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/refs/schemas/drrif.schema.json b/refs/schemas/drrif.schema.json index 1cdf61e0..323c6c4f 100644 --- a/refs/schemas/drrif.schema.json +++ b/refs/schemas/drrif.schema.json @@ -126,13 +126,33 @@ "AUTOMATED-DECISION-MAKING", "COLLECTION", "GENERATING", + "MATCHING", "PUBLISHING", "STORING", "SHARING", "OTHER"] - } - , - + }, + + "purposes": { + "enum": ["ADVERTISING", + "CONTRACT", + "CONTRACT.BASIC-SERVICE", + "CONTRACT.ADDITIONAL-SERVICES", + "NECESSARY", + "NECESSARY.JUSTICE" + "NECESSARY.LEGAL", + "NECESSARY.MEDICAL", + "NECESSARY.SOCIAL-PROTECTION", + "NECESSARY.PUBLIC-INTERESTS", + "NECESSARY.VITAL-INTERESTS", + "MARKETING", + "PERSONNALISATION", + "SALE", + "SECURITY", + "TRACKING", + "ANY"] + }, + }, From 4e779a217c849ee3c62c4abad54474e7f911ee53 Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 21:14:22 +0200 Subject: [PATCH 051/204] Create en.actions.json --- refs/schemas/dictionary/actions/en.actions.json | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 refs/schemas/dictionary/actions/en.actions.json diff --git a/refs/schemas/dictionary/actions/en.actions.json b/refs/schemas/dictionary/actions/en.actions.json new file mode 100644 index 00000000..346f46cb --- /dev/null +++ b/refs/schemas/dictionary/actions/en.actions.json @@ -0,0 +1,16 @@ +{ + "ACCESS": "To access the data the System has on me", + "DELETE": "To have my data deleted", + "MODIFY": "To modify the existing or complement the incomplete data the System has on me", + "PORTABILITY": "To take my day and ahve it transfered somewhere else", + "OBJECT": "To contact the user to offer products, services, or other promotions", + "REVOKE-CONSENT": "To revoke prviousely given consent for data processing", + "TRANSPARENCY": "To demand information related to data processing practices", + "TRANSPARENCY.WHERE": "To know where is the data about me stored", + "TRANSPARENCY.WHO": "To know who can access the data that the System has on me", + "TRANSPARENCY.PROVENANCE": "To know the sources that the data concerning me come from", + "TRANSPARENCY.RETENTION": "To know for how long is the data concerning me kept", + "TRANSPARENCY.POLICY": "To know the policies being applied to processing of data concerning me", + "TRANSPARENCY.PURPOSE": "To know the purpose of the processing of the data the System has on me", + "TRANSPARENCY.PROCESSING": "To know the categories of processing being done on the data the System has on me", +} From 1910bd4e6805166493ff75358ec890ec0ef9ec0a Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 24 May 2022 21:15:12 +0200 Subject: [PATCH 052/204] update to purposes --- .../processing-categories/en.processing-categories.json | 3 ++- refs/schemas/dictionary/purposes/en.purposes.json | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/refs/schemas/dictionary/processing-categories/en.processing-categories.json b/refs/schemas/dictionary/processing-categories/en.processing-categories.json index a0cb2dc0..f268f131 100644 --- a/refs/schemas/dictionary/processing-categories/en.processing-categories.json +++ b/refs/schemas/dictionary/processing-categories/en.processing-categories.json @@ -1,5 +1,5 @@ { - "ANONYMIZATION": "Using data to make data sets in which the person can no longer be identified", + "ANONYMIZATION": "Transforming data to make data sets in which the person can no longer be identified", "AUTOMATED-INFERENCE": "Automatically infering data about the person, including profiling and clustering", "AUTOMATED-DECISION-MAKING": "Automated decision-making", "COLLECTION": "Collecting data about the person from the person or from another source, including ", @@ -8,5 +8,6 @@ "PUBLISHING": "Making data publicly available", "STORING": "Storing data for further use, including adaptations and formating of the data", "SHARING": "Sharing data in controled manner with clearly identified parties", + "USING": "Consulting and using data", "OTHER": "Other data" } diff --git a/refs/schemas/dictionary/purposes/en.purposes.json b/refs/schemas/dictionary/purposes/en.purposes.json index 8fb473bf..89a9e5ff 100644 --- a/refs/schemas/dictionary/purposes/en.purposes.json +++ b/refs/schemas/dictionary/purposes/en.purposes.json @@ -1,6 +1,6 @@ { "ADVERTISING": "To show ads that are either targeted to the specific user or not targeted", - "CONTRACT": "processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract", + "CONTRACT": "Processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract", "CONTRACT.BASIC-SERVICE": "Providing the basic service to the person", "CONTRACT.ADDITIONAL-SERVICES": "Providing the services that the person requires that are not part of the basic service", "MARKETING": "To contact the user to offer products, services, or other promotions", From 93464e95b74e8eefd4f9a6070d0fc595352ba189 Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 21:19:56 +0200 Subject: [PATCH 053/204] adding actions --- refs/schemas/drrif.schema.json | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/refs/schemas/drrif.schema.json b/refs/schemas/drrif.schema.json index 323c6c4f..20fb4cb1 100644 --- a/refs/schemas/drrif.schema.json +++ b/refs/schemas/drrif.schema.json @@ -91,6 +91,23 @@ "type": "string" }, + "action": { + "enum":["ACCESS", + "DELETE", + "MODIFY", + "PORTABILITY", + "OBJECT", + "REVOKE-CONSENT", + "TRANSPARENCY", + "TRANSPARENCY.WHERE", + "TRANSPARENCY.WHO", + "TRANSPARENCY.PROVENANCE", + "TRANSPARENCY.RETENTION", + "TRANSPARENCY.POLICY", + "TRANSPARENCY.PURPOSE", + "TRANSPARENCY.PROCESSING"] + }, + "data-categories": { "enum": ["AFFILIATION", "BEHAVIOR", @@ -130,6 +147,7 @@ "PUBLISHING", "STORING", "SHARING", + "USING", "OTHER"] }, From 353458bd80e4f3b94dce4f9fe380a86c93e54b1c Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 24 May 2022 23:25:33 +0200 Subject: [PATCH 054/204] Update en.data-categories.json --- .../dictionary/data-categories/en.data-categories.json | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/refs/schemas/dictionary/data-categories/en.data-categories.json b/refs/schemas/dictionary/data-categories/en.data-categories.json index 3886441e..6070a036 100644 --- a/refs/schemas/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/dictionary/data-categories/en.data-categories.json @@ -1,5 +1,5 @@ { - "AFFILIATION": "Goups to which a person is a member of; Organisations the person is linked to through work, studies, or beliefs", + "AFFILIATION": "Goups and Organisations the person is linked to through work, studies, or membership", "BEHAVIOR": "Data about the person's behavior", "BEHAVIOR.CONNECTION": "Times of connection", "BEHAVIOR.ACTIVITY": "Activities perfomed online or off-line", @@ -10,10 +10,11 @@ "CONTACT.ADDRESS": "Postal address", "CONTACT.PHONE": "Phone number", "DEMOGRAPHIC": "All information allowing to class the person in a demographic category", - "DEMOGRAPHIC.GENDER": "Data related to gender and gender identity", "DEMOGRAPHIC.AGE": "Data related to age, including date of birth", - "DEMOGRAPHIC.ORIGIN": "Data related ethnic origin and nationality", - "DEMOGRAPHIC.RACE": "Data related race", + "DEMOGRAPHIC.BELIEFS": "Data related political opinions, religious or philosophical beliefs", + "DEMOGRAPHIC.GENDER": "Data related to gender and gender identity", + "DEMOGRAPHIC.ORIGIN": "Data related to ethnic origin and nationality", + "DEMOGRAPHIC.RACE": "Data related to race", "DEVICE": "Data about the device used by a person", "FINANCIAL": "Data about the financial situation of a person", "GENIC": "Generic data", From e7dd1f87716188c2d62b17982e2fb9851accb418 Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 23:26:45 +0200 Subject: [PATCH 055/204] Update drrif.schema.json --- refs/schemas/drrif.schema.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/refs/schemas/drrif.schema.json b/refs/schemas/drrif.schema.json index 20fb4cb1..e633b3b2 100644 --- a/refs/schemas/drrif.schema.json +++ b/refs/schemas/drrif.schema.json @@ -120,8 +120,9 @@ "CONTACT.ADDRESS", "CONTACT.PHONE", "DEMOGRAPHIC", - "DEMOGRAPHIC.GENDER", "DEMOGRAPHIC.AGE", + "DEMOGRAPHIC.BELIEFS", + "DEMOGRAPHIC.GENDER", "DEMOGRAPHIC.ORIGIN", "DEMOGRAPHIC.RACE", "DEVICE", From 23c078da7dbdde3e42ef7489981381afae1371df Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 24 May 2022 23:29:33 +0200 Subject: [PATCH 056/204] Update drrif.schema.json --- refs/schemas/drrif.schema.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/drrif.schema.json b/refs/schemas/drrif.schema.json index e633b3b2..075b4407 100644 --- a/refs/schemas/drrif.schema.json +++ b/refs/schemas/drrif.schema.json @@ -111,8 +111,8 @@ "data-categories": { "enum": ["AFFILIATION", "BEHAVIOR", - "BEHAVIOR.CONNECTION", "BEHAVIOR.ACTIVITY", + "BEHAVIOR.CONNECTION", "BEHAVIOR.PREFERENCE", "BIOMETRIC", "CONTACT", From cd5cbdc8a5e4f174821a3187102ba461a818cad3 Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 25 May 2022 00:18:36 +0200 Subject: [PATCH 057/204] Update RFC-rights-request-interoperability-format.md --- ...-rights-request-interoperability-format.md | 80 +++++++++++++------ 1 file changed, 56 insertions(+), 24 deletions(-) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/RFC-rights-request-interoperability-format.md index 62e81290..b0ee5488 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/RFC-rights-request-interoperability-format.md @@ -1,4 +1,4 @@ -# Rights Request Interoperability Format (RRIF) +# Privacy Request Interoperability Format (PRIF) | Status | draft | | :------------ | :------------------------------------------------------------------------------------- | @@ -7,21 +7,34 @@ | **Sponsor** | milstan (milstan@blindnet.io) | | **Updated** | 2022-05-19 | -## Objective +## Introduction -We propose a simple, structured data format for representing [Rights Requests](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-conceptualization#data-capture--rights-requests). +We propose a simple, structured data format for representing [Privacy Requests](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-conceptualization#data-capture--rights-requests). -Rights Requests exist within the relationship between an individual and software systems (and organisations operating them) treating data that concerns that individual. +Privacy Requests exist within the relationship between an individual and software Systems (and Organisations operating them) processing data that concerns that individual. +Internet Systems are tools for connection. +[Connectedness requires privacy - the selective control of access to the self](https://github.com/blindnet-io/product-management/blob/10bebeefc14f7db7bf7a491932d62a4a5d18ad70/refs/notion-of-privacy/notion-of-privacy.md). +An individual MAY formulate a Privacy Request in order to establish that control and regulate the relationship, . Systems MAY process and respond to Rights Request by legal obligation, or as a simple courtesy in the pursuit of gaining and maintaining the individual's trust. ## Motivation -Different systems, and different compontents of a single system, including different comnponents of blindnet devkit are likely to exchange information about Rights Requests. +Different Systems, and different compontents of a single System, including different comnponents of blindnet devkit are likely to exchange information about Privacy Requests. Therefore, a common format is needed to facilitate exchange of information without loss of semantics. -Our goal is to establish a shared semantics of Rights Request so that their processing can be, as much as possible, automatised by the Systems. +The goal of Privacy Request Interoperability Format is to establish a shared conceptualisation and format of Privacy Request so that their processing can be, as much as possible, automatised by the Systems. + +## Terminology + +>**TO BE Updated** once Lexicon and High Level Conceptualization are synchronised + +- We use the term Privacy Request interchangeably with the (deprecated) terms Rights Request and Data Rights Request as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) +- We use the terms Individual, Person, You, and Data Subject as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) +- We use the term System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) +- We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) +- We use the terms Organization, Submitter, Data Consumer as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) as defined there. ## Design Considerations @@ -34,17 +47,6 @@ The design also aimes to maximise: - encryption. - -## Terminology - ->**TO BE Updated** once Lexicon and High Level Conceptualization are synchronised - -- We use the terms Rights Request, Data Subject, System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) -- We use the terms Rights Request and Data Rights Request interchangeably -- We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) -- We use all the terms from the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) as defined there. - - ## Proposal ### Rights Request @@ -55,6 +57,8 @@ Data Subjects is the author of a Rights Request. | --------------- | ------------ | ------ | -------------------- | | `data-subject` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | An array of objects, each containing a (`dsid`,`dsid-schema`) pair | +A System MAY have muptiple ways to identify the Data Subject, especially when data about them came from some other System that uses different identifiers. The System capturing the Rights Request MAY associate multiple Data Subject Identities to the Rights Request, especially if the Rights Request is likely to be transmitted to other systems. + An array of one or more [Data Subject Identities](#decentralized-identity-of-data-subjects) MUST be provided in order to match the Data Subject with the data concerning them. In addition, the Rights Request has other meta-data: @@ -63,6 +67,7 @@ In addition, the Rights Request has other meta-data: | --------------- | ------------ | ------ | -------------------- | | `request-id` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique ID for referening to this request in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | Date and Time when Rights Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `demands` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | An array of [Demands](#demands) | | `language` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | **TBD format** Language of textual message associated with demands | The Data Subject can request several things (e.g. see the data the System has on me, know the source from where you have got it, and have my data deleted). We call those 'Demands'. @@ -76,23 +81,29 @@ A Demand is a concrete action that the user requests. | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | | `demande-id` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique ID for referening to this demande in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `action` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | **TBD** | +| `action` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `PORTABILITY`, `OBJECT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.PROCESSING`} | | `legal-grounds`| [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings representing legal grounds that support the Demand. E.g. "GDPR.13" indicates Article 13 of GDPR, "CCPA.1798.105" indicates Section 1798.105 of CCPA | | `message` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | Optional comment, motivation or explanation of Demand | +The key element that defines the nature of the Demand is the `action`. A Demande MUST have one and only one `action`. + +Actions are hierarchical. Their relationships are dentoed with a dot "." sparating two actions, the more one being written on the left. `TRANSPARENCY` includes `TRANSPARENCY.WHERE`. When `TRANSPARENCY` is demanded, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` (`TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.PROCESSING`) were demanded. + ##### Demand Restrictions +The `action` that the Data Subject requests with a particular Demand MUST be interpreted in the context of restrictions. A Demand MAY refer to only certain categories of data, or certain types of processing, certain purposes of processing etc. + ###### Data Categories A Demand MAY be restricted to one or more data categories. For example, a Data Subject can request to access to all data concerning his location. | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | -| `data-category` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER`} | +| `data-category` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER`} | When several values are given, Systems MUST interpret the `data-category` restriction as a union of all the categories indicated. -Categories are organised as a hierarchy, denoted with a full-stop ".", the more general category being written on the left. E.g. the following two `data-category` restrictions are equivalent: +Categories are organised as a hierarchy, denoted with a dot ".", the more general category being written on the left. E.g. the following two `data-category` restrictions are equivalent: - `CONTACT`,`CONTACT.EMAIL` - `CONTACT` @@ -104,7 +115,7 @@ A Demand can be restricted to particular kind of data Treatment. For example, a | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | -| `processing-categories` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `OTHER`} | +| `processing-categories` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `USING`, `OTHER`} | When several values are given, Systems MUST interpret the `treatment` restriction as a union of all the treatments indicated. @@ -122,7 +133,7 @@ A Demand can be restricted to particular purpose of Treatment. For example, a Da When several values are given, Systems MUST interpret the `purposes` restriction as a union of all the purposes indicated. -Purposes are organised as a hierarchy, denoted with a full-stop ".", the more general category being written on the left. E.g. the following two `data-category` restrictions are equivalent: +Purposes are organised as a hierarchy, denoted with a dot ".", the more general purpose being written on the left. E.g. the following two `pruposes` restrictions are equivalent: - `NECESSARY`,`NECESSARY.LEGAL` - `NECESSARY` @@ -134,7 +145,7 @@ A Demand can be restricted to particular Consent ID(s). For example, a Data Subj | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | -| `consent-ids` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of consent ids to indicate that the Demand (e.g. a `REVOQUE-CONSENT` Demand) is restricted to particular consents. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `consent-ids` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of consent ids to indicate that the Demand (e.g. a `REVOKE-CONSENT` Demand) is restricted to particular consents. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | When one or more `consent-ids` are idnicated, Systems MUST interpret the Demand as related to all Consents related to indicated `consent-ids`. @@ -458,21 +469,42 @@ Should we include rescritions in the schema according to the [JSON-schema-valida In the curent proposal, this is the case for Transitivity, but not for request types, data categories, and user identity schemas. We might want to include more forma constraints there, or deliberately leave flexibility. This is a discussion we need to have. +### Dot-notation for category hierarchies + +Hierarchies of categories are represented using the "supercategory.subcategory" notation. The idea behind this is to allow developers to use the level of granularity that is adapted to them, yet be able to easily situate the subcategory in supercategory when dealing with more generic requests. + +E.g. We have a data capture associated to "CONTACT.ADDRESS" data category. The Data Subject makes a DELETE request related to all of their data falling under "CONTACT" data category. The developer can easily identify "CONTACT.ADDRESS" as being a subcategory of ""CONTACT.ADDRESS". + +However, this notation (although intuitive) is to the best of my knoweldge, non-standard. Maybe there are reasons for it, or a standard (better) notation we can adopt? + +### Reply-to is maybe unnecessary + +The schema allows requests to specify a [`reply-to`](#reply-to) and idnicate which mode of answer is prefered with regards to the two possible scenarios: [scenario of nested responses](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#scenario-1---nested-responses) and [scenario of direct responses](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#scenario-2---direct-responses). + +However, it is likely that the System receiving a request will decide how to respond depending on the type of request and depending on its relationship with the user, in which case speficying this field is unnecessary. + +### Representation of Legal Articles + +Is there a better way to unambiguousely refer, in a machine-readable way, to parts of legislations? + + ## References ### Normative References - - **[RFC8259]** Bray, T., ["The JavaScript Object Notation (JSON) Data Interchange Format"](https://datatracker.ietf.org/doc/html/rfc8259), STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. ### Informative References + - ### Supported Legilsation + - [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) - [CCPA](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5) ### Yet to be Supported Legilsation + - [CPRA]([https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://vig.cdn.sos.ca.gov/2020/general/pdf/topl-prop24.pdf)) - [HIPPA]([https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5](https://www.govinfo.gov/content/pkg/PLAW-104publ191/pdf/PLAW-104publ191.pdf)) From bf824c202fb9d6c2f020a0507b0f1065bfb50d1b Mon Sep 17 00:00:00 2001 From: milstan Date: Wed, 25 May 2022 02:13:17 +0200 Subject: [PATCH 058/204] cleaning up --- .../RFC-prif.md} | 88 +++++++++++-------- .../dictionary/actions/en.actions.json | 0 .../data-categories/en.data-categories.json | 0 .../en.processing-categories.json | 0 .../dictionary/purposes/en.purposes.json | 0 .../transitivity/en.transitivity.json | 0 .../prif.schema.json} | 52 ++++++----- 7 files changed, 83 insertions(+), 57 deletions(-) rename refs/schemas/{RFC-rights-request-interoperability-format.md => prif/RFC-prif.md} (87%) rename refs/schemas/{ => prif}/dictionary/actions/en.actions.json (100%) rename refs/schemas/{ => prif}/dictionary/data-categories/en.data-categories.json (100%) rename refs/schemas/{ => prif}/dictionary/processing-categories/en.processing-categories.json (100%) rename refs/schemas/{ => prif}/dictionary/purposes/en.purposes.json (100%) rename refs/schemas/{ => prif}/dictionary/transitivity/en.transitivity.json (100%) rename refs/schemas/{drrif.schema.json => prif/prif.schema.json} (94%) diff --git a/refs/schemas/RFC-rights-request-interoperability-format.md b/refs/schemas/prif/RFC-prif.md similarity index 87% rename from refs/schemas/RFC-rights-request-interoperability-format.md rename to refs/schemas/prif/RFC-prif.md index b0ee5488..63a86b1f 100644 --- a/refs/schemas/RFC-rights-request-interoperability-format.md +++ b/refs/schemas/prif/RFC-prif.md @@ -38,41 +38,42 @@ The goal of Privacy Request Interoperability Format is to establish a shared con ## Design Considerations -The design also aimes to maximise: -- Consistent Interpretation of Rights Request accorss different Systems -- Automatisation of Rights Request Processing -- Confidentialty of data -- Compatibility with the use of different protocols and tools for: - - user identity management and authentication, - - encryption. +With this design we seek: +- Consistent unambiguous interpretation of Privacy Request across different Systems, independently of programming languages and components they use, +- Minimal exposure of Data Subject and their data during the processing of a Privacy Request, +- Making processing of Privacy Requests as automatic as possible, +- Compatibility with the use of different protocols and tools for user identity management, authentication, and encryption, +- Allowing developers to be fully comply with [supported legislation](#supported-legislation) quickly and easily +- Highly normative minimal specification, using as much as possible the [Plain Language](https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf) while at the same time making clear references to the (often misfortunate) language of the [supported legislations](#supported-legislation) +- Decentralised design compatible with both the Internet's Client-Server Architecture and Metaverse/Web3 Architecture ## Proposal -### Rights Request +### Privacy Request -Data Subjects is the author of a Rights Request. +Data Subject is the author of a Privacy Request. | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | | `data-subject` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | An array of objects, each containing a (`dsid`,`dsid-schema`) pair | -A System MAY have muptiple ways to identify the Data Subject, especially when data about them came from some other System that uses different identifiers. The System capturing the Rights Request MAY associate multiple Data Subject Identities to the Rights Request, especially if the Rights Request is likely to be transmitted to other systems. +A System MAY have muptiple ways to identify the Data Subject, especially when data about them came from some other System that uses different identifiers. +The System capturing the Privacy Request MAY associate multiple Data Subject Identities to the Privacy Request, especially if the Privacy Request is likely to be transmitted to other systems. An array of one or more [Data Subject Identities](#decentralized-identity-of-data-subjects) MUST be provided in order to match the Data Subject with the data concerning them. -In addition, the Rights Request has other meta-data: +In addition, the Privacy Request has other meta-data: | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | | `request-id` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique ID for referening to this request in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `date` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | Date and Time when Rights Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `date` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | Date and Time when Privacy Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `demands` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | An array of [Demands](#demands) | -| `language` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | **TBD format** Language of textual message associated with demands | The Data Subject can request several things (e.g. see the data the System has on me, know the source from where you have got it, and have my data deleted). We call those 'Demands'. -A Rights Request includes an array of one or more Demands. +A Privacy Request includes an array of one or more Demands. #### Demands @@ -84,14 +85,19 @@ A Demand is a concrete action that the user requests. | `action` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `PORTABILITY`, `OBJECT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.PROCESSING`} | | `legal-grounds`| [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings representing legal grounds that support the Demand. E.g. "GDPR.13" indicates Article 13 of GDPR, "CCPA.1798.105" indicates Section 1798.105 of CCPA | | `message` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | Optional comment, motivation or explanation of Demand | +| `language` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | The key element that defines the nature of the Demand is the `action`. A Demande MUST have one and only one `action`. -Actions are hierarchical. Their relationships are dentoed with a dot "." sparating two actions, the more one being written on the left. `TRANSPARENCY` includes `TRANSPARENCY.WHERE`. When `TRANSPARENCY` is demanded, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` (`TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.PROCESSING`) were demanded. +Actions are hierarchical. +Their relationships are dentoed with a dot "." separating two actions, the more general one being written on the left. +`TRANSPARENCY` includes `TRANSPARENCY.WHERE`. +When `TRANSPARENCY` is demanded, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` (`TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.PROCESSING`) were demanded. ##### Demand Restrictions -The `action` that the Data Subject requests with a particular Demand MUST be interpreted in the context of restrictions. A Demand MAY refer to only certain categories of data, or certain types of processing, certain purposes of processing etc. +The `action` that the Data Subject requests with a particular Demand MUST be interpreted in the context of restrictions. +A Demand MAY refer to only certain categories of data, or certain types of processing, certain purposes of processing etc. ###### Data Categories @@ -103,29 +109,32 @@ A Demand MAY be restricted to one or more data categories. For example, a Data S When several values are given, Systems MUST interpret the `data-category` restriction as a union of all the categories indicated. -Categories are organised as a hierarchy, denoted with a dot ".", the more general category being written on the left. E.g. the following two `data-category` restrictions are equivalent: +Categories are organised as a hierarchy, denoted with a dot ".", the more general category being written on the left. +E.g. the following two `data-category` restrictions are equivalent: - `CONTACT`,`CONTACT.EMAIL` - `CONTACT` -In the absence of indication of any `data-category` restriction, Systems MUST interpret the Demand as being related to all categories of data. [A list of eligible `data-category` values with corresponding user-facing descriptions is provided](./dictionary/data-categories/) for conveniance. +In the absence of indication of any `data-category` restriction, Systems MUST interpret the Demand as being related to all categories of data. +[A list of eligible `data-category` values with corresponding user-facing descriptions is provided](./dictionary/data-categories/) for conveniance. ###### Categories of Processing -A Demand can be restricted to particular kind of data Treatment. For example, a Data Subject can oppose to automatic inference but continue to accept their data beeing collected and stored. +A Demand can be restricted to particular kinds of data processing. +For example, a Data Subject can oppose to automatic inference but continue to accept their data beeing collected and stored. | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | | `processing-categories` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `USING`, `OTHER`} | -When several values are given, Systems MUST interpret the `treatment` restriction as a union of all the treatments indicated. +When several values are given, Systems MUST interpret the `processing-categories` restriction as a union of all the processing categories indicated. -In the absence of indication of any `purpose` restriction, Systems MUST interpret the Demand as being related to all and any purpose of treatment. +In the absence of indication of any `processing-categories` restriction, Systems MUST interpret the Demand as being related to all and any `processing-categories` of treatment. -[A list of eligible `treatments` values with corresponding user-facing descriptions is provided](./dictionary/purposes/) for conveniance. +[A list of eligible `processing-categories` values with corresponding user-facing descriptions is provided](./dictionary/purposes/) for conveniance. ###### Purposes of Processing -A Demand can be restricted to particular purpose of Treatment. For example, a Data Subject can oppose to any treatment done for Marketing purposes, but still accept their data being treated for the sake of personalisation of their experience. +A Demand can be restricted to particular purpose of data processing. For example, a Data Subject can oppose to any data processing done for marketing purposes, but still accept their data being processed for the sake of personalisation of their experience. | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | @@ -137,6 +146,8 @@ Purposes are organised as a hierarchy, denoted with a dot ".", the more general - `NECESSARY`,`NECESSARY.LEGAL` - `NECESSARY` +In the absence of indication of any `purpose` restriction, Systems MUST interpret the Demand as being related to all and any purpose of treatment. + [A list of eligible `purposes` values with corresponding user-facing descriptions is provided](./dictionary/purposes/) for conveniance. ###### Consent IDs @@ -159,10 +170,10 @@ A Demand can be restricted to particular Capture ID(s). For example, a Data Subj When one or more `capture-ids` are indicated, Systems MUST interpret the demande all related to all the data captured as part of those Data Captures. -#### Transitive Rights Request +#### Transitive Privacy Request -A Rights Request can be transitive. -Transitive Rights Requests are usefull in a distributed context where System A gave information about the Data Subject to System B, and System B gave information about the Data Subject to System C. +A Privacy Request can be transitive. +Transitive Privacy Requests are usefull in a distributed context where System A gave information about the Data Subject to System B, and System B gave information about the Data Subject to System C. When a System receives a transitive Rights Request, it SHOULD not only respond to it, but also transfer it to corresponding Systems with which it exchnaged data about the Data Subject. @@ -179,7 +190,7 @@ When System B receives an `INTRANSITIVE` Rights Request, it SHOULD NOT transfer Systems should interpret the transitivity of Rights Request the same way regardless of the Rights Request being received directly from the Data Subject or from a corresponding System. -Convenient tables of Transitivity vlaues and corresponding user-facing descriptions, in different languages, are provided [here](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/schemas/dictionary/transitivity/). +Convenient tables of `transitivity` vlaues and corresponding user-facing descriptions, in different languages, are provided [here](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/schemas/dictionary/transitivity/). #### Reply-to @@ -358,19 +369,19 @@ Transced proposes the following [data categories](https://github.com/transcend-i ### JSON format -In addition to this specification document we provide a JSON Schema document (link soon), for machine-readable interpretation of Rights Requests compliant with [v4 (or ideally lower) of IETF specification](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#:~:text=JSON%20Schema%20is%20a%20JSON,interaction%20control%20of%20JSON%20data.) +We provide a JSON Schema document (**!!!link soon!!!!!**) for machine-readable interpretation of Privacy Requests compliant with [v4 (or ideally lower) of IETF specification](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#:~:text=JSON%20Schema%20is%20a%20JSON,interaction%20control%20of%20JSON%20data.) The key requirements of the design are to enable: -- Unambiguous expression of Rights Requests in a machine-readable form -- Integrity of Rights Requests semantics when exchanged between components and systems. -I.e. A system that has not directly collected the Rights Requests from the user, but has received in in JSON format from another system, can make the exact same interpretation of the request as if it had collected the request directly. -- A way of uniquely identifying one and the same Rights Request across systems and components concerned by it. +- Unambiguous expression of Privacy Requests in a machine-readable form +- Integrity of Privacy Requests semantics when exchanged between components and systems. +I.e. A system that has not directly collected the Privacy Requests from the user, but has received in in JSON format from another system, can make the exact same interpretation of the request as if it had collected the request directly. +- A way of uniquely identifying one and the same Privacy Request across systems and components concerned by it. ### Authenticated exchanges -Systems exchanging Rignts Requests MUST be able to do so in a way allowing them to very the integrity of their content, and the identity of the system having emitted the Rignts Request. +Systems exchanging Privacy Requests MUST be able to do so in a way allowing them to very the integrity of their content, and the identity of the system having emitted the Rignts Request. -For this purposes Rignts Requests MAY be embedded as 'Claims' in [JWTs (FRC7519)](https://datatracker.ietf.org/doc/html/rfc7519). +For this purposes Privacy Requests MAY be embedded as 'Claims' in [JWTs (FRC7519)](https://datatracker.ietf.org/doc/html/rfc7519). ### Decentralized Identity of Data Subjects @@ -433,6 +444,10 @@ Systems SHOULD NOT imply Data Subject Identity equivalence from Rights Requests, ### Data Capture IDs, Data Capture Fragment IDs, Consent IDs, Rights Request IDs, Demand IDs, Rights Request Respons IDs are Globally Unique All of the following identifiers `data-capture-id`, `fragment-id`, `consent-id`, `rights-request-id`, `demand-id`, `rights-response-id` MUST be globally unique and be generated according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) in order for the corresponding objects to be easily identifiable across systems. +The reason for using UUDIs is to allow Systems to independently generate globally unique identifiers while being autonomous from a central entity that would ensure identifier uniqueness. + +Having a public ledger for UUDIs MAY be considered for Consents and Data Captures, but serious implications to Data Subject exposure MUST also be considered. +However, the design MUST be compatible with building a public decentralised ledger. ### Data Categories, Treatment Types, Actions, and Purposes SHOULD be Unambiguous and Complete @@ -476,6 +491,7 @@ Hierarchies of categories are represented using the "supercategory.subcategory" E.g. We have a data capture associated to "CONTACT.ADDRESS" data category. The Data Subject makes a DELETE request related to all of their data falling under "CONTACT" data category. The developer can easily identify "CONTACT.ADDRESS" as being a subcategory of ""CONTACT.ADDRESS". However, this notation (although intuitive) is to the best of my knoweldge, non-standard. Maybe there are reasons for it, or a standard (better) notation we can adopt? +Or if none (which would be surprising) we could define our syntax using [Backus-Naur Form](https://datatracker.ietf.org/doc/html/rfc4234). Advantage: geeks will love us. ### Reply-to is maybe unnecessary @@ -485,7 +501,7 @@ However, it is likely that the System receiving a request will decide how to res ### Representation of Legal Articles -Is there a better way to unambiguousely refer, in a machine-readable way, to parts of legislations? +Is there a better way to unambiguousely refer, in a machine-readable way, to parts of legislations? ## References @@ -498,7 +514,7 @@ Is there a better way to unambiguousely refer, in a machine-readable way, to par - -### Supported Legilsation +### Supported Legislation - [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) - [CCPA](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5) diff --git a/refs/schemas/dictionary/actions/en.actions.json b/refs/schemas/prif/dictionary/actions/en.actions.json similarity index 100% rename from refs/schemas/dictionary/actions/en.actions.json rename to refs/schemas/prif/dictionary/actions/en.actions.json diff --git a/refs/schemas/dictionary/data-categories/en.data-categories.json b/refs/schemas/prif/dictionary/data-categories/en.data-categories.json similarity index 100% rename from refs/schemas/dictionary/data-categories/en.data-categories.json rename to refs/schemas/prif/dictionary/data-categories/en.data-categories.json diff --git a/refs/schemas/dictionary/processing-categories/en.processing-categories.json b/refs/schemas/prif/dictionary/processing-categories/en.processing-categories.json similarity index 100% rename from refs/schemas/dictionary/processing-categories/en.processing-categories.json rename to refs/schemas/prif/dictionary/processing-categories/en.processing-categories.json diff --git a/refs/schemas/dictionary/purposes/en.purposes.json b/refs/schemas/prif/dictionary/purposes/en.purposes.json similarity index 100% rename from refs/schemas/dictionary/purposes/en.purposes.json rename to refs/schemas/prif/dictionary/purposes/en.purposes.json diff --git a/refs/schemas/dictionary/transitivity/en.transitivity.json b/refs/schemas/prif/dictionary/transitivity/en.transitivity.json similarity index 100% rename from refs/schemas/dictionary/transitivity/en.transitivity.json rename to refs/schemas/prif/dictionary/transitivity/en.transitivity.json diff --git a/refs/schemas/drrif.schema.json b/refs/schemas/prif/prif.schema.json similarity index 94% rename from refs/schemas/drrif.schema.json rename to refs/schemas/prif/prif.schema.json index 075b4407..ac66e293 100644 --- a/refs/schemas/drrif.schema.json +++ b/refs/schemas/prif/prif.schema.json @@ -2,8 +2,8 @@ "$id": "https://blindnet.io/schemas/rights-request", "$schema": "https://json-schema.org/draft/2020-12/schema", - "title": "Data Rights Request", - "description": "This document defines a format for interoperability of Data Rights Requests", + "title": "Privacy Request", + "description": "This document defines a format for interoperability of Privacy Requests", "type": "object", "properties": { @@ -38,25 +38,7 @@ "enum": ["SYSTEM","USER"] }, - "legal-grounds": { - "type": "array", - "items": { "type": "string" } - }, - - "consent-ids": { - "type": "array", - "items": { - "type": "string", - "format": "uuid" - } - }, - "capture-ids": { - "type": "array", - "items": { - "type": "string", - "format": "uuid" - } - } + }, @@ -91,6 +73,34 @@ "type": "string" }, + "message": { + "type": "string" + }, + + "language": { + "type": "string" + }, + + "legal-grounds": { + "type": "array", + "items": { "type": "string" } + }, + + "consent-ids": { + "type": "array", + "items": { + "type": "string", + "format": "uuid" + } + }, + "capture-ids": { + "type": "array", + "items": { + "type": "string", + "format": "uuid" + } + } + "action": { "enum":["ACCESS", "DELETE", From 0a836bcb4d45ba3f11af8234174dfbb6ce50dc7b Mon Sep 17 00:00:00 2001 From: milstan Date: Wed, 25 May 2022 18:06:01 +0200 Subject: [PATCH 059/204] .DS_Store banished! --- .gitignore | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index ccc9fd93..725138a5 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1 @@ -*.DS_Store \ No newline at end of file +*.DS_Store.DS_Store From 8ccd373edc2a8e0b52ae0bd53b363e3d1b348935 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 26 May 2022 00:26:45 +0200 Subject: [PATCH 060/204] restructuring examples + missing categories --- .gitignore | 2 + refs/schemas/prif/RFC-prif.md | 244 +++----------- .../prif/dictionary/actions/en.actions.json | 20 +- .../data-categories/en.data-categories.json | 1 + .../en.processing-categories.json | 4 +- refs/schemas/prif/examples.md | 305 ++++++++++++++++++ refs/schemas/prif/prif.schema.json | 19 +- 7 files changed, 387 insertions(+), 208 deletions(-) create mode 100644 refs/schemas/prif/examples.md diff --git a/.gitignore b/.gitignore index 725138a5..cd8491f7 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,3 @@ *.DS_Store.DS_Store +refs/schemas/prif/dictionary/.DS_Store +.DS_Store diff --git a/refs/schemas/prif/RFC-prif.md b/refs/schemas/prif/RFC-prif.md index 63a86b1f..df023652 100644 --- a/refs/schemas/prif/RFC-prif.md +++ b/refs/schemas/prif/RFC-prif.md @@ -5,24 +5,25 @@ | **PR #** | [NNN](https://github.com/blindnet-io/PROJECT/pull/NNN) (update when you have PR #) | | **Author(s)** | milstan (milstan@blindnet.io), Clémentine VINCENT (clementine@blindnet.io) | | **Sponsor** | milstan (milstan@blindnet.io) | -| **Updated** | 2022-05-19 | +| **Updated** | 2022-05-25 | ## Introduction We propose a simple, structured data format for representing [Privacy Requests](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-conceptualization#data-capture--rights-requests). +This format corresponds to the [Data Rights Request Schema](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#schemas) component of the [High- Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). -Privacy Requests exist within the relationship between an individual and software Systems (and Organisations operating them) processing data that concerns that individual. +Privacy Requests exist within the relationship between an individual and software Systems (and Organisations operating them) processing data that concerns that individual. -Internet Systems are tools for connection. -[Connectedness requires privacy - the selective control of access to the self](https://github.com/blindnet-io/product-management/blob/10bebeefc14f7db7bf7a491932d62a4a5d18ad70/refs/notion-of-privacy/notion-of-privacy.md). -An individual MAY formulate a Privacy Request in order to establish that control and regulate the relationship, . +Internet Systems are tools for connection. +[Connectedness requires privacy - the selective control of access to the self](https://github.com/blindnet-io/product-management/blob/10bebeefc14f7db7bf7a491932d62a4a5d18ad70/refs/notion-of-privacy/notion-of-privacy.md). +An individual MAY formulate a Privacy Request in order to establish that control and regulate the relationship, . Systems MAY process and respond to Rights Request by legal obligation, or as a simple courtesy in the pursuit of gaining and maintaining the individual's trust. ## Motivation Different Systems, and different compontents of a single System, including different comnponents of blindnet devkit are likely to exchange information about Privacy Requests. -Therefore, a common format is needed to facilitate exchange of information without loss of semantics. +Therefore, a common format is needed to facilitate exchange of information without loss of semantics. The goal of Privacy Request Interoperability Format is to establish a shared conceptualisation and format of Privacy Request so that their processing can be, as much as possible, automatised by the Systems. @@ -44,6 +45,7 @@ With this design we seek: - Making processing of Privacy Requests as automatic as possible, - Compatibility with the use of different protocols and tools for user identity management, authentication, and encryption, - Allowing developers to be fully comply with [supported legislation](#supported-legislation) quickly and easily +- Exhaustivity with regards to situations we need to support in response to [supported legislation](#supported-legislation) yet Extensibility in case new situations arise in the future. - Highly normative minimal specification, using as much as possible the [Plain Language](https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf) while at the same time making clear references to the (often misfortunate) language of the [supported legislations](#supported-legislation) - Decentralised design compatible with both the Internet's Client-Server Architecture and Metaverse/Web3 Architecture @@ -58,8 +60,8 @@ Data Subject is the author of a Privacy Request. | --------------- | ------------ | ------ | -------------------- | | `data-subject` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | An array of objects, each containing a (`dsid`,`dsid-schema`) pair | -A System MAY have muptiple ways to identify the Data Subject, especially when data about them came from some other System that uses different identifiers. -The System capturing the Privacy Request MAY associate multiple Data Subject Identities to the Privacy Request, especially if the Privacy Request is likely to be transmitted to other systems. +A System MAY have muptiple ways to identify the Data Subject, especially when data about them came from some other System that uses different identifiers. +The System capturing the Privacy Request MAY associate multiple Data Subject Identities to the Privacy Request, especially if the Privacy Request is likely to be transmitted to other systems. An array of one or more [Data Subject Identities](#decentralized-identity-of-data-subjects) MUST be provided in order to match the Data Subject with the data concerning them. @@ -82,21 +84,31 @@ A Demand is a concrete action that the user requests. | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | | `demande-id` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique ID for referening to this demande in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `action` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `PORTABILITY`, `OBJECT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.PROCESSING`} | +| `action` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | | `legal-grounds`| [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings representing legal grounds that support the Demand. E.g. "GDPR.13" indicates Article 13 of GDPR, "CCPA.1798.105" indicates Section 1798.105 of CCPA | | `message` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | Optional comment, motivation or explanation of Demand | | `language` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | -The key element that defines the nature of the Demand is the `action`. A Demande MUST have one and only one `action`. +The key element that defines the nature of the Demand is the `action`. A Demande MUST have one and only one `action`. -Actions are hierarchical. -Their relationships are dentoed with a dot "." separating two actions, the more general one being written on the left. -`TRANSPARENCY` includes `TRANSPARENCY.WHERE`. -When `TRANSPARENCY` is demanded, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` (`TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.PROCESSING`) were demanded. +Actions are hierarchical. +Their relationships are dentoed with a dot "." separating two actions, the more general one being written on the left. +`TRANSPARENCY` includes `TRANSPARENCY.WHERE`. +When `TRANSPARENCY` is demanded, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` were demanded. + +> **Note** +> +> To be compliant with GDPR.{13,14,15} and use this schema, the Systems MUST ensure to include the following information in their Privacy Policy: +> - the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability +> - where the processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal +> - the right to lodge a complaint with a supervisory authority; +> - whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data and of the possible consequences of failure to provide such data +> - the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject. +> - Where personal data are transferred to a third country or to an international organisation, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer. ##### Demand Restrictions -The `action` that the Data Subject requests with a particular Demand MUST be interpreted in the context of restrictions. +The `action` that the Data Subject requests with a particular Demand MUST be interpreted in the context of restrictions. A Demand MAY refer to only certain categories of data, or certain types of processing, certain purposes of processing etc. ###### Data Categories @@ -105,28 +117,28 @@ A Demand MAY be restricted to one or more data categories. For example, a Data S | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | -| `data-category` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER`} | +| `data-category` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER`} | -When several values are given, Systems MUST interpret the `data-category` restriction as a union of all the categories indicated. +When several values are given, Systems MUST interpret the `data-category` restriction as a union of all the categories indicated. -Categories are organised as a hierarchy, denoted with a dot ".", the more general category being written on the left. +Categories are organised as a hierarchy, denoted with a dot ".", the more general category being written on the left. E.g. the following two `data-category` restrictions are equivalent: - `CONTACT`,`CONTACT.EMAIL` - `CONTACT` -In the absence of indication of any `data-category` restriction, Systems MUST interpret the Demand as being related to all categories of data. +In the absence of indication of any `data-category` restriction, Systems MUST interpret the Demand as being related to all categories of data. [A list of eligible `data-category` values with corresponding user-facing descriptions is provided](./dictionary/data-categories/) for conveniance. ###### Categories of Processing -A Demand can be restricted to particular kinds of data processing. +A Demand can be restricted to particular kinds of data processing. For example, a Data Subject can oppose to automatic inference but continue to accept their data beeing collected and stored. | Schema propery | JSON Type | Expected cardinality | Expected values | | --------------- | ------------ | ------ | -------------------- | | `processing-categories` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `USING`, `OTHER`} | -When several values are given, Systems MUST interpret the `processing-categories` restriction as a union of all the processing categories indicated. +When several values are given, Systems MUST interpret the `processing-categories` restriction as a union of all the processing categories indicated. In the absence of indication of any `processing-categories` restriction, Systems MUST interpret the Demand as being related to all and any `processing-categories` of treatment. @@ -140,7 +152,7 @@ A Demand can be restricted to particular purpose of data processing. For example | --------------- | ------------ | ------ | -------------------- | | `purposes` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`ADVERTISING`, `CONTRACT`, `CONTRACT.BASIC-SERVICE`, `CONTRACT.ADDITIONAL-SERVICES`, `NECESSARY`, `NECESSARY.JUSTICE`, `NECESSARY.LEGAL`, `NECESSARY.MEDICAL`, `NECESSARY.PUBLIC-INTERESTS`, `NECESSARY.VITAL-INTERESTS`, `NECESSARY.SOCIAL-PROTECTION`, `MARKETING`, `PERSONNALISATION`, `SALE`, `SECURITY`, `TRACKING`, `OTHER`, `ANY`} | -When several values are given, Systems MUST interpret the `purposes` restriction as a union of all the purposes indicated. +When several values are given, Systems MUST interpret the `purposes` restriction as a union of all the purposes indicated. Purposes are organised as a hierarchy, denoted with a dot ".", the more general purpose being written on the left. E.g. the following two `pruposes` restrictions are equivalent: - `NECESSARY`,`NECESSARY.LEGAL` @@ -158,7 +170,7 @@ A Demand can be restricted to particular Consent ID(s). For example, a Data Subj | --------------- | ------------ | ------ | -------------------- | | `consent-ids` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of consent ids to indicate that the Demand (e.g. a `REVOKE-CONSENT` Demand) is restricted to particular consents. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -When one or more `consent-ids` are idnicated, Systems MUST interpret the Demand as related to all Consents related to indicated `consent-ids`. +When one or more `consent-ids` are idnicated, Systems MUST interpret the Demand as related to all Consents related to indicated `consent-ids`. ###### Capture IDs @@ -204,176 +216,19 @@ In a distributed context, where one System transmits the Rights Request to anoth `USER` indicated the [scenario of direct responses](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#scenario-2---direct-responses) is prefered. Each System having received a Rights Request is expected to reply directly to the Data Subject, using contact information it has. -### Requests list - -| Nb | Request | Description | Associated treatment | Associated data category | Advised elements to provide | Legal ground | CNIL reference -| ---------- | ---- | ---- | ---- | ---- | ---- | ---- |---- | -| -- | ACCESS TYPE | ---- | ---- | ---- | ---- | ---- | ---- | -| 01 | **Access** | Access to all data the organization has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | -| 15 | **Access to my medical record** | Acces to my medical record | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | -| 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | -| 07 | **Access to data a financial organization has on me** *-> to delete and let user make access request + provenance request to the financial organization* | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me *(access+provenance info request)* | ---- | ---- | ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | -| 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** *-> to delete and let user make access request to the "Fichier central des Chèques (FCC)" ?*| Access to all data Fichier central des Chèques (FCC) has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | -| 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** *-> to delete and let user make access request to the "Fichier national des Incidents de remboursement de Crédit (FICP)" ?*| Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | -| 11 | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time *access request to geolocation data and device data* | ---- | ---- | ID, Device type, Date and time | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | -| 12 | **Access to video surveillance data** | Access to video data organization has on me on a specific period of time *access request to video surveillance data* | ---- | ---- | ID, Date and time | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | -| 34 | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller *access request + donwnload?* | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | -| -- | MODIFICATION TYPE | ---- | ---- |---- | -| 02 | **Modification** | Rectify incorrect data organization has on me | ---- | ---- | ID, Information to modify, Information rectified | ---- | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | -| 03 | **Rectification** *to merge in one modification?* | Rectify incomplete data organization has on me | ---- | ---- | ID, Information to modify, Information rectified | ---- | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | -| -- | DELETION TYPE | ---- | ---- |---- | -| 04 | **Deletion** | Delete the data the organization has on me | ---- | ---- | ID, Information to delete*, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | -| 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | ---- | ---- | ID, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | -| 13 | **Closing an online account** | Closing online account, Deletion of all data the organization has on me | ---- | ---- | ID, Account name, Website name, URL of the pages with my data, Data to delete | ---- | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | -| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | ---- | ---- | ID, URL of the pages with my data, Data to delete, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet, https://www.cnil.fr/fr/webmaster-ou-responsables-de-sites-comment-repondre-aux-demandes-de-suppression-de-donnees | -| 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| ---- | ---- | ID | ---- | | -| 33 | **Removal of my image online** | Remove photo or video of me that has been published without my consent| ---- | ---- | ID | ---- | https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne | -| -- | OPPOSITION TO TREATMENT TYPE | ---- | ---- |---- | -| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | ---- | ---- |ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | -| 06 | **Opposition to treatment of all data an organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | ---- | ---- | ID, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | -| 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | *Type of treatment (to choose from possible type of treatment list)* | ---- | | ---- | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | -| 29 | **Opt out of automated decision making** *-> to delete to include in 24. Limit treatment* | Opposition to automated decision making on the data organizatio has on me | ---- | ---- | ID | ---- | | -| 30 | **Opt out of sale of my data** *-> to delete to include in 24. Limit treatment* | Opposition to sale of the data an organization has on me| ---- | ---- | ID | ---- | | -| 31 | **Opt out of tracking on my data** *-> to delete to include in 24. Limit treatment* | Opposition to the tracking of my data from an organization | ---- | ---- | ID | ---- | | -| 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | *Type of treatment (to choose from possible type of treatment list)* | ---- | ID | ---- | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | -| -- | INFORMATIONNAL TYPE | ---- | ---- |---- | -| 17 | **Storage information** | Know where is stored the data organization has on me | ---- | ---- | ID | ---- | | -| 18 | **Accessibility information** | Know who can access the data organization has on me | ---- | ---- | ID | ---- | | -| 19 | **Provenance information** | Know the provenance of data organization has on me | ---- | ---- | ID | ---- | | -| 20 | **Retention information** | Know for how long the data organization has on me will be kept | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | -| 21 | **Deletion information** | Know when my data will be deleted | ---- | ---- | ID | ---- | | -| 22 | **Policy information** | Know what is the policy of the organization to keep data it has on me | ---- | ---- | ID | ---- | | -| 23 | **Purpose of treatment information** | Know the purpose of the treatment organization does on the data it has on me | ---- | ---- | ID | ---- | | -| 25 | **Treatment information** | Know what type(s) of treatment organization does on the data it has on me | ---- | ---- | ID | ---- | | -| 26 | **Particular type(s) of treatment information** | Know if a particular type of treatment is done by organisation on the data it has on me | *Type of treatment (to choose from possible type of treatment list)* | ---- | ID | ---- | | -| -- | OTHER TYPE | ---- | ---- |---- | -| 28 | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | ---- | ---- | | ---- | | - -### Types of treatment list -| Nb | Treatment | Description | CNIL reference -| ---------- | ---- | ---- | ---- | -| 01 | **Collection** | Data collection | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 02 | **Recording** | Data recording | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 03 | **Organisation** | Data organisation | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 04 | **Retention** | Data retention | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 05 | **Adapation** | Data adaptation | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 07 | **Modification** | Data modification | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 08 | **Extraction** | Data extraction | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 09 | **Consultation** | Data consultation| https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 10 | **Usage** | Data usage | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 11 | **Communication** | Data communication by transmission or broadcast or any other form of data communication | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 12| *FR: "Rapprochement" -> EN: "Matching" or "Reconciliation" ?* | | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 13 | **Automatic Inference and Descisionmaking** | Any automatic inference made on the data | [GDPR chap3 art. 13 section 2. c)](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre3#Article13)| -| 14 | **Basic service** | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality | | -| 15 | **Additonal service** | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | | -| 16 | **Tracking** | Tracking information about user behavior and activity online | | -| 17 | **Advertising** | To show ads that are either targeted to the specific user or not targeted | | -| 18 | **Marketing** | To contact the user to offer products, services, or other promotions | | -| 19 | **Analytics** | For understanding the product’s audience, improving the product, inform company strategy, or general research | | -| 20 | **Personnalisation** | For providing user with a personalized experience | | -| 21 | **Operation security** | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | -| 22 | **Legal** | For compliance with legal obligations | | -| 23 | **Ongoing contract** | For ongoing contract purpose | | -| 24 | **Data transfer** | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | -| 25 | **Sale** | Selling data to third parties | | -| 26 | **OTHER** | Other specific purpose not covered above | | -| 27 | **UNSPECIFIED** | The purpose is not explicitly stated or is unclear | | -| 28 | **ALL** | | | - -### Data categories list -| Nb | Data category | Description | CNIL reference -| ---------- | ---- | ---- | ---- | -| 01 | **Name** | Firstname, Surname | | -| 02 | **Postal address** | *contact information* | | -| 03 | **Email address** | *contact information* | | -| 04 | **Phone number** | *contact information* | | -| 04 | **ID data** | Identifiers that uniquely identify a person | | -| 05 | **Financial data** | Financial information | | -| 06 | **Connection data** | Information associated to connection | | -| 07 | **Geoocation data** | Location information | | -| 08 | **Health data** | Health information | | -| 09 | **Tracking data** | Cookies and tracking information about user behavior and activity online| | -| 10 | **User profile** | User’s profile on the first-party website/app and its contents | | -| 11 | **Device data** | Device (desktop, tablet, mobile...) information | | -| 12 | **Form data** | Information collected through forms | | -| 13 | **Image data** | Photo or video | | -| 14 | **Video surveillance data** | Video from video surveillance | | -| 15 | **OTHER** | A specific type of information not covered by the above categories | | -| 16 | **UNSPECIFIED** | The type of information is not explicitly stated or unclear| -| 17 | **ALL** | | | - -### Alternatives Considered - -#### Transcend - -Transcend proposes the following [action (demand) types](https://github.com/transcend-io/privacy-types/blob/main/src/actions.ts): -| Demand Type | Description | Observation | -| -------------- | ----------------------------------------- | ------------------------ | -| ACCESS | Data Download request | | -| ERASURE | Erase the file completely | | -| ACCOUNT_DELETION | Run an account deletion instead of a fully compliant deletion | | -| AUTOMATED_DECISION_MAKING_OPT_OUT | Opt out of automated decision making | | -| CONTACT_OPT_OUT | A contact opt out request | | -| SALE_OPT_OUT | Opt-out of the sale of personal data | | -| TRACKING_OPT_OUT | A tracking opt out request | | -| RECTIFICATION | Make an update to an inaccurate record | | -| RESTRICTION | A restriction of processing request | | - -All of those can be modeled using our Demand Types. - -Transced proposes the following [treatment types](https://github.com/transcend-io/privacy-types/blob/main/src/objects.ts): -| Treatment Type | Description | Observation | -| -------------- | ----------------------------------------- | ------------------------ | -| ESSENTIAL | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality| | -| ADDITIONAL_FUNCTIONALITY | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | | -| ADVERTISING | To show ads that are either targeted to the specific user or not targeted | | -| MARKETING | To contact the user to offer products, services, or other promotions | | -| ANALYTICS | For understanding the product’s audience, improving the product, inform company strategy, or general research | | -| PERSONALIZATION | For providing user with a personalized experience | | -| OPERATION_SECURITY | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | -| LEGAL | For compliance with legal obligations | | -| TRANSFER | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | -| SALE | For selling the data to third parties | | -| HR | For personnel training, recruitment, payroll, management, etc. | corresponds to ongoing contract in our terminology| -| OTHER | Other specific purpose not covered above | | -| UNSPECIFIED | The purpose is not explicitly stated or is unclear | | - -All of those SHOULD be modeled using our Treatment Types. - -Transced proposes the following [data categories](https://github.com/transcend-io/privacy-types/blob/main/src/objects.ts): -| Data Category | Description | Observation | -| -------------- | ----------------------------------------- | ------------------------ | -| FINANCIAL | Financial information | | -| HEALTH | Health information | | -| CONTACT | Contact information | | -| LOCATION | Geo-location information | | -| DEMOGRAPHIC | Demographic Information | | -| ID | Identifiers that uniquely identify a person | | -| ONLINE_ACTIVITY | The user's online activities on the first party website/app or other websites/apps | | -| USER_PROFILE | he user’s profile on the first-party website/app and its contents | | -| SOCIAL_MEDIA | User profile and data from a social media website/app or other third party service | | -| CONNECTION | Connection information for the current browsing session, e.g. device IDs, MAC addresses, IP addresses, etc. | | -| TRACKING | Cookies and tracking elements | | -| DEVICE | Computer or device information | | -| SURVEY | Any data that is collected through surveys | | -| OTHER | A specific type of information not covered by the above categories | | -| UNSPECIFIED | The type of information is not explicitly stated or unclear| | - - - -### User Impact - -**TBD**- What are the user-facing changes? How will this feature be rolled out? +## Detailed Design + +A separate document lists [examples](./examples.md) on how real-life Privacy Requests, as defined in [supported legislation](#supported-legislation), or as modeled in existing systems with which we seek interoperability. ## Detailed Design ### JSON format -We provide a JSON Schema document (**!!!link soon!!!!!**) for machine-readable interpretation of Privacy Requests compliant with [v4 (or ideally lower) of IETF specification](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#:~:text=JSON%20Schema%20is%20a%20JSON,interaction%20control%20of%20JSON%20data.) +We provide a [JSON Schema document](./prif.schema.json) for machine-readable interpretation of Privacy Requests compliant with [v4 (or ideally lower) of IETF specification](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#:~:text=JSON%20Schema%20is%20a%20JSON,interaction%20control%20of%20JSON%20data.) The key requirements of the design are to enable: - Unambiguous expression of Privacy Requests in a machine-readable form -- Integrity of Privacy Requests semantics when exchanged between components and systems. +- Integrity of Privacy Requests semantics when exchanged between components and systems. I.e. A system that has not directly collected the Privacy Requests from the user, but has received in in JSON format from another system, can make the exact same interpretation of the request as if it had collected the request directly. - A way of uniquely identifying one and the same Privacy Request across systems and components concerned by it. @@ -381,11 +236,11 @@ I.e. A system that has not directly collected the Privacy Requests from the user Systems exchanging Privacy Requests MUST be able to do so in a way allowing them to very the integrity of their content, and the identity of the system having emitted the Rignts Request. -For this purposes Privacy Requests MAY be embedded as 'Claims' in [JWTs (FRC7519)](https://datatracker.ietf.org/doc/html/rfc7519). +For this purposes Privacy Requests MAY be embedded as 'Claims' in [JWTs (RFC7519)](https://datatracker.ietf.org/doc/html/rfc7519). ### Decentralized Identity of Data Subjects -The Systems are only able to provide control to Data Subjects if they can identify them. On the other hand, there is no cetnral authority to manage Data Subject identity globally. +The Systems are only able to provide control to Data Subjects if they can identify them. On the other hand, there is no cetnral authority to manage Data Subject identity globally. Therefore, we use a set of atributes to uniquely indenitfy one Data Subject. One and the same Data Subject can have multiple such identities. @@ -465,7 +320,7 @@ When data about Data Subjects is transmitted from one system to another, in orde - Data Subject Identities (`dsid`,`dsid-schema`) pairs associated to the data being trasnfered > **Note** -> +> > Systems that exchange Data Subject information with other Systems MUST: > - expose an API for communicating with other systems about Rights Requests: > - receiving Rights Requests from those other Systems, @@ -480,7 +335,7 @@ We chould immagine an alternative design, where we would force systems to use an ### Mandatory properties and value constrains -Should we include rescritions in the schema according to the [JSON-schema-validation vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#page-4) in order to make certian properties mandatory and ensure to limit string values to the values we suppoort? +Should we include rescritions in the schema according to the [JSON-schema-validation vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#page-4) in order to make certian properties mandatory and ensure to limit string values to the values we suppoort? In the curent proposal, this is the case for Transitivity, but not for request types, data categories, and user identity schemas. We might want to include more forma constraints there, or deliberately leave flexibility. This is a discussion we need to have. @@ -501,18 +356,22 @@ However, it is likely that the System receiving a request will decide how to res ### Representation of Legal Articles -Is there a better way to unambiguousely refer, in a machine-readable way, to parts of legislations? +Is there a better way to unambiguousely refer, in a machine-readable way, to parts of legislations? + +### Schema elegance and modularity +We need a way to make enums different categories and types more elegant, and reusable in the perspective of using them to also represent Data Captures, Consents and responses to Privacy Requests. ## References ### Normative References -- **[RFC8259]** Bray, T., ["The JavaScript Object Notation (JSON) Data Interchange Format"](https://datatracker.ietf.org/doc/html/rfc8259), STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. +- **[RFC8259]** Bray, T., ["The JavaScript Object Notation (JSON) Data Interchange Format"](https://datatracker.ietf.org/doc/html/rfc8259), STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. +- **[RFC2119]** Bradner, S., ["Key words for use in RFCs to Indicate Requirement Levels"](https://datatracker.ietf.org/doc/html/rfc2119), BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, ### Informative References -- +- ### Supported Legislation @@ -523,4 +382,3 @@ Is there a better way to unambiguousely refer, in a machine-readable way, to par - [CPRA]([https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://vig.cdn.sos.ca.gov/2020/general/pdf/topl-prop24.pdf)) - [HIPPA]([https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5](https://www.govinfo.gov/content/pkg/PLAW-104publ191/pdf/PLAW-104publ191.pdf)) - diff --git a/refs/schemas/prif/dictionary/actions/en.actions.json b/refs/schemas/prif/dictionary/actions/en.actions.json index 346f46cb..22b3dc6c 100644 --- a/refs/schemas/prif/dictionary/actions/en.actions.json +++ b/refs/schemas/prif/dictionary/actions/en.actions.json @@ -2,15 +2,21 @@ "ACCESS": "To access the data the System has on me", "DELETE": "To have my data deleted", "MODIFY": "To modify the existing or complement the incomplete data the System has on me", - "PORTABILITY": "To take my day and ahve it transfered somewhere else", "OBJECT": "To contact the user to offer products, services, or other promotions", + "PORTABILITY": "To take my day and ahve it transfered somewhere else", + "RESTRICT": "To restrict processing of my data", "REVOKE-CONSENT": "To revoke prviousely given consent for data processing", - "TRANSPARENCY": "To demand information related to data processing practices", - "TRANSPARENCY.WHERE": "To know where is the data about me stored", - "TRANSPARENCY.WHO": "To know who can access the data that the System has on me", - "TRANSPARENCY.PROVENANCE": "To know the sources that the data concerning me come from", - "TRANSPARENCY.RETENTION": "To know for how long is the data concerning me kept", + "TRANSPARENCY": "To demand information related to data processing practices and know if the system has data on me", + "TRANSPARENCY.DATA-CATEGORIES": "To know the categories of processing being done on the data the System has on me", + "TRANSPARENCY.DPO": "To know the contact details of the data protection officer", + "TRANSPARENCY.LEGAL-BASES": "To know the legal bases for processing my data (including legitimate interests)", + "TRANSPARENCY.ORGANISATION": "To know the identity and the contact details of the organisation processing my data", "TRANSPARENCY.POLICY": "To know the policies being applied to processing of data concerning me", + "TRANSPARENCY.PROCESSING-CATEGORIES": "To know the categories of processing being done on the data the System has on me", + "TRANSPARENCY.PROVENANCE": "To know the sources that the data concerning me come from", "TRANSPARENCY.PURPOSE": "To know the purpose of the processing of the data the System has on me", - "TRANSPARENCY.PROCESSING": "To know the categories of processing being done on the data the System has on me", + "TRANSPARENCY.RETENTION": "To know for how long is the data concerning me kept", + "TRANSPARENCY.WHERE": "To know where is the data about me stored", + "TRANSPARENCY.WHO": "To know who can access the data that the System has on me", + "OTHER": "To do or know something else (specify within the message)", } diff --git a/refs/schemas/prif/dictionary/data-categories/en.data-categories.json b/refs/schemas/prif/dictionary/data-categories/en.data-categories.json index 6070a036..c64ddd72 100644 --- a/refs/schemas/prif/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/prif/dictionary/data-categories/en.data-categories.json @@ -17,6 +17,7 @@ "DEMOGRAPHIC.RACE": "Data related to race", "DEVICE": "Data about the device used by a person", "FINANCIAL": "Data about the financial situation of a person", + "FINANCIAL.BANK-ACCOUNT": "Bank account number and Bank identifier", "GENIC": "Generic data", "HEALTH": "Data about the health", "IMAGE": "Any graphic representation (e.g., image, video) of the person", diff --git a/refs/schemas/prif/dictionary/processing-categories/en.processing-categories.json b/refs/schemas/prif/dictionary/processing-categories/en.processing-categories.json index f268f131..f710c64b 100644 --- a/refs/schemas/prif/dictionary/processing-categories/en.processing-categories.json +++ b/refs/schemas/prif/dictionary/processing-categories/en.processing-categories.json @@ -1,6 +1,6 @@ { - "ANONYMIZATION": "Transforming data to make data sets in which the person can no longer be identified", - "AUTOMATED-INFERENCE": "Automatically infering data about the person, including profiling and clustering", + "ANONYMIZATION": "Processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information", + "AUTOMATED-INFERENCE": "Automatically infering data about the person, including for profiling and clustering", "AUTOMATED-DECISION-MAKING": "Automated decision-making", "COLLECTION": "Collecting data about the person from the person or from another source, including ", "GENERATING": "Producing novel data related to the person, such as making photo, voice or video recordings, or reconding user actions such as making a log.", diff --git a/refs/schemas/prif/examples.md b/refs/schemas/prif/examples.md new file mode 100644 index 00000000..cf741049 --- /dev/null +++ b/refs/schemas/prif/examples.md @@ -0,0 +1,305 @@ +# Privacy Request Interoperability Format : Examples + +| Status | draft | +| :------------ | :------------------------------------------------------------------------------------- | +| **PR #** | [NNN](https://github.com/blindnet-io/PROJECT/pull/NNN) (update when you have PR #) | +| **Author(s)** | milstan (milstan@blindnet.io), Clémentine VINCENT (clementine@blindnet.io) | +| **Sponsor** | milstan (milstan@blindnet.io) | +| **Updated** | 2022-05-25 | + +## Introduction + +This documents examines how the [Privacy Request Interoperability Format](./RFC-prif.md) can be used to represent Privacy Requests: +- introduced by the [supported legislation](#supported-legislation), +- illustrated by tutorials and request templates from regulatory bodies (e.g. [CNIL](https://www.cnil.fr/)), +- or made possible by existing software solutions with which interoperability SHOULD be achieved (e.g. Transcend, Alias.dev) + + +## Motivation + +Elaborating the examples in detail should allow us to test the Privacy Request Interoperability Format for exhaustivity. + +## Terminology + +>**TBD** + +- We use the term Privacy Request interchangeably with the (deprecated) terms Rights Request and Data Rights Request as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) +- We use the terms Individual, Person, You, and Data Subject as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) +- We use the term System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) +- We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) +- We use the terms Organization, Submitter, Data Consumer as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) as defined there. + + +## Examples + +In the following examples we show how, requests introduced by different regulations and systems can be modeled using the Privacy Request Interoperability Format. + +### BASIC GDPR REQUESTS + +#### Articles 13 and 14 + +*...the controller shall, ..., provide the data subject with all of the following information:* + +| CODENAME | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | +| -------- | ----------------------------------------------------- | ------------ | ------------ | ------------ | ------------ | +| `GDPR.13.1.a`, `GDPR.14.1.a` | the identity and the contact details of the controller and, where applicable, of the controller’s representative | `TRANSPARENCY.ORGANISATION` | `null` | `null` | `null` | +| `GDPR.13.1.b`, `GDPR.14.1.b` | the contact details of the data protection officer, where applicable; | `TRANSPARENCY.DPO` | `null` | `null` | `null` | +| `GDPR.13.1.c`, `GDPR.14.1.c` | the purposes of the processing for which the personal data are intended | `TRANSPARENCY.PURPOSE` | `null` | `null` | `null` | +| `GDPR.13.1.c`, `GDPR.14.1.c` | ... legal basis for the processing | `TRANSPARENCY.LEGAL-BASES` | `null` | `null` | `null` | +| `GDPR.13.1.d`, `GDPR.14.1.d` | where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party | `TRANSPARENCY.LEGAL-BASES` | `null` | `null` | `null` | +| `GDPR.13.1.e`, `GDPR.14.1.e` | the recipients or categories of recipients of the personal data, if any; | `TRANSPARENCY.WHO` | `null` | `null` | `null` | +| `GDPR.13.1.f`, `GDPR.14.1.f` | where applicable, the fact that the controller intends to transfer personal data to a third country or international organisation | `TRANSPARENCY.WHERE` | `null` | `null` | `null` | +| `GDPR.13.1.f`, `GDPR.14.1.f` | the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means by which to obtain a copy of them or where they have been made available. | `OTHER` | `null` | `null` | `null` | +| `GDPR.13.2.a`, `GDPR.14.2.a` | the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | +| `GDPR.13.2.b`, `GDPR.14.2.b` | the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | +| `GDPR.13.2.c`, `GDPR.14.2.c` | where the processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | +| `GDPR.13.2.d`, `GDPR.14.2.d` | the right to lodge a complaint with a supervisory authority | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | +| `GDPR.13.2.e`, `GDPR.14.2.e` | whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data | `TRANSPARENCY.PURPOSE` | `null` | `null` | `null` | +| `GDPR.13.2.e`, `GDPR.14.2.e` | ... and of the possible consequences of failure to provide such data | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | +| `GDPR.13.2.f`, `GDPR.14.2.f` | the existence of automated decision-making, including profiling | `TRANSPARENCY.PROCESSING` | `null` | `null` | `null` | +| `GDPR.13.2.f`, `GDPR.14.2.g` | the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject. | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | +| `GDPR.14.2.f` | from which source the personal data originate, and if applicable, whether it came from publicly accessible sources; | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | + + + +#### Article 15.1 + +*The data subject shall have the right to obtain from the controller confirmation as to whether or not personal data concerning him or her are being processed, and, where that is the case, access to the personal data and the following information:* + +| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | +| -------- | ----------------------------------------------------- | ------------ | ------------ | ------------ | ------------ | +| `GDPR.15.1.a` | the purposes of the processing | `TRANSPARENCY.PURPOSE` | `null` | `null` | `null` | +| `GDPR.15.1.b` | the categories of personal data concerned | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `null` | `null` | +| `GDPR.15.1.c` | the recipients or categories of recipient to whom the personal data have been or will be disclosed, in particular recipients in third countries or international organisations; | `TRANSPARENCY.WHO` | `null` | `null` | `null` | +| `GDPR.15.1.d` | where possible, the envisaged period for which the personal data will be stored, or, if not possible, the criteria used to determine that period; | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | +| `GDPR.15.1.e` | the existence of the right to request from the controller rectification or erasure of personal data or restriction of processing of personal data concerning the data subject or to object to such processing; | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | +| `GDPR.15.1.f` | the right to lodge a complaint with a supervisory authority | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | +| `GDPR.15.1.g` | where the personal data are not collected from the data subject, any available information as to their source | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | +| `GDPR.15.1.h` | the existence of automated decision-making, including profiling | `TRANSPARENCY.PROCESSING` | `null` | `null` | `null` | +| `GDPR.15.1.h` | the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | + +#### Article 15.2 and 15.3 + +| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | +| -------- | ----------------------------------------------------- | ------------ | ------------ | ------------ | ------------ | +| `GDPR.15.2` | Where personal data are transferred to a third country or to an international organisation, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | +| `GDPR.15.3` | The controller shall provide a copy of the personal data undergoing processing. | `ACCESS` | `null` | `null` | `null` | + +#### Article 16-22 + +| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | +| -------- | ----------------------------------------------------- | ------------ | ------------ | ------------ | ------------ | +| `GDPR.16` | The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. 2Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement. | `MODIFY` | `null` | `null` | `null` | +| `GDPR.17` | The data subject shall have the right to obtain from the controller the erasure of personal data concerning him | `DELETE` | `null` | `null` | `null` | +| `GDPR.18` | The data subject shall have the right to obtain from the controller restriction of processing | `RESTRICT` | `null` | `null` | `null` | +| `GDPR.20` | **TBD** | `**TBD**` | `null` | `null` | `null` | +| `GDPR.21` | **TBD** (note: 21.2 is not yet supported by the schema)| `**TBD**` | `null` | `null` | `null` | +| `GDPR.22` | **TBD** | `**TBD**` | `null` | `null` | `null` | + + + +### GDPR REQUEST TEMPLATES FROM CNIL + +*[Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant)* + +| LAW | Demande | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | +| -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | +| `GDPR.15` | Access to video surveillance data from 01 Feb 2021 to 03 Feb 2021 | `ACCESS` | `IMAGE` | `null` | `SECURITY` | video surveillance data from 01 Feb 2021 to 03 Feb 2021 | + +>**Note** +> +>we need to add a schema field for providing data ranges (from date to date) + +### OTHER EXAMPLES FROM DAILY LIFE + +*Change my address* + +| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | +| -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | +| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | `MODIFY` | `CONTACT.ADDRESS` | `null` | `null` | `null` | + +>**Note** +> +>we need to add a schema field for providing new data, and date of validity of new data (not necessairly the date of trnasmission) + + +### Requests list (**TO BE TRANSFORMED IN THE ABOVE FORMAT**) + +| Nb | Request | Description | Associated treatment | Associated data category | Advised elements to provide | Legal ground | CNIL reference +| ---------- | ---- | ---- | ---- | ---- | ---- | ---- |---- | +| -- | ACCESS TYPE | ---- | ---- | ---- | ---- | ---- | ---- | +| 01 | **Access** | Access to all data the organization has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | +| 15 | **Access to my medical record** | Acces to my medical record | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | +| 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | +| 07 | **Access to data a financial organization has on me** *-> to delete and let user make access request + provenance request to the financial organization* | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me *(access+provenance info request)* | ---- | ---- | ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | +| 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** *-> to delete and let user make access request to the "Fichier central des Chèques (FCC)" ?*| Access to all data Fichier central des Chèques (FCC) has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | +| 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** *-> to delete and let user make access request to the "Fichier national des Incidents de remboursement de Crédit (FICP)" ?*| Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | +| 11 | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time *access request to geolocation data and device data* | ---- | ---- | ID, Device type, Date and time | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | +| 12 | **Access to video surveillance data** | Access to video data organization has on me on a specific period of time *access request to video surveillance data* | ---- | ---- | ID, Date and time | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | +| 34 | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller *access request + donwnload?* | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | +| -- | MODIFICATION TYPE | ---- | ---- |---- | +| 02 | **Modification** | Rectify incorrect data organization has on me | ---- | ---- | ID, Information to modify, Information rectified | ---- | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | +| 03 | **Rectification** *to merge in one modification?* | Rectify incomplete data organization has on me | ---- | ---- | ID, Information to modify, Information rectified | ---- | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | +| -- | DELETION TYPE | ---- | ---- |---- | +| 04 | **Deletion** | Delete the data the organization has on me | ---- | ---- | ID, Information to delete*, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | +| 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | ---- | ---- | ID, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | +| 13 | **Closing an online account** | Closing online account, Deletion of all data the organization has on me | ---- | ---- | ID, Account name, Website name, URL of the pages with my data, Data to delete | ---- | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | +| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | ---- | ---- | ID, URL of the pages with my data, Data to delete, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet, https://www.cnil.fr/fr/webmaster-ou-responsables-de-sites-comment-repondre-aux-demandes-de-suppression-de-donnees | +| 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| ---- | ---- | ID | ---- | | +| 33 | **Removal of my image online** | Remove photo or video of me that has been published without my consent| ---- | ---- | ID | ---- | https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne | +| -- | OPPOSITION TO TREATMENT TYPE | ---- | ---- |---- | +| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | ---- | ---- |ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | +| 06 | **Opposition to treatment of all data an organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | ---- | ---- | ID, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | +| 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | *Type of treatment (to choose from possible type of treatment list)* | ---- | | ---- | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | +| 29 | **Opt out of automated decision making** *-> to delete to include in 24. Limit treatment* | Opposition to automated decision making on the data organizatio has on me | ---- | ---- | ID | ---- | | +| 30 | **Opt out of sale of my data** *-> to delete to include in 24. Limit treatment* | Opposition to sale of the data an organization has on me| ---- | ---- | ID | ---- | | +| 31 | **Opt out of tracking on my data** *-> to delete to include in 24. Limit treatment* | Opposition to the tracking of my data from an organization | ---- | ---- | ID | ---- | | +| 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | *Type of treatment (to choose from possible type of treatment list)* | ---- | ID | ---- | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | +| -- | INFORMATIONNAL TYPE | ---- | ---- |---- | +| 17 | **Storage information** | Know where is stored the data organization has on me | ---- | ---- | ID | ---- | | +| 18 | **Accessibility information** | Know who can access the data organization has on me | ---- | ---- | ID | ---- | | +| 19 | **Provenance information** | Know the provenance of data organization has on me | ---- | ---- | ID | ---- | | +| 20 | **Retention information** | Know for how long the data organization has on me will be kept | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | +| 21 | **Deletion information** | Know when my data will be deleted | ---- | ---- | ID | ---- | | +| 22 | **Policy information** | Know what is the policy of the organization to keep data it has on me | ---- | ---- | ID | ---- | | +| 23 | **Purpose of treatment information** | Know the purpose of the treatment organization does on the data it has on me | ---- | ---- | ID | ---- | | +| 25 | **Treatment information** | Know what type(s) of treatment organization does on the data it has on me | ---- | ---- | ID | ---- | | +| 26 | **Particular type(s) of treatment information** | Know if a particular type of treatment is done by organisation on the data it has on me | *Type of treatment (to choose from possible type of treatment list)* | ---- | ID | ---- | | +| -- | OTHER TYPE | ---- | ---- |---- | +| 28 | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | ---- | ---- | | ---- | | + +### Types of treatment list +| Nb | Treatment | Description | CNIL reference +| ---------- | ---- | ---- | ---- | +| 01 | **Collection** | Data collection | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 02 | **Recording** | Data recording | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 03 | **Organisation** | Data organisation | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 04 | **Retention** | Data retention | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 05 | **Adapation** | Data adaptation | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 07 | **Modification** | Data modification | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 08 | **Extraction** | Data extraction | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 09 | **Consultation** | Data consultation| https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 10 | **Usage** | Data usage | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 11 | **Communication** | Data communication by transmission or broadcast or any other form of data communication | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 12| *FR: "Rapprochement" -> EN: "Matching" or "Reconciliation" ?* | | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | +| 13 | **Automatic Inference and Descisionmaking** | Any automatic inference made on the data | [GDPR chap3 art. 13 section 2. c)](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre3#Article13)| +| 14 | **Basic service** | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality | | +| 15 | **Additonal service** | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | | +| 16 | **Tracking** | Tracking information about user behavior and activity online | | +| 17 | **Advertising** | To show ads that are either targeted to the specific user or not targeted | | +| 18 | **Marketing** | To contact the user to offer products, services, or other promotions | | +| 19 | **Analytics** | For understanding the product’s audience, improving the product, inform company strategy, or general research | | +| 20 | **Personnalisation** | For providing user with a personalized experience | | +| 21 | **Operation security** | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | +| 22 | **Legal** | For compliance with legal obligations | | +| 23 | **Ongoing contract** | For ongoing contract purpose | | +| 24 | **Data transfer** | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | +| 25 | **Sale** | Selling data to third parties | | +| 26 | **OTHER** | Other specific purpose not covered above | | +| 27 | **UNSPECIFIED** | The purpose is not explicitly stated or is unclear | | +| 28 | **ALL** | | | + +### Data categories list +| Nb | Data category | Description | CNIL reference +| ---------- | ---- | ---- | ---- | +| 01 | **Name** | Firstname, Surname | | +| 02 | **Postal address** | *contact information* | | +| 03 | **Email address** | *contact information* | | +| 04 | **Phone number** | *contact information* | | +| 04 | **ID data** | Identifiers that uniquely identify a person | | +| 05 | **Financial data** | Financial information | | +| 06 | **Connection data** | Information associated to connection | | +| 07 | **Geoocation data** | Location information | | +| 08 | **Health data** | Health information | | +| 09 | **Tracking data** | Cookies and tracking information about user behavior and activity online| | +| 10 | **User profile** | User’s profile on the first-party website/app and its contents | | +| 11 | **Device data** | Device (desktop, tablet, mobile...) information | | +| 12 | **Form data** | Information collected through forms | | +| 13 | **Image data** | Photo or video | | +| 14 | **Video surveillance data** | Video from video surveillance | | +| 15 | **OTHER** | A specific type of information not covered by the above categories | | +| 16 | **UNSPECIFIED** | The type of information is not explicitly stated or unclear| +| 17 | **ALL** | | | + +### Alternatives Considered + +#### Transcend + +Transcend proposes the following [action (demand) types](https://github.com/transcend-io/privacy-types/blob/main/src/actions.ts): +| Demand Type | Description | Observation | +| -------------- | ----------------------------------------- | ------------------------ | +| ACCESS | Data Download request | | +| ERASURE | Erase the file completely | | +| ACCOUNT_DELETION | Run an account deletion instead of a fully compliant deletion | | +| AUTOMATED_DECISION_MAKING_OPT_OUT | Opt out of automated decision making | | +| CONTACT_OPT_OUT | A contact opt out request | | +| SALE_OPT_OUT | Opt-out of the sale of personal data | | +| TRACKING_OPT_OUT | A tracking opt out request | | +| RECTIFICATION | Make an update to an inaccurate record | | +| RESTRICTION | A restriction of processing request | | + +All of those can be modeled using our Demand Types. + +Transced proposes the following [treatment types](https://github.com/transcend-io/privacy-types/blob/main/src/objects.ts): +| Treatment Type | Description | Observation | +| -------------- | ----------------------------------------- | ------------------------ | +| ESSENTIAL | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality| | +| ADDITIONAL_FUNCTIONALITY | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | | +| ADVERTISING | To show ads that are either targeted to the specific user or not targeted | | +| MARKETING | To contact the user to offer products, services, or other promotions | | +| ANALYTICS | For understanding the product’s audience, improving the product, inform company strategy, or general research | | +| PERSONALIZATION | For providing user with a personalized experience | | +| OPERATION_SECURITY | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | +| LEGAL | For compliance with legal obligations | | +| TRANSFER | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | +| SALE | For selling the data to third parties | | +| HR | For personnel training, recruitment, payroll, management, etc. | corresponds to ongoing contract in our terminology| +| OTHER | Other specific purpose not covered above | | +| UNSPECIFIED | The purpose is not explicitly stated or is unclear | | + +All of those SHOULD be modeled using our Treatment Types. + +Transced proposes the following [data categories](https://github.com/transcend-io/privacy-types/blob/main/src/objects.ts): +| Data Category | Description | Observation | +| -------------- | ----------------------------------------- | ------------------------ | +| FINANCIAL | Financial information | | +| HEALTH | Health information | | +| CONTACT | Contact information | | +| LOCATION | Geo-location information | | +| DEMOGRAPHIC | Demographic Information | | +| ID | Identifiers that uniquely identify a person | | +| ONLINE_ACTIVITY | The user's online activities on the first party website/app or other websites/apps | | +| USER_PROFILE | he user’s profile on the first-party website/app and its contents | | +| SOCIAL_MEDIA | User profile and data from a social media website/app or other third party service | | +| CONNECTION | Connection information for the current browsing session, e.g. device IDs, MAC addresses, IP addresses, etc. | | +| TRACKING | Cookies and tracking elements | | +| DEVICE | Computer or device information | | +| SURVEY | Any data that is collected through surveys | | +| OTHER | A specific type of information not covered by the above categories | | +| UNSPECIFIED | The type of information is not explicitly stated or unclear| | + + + +## Questions and Discussion Topics + + + +## References + +### Normative References + +- **[RFC8259]** Bray, T., ["The JavaScript Object Notation (JSON) Data Interchange Format"](https://datatracker.ietf.org/doc/html/rfc8259), STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. + +### Informative References + +- + +### Supported Legislation + +- [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) +- [CCPA](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5) + +### Yet to be Supported Legilsation + +- [CPRA]([https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://vig.cdn.sos.ca.gov/2020/general/pdf/topl-prop24.pdf)) +- [HIPPA]([https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5](https://www.govinfo.gov/content/pkg/PLAW-104publ191/pdf/PLAW-104publ191.pdf)) diff --git a/refs/schemas/prif/prif.schema.json b/refs/schemas/prif/prif.schema.json index ac66e293..5084f27c 100644 --- a/refs/schemas/prif/prif.schema.json +++ b/refs/schemas/prif/prif.schema.json @@ -105,17 +105,23 @@ "enum":["ACCESS", "DELETE", "MODIFY", - "PORTABILITY", "OBJECT", + "PORTABILITY", + "RESTRICT", "REVOKE-CONSENT", "TRANSPARENCY", - "TRANSPARENCY.WHERE", - "TRANSPARENCY.WHO", - "TRANSPARENCY.PROVENANCE", - "TRANSPARENCY.RETENTION", + "TRANSPARENCY.DATA-CATEGORIES", + "TRANSPARENCY.DPO", + "TRANSPARENCY.LEGAL-BASES", + "TRANSPARENCY.ORGANISATION", "TRANSPARENCY.POLICY", + "TRANSPARENCY.PROCESSING-CATEGORIES", + "TRANSPARENCY.PROVENANCE", "TRANSPARENCY.PURPOSE", - "TRANSPARENCY.PROCESSING"] + "TRANSPARENCY.RETENTION", + "TRANSPARENCY.WHERE", + "TRANSPARENCY.WHO", + "OTHER"] }, "data-categories": { @@ -137,6 +143,7 @@ "DEMOGRAPHIC.RACE", "DEVICE", "FINANCIAL", + "FINANCIAL.BANK-ACCOUNT", "GENETIC", "HEALTH", "IMAGE", From 0fe7cbe5128360fc413707ac7e2e48bdd2312797 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 26 May 2022 12:12:51 +0200 Subject: [PATCH 061/204] Simplifciation of the format --- refs/schemas/prif/RFC-prif.md | 117 +++++++++++++++++------------ refs/schemas/prif/prif.schema.json | 68 ++++++++--------- 2 files changed, 100 insertions(+), 85 deletions(-) diff --git a/refs/schemas/prif/RFC-prif.md b/refs/schemas/prif/RFC-prif.md index df023652..d9fee023 100644 --- a/refs/schemas/prif/RFC-prif.md +++ b/refs/schemas/prif/RFC-prif.md @@ -12,20 +12,16 @@ We propose a simple, structured data format for representing [Privacy Requests](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-conceptualization#data-capture--rights-requests). This format corresponds to the [Data Rights Request Schema](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#schemas) component of the [High- Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). -Privacy Requests exist within the relationship between an individual and software Systems (and Organisations operating them) processing data that concerns that individual. +## Motivation -Internet Systems are tools for connection. -[Connectedness requires privacy - the selective control of access to the self](https://github.com/blindnet-io/product-management/blob/10bebeefc14f7db7bf7a491932d62a4a5d18ad70/refs/notion-of-privacy/notion-of-privacy.md). -An individual MAY formulate a Privacy Request in order to establish that control and regulate the relationship, . -Systems MAY process and respond to Rights Request by legal obligation, or as a simple courtesy in the pursuit of gaining and maintaining the individual's trust. +An individual is in connection with software Systems (and Organisations operating them) that process the individual's data. +In order to [regulate the relationship](https://github.com/blindnet-io/product-management/blob/10bebeefc14f7db7bf7a491932d62a4a5d18ad70/refs/notion-of-privacy/notion-of-privacy.md) with those Systems (and Organisations), the individual makes requests related to their privacy. -## Motivation +With a Privacy Request the individual aims to gain a degree of transparency about data processing and a degree of control over the data and over the data processing. Allowing individuals to make Privacy Requests is becoming more and more a legal obligation. -Different Systems, and different compontents of a single System, including different comnponents of blindnet devkit are likely to exchange information about Privacy Requests. +Different Systems, and different compontents of a single System, including different comnponents of blindnet devkit are likely to exchange information about Privacy Requests. Therefore, a common format is needed to facilitate exchange of information without loss of semantics. The goal of Privacy Request Interoperability Format is to establish a shared conceptualisation and format of Privacy Request so that their processing can be, as much as possible, automatised by the Systems. -Therefore, a common format is needed to facilitate exchange of information without loss of semantics. -The goal of Privacy Request Interoperability Format is to establish a shared conceptualisation and format of Privacy Request so that their processing can be, as much as possible, automatised by the Systems. ## Terminology @@ -39,16 +35,30 @@ The goal of Privacy Request Interoperability Format is to establish a shared con ## Design Considerations +### Design Goals + With this design we seek: -- Consistent unambiguous interpretation of Privacy Request across different Systems, independently of programming languages and components they use, +- Consistent unambiguous interpretation of Privacy Requests (including shared understanding of their meaning and ways to uniquely identify them) across different Systems, independently of programming languages and components they use - Minimal exposure of Data Subject and their data during the processing of a Privacy Request, - Making processing of Privacy Requests as automatic as possible, - Compatibility with the use of different protocols and tools for user identity management, authentication, and encryption, -- Allowing developers to be fully comply with [supported legislation](#supported-legislation) quickly and easily +- Allowing developers to be fully comply with [supported legislation](#supported-legislation) related to Privacy Requests quickly and easily - Exhaustivity with regards to situations we need to support in response to [supported legislation](#supported-legislation) yet Extensibility in case new situations arise in the future. - Highly normative minimal specification, using as much as possible the [Plain Language](https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf) while at the same time making clear references to the (often misfortunate) language of the [supported legislations](#supported-legislation) - Decentralised design compatible with both the Internet's Client-Server Architecture and Metaverse/Web3 Architecture +### Design Choices + +We have made the following choices: +- **Language Independence**. The Privacy Request Interoperability Format is independent from any language for expressing structured data, and can be materialised in different forms such as json, xml, or other. A [json schema](prif.schema.json) is provided for convenience. + +- **Rich Semantics**. The Privacy Request Interoperability Format includes reserved words to describe common types of Privacy Requests, categories of data, categories of data processing and other key concepts. This choice is made to facilitate their uniform interpretation by the implementing systems. Their [human-readable titles and descriptions](dictionary) are provided in json format for convenience. + +- **Multiple User Identities**. The Privacy Request Interoperability Format allows for a Data Subject to be identified using more than one user identity. This choice is made to enable the Privacy Request to be easily exchanged across Systems that use different user identifiers. + +- **System as a Target**. The Privacy Requests are interpreted at the level of a particular System. If an Organisation operates several systems, and if the Data Subject wants to have the Privacy Request transmitted to all of them, each System may respond differently. The target of a Privacy Request is thus the System exposing an API for Privacy Requests. + +- **Decentralised IDs**. The Privacy Request Interoperability Format uses decentralised ways to uniquely identify Data Subjects, Systems, Requests and their elements. The exchange of Privacy Requests can happen without a centralised entity to control identity disambiguation. ## Proposal @@ -96,16 +106,6 @@ Their relationships are dentoed with a dot "." separating two actions, the more `TRANSPARENCY` includes `TRANSPARENCY.WHERE`. When `TRANSPARENCY` is demanded, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` were demanded. -> **Note** -> -> To be compliant with GDPR.{13,14,15} and use this schema, the Systems MUST ensure to include the following information in their Privacy Policy: -> - the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability -> - where the processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal -> - the right to lodge a complaint with a supervisory authority; -> - whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data and of the possible consequences of failure to provide such data -> - the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject. -> - Where personal data are transferred to a third country or to an international organisation, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer. - ##### Demand Restrictions The `action` that the Data Subject requests with a particular Demand MUST be interpreted in the context of restrictions. @@ -127,7 +127,7 @@ E.g. the following two `data-category` restrictions are equivalent: - `CONTACT` In the absence of indication of any `data-category` restriction, Systems MUST interpret the Demand as being related to all categories of data. -[A list of eligible `data-category` values with corresponding user-facing descriptions is provided](./dictionary/data-categories/) for conveniance. +[A list of eligible `data-category` values with corresponding user-facing descriptions is provided](dictionary/data-categories/) for conveniance. ###### Categories of Processing @@ -142,7 +142,7 @@ When several values are given, Systems MUST interpret the `processing-categories In the absence of indication of any `processing-categories` restriction, Systems MUST interpret the Demand as being related to all and any `processing-categories` of treatment. -[A list of eligible `processing-categories` values with corresponding user-facing descriptions is provided](./dictionary/purposes/) for conveniance. +[A list of eligible `processing-categories` values with corresponding user-facing descriptions is provided](dictionary/purposes) for conveniance. ###### Purposes of Processing @@ -202,23 +202,11 @@ When System B receives an `INTRANSITIVE` Rights Request, it SHOULD NOT transfer Systems should interpret the transitivity of Rights Request the same way regardless of the Rights Request being received directly from the Data Subject or from a corresponding System. -Convenient tables of `transitivity` vlaues and corresponding user-facing descriptions, in different languages, are provided [here](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/schemas/dictionary/transitivity/). - -#### Reply-to - -In a distributed context, where one System transmits the Rights Request to another System, a `reply-to` field MAY be specified. - -| Schema propery | JSON Type | Expected cardinality | Expected values | -| --------------- | ------------ | ------ | -------------------- | -| `reply-to` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | One of {`SYSTEM`, `USER`} | - -`SYSTEM` indicates that the [scenario of nested responses](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#scenario-1---nested-responses) is prefered. The System having registered the Rights Request from the Data Subject gathers responses and presents them to the Data Subject. - -`USER` indicated the [scenario of direct responses](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#scenario-2---direct-responses) is prefered. Each System having received a Rights Request is expected to reply directly to the Data Subject, using contact information it has. +Convenient tables of `transitivity` values and corresponding user-facing descriptions, in different languages, are provided [here](dictionary/transitivity). ## Detailed Design -A separate document lists [examples](./examples.md) on how real-life Privacy Requests, as defined in [supported legislation](#supported-legislation), or as modeled in existing systems with which we seek interoperability. +A separate document gives a list of [examples](examples.md) on how to represent real-life Privacy Requests, as defined in [supported legislation](#supported-legislation), or as modeled in existing systems with which we seek interoperability. ## Detailed Design @@ -226,12 +214,6 @@ A separate document lists [examples](./examples.md) on how real-life Privacy Req We provide a [JSON Schema document](./prif.schema.json) for machine-readable interpretation of Privacy Requests compliant with [v4 (or ideally lower) of IETF specification](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#:~:text=JSON%20Schema%20is%20a%20JSON,interaction%20control%20of%20JSON%20data.) -The key requirements of the design are to enable: -- Unambiguous expression of Privacy Requests in a machine-readable form -- Integrity of Privacy Requests semantics when exchanged between components and systems. -I.e. A system that has not directly collected the Privacy Requests from the user, but has received in in JSON format from another system, can make the exact same interpretation of the request as if it had collected the request directly. -- A way of uniquely identifying one and the same Privacy Request across systems and components concerned by it. - ### Authenticated exchanges Systems exchanging Privacy Requests MUST be able to do so in a way allowing them to very the integrity of their content, and the identity of the system having emitted the Rignts Request. @@ -310,9 +292,11 @@ The lists of Data Categories, Treatment Types, Actions, and Purposes SHOULD be d - **Unambiguous** : The developer using the schema knows without ambiguity which one (of which ones) to use in any given situation, AND - **Complete** : They allow to exress the totality of possible needs in the context of a user wanting to [regulate their privacy/connectedness](https://github.com/blindnet-io/product-management/blob/dogma/refs/notion-of-privacy/notion-of-privacy.md), as well as the totality of requests defined by the [supported legilsation](#supported-legilsation). +## Design Implications for Systems Implementing PRIF + ### Remembering Transfers -When data about Data Subjects is transmitted from one system to another, in order to be able to process [Transitive Rights Requests](#transitive-rights-request), Systems MUST keep track of: +When data about Data Subjects is transmitted from one system to another, in order to be able to process [Transitive Rights Requests](#transitive-rights-request), and in order to reply to `TRANSPARENCY.WHO` and `TRANSPARENCY.PROVENANCE` demands, Systems MUST keep track of: - System of destination/origin and addresses where their APIs can be reached - Categories of data being trasnfered - Identifiers (`data-capture-id`s,`fragment-id`s) associated to the data being trasnfered @@ -326,6 +310,40 @@ When data about Data Subjects is transmitted from one system to another, in orde > - receiving Rights Requests from those other Systems, > - receiving Rights Request Responses from other Systems in the case of [Nested Responses Scenario](https://github.com/blindnet-io/product-management/tree/devkit-schemas/refs/high-level-architecture#different-rights-request-response-scenrarios). +### Storing General Information + +In order to automatically respond to `TRANSPARENCY` demands, Systems should store general information about: +- Countries where data servers are located (`TRANSPARENCY.WHERE`) +- The identity of the organization controling them, and the Organization's representative(s) (`TRANSPARENCY.WHO`) +- The categories of Data Consumers, and access policies (`TRANSPARENCY.WHO`) +- Identity and contact of a Data Protection Officer (`TRANSPARENCY.DPO`) +- A link to their Privacy Policy (`TRANSPARENCY.POLICY`) +> **Note** +> +> To be compliant with GDPR.{13,14,15} and use this schema, the Systems MUST ensure to include the following information in their Privacy Policy: +> - the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability +> - where the processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal +> - the right to lodge a complaint with a supervisory authority; +> - whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data and of the possible consequences of failure to provide such data +> - the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject. +> - Where personal data are transferred to a third country or to an international organisation, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer. + +### Storing Capture-related Information + +In order to automatically respond to data-specific demands, Systems should store particular information about every Data Capture (and make sure to implement ways of configuring how this information is applied to Data Captures): +- Legal Basis for processing particular data - can be different per Data Capture Fragment (`TRANSPARENCY.LEGAL-BASES`, but also for automatically evaluating the legality of keeping data upon `REVOKE-CONSENT`, `OBJECT`, `RESTRICT`, `DELETE` requests) +- Purposes of data processing - can be different per Data Capture Fragment (`TRANSPARENCY.PURPOSES`, but also for automatically evaluating `OBJECT` and `RESTRICT` requests related to particular Purposes) +- Duration of mandatory data keeping, as well as period after which the data is automatically deleted - Can be difernt per Data Capture Fragment, and relative to en event such as Data Capture, End of Contract, Account Deletion (`TRANSPARENCY.RETENTION`, but also for automatically evaluating the legality of keeping data at a certain time and upon `REVOKE-CONSENT`, `OBJECT`, `RESTRICT`, `DELETE` requests) +- Data Categories - can be different per Data Capture Fragment (`TRANSPARENCY.DATA-CATEGORIES`) +- Data Processing Categories - can be different per Data Capture Fragment (`TRANSPARENCY.PROCESSING-CATEGORIES`) +- Purposes of Data Processing - can be different per Data Capture Fragment (`TRANSPARENCY.PURPOSE`) + +>**Note** +> +> To automatically calculate legality of keeping a particular data, Systems MUST track events such as Data Capture, End of Contract, Account Deletion + + + ## Questions and Discussion Topics @@ -348,12 +366,6 @@ E.g. We have a data capture associated to "CONTACT.ADDRESS" data category. The D However, this notation (although intuitive) is to the best of my knoweldge, non-standard. Maybe there are reasons for it, or a standard (better) notation we can adopt? Or if none (which would be surprising) we could define our syntax using [Backus-Naur Form](https://datatracker.ietf.org/doc/html/rfc4234). Advantage: geeks will love us. -### Reply-to is maybe unnecessary - -The schema allows requests to specify a [`reply-to`](#reply-to) and idnicate which mode of answer is prefered with regards to the two possible scenarios: [scenario of nested responses](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#scenario-1---nested-responses) and [scenario of direct responses](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#scenario-2---direct-responses). - -However, it is likely that the System receiving a request will decide how to respond depending on the type of request and depending on its relationship with the user, in which case speficying this field is unnecessary. - ### Representation of Legal Articles Is there a better way to unambiguousely refer, in a machine-readable way, to parts of legislations? @@ -362,6 +374,11 @@ Is there a better way to unambiguousely refer, in a machine-readable way, to par We need a way to make enums different categories and types more elegant, and reusable in the perspective of using them to also represent Data Captures, Consents and responses to Privacy Requests. +### Addressability of System Endpoints + +Is there a standard way for representing peer-to-peer System's API endpoints that we can reuse here for representing systems. + + ## References ### Normative References diff --git a/refs/schemas/prif/prif.schema.json b/refs/schemas/prif/prif.schema.json index 5084f27c..82ba32e7 100644 --- a/refs/schemas/prif/prif.schema.json +++ b/refs/schemas/prif/prif.schema.json @@ -1,29 +1,29 @@ { "$id": "https://blindnet.io/schemas/rights-request", "$schema": "https://json-schema.org/draft/2020-12/schema", - + "title": "Privacy Request", "description": "This document defines a format for interoperability of Privacy Requests", - + "type": "object", "properties": { "request-id": { "type": "string", "format": "uuid" }, - + "data-subject": { "type": "array", - "items": { "$ref": "#/$defs/data-subject-identity" }, + "items": { "$ref": "#/$defs/data-subject-identity" }, "minItems": 1 }, - + "demands": { "type": "array", - "items": { "$ref": "#/$defs/demand" }, + "items": { "$ref": "#/$defs/demand" }, "minItems": 1 }, - + "transitivity": { "enum": ["DOWNWARD","UPWARD","BIDIRECTIONAL","INTRANSITIVE"], "default": "INTRANSITIVE", @@ -34,73 +34,71 @@ "format": "date-time" }, - "reply-to": { - "enum": ["SYSTEM","USER"] - }, - + + }, - + "required": ["rights-request-id", "timestamp"], "definitions": { - + }, - + "$defs": { "data-subject-identity": { "$id": "/schemas/data-subject-identity", "$schema": "https://json-schema.org/draft/2020-12/schema#", "type": "object", - + "properties": { "dsid-schema": { "type": "string" }, "dsid": { "type": "string" }, }, - + "required": ["dsid-schema", "dsid"], }, - + "demand": { "$id": "/schemas/demand", "$schema": "https://json-schema.org/draft/2020-12/schema#", "type": "object", - + "properties": { "demande-id": { "type": "string" }, - + "message": { "type": "string" }, - + "language": { "type": "string" }, - + "legal-grounds": { "type": "array", - "items": { "type": "string" } + "items": { "type": "string" } }, - + "consent-ids": { "type": "array", - "items": { + "items": { "type": "string", "format": "uuid" - } + } }, "capture-ids": { "type": "array", - "items": { + "items": { "type": "string", "format": "uuid" - } + } } - + "action": { "enum":["ACCESS", "DELETE", @@ -123,7 +121,7 @@ "TRANSPARENCY.WHO", "OTHER"] }, - + "data-categories": { "enum": ["AFFILIATION", "BEHAVIOR", @@ -152,9 +150,9 @@ "RELATIONSHIPS", "PROFILING", "UID", - "OTHER"] + "OTHER"] }, - + "processing-categories": { "enum": ["ANONYMIZATION", "AUTOMATED-INFERENCE", @@ -189,11 +187,11 @@ "ANY"] }, - - + + }, - - + + }, From 52d2036d6fc2baff9a287ad0ca08356c1dd42bf7 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 26 May 2022 12:40:55 +0200 Subject: [PATCH 062/204] removing json type (for language-independance) --- refs/schemas/prif/RFC-prif.md | 70 +++++++++++++++++------------------ 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/refs/schemas/prif/RFC-prif.md b/refs/schemas/prif/RFC-prif.md index d9fee023..d160d349 100644 --- a/refs/schemas/prif/RFC-prif.md +++ b/refs/schemas/prif/RFC-prif.md @@ -66,9 +66,9 @@ We have made the following choices: Data Subject is the author of a Privacy Request. -| Schema propery | JSON Type | Expected cardinality | Expected values | -| --------------- | ------------ | ------ | -------------------- | -| `data-subject` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | An array of objects, each containing a (`dsid`,`dsid-schema`) pair | +| Schema propery | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `data-subject` | 1-* | Objects, each containing a (`dsid`,`dsid-schema`) pair | A System MAY have muptiple ways to identify the Data Subject, especially when data about them came from some other System that uses different identifiers. The System capturing the Privacy Request MAY associate multiple Data Subject Identities to the Privacy Request, especially if the Privacy Request is likely to be transmitted to other systems. @@ -77,11 +77,11 @@ An array of one or more [Data Subject Identities](#decentralized-identity-of-dat In addition, the Privacy Request has other meta-data: -| Schema propery | JSON Type | Expected cardinality | Expected values | -| --------------- | ------------ | ------ | -------------------- | -| `request-id` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique ID for referening to this request in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `date` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | Date and Time when Privacy Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| `demands` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1-* | An array of [Demands](#demands) | +| Schema propery | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `request-id` | 1 | Unique ID for referening to this request in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `date` | 1 | Date and Time when Privacy Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `demands` | 1-* | [Demands](#demands) | The Data Subject can request several things (e.g. see the data the System has on me, know the source from where you have got it, and have my data deleted). We call those 'Demands'. @@ -91,13 +91,13 @@ A Privacy Request includes an array of one or more Demands. A Demand is a concrete action that the user requests. -| Schema propery | JSON Type | Expected cardinality | Expected values | -| --------------- | ------------ | ------ | -------------------- | -| `demande-id` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique ID for referening to this demande in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `action` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | -| `legal-grounds`| [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of strings representing legal grounds that support the Demand. E.g. "GDPR.13" indicates Article 13 of GDPR, "CCPA.1798.105" indicates Section 1798.105 of CCPA | -| `message` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | Optional comment, motivation or explanation of Demand | -| `language` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | +| Schema propery | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `demande-id` | 1 | Unique ID for referening to this demande in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `action` | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | +| `legal-grounds`| 0-* | Optional strings representing legal grounds that support the Demand. E.g. "GDPR.13" indicates Article 13 of GDPR, "CCPA.1798.105" indicates Section 1798.105 of CCPA | +| `message` | 0-1 | Optional string comment, motivation or explanation of Demand | +| `language` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | The key element that defines the nature of the Demand is the `action`. A Demande MUST have one and only one `action`. @@ -115,9 +115,9 @@ A Demand MAY refer to only certain categories of data, or certain types of proce A Demand MAY be restricted to one or more data categories. For example, a Data Subject can request to access to all data concerning his location. -| Schema propery | JSON Type | Expected cardinality | Expected values | -| --------------- | ------------ | ------ | -------------------- | -| `data-category` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER`} | +| Schema propery | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `data-category` | 0-* | `AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER` | When several values are given, Systems MUST interpret the `data-category` restriction as a union of all the categories indicated. @@ -134,9 +134,9 @@ In the absence of indication of any `data-category` restriction, Systems MUST in A Demand can be restricted to particular kinds of data processing. For example, a Data Subject can oppose to automatic inference but continue to accept their data beeing collected and stored. -| Schema propery | JSON Type | Expected cardinality | Expected values | -| --------------- | ------------ | ------ | -------------------- | -| `processing-categories` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `USING`, `OTHER`} | +| Schema propery | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `processing-categories` | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `USING`, `OTHER`} | When several values are given, Systems MUST interpret the `processing-categories` restriction as a union of all the processing categories indicated. @@ -148,9 +148,9 @@ In the absence of indication of any `processing-categories` restriction, Systems A Demand can be restricted to particular purpose of data processing. For example, a Data Subject can oppose to any data processing done for marketing purposes, but still accept their data being processed for the sake of personalisation of their experience. -| Schema propery | JSON Type | Expected cardinality | Expected values | -| --------------- | ------------ | ------ | -------------------- | -| `purposes` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | One of {`ADVERTISING`, `CONTRACT`, `CONTRACT.BASIC-SERVICE`, `CONTRACT.ADDITIONAL-SERVICES`, `NECESSARY`, `NECESSARY.JUSTICE`, `NECESSARY.LEGAL`, `NECESSARY.MEDICAL`, `NECESSARY.PUBLIC-INTERESTS`, `NECESSARY.VITAL-INTERESTS`, `NECESSARY.SOCIAL-PROTECTION`, `MARKETING`, `PERSONNALISATION`, `SALE`, `SECURITY`, `TRACKING`, `OTHER`, `ANY`} | +| Schema propery | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `purposes` | 0-* | `ADVERTISING`, `CONTRACT`, `CONTRACT.BASIC-SERVICE`, `CONTRACT.ADDITIONAL-SERVICES`, `NECESSARY`, `NECESSARY.JUSTICE`, `NECESSARY.LEGAL`, `NECESSARY.MEDICAL`, `NECESSARY.PUBLIC-INTERESTS`, `NECESSARY.VITAL-INTERESTS`, `NECESSARY.SOCIAL-PROTECTION`, `MARKETING`, `PERSONNALISATION`, `SALE`, `SECURITY`, `TRACKING`, `OTHER`, `ANY` | When several values are given, Systems MUST interpret the `purposes` restriction as a union of all the purposes indicated. @@ -166,9 +166,9 @@ In the absence of indication of any `purpose` restriction, Systems MUST interpre A Demand can be restricted to particular Consent ID(s). For example, a Data Subject revoques a particular consent only (the one related to his data being shared with 3rd parties) but maintains other consents they may have given. -| Schema propery | JSON Type | Expected cardinality | Expected values | -| --------------- | ------------ | ------ | -------------------- | -| `consent-ids` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of consent ids to indicate that the Demand (e.g. a `REVOKE-CONSENT` Demand) is restricted to particular consents. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| Schema propery | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `consent-ids` | 0-* | Optional array of consent ids to indicate that the Demand (e.g. a `REVOKE-CONSENT` Demand) is restricted to particular consents. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | When one or more `consent-ids` are idnicated, Systems MUST interpret the Demand as related to all Consents related to indicated `consent-ids`. @@ -176,22 +176,22 @@ When one or more `consent-ids` are idnicated, Systems MUST interpret the Demand A Demand can be restricted to particular Capture ID(s). For example, a Data Subject to delete a particular data, they indicate the data capture concerned by their Demand. -| Schema propery | JSON Type | Expected cardinality | Expected values | -| --------------- | ------------ | ------ | -------------------- | -| `capture-ids` | [array](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-* | Optional array of Data Capture IDs to indicate that the Demand (e.g. a `DELETE` Demand) is restricted to data captured within particular Data Captures. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| Schema propery | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `capture-ids` | 0-* | Optional array of Data Capture IDs to indicate that the Demand (e.g. a `DELETE` Demand) is restricted to data captured within particular Data Captures. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | When one or more `capture-ids` are indicated, Systems MUST interpret the demande all related to all the data captured as part of those Data Captures. #### Transitive Privacy Request A Privacy Request can be transitive. -Transitive Privacy Requests are usefull in a distributed context where System A gave information about the Data Subject to System B, and System B gave information about the Data Subject to System C. +Transitive Privacy Requests are useful in a distributed context where System A gave information about the Data Subject to System B, and System B gave information about the Data Subject to System C. -When a System receives a transitive Rights Request, it SHOULD not only respond to it, but also transfer it to corresponding Systems with which it exchnaged data about the Data Subject. +When a System receives a transitive Rights Request, it SHOULD not only respond to it, but also transfer it to corresponding Systems with which it exchanged data about the Data Subject. -| Schema propery | JSON Type | Expected cardinality | Expected values | -| --------------- | ------------ | ------ | -------------------- | -| `transitivity` | [string](https://datatracker.ietf.org/doc/html/rfc8259#page-6) | 0-1 | One of {`DOWNWARD`, `UPWARD`, `BIDIRECTIONAL`, `INTRANSITIVE`} | +| Schema property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `transitivity` | 0-1 | Optionally one of {`DOWNWARD`, `UPWARD`, `BIDIRECTIONAL`, `INTRANSITIVE`} | Transitivity of Rights Requests can be `DOWNWARD` `UPWARD`, `BIDIRECTIONAL` or `INTRANSITIVE`. In the absence of any indication `INTRANSITIVE` SHOULD be assumed. From 5e348c36546bc6fac39b6da5a67cf68faedf3de8 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 26 May 2022 14:50:47 +0200 Subject: [PATCH 063/204] typos, and more questions for discussion --- refs/schemas/prif/RFC-prif.md | 139 ++++++++++++------ .../prif/dictionary/actions/en.actions.json | 1 + refs/schemas/prif/prif.schema.json | 1 + 3 files changed, 93 insertions(+), 48 deletions(-) diff --git a/refs/schemas/prif/RFC-prif.md b/refs/schemas/prif/RFC-prif.md index d160d349..1ab4cf98 100644 --- a/refs/schemas/prif/RFC-prif.md +++ b/refs/schemas/prif/RFC-prif.md @@ -3,8 +3,8 @@ | Status | draft | | :------------ | :------------------------------------------------------------------------------------- | | **PR #** | [NNN](https://github.com/blindnet-io/PROJECT/pull/NNN) (update when you have PR #) | -| **Author(s)** | milstan (milstan@blindnet.io), Clémentine VINCENT (clementine@blindnet.io) | -| **Sponsor** | milstan (milstan@blindnet.io) | +| **Author(s)** | [milstan](https://github.com/milstan) (milstan@blindnet.io) | +| **Sponsor** | [milstan](https://github.com/milstan) (milstan@blindnet.io) | | **Updated** | 2022-05-25 | ## Introduction @@ -19,7 +19,7 @@ In order to [regulate the relationship](https://github.com/blindnet-io/product-m With a Privacy Request the individual aims to gain a degree of transparency about data processing and a degree of control over the data and over the data processing. Allowing individuals to make Privacy Requests is becoming more and more a legal obligation. -Different Systems, and different compontents of a single System, including different comnponents of blindnet devkit are likely to exchange information about Privacy Requests. Therefore, a common format is needed to facilitate exchange of information without loss of semantics. The goal of Privacy Request Interoperability Format is to establish a shared conceptualisation and format of Privacy Request so that their processing can be, as much as possible, automatised by the Systems. +Different Systems, and different components of a single System, including different components of blindnet devkit are likely to exchange information about Privacy Requests. Therefore, a common format is needed to facilitate exchange of information without loss of semantics. The goal of Privacy Request Interoperability Format is to establish a shared conceptualisation and format of Privacy Request so that their processing can be, as much as possible, automatised by the Systems. @@ -66,20 +66,21 @@ We have made the following choices: Data Subject is the author of a Privacy Request. -| Schema propery | Expected cardinality | Expected values | +| Schema property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-subject` | 1-* | Objects, each containing a (`dsid`,`dsid-schema`) pair | +| `data-subject` | 1-* | [Data Subject Identities](#decentralized-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| + +A System MAY have multiple ways to identify the Data Subject, especially when data about them came from some other System that uses different identifiers. -A System MAY have muptiple ways to identify the Data Subject, especially when data about them came from some other System that uses different identifiers. The System capturing the Privacy Request MAY associate multiple Data Subject Identities to the Privacy Request, especially if the Privacy Request is likely to be transmitted to other systems. An array of one or more [Data Subject Identities](#decentralized-identity-of-data-subjects) MUST be provided in order to match the Data Subject with the data concerning them. In addition, the Privacy Request has other meta-data: -| Schema propery | Expected cardinality | Expected values | +| Schema property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `request-id` | 1 | Unique ID for referening to this request in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `request-id` | 1 | Unique ID for referring to this request in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Privacy Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `demands` | 1-* | [Demands](#demands) | @@ -91,10 +92,10 @@ A Privacy Request includes an array of one or more Demands. A Demand is a concrete action that the user requests. -| Schema propery | Expected cardinality | Expected values | +| Schema property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `demande-id` | 1 | Unique ID for referening to this demande in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `action` | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | +| `demande-id` | 1 | Unique ID for referring to this demande in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `action` | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | | `legal-grounds`| 0-* | Optional strings representing legal grounds that support the Demand. E.g. "GDPR.13" indicates Article 13 of GDPR, "CCPA.1798.105" indicates Section 1798.105 of CCPA | | `message` | 0-1 | Optional string comment, motivation or explanation of Demand | | `language` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | @@ -102,7 +103,7 @@ A Demand is a concrete action that the user requests. The key element that defines the nature of the Demand is the `action`. A Demande MUST have one and only one `action`. Actions are hierarchical. -Their relationships are dentoed with a dot "." separating two actions, the more general one being written on the left. +Their relationships are denoted with a dot "." separating two actions, the more general one being written on the left. `TRANSPARENCY` includes `TRANSPARENCY.WHERE`. When `TRANSPARENCY` is demanded, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` were demanded. @@ -115,7 +116,7 @@ A Demand MAY refer to only certain categories of data, or certain types of proce A Demand MAY be restricted to one or more data categories. For example, a Data Subject can request to access to all data concerning his location. -| Schema propery | Expected cardinality | Expected values | +| Schema property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `data-category` | 0-* | `AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER` | @@ -132,7 +133,7 @@ In the absence of indication of any `data-category` restriction, Systems MUST in ###### Categories of Processing A Demand can be restricted to particular kinds of data processing. -For example, a Data Subject can oppose to automatic inference but continue to accept their data beeing collected and stored. +For example, a Data Subject can oppose to automatic inference but continue to accept their data being collected and stored. | Schema propery | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | @@ -148,7 +149,7 @@ In the absence of indication of any `processing-categories` restriction, Systems A Demand can be restricted to particular purpose of data processing. For example, a Data Subject can oppose to any data processing done for marketing purposes, but still accept their data being processed for the sake of personalisation of their experience. -| Schema propery | Expected cardinality | Expected values | +| Schema property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `purposes` | 0-* | `ADVERTISING`, `CONTRACT`, `CONTRACT.BASIC-SERVICE`, `CONTRACT.ADDITIONAL-SERVICES`, `NECESSARY`, `NECESSARY.JUSTICE`, `NECESSARY.LEGAL`, `NECESSARY.MEDICAL`, `NECESSARY.PUBLIC-INTERESTS`, `NECESSARY.VITAL-INTERESTS`, `NECESSARY.SOCIAL-PROTECTION`, `MARKETING`, `PERSONNALISATION`, `SALE`, `SECURITY`, `TRACKING`, `OTHER`, `ANY` | @@ -160,23 +161,23 @@ Purposes are organised as a hierarchy, denoted with a dot ".", the more general In the absence of indication of any `purpose` restriction, Systems MUST interpret the Demand as being related to all and any purpose of treatment. -[A list of eligible `purposes` values with corresponding user-facing descriptions is provided](./dictionary/purposes/) for conveniance. +[A list of eligible `purposes` values with corresponding user-facing descriptions is provided](./dictionary/purposes/) for convenience. ###### Consent IDs -A Demand can be restricted to particular Consent ID(s). For example, a Data Subject revoques a particular consent only (the one related to his data being shared with 3rd parties) but maintains other consents they may have given. +A Demand can be restricted to particular Consent ID(s). For example, a Data Subject revokes a particular consent only (the one related to his data being shared with 3rd parties) but maintains other consents they may have given. -| Schema propery | Expected cardinality | Expected values | +| Schema property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `consent-ids` | 0-* | Optional array of consent ids to indicate that the Demand (e.g. a `REVOKE-CONSENT` Demand) is restricted to particular consents. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -When one or more `consent-ids` are idnicated, Systems MUST interpret the Demand as related to all Consents related to indicated `consent-ids`. +When one or more `consent-ids` are indicated, Systems MUST interpret the Demand as related to all Consents related to indicated `consent-ids`. ###### Capture IDs A Demand can be restricted to particular Capture ID(s). For example, a Data Subject to delete a particular data, they indicate the data capture concerned by their Demand. -| Schema propery | Expected cardinality | Expected values | +| Schema property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `capture-ids` | 0-* | Optional array of Data Capture IDs to indicate that the Demand (e.g. a `DELETE` Demand) is restricted to data captured within particular Data Captures. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | @@ -206,7 +207,7 @@ Convenient tables of `transitivity` values and corresponding user-facing descrip ## Detailed Design -A separate document gives a list of [examples](examples.md) on how to represent real-life Privacy Requests, as defined in [supported legislation](#supported-legislation), or as modeled in existing systems with which we seek interoperability. +A separate document gives a list of [examples](examples.md) on how to represent real-life Privacy Requests, as defined in [supported legislation](#supported-legislation), or as modelled in existing systems with which we seek interoperability. ## Detailed Design @@ -216,25 +217,25 @@ We provide a [JSON Schema document](./prif.schema.json) for machine-readable int ### Authenticated exchanges -Systems exchanging Privacy Requests MUST be able to do so in a way allowing them to very the integrity of their content, and the identity of the system having emitted the Rignts Request. +Systems exchanging Privacy Requests MUST be able to do so in a way allowing them to very the integrity of their content, and the identity of the system having emitted the Privacy Request. For this purposes Privacy Requests MAY be embedded as 'Claims' in [JWTs (RFC7519)](https://datatracker.ietf.org/doc/html/rfc7519). -### Decentralized Identity of Data Subjects +### Decentralised Identity of Data Subjects -The Systems are only able to provide control to Data Subjects if they can identify them. On the other hand, there is no cetnral authority to manage Data Subject identity globally. +The Systems are only able to provide control to Data Subjects if they can identify them. On the other hand, there is no central authority to manage Data Subject identity globally. -Therefore, we use a set of atributes to uniquely indenitfy one Data Subject. One and the same Data Subject can have multiple such identities. +Therefore, we use a set of attributes to uniquely identify one Data Subject. One and the same Data Subject can have multiple such identities. -#### Globaly Unique Data Subject Identities +#### Globally Unique Data Subject Identities -The identifiers used to refer to Data Subjects MUST be globaly unique. One Data Subject identity corresponds to one Data Subject. One Data Subject can have several Data Subject Identity. +The identifiers used to refer to Data Subjects MUST be globally unique. One Data Subject identity corresponds to one Data Subject. One Data Subject can have several Data Subject Identity. -When refering to a Data Subject, Systems MUST use both of the following atributes: +When refering to a Data Subject, Systems MUST use both of the following attributes: - `dsid` - Data Subject ID -- `dsid-schema` - A scheme allowign to dereference the Data Subject ID +- `dsid-schema` - A scheme allowing to dereference the Data Subject ID -The (`dsid`,`dsid-schema`) pair denotes a globaly unique reference to always the same Data Subject. +The (`dsid`,`dsid-schema`) pair denotes a globally unique reference to always the same Data Subject. We refer to (`dsid`,`dsid-schema`) pairs as Data Subject Identities. @@ -246,7 +247,7 @@ Systems using RRIF MUST implement at least the following `dsid-schema`: |`dsid-schema` value | Interpretation of the corresponding `dsid` value | | ------------------- | ---- | -|`uuid`| Indicates that the value of the corresponding `dsid` attribute is a Universaly Unique ID in the sens of [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) | +|`uuid`| Indicates that the value of the corresponding `dsid` attribute is a Universally Unique ID in the sens of [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) | Systems using RRIF SHOULD implement at the following `dsid-schema`: @@ -254,7 +255,7 @@ Systems using RRIF SHOULD implement at the following `dsid-schema`: | ------------------- | ---- | |`email-sha-256`| Indicates that the value of the corresponding `dsid` attribute is the result of the SHA-256 hashing function taking the e-mail of the Data Subject as argument | -Additional Data Subject ID Schemes MAY be definied by convention. For example the following MAY be used: +Additional Data Subject ID Schemes MAY be defined by convention. For example the following MAY be used: |`dsid-schema` value | Interpretation of the corresponding `dsid` value | | ------------------- | ---- | @@ -268,7 +269,7 @@ However, in most cases, Systems MUST require the Data Subject to be authenticate When processing Rights Request, Systems MAY automatically disregard the (`dsid`,`dsid-schema`) paris for which they have not been able to establish Data Subject authentication. -However, the authentication does not necessairly have to be performed during the collection of the Rights Request. It can be done separately. +However, the authentication does not necessarily have to be performed during the collection of the Rights Request. It can be done separately. #### Matching Multiple Data Subject Identities @@ -276,9 +277,9 @@ Systems MAY keep track of Data Subject Identities that refer to the same Data Su When Systems do know that one Data Subject Identity corresponds to the same user as another Data Subject Identity, then Systems SHOULD offer the Data Subject a possibility for their Rights Requests, expressed in relation to one Data Subject Identity to be automatically extended to include other equivalent Data Subject Identities. -Systems SHOULD NOT imply Data Subject Identity equivalence from Rights Requests, especially when granding Rights Requests that require authentication. +Systems SHOULD NOT imply Data Subject Identity equivalence from Rights Requests, especially when granting Rights Requests that require authentication. -### Data Capture IDs, Data Capture Fragment IDs, Consent IDs, Rights Request IDs, Demand IDs, Rights Request Respons IDs are Globally Unique +### Data Capture IDs, Data Capture Fragment IDs, Consent IDs, Rights Request IDs, Demand IDs, Rights Request Response IDs are Globally Unique All of the following identifiers `data-capture-id`, `fragment-id`, `consent-id`, `rights-request-id`, `demand-id`, `rights-response-id` MUST be globally unique and be generated according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) in order for the corresponding objects to be easily identifiable across systems. The reason for using UUDIs is to allow Systems to independently generate globally unique identifiers while being autonomous from a central entity that would ensure identifier uniqueness. @@ -288,9 +289,9 @@ However, the design MUST be compatible with building a public decentralised ledg ### Data Categories, Treatment Types, Actions, and Purposes SHOULD be Unambiguous and Complete -The lists of Data Categories, Treatment Types, Actions, and Purposes SHOULD be desiged in such a way to be: +The lists of Data Categories, Treatment Types, Actions, and Purposes SHOULD be designed in such a way to be: - **Unambiguous** : The developer using the schema knows without ambiguity which one (of which ones) to use in any given situation, AND -- **Complete** : They allow to exress the totality of possible needs in the context of a user wanting to [regulate their privacy/connectedness](https://github.com/blindnet-io/product-management/blob/dogma/refs/notion-of-privacy/notion-of-privacy.md), as well as the totality of requests defined by the [supported legilsation](#supported-legilsation). +- **Complete** : They allow to express the totality of possible needs in the context of a user wanting to [regulate their privacy/connectedness](https://github.com/blindnet-io/product-management/blob/dogma/refs/notion-of-privacy/notion-of-privacy.md), as well as the totality of requests defined by the [supported legilsation](#supported-legilsation). ## Design Implications for Systems Implementing PRIF @@ -298,10 +299,10 @@ The lists of Data Categories, Treatment Types, Actions, and Purposes SHOULD be d When data about Data Subjects is transmitted from one system to another, in order to be able to process [Transitive Rights Requests](#transitive-rights-request), and in order to reply to `TRANSPARENCY.WHO` and `TRANSPARENCY.PROVENANCE` demands, Systems MUST keep track of: - System of destination/origin and addresses where their APIs can be reached -- Categories of data being trasnfered -- Identifiers (`data-capture-id`s,`fragment-id`s) associated to the data being trasnfered -- Consents (`consent-id`) associated to the data being trasnfered -- Data Subject Identities (`dsid`,`dsid-schema`) pairs associated to the data being trasnfered +- Categories of data being transferred +- Identifiers (`data-capture-id`s,`fragment-id`s) associated to the data being transferred +- Consents (`consent-id`) associated to the data being transferred +- Data Subject Identities (`dsid`,`dsid-schema`) pairs associated to the data being transferred > **Note** > @@ -314,7 +315,7 @@ When data about Data Subjects is transmitted from one system to another, in orde In order to automatically respond to `TRANSPARENCY` demands, Systems should store general information about: - Countries where data servers are located (`TRANSPARENCY.WHERE`) -- The identity of the organization controling them, and the Organization's representative(s) (`TRANSPARENCY.WHO`) +- The identity of the organisation controlling them, and the Organization's representative(s) (`TRANSPARENCY.WHO`) - The categories of Data Consumers, and access policies (`TRANSPARENCY.WHO`) - Identity and contact of a Data Protection Officer (`TRANSPARENCY.DPO`) - A link to their Privacy Policy (`TRANSPARENCY.POLICY`) @@ -333,7 +334,7 @@ In order to automatically respond to `TRANSPARENCY` demands, Systems should stor In order to automatically respond to data-specific demands, Systems should store particular information about every Data Capture (and make sure to implement ways of configuring how this information is applied to Data Captures): - Legal Basis for processing particular data - can be different per Data Capture Fragment (`TRANSPARENCY.LEGAL-BASES`, but also for automatically evaluating the legality of keeping data upon `REVOKE-CONSENT`, `OBJECT`, `RESTRICT`, `DELETE` requests) - Purposes of data processing - can be different per Data Capture Fragment (`TRANSPARENCY.PURPOSES`, but also for automatically evaluating `OBJECT` and `RESTRICT` requests related to particular Purposes) -- Duration of mandatory data keeping, as well as period after which the data is automatically deleted - Can be difernt per Data Capture Fragment, and relative to en event such as Data Capture, End of Contract, Account Deletion (`TRANSPARENCY.RETENTION`, but also for automatically evaluating the legality of keeping data at a certain time and upon `REVOKE-CONSENT`, `OBJECT`, `RESTRICT`, `DELETE` requests) +- Duration of mandatory data keeping, as well as period after which the data is automatically deleted - Can be different per Data Capture Fragment, and relative to en event such as Data Capture, End of Contract, Account Deletion (`TRANSPARENCY.RETENTION`, but also for automatically evaluating the legality of keeping data at a certain time and upon `REVOKE-CONSENT`, `OBJECT`, `RESTRICT`, `DELETE` requests) - Data Categories - can be different per Data Capture Fragment (`TRANSPARENCY.DATA-CATEGORIES`) - Data Processing Categories - can be different per Data Capture Fragment (`TRANSPARENCY.PROCESSING-CATEGORIES`) - Purposes of Data Processing - can be different per Data Capture Fragment (`TRANSPARENCY.PURPOSE`) @@ -342,6 +343,16 @@ In order to automatically respond to data-specific demands, Systems should store > > To automatically calculate legality of keeping a particular data, Systems MUST track events such as Data Capture, End of Contract, Account Deletion +### Exposing Privacy Request API + +The Systems that implementing the Privacy Request Interoperability Format SHOULD expose an API to: +- Receive Privacy Requests from other Systems and acknowledge their reception +- Receive Privacy Request Responses from other Systems and acknowledge their reception + +A System MAY be made only to collect Privacy Requests and send them to other Systems implementing the above-mentioned APIs. + + + @@ -349,11 +360,11 @@ In order to automatically respond to data-specific demands, Systems should store ### Use UUID for identifying Data Subjects -We chould immagine an alternative design, where we would force systems to use an [UUID]([uuid](https://en.wikipedia.org/wiki/Universally_unique_identifier)) (according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html)), to identify the users. That would require us to provide some way for systems to match UUIDs with their local IDs (usernames, or e-mails), and would ponteltially limit the ability of 3rd party systems to interprete Rights Request made at another system. This goal of proposed design is to allow for flexibility. However it is a very important aspect of the proposal, that deserves further debate. +We could imagine an alternative design, where we would force systems to use an [UUID]([uuid](https://en.wikipedia.org/wiki/Universally_unique_identifier)) (according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html)), to identify the users. That would require us to provide some way for systems to match UUIDs with their local IDs (usernames, or e-mails), and would potentially limit the ability of 3rd party systems to interpret Rights Request made at another system. This goal of proposed design is to allow for flexibility. However it is a very important aspect of the proposal, that deserves further debate. ### Mandatory properties and value constrains -Should we include rescritions in the schema according to the [JSON-schema-validation vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#page-4) in order to make certian properties mandatory and ensure to limit string values to the values we suppoort? +Should we include rescissions in the schema according to the [JSON-schema-validation vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#page-4) in order to make certain properties mandatory and ensure to limit string values to the values we support? In the curent proposal, this is the case for Transitivity, but not for request types, data categories, and user identity schemas. We might want to include more forma constraints there, or deliberately leave flexibility. This is a discussion we need to have. @@ -363,12 +374,12 @@ Hierarchies of categories are represented using the "supercategory.subcategory" E.g. We have a data capture associated to "CONTACT.ADDRESS" data category. The Data Subject makes a DELETE request related to all of their data falling under "CONTACT" data category. The developer can easily identify "CONTACT.ADDRESS" as being a subcategory of ""CONTACT.ADDRESS". -However, this notation (although intuitive) is to the best of my knoweldge, non-standard. Maybe there are reasons for it, or a standard (better) notation we can adopt? +However, this notation (although intuitive) is to the best of my knowledge, non-standard. Maybe there are reasons for it, or a standard (better) notation we can adopt? Or if none (which would be surprising) we could define our syntax using [Backus-Naur Form](https://datatracker.ietf.org/doc/html/rfc4234). Advantage: geeks will love us. ### Representation of Legal Articles -Is there a better way to unambiguousely refer, in a machine-readable way, to parts of legislations? +Is there a better way to unambiguously refer, in a machine-readable way, to parts of legislations? ### Schema elegance and modularity @@ -378,6 +389,38 @@ We need a way to make enums different categories and types more elegant, and reu Is there a standard way for representing peer-to-peer System's API endpoints that we can reuse here for representing systems. +### Anonymous Privacy Requests + +In the current design, a Privacy Request must have at least one Data Subject Identity associated to it. However it might be useful to allow change the Expected cardinality from `1-*` to `0-*` so that a request can be made about general practices (`TRANSPARENCY`) without reference to any user. + +This would make sense if the Systems would be responsable for finding a way to respond to such, unidentified user. + +### General vs Specific Interpretation of `TRANSPARENCY` Privacy Requests + +A Data Subject can formulate a request to know about processing generally practiced by the System, or to know about processing being done on Data Subejct's particular data. Those can be different. Yet we have only one category 'TRANSPARENCY.PROCESSING-CATEGORIES'. Same goes for other `TRANSPARENCY` requests. + +Currently we don't offer any way to distinguish between those two kinds of demands. We will offer instructions for Systems (under [Expected Behavior](expected-behavior.md) - **TO BE WRITTEN**) on how to interpret them based on context (whether the request is made during capture, or prior to capture where request scope SHOULD be interpreted as general, or in some other context where the request scope SHOULD be interpreted as related to user's particular data). + +This design choice MAY be a bad idea. + +### Inform-as-you-capture + +To better explain Inform-as-you-capture, we introduce to the concept of a theoretical superprivate System, in which the Data Subject's ability of control is absolute. + +As the user provides the data to the superprivate system, the system is able to dynamically show, for each field (Data Capture Fragment) the intended usage (including purposes and categories of processing, duration of retention, legal grounds and other privacy-related parameters). As they enter data, the Data Subject, if they wish so, is able to dynamically restrict this intended usage and impose their own terms. + +A consent scope (including purposes and categories of processing, duration of retention etc.) can be dynamically defined and negotiated with the Data Subject at the time of Data Capture. Instead of a predefined consent, the Data Subject is offered to give a personalised consent. + +The superprivate system can dynamically inform the Data Subject of consequences of certain consent restrictions (such as inability to provide certain functionalities). + +To achieve this ability, the superprivate system uses a data structure describing all the data fields (Data Capture Fragments) and to them associated: +- objective information (data categories; legal bases), +- general intentions (default values of: categories of processing, retention, purposes) +- minimal viable consent settings allowing the System to offer certain functionalities. + +After negotiation with the Data Subject during Data Capture, the superprivate System applies metadata to the Data Capture to indicate concrete consents and limitations that it wants to respect in run-time of data processing. + +Even if a less than superprivate System does not want to dynamically negotiate consent, it can stil benefit from this data structure in roder to show (fragment by fragment) the policies in place. The information obligation during capture (as defined by GDPR.13 and GDPR.14) is currently mostly achieved by Privacy Policies (that nobody ever reads). The inform-as-you-capture paradigm works as tooltip (or equivalent interface element), more adapted to the actual demonstration of transparency. ## References @@ -395,7 +438,7 @@ Is there a standard way for representing peer-to-peer System's API endpoints tha - [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) - [CCPA](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5) -### Yet to be Supported Legilsation +### Yet to be Supported Legislation - [CPRA]([https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://vig.cdn.sos.ca.gov/2020/general/pdf/topl-prop24.pdf)) - [HIPPA]([https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5](https://www.govinfo.gov/content/pkg/PLAW-104publ191/pdf/PLAW-104publ191.pdf)) diff --git a/refs/schemas/prif/dictionary/actions/en.actions.json b/refs/schemas/prif/dictionary/actions/en.actions.json index 22b3dc6c..bba8832d 100644 --- a/refs/schemas/prif/dictionary/actions/en.actions.json +++ b/refs/schemas/prif/dictionary/actions/en.actions.json @@ -9,6 +9,7 @@ "TRANSPARENCY": "To demand information related to data processing practices and know if the system has data on me", "TRANSPARENCY.DATA-CATEGORIES": "To know the categories of processing being done on the data the System has on me", "TRANSPARENCY.DPO": "To know the contact details of the data protection officer", + "TRANSPARENCY.KNOWN": "To know if the System has data on me", "TRANSPARENCY.LEGAL-BASES": "To know the legal bases for processing my data (including legitimate interests)", "TRANSPARENCY.ORGANISATION": "To know the identity and the contact details of the organisation processing my data", "TRANSPARENCY.POLICY": "To know the policies being applied to processing of data concerning me", diff --git a/refs/schemas/prif/prif.schema.json b/refs/schemas/prif/prif.schema.json index 82ba32e7..e728d490 100644 --- a/refs/schemas/prif/prif.schema.json +++ b/refs/schemas/prif/prif.schema.json @@ -110,6 +110,7 @@ "TRANSPARENCY", "TRANSPARENCY.DATA-CATEGORIES", "TRANSPARENCY.DPO", + "TRANSPARENCY.KNOWN", "TRANSPARENCY.LEGAL-BASES", "TRANSPARENCY.ORGANISATION", "TRANSPARENCY.POLICY", From 2a9c4d1cbd6d2736e960181a749936616b5c106a Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 26 May 2022 16:12:46 +0200 Subject: [PATCH 064/204] adding TRANSPARENCY.KNOW to examples --- refs/schemas/prif/RFC-prif.md | 2 +- refs/schemas/prif/examples.md | 11 ++++++++++- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/refs/schemas/prif/RFC-prif.md b/refs/schemas/prif/RFC-prif.md index 1ab4cf98..1fd7ed7d 100644 --- a/refs/schemas/prif/RFC-prif.md +++ b/refs/schemas/prif/RFC-prif.md @@ -420,7 +420,7 @@ To achieve this ability, the superprivate system uses a data structure describin After negotiation with the Data Subject during Data Capture, the superprivate System applies metadata to the Data Capture to indicate concrete consents and limitations that it wants to respect in run-time of data processing. -Even if a less than superprivate System does not want to dynamically negotiate consent, it can stil benefit from this data structure in roder to show (fragment by fragment) the policies in place. The information obligation during capture (as defined by GDPR.13 and GDPR.14) is currently mostly achieved by Privacy Policies (that nobody ever reads). The inform-as-you-capture paradigm works as tooltip (or equivalent interface element), more adapted to the actual demonstration of transparency. +Even if a less than superprivate System does not want to dynamically negotiate consent, it can still benefit from this data structure in order to show (fragment by fragment) the policies in place. The information obligation during capture (as defined by GDPR.13 and GDPR.14) is currently mostly achieved by Privacy Policies (that nobody ever reads). The inform-as-you-capture paradigm works as tooltip (or equivalent interface element), more adapted to the actual demonstration of transparency. ## References diff --git a/refs/schemas/prif/examples.md b/refs/schemas/prif/examples.md index cf741049..706ebc5e 100644 --- a/refs/schemas/prif/examples.md +++ b/refs/schemas/prif/examples.md @@ -64,7 +64,13 @@ In the following examples we show how, requests introduced by different regulati #### Article 15.1 -*The data subject shall have the right to obtain from the controller confirmation as to whether or not personal data concerning him or her are being processed, and, where that is the case, access to the personal data and the following information:* +*The data subject shall have the right to obtain from the controller confirmation as to whether or not personal data concerning him or her are being processed* + +| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | +| -------- | ----------------------------------------------------- | ------------ | ------------ | ------------ | ------------ | +| `GDPR.15.1` | confirmation as to whether or not personal data concerning him or her are being processed | `TRANSPARENCY.KNOW` | `null` | `null` | `null` | + +*and, where that is the case, access to the personal data and the following information:* | LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | | -------- | ----------------------------------------------------- | ------------ | ------------ | ------------ | ------------ | @@ -78,6 +84,9 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.15.1.h` | the existence of automated decision-making, including profiling | `TRANSPARENCY.PROCESSING` | `null` | `null` | `null` | | `GDPR.15.1.h` | the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | +>**Note** +> +> To make a request to know if the System has data on them (`GDPR.15.1`) and know about the purposes of processing of that data, the Data Subject MUST make a request with two demands, one `TRANSPARENCY.KNOW` and one `TRANSPARENCY.PURPOSE` #### Article 15.2 and 15.3 | LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | From c61fa9773008ad8e65ecaead7ec0c4cbb13aebba Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 26 May 2022 21:10:18 +0200 Subject: [PATCH 065/204] more concerns --- refs/schemas/prif/RFC-prif.md | 87 +++++++++++++++++++++++++++++------ refs/schemas/prif/examples.md | 2 +- 2 files changed, 73 insertions(+), 16 deletions(-) diff --git a/refs/schemas/prif/RFC-prif.md b/refs/schemas/prif/RFC-prif.md index 1fd7ed7d..77bb0a69 100644 --- a/refs/schemas/prif/RFC-prif.md +++ b/refs/schemas/prif/RFC-prif.md @@ -66,7 +66,7 @@ We have made the following choices: Data Subject is the author of a Privacy Request. -| Schema property | Expected cardinality | Expected values | +| Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `data-subject` | 1-* | [Data Subject Identities](#decentralized-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| @@ -78,7 +78,7 @@ An array of one or more [Data Subject Identities](#decentralized-identity-of-dat In addition, the Privacy Request has other meta-data: -| Schema property | Expected cardinality | Expected values | +| Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `request-id` | 1 | Unique ID for referring to this request in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Privacy Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | @@ -92,13 +92,13 @@ A Privacy Request includes an array of one or more Demands. A Demand is a concrete action that the user requests. -| Schema property | Expected cardinality | Expected values | +| Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `demande-id` | 1 | Unique ID for referring to this demande in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `action` | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | | `legal-grounds`| 0-* | Optional strings representing legal grounds that support the Demand. E.g. "GDPR.13" indicates Article 13 of GDPR, "CCPA.1798.105" indicates Section 1798.105 of CCPA | | `message` | 0-1 | Optional string comment, motivation or explanation of Demand | -| `language` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | +| `lang` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | The key element that defines the nature of the Demand is the `action`. A Demande MUST have one and only one `action`. @@ -116,7 +116,7 @@ A Demand MAY refer to only certain categories of data, or certain types of proce A Demand MAY be restricted to one or more data categories. For example, a Data Subject can request to access to all data concerning his location. -| Schema property | Expected cardinality | Expected values | +| Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `data-category` | 0-* | `AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER` | @@ -128,7 +128,7 @@ E.g. the following two `data-category` restrictions are equivalent: - `CONTACT` In the absence of indication of any `data-category` restriction, Systems MUST interpret the Demand as being related to all categories of data. -[A list of eligible `data-category` values with corresponding user-facing descriptions is provided](dictionary/data-categories/) for conveniance. +[A list of eligible `data-category` values with corresponding user-facing descriptions is provided](dictionary/data-categories/) for convenience. ###### Categories of Processing @@ -143,13 +143,13 @@ When several values are given, Systems MUST interpret the `processing-categories In the absence of indication of any `processing-categories` restriction, Systems MUST interpret the Demand as being related to all and any `processing-categories` of treatment. -[A list of eligible `processing-categories` values with corresponding user-facing descriptions is provided](dictionary/purposes) for conveniance. +[A list of eligible `processing-categories` values with corresponding user-facing descriptions is provided](dictionary/purposes) for convenience. ###### Purposes of Processing A Demand can be restricted to particular purpose of data processing. For example, a Data Subject can oppose to any data processing done for marketing purposes, but still accept their data being processed for the sake of personalisation of their experience. -| Schema property | Expected cardinality | Expected values | +| Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `purposes` | 0-* | `ADVERTISING`, `CONTRACT`, `CONTRACT.BASIC-SERVICE`, `CONTRACT.ADDITIONAL-SERVICES`, `NECESSARY`, `NECESSARY.JUSTICE`, `NECESSARY.LEGAL`, `NECESSARY.MEDICAL`, `NECESSARY.PUBLIC-INTERESTS`, `NECESSARY.VITAL-INTERESTS`, `NECESSARY.SOCIAL-PROTECTION`, `MARKETING`, `PERSONNALISATION`, `SALE`, `SECURITY`, `TRACKING`, `OTHER`, `ANY` | @@ -167,7 +167,7 @@ In the absence of indication of any `purpose` restriction, Systems MUST interpre A Demand can be restricted to particular Consent ID(s). For example, a Data Subject revokes a particular consent only (the one related to his data being shared with 3rd parties) but maintains other consents they may have given. -| Schema property | Expected cardinality | Expected values | +| Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `consent-ids` | 0-* | Optional array of consent ids to indicate that the Demand (e.g. a `REVOKE-CONSENT` Demand) is restricted to particular consents. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | @@ -177,7 +177,7 @@ When one or more `consent-ids` are indicated, Systems MUST interpret the Demand A Demand can be restricted to particular Capture ID(s). For example, a Data Subject to delete a particular data, they indicate the data capture concerned by their Demand. -| Schema property | Expected cardinality | Expected values | +| Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `capture-ids` | 0-* | Optional array of Data Capture IDs to indicate that the Demand (e.g. a `DELETE` Demand) is restricted to data captured within particular Data Captures. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | @@ -190,7 +190,7 @@ Transitive Privacy Requests are useful in a distributed context where System A g When a System receives a transitive Rights Request, it SHOULD not only respond to it, but also transfer it to corresponding Systems with which it exchanged data about the Data Subject. -| Schema property | Expected cardinality | Expected values | +| Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `transitivity` | 0-1 | Optionally one of {`DOWNWARD`, `UPWARD`, `BIDIRECTIONAL`, `INTRANSITIVE`} | @@ -205,6 +205,28 @@ Systems should interpret the transitivity of Rights Request the same way regardl Convenient tables of `transitivity` values and corresponding user-facing descriptions, in different languages, are provided [here](dictionary/transitivity). +### Privacy Request Response + +Systems SHOULD respond to [Privacy Requests](#privacy-request). +Regardless of the [scenario (Responding to the Data Subject directly or to the System)](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#different-rights-request-response-scenrarios) that should be defined by a protocol (**TO BE WRITTEN**), Systems SHOULD generate a response using the Privacy Request Interoperability Format. + +| Property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `response-id` | 1 | Unique ID for referring to this request in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `in-response-to` | 1 | `request-id` of the Privacy Request to which response is made or `demand-id` of the particular Demand to which response is made, in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `date` | 1 | Date and Time when Privacy Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `by` | 1 | **TBD ID of the System having generated the response** | +| `status` | 1 | One of {`GRANTED`, `DENIED`, `UNDER-REVIEW`} | +| `motive` | 0-1 | Optionally one of {`IDENTITY-UNCONFIRMED`, `USER-UNKNOWN`, `LEGAL-OBLIGATIONS`, `LEGAL-GROUNDS`, `LANGUAGE-UNSUPPORTED`, `REQUEST-UNSUPPORTED`} | +| `terms` | 0-* | Any of the terms the meaning of which is defined by the present format and its dictionaries | +| `message` | 0-1 | Optional string comment, motivation or explanation of Demand | +| `lang` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | +| `includes` | 0-* | Optionally an array of one or more [Privacy Request Response](#privacy-request-response)s | + +//**TODO** make dictionaries for statuses, motives. Add defined TERMS for Yes and No, check if it covers all possible responses. Make Expected behavior document + + + ## Detailed Design A separate document gives a list of [examples](examples.md) on how to represent real-life Privacy Requests, as defined in [supported legislation](#supported-legislation), or as modelled in existing systems with which we seek interoperability. @@ -351,8 +373,13 @@ The Systems that implementing the Privacy Request Interoperability Format SHOULD A System MAY be made only to collect Privacy Requests and send them to other Systems implementing the above-mentioned APIs. +It SHOULD be possible for systems to expose Privacy Request APIs in such a way that browsers can detect them while a Data Subject is on their website. The browser SHOULD be able to make (at least a simple `TRANSPARENCY.KNOW` or `TRANSPARENCY.POLICY`) requests and get instant answers to show to the user. +### Compliance History + +Systems SHOULD keep a log of received [Privacy Requests](#privacy-request), generated [responses](#privacy-request-response), and as much as possible proofs of response delivery and visualisation. + @@ -372,10 +399,25 @@ In the curent proposal, this is the case for Transitivity, but not for request t Hierarchies of categories are represented using the "supercategory.subcategory" notation. The idea behind this is to allow developers to use the level of granularity that is adapted to them, yet be able to easily situate the subcategory in supercategory when dealing with more generic requests. -E.g. We have a data capture associated to "CONTACT.ADDRESS" data category. The Data Subject makes a DELETE request related to all of their data falling under "CONTACT" data category. The developer can easily identify "CONTACT.ADDRESS" as being a subcategory of ""CONTACT.ADDRESS". +E.g. We have a data capture associated to "CONTACT.ADDRESS" data category. The Data Subject makes a DELETE request related to all of their data falling under "CONTACT" data category. The developer can easily identify "CONTACT.ADDRESS" as being a subcategory of ""CONTACT.ADDRESS" (either in SQL or in jquery). + +The advantages are: +- It is human-readable +- It is easy to filter and get what you need + +The disadvantages: +- Takes a lot of bites to store (as it is text) and the search operations in it a string operations (also taking time). Those disadvantages can be easily managed on the level of the storage used for the data, and do not have to be managed on the level of this interoperability format, +- this notation (although intuitive) is to the best of my knowledge, non-standard. + +Maybe there are reasons for it (although similar notations are used for packages in programming languages, which are also hierarchical structures). + +*Is there a standard (better) notation we can adopt?* + +A candidate for a standard notation is the [URN](https://datatracker.ietf.org/doc/html/rfc8141). It is - less pretty (still human-readable), + standard, = equally searchable, = equally bad for storage and time. However we would still need to specify our own notation of the part of the URN that we want to customise. So the advantages are limited (if any). -However, this notation (although intuitive) is to the best of my knowledge, non-standard. Maybe there are reasons for it, or a standard (better) notation we can adopt? Or if none (which would be surprising) we could define our syntax using [Backus-Naur Form](https://datatracker.ietf.org/doc/html/rfc4234). Advantage: geeks will love us. +We would need to ensure: that any string used on any side of any dot, it is not contained in any other string not containing a dot. +Disadvantage: using a non-standard notation we expose ourselves to unpredictable risks. ### Representation of Legal Articles @@ -387,13 +429,13 @@ We need a way to make enums different categories and types more elegant, and reu ### Addressability of System Endpoints -Is there a standard way for representing peer-to-peer System's API endpoints that we can reuse here for representing systems. +Is there a standard way for representing peer-to-peer System's API endpoints (compatible with our [implications for systems](#exposing-privacy-request-api)) that we can reuse here for representing systems? ### Anonymous Privacy Requests In the current design, a Privacy Request must have at least one Data Subject Identity associated to it. However it might be useful to allow change the Expected cardinality from `1-*` to `0-*` so that a request can be made about general practices (`TRANSPARENCY`) without reference to any user. -This would make sense if the Systems would be responsable for finding a way to respond to such, unidentified user. +This would make sense if the Systems would be responsible for finding a way to respond to such, unidentified user. ### General vs Specific Interpretation of `TRANSPARENCY` Privacy Requests @@ -407,6 +449,8 @@ This design choice MAY be a bad idea. To better explain Inform-as-you-capture, we introduce to the concept of a theoretical superprivate System, in which the Data Subject's ability of control is absolute. +This absolute control involves also the ability to acquire absolute transparency about future processing at the time of capture. + As the user provides the data to the superprivate system, the system is able to dynamically show, for each field (Data Capture Fragment) the intended usage (including purposes and categories of processing, duration of retention, legal grounds and other privacy-related parameters). As they enter data, the Data Subject, if they wish so, is able to dynamically restrict this intended usage and impose their own terms. A consent scope (including purposes and categories of processing, duration of retention etc.) can be dynamically defined and negotiated with the Data Subject at the time of Data Capture. Instead of a predefined consent, the Data Subject is offered to give a personalised consent. @@ -422,6 +466,19 @@ After negotiation with the Data Subject during Data Capture, the superprivate Sy Even if a less than superprivate System does not want to dynamically negotiate consent, it can still benefit from this data structure in order to show (fragment by fragment) the policies in place. The information obligation during capture (as defined by GDPR.13 and GDPR.14) is currently mostly achieved by Privacy Policies (that nobody ever reads). The inform-as-you-capture paradigm works as tooltip (or equivalent interface element), more adapted to the actual demonstration of transparency. +### A Way for Systems to Sign Responses + +Should we include a way for systems to sign responses and allow to confirm their authenticity. Maybe it can be a set of optional variables for signatures and keys in the [Privacy Request Response](#privacy-request-response)) so that they can be easily nested as they only sign the body of the response? Or is there (certainly is, but should we use it) some standard way to handle this separately from the format of the requests and responses? + +### Place of `message`, `lang`, `transitivity` + +Should `message`, `lang`, `transitivity` be properties of Privacy Request, Demand or both? + +### Expect Language + +Should we implement the Accept-Language logic from HTTP? Data Subjects arent' supposed to all speak English? + + ## References ### Normative References diff --git a/refs/schemas/prif/examples.md b/refs/schemas/prif/examples.md index 706ebc5e..c4e6b5aa 100644 --- a/refs/schemas/prif/examples.md +++ b/refs/schemas/prif/examples.md @@ -9,7 +9,7 @@ ## Introduction -This documents examines how the [Privacy Request Interoperability Format](./RFC-prif.md) can be used to represent Privacy Requests: +This document examines how the [Privacy Request Interoperability Format](./RFC-prif.md) can be used to represent Privacy Requests: - introduced by the [supported legislation](#supported-legislation), - illustrated by tutorials and request templates from regulatory bodies (e.g. [CNIL](https://www.cnil.fr/)), - or made possible by existing software solutions with which interoperability SHOULD be achieved (e.g. Transcend, Alias.dev) From b8f2631791ae2b14d5d6b53acd975aa2e4136503 Mon Sep 17 00:00:00 2001 From: milstan Date: Sat, 28 May 2022 11:53:56 +0200 Subject: [PATCH 066/204] renaming to PRIV sorry for link breaks :( --- .../{prif/RFC-prif.md => priv/RFC-PRIV.md} | 58 +++++++++++++---- .../dictionary/actions/en.actions.json | 0 .../data-categories/en.data-categories.json | 0 .../en.processing-categories.json | 0 .../dictionary/purposes/en.purposes.json | 0 .../transitivity/en.transitivity.json | 0 refs/schemas/{prif => priv}/examples.md | 10 ++- refs/schemas/priv/expected-behavior.md | 65 +++++++++++++++++++ .../priv.schema.json} | 0 9 files changed, 113 insertions(+), 20 deletions(-) rename refs/schemas/{prif/RFC-prif.md => priv/RFC-PRIV.md} (90%) rename refs/schemas/{prif => priv}/dictionary/actions/en.actions.json (100%) rename refs/schemas/{prif => priv}/dictionary/data-categories/en.data-categories.json (100%) rename refs/schemas/{prif => priv}/dictionary/processing-categories/en.processing-categories.json (100%) rename refs/schemas/{prif => priv}/dictionary/purposes/en.purposes.json (100%) rename refs/schemas/{prif => priv}/dictionary/transitivity/en.transitivity.json (100%) rename refs/schemas/{prif => priv}/examples.md (98%) create mode 100644 refs/schemas/priv/expected-behavior.md rename refs/schemas/{prif/prif.schema.json => priv/priv.schema.json} (100%) diff --git a/refs/schemas/prif/RFC-prif.md b/refs/schemas/priv/RFC-PRIV.md similarity index 90% rename from refs/schemas/prif/RFC-prif.md rename to refs/schemas/priv/RFC-PRIV.md index 77bb0a69..46bd90e4 100644 --- a/refs/schemas/prif/RFC-prif.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -1,4 +1,4 @@ -# Privacy Request Interoperability Format (PRIF) +# Privacy Request Interchange Vocabulary (PRIV) | Status | draft | | :------------ | :------------------------------------------------------------------------------------- | @@ -7,10 +7,15 @@ | **Sponsor** | [milstan](https://github.com/milstan) (milstan@blindnet.io) | | **Updated** | 2022-05-25 | + + ## Introduction -We propose a simple, structured data format for representing [Privacy Requests](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-conceptualization#data-capture--rights-requests). -This format corresponds to the [Data Rights Request Schema](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#schemas) component of the [High- Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). +We propose a simple vocabulary for representing [Privacy Requests](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-conceptualization#data-capture--rights-requests). + +The vocabulary introduces a finite set of `concepts`, `properties` and `terms`. `Concepts` define the objects of exchange, `properties` define their characteristics, and `terms` define commonly understood values of properties. + +This vocabulary corresponds to the [Data Rights Request Schema](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#schemas) component of the [High- Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). ## Motivation @@ -19,8 +24,7 @@ In order to [regulate the relationship](https://github.com/blindnet-io/product-m With a Privacy Request the individual aims to gain a degree of transparency about data processing and a degree of control over the data and over the data processing. Allowing individuals to make Privacy Requests is becoming more and more a legal obligation. -Different Systems, and different components of a single System, including different components of blindnet devkit are likely to exchange information about Privacy Requests. Therefore, a common format is needed to facilitate exchange of information without loss of semantics. The goal of Privacy Request Interoperability Format is to establish a shared conceptualisation and format of Privacy Request so that their processing can be, as much as possible, automatised by the Systems. - +Different Systems, and different components of a single System, including different components of blindnet devkit are likely to exchange information about Privacy Requests. Therefore, a common format is needed to facilitate exchange of information without loss of semantics. The goal of Privacy Request Interchange Vocabulary is to establish a shared conceptualisation and format of Privacy Request so that their processing can be, as much as possible, automatised by the Systems. ## Terminology @@ -33,6 +37,10 @@ Different Systems, and different components of a single System, including differ - We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) - We use the terms Organization, Submitter, Data Consumer as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) as defined there. +## Version + +This document defines the version `1.0` of the Privacy Request Interchange Vocabulary. + ## Design Considerations ### Design Goals @@ -50,15 +58,15 @@ With this design we seek: ### Design Choices We have made the following choices: -- **Language Independence**. The Privacy Request Interoperability Format is independent from any language for expressing structured data, and can be materialised in different forms such as json, xml, or other. A [json schema](prif.schema.json) is provided for convenience. +- **Language Independence**. The Privacy Request Interchange Vocabulary is independent from any programming language, or any format or language for expressing structured data, and can be materialised in different forms such as json, xml, or other. A [json schema](PRIV.schema.json) is provided for convenience. -- **Rich Semantics**. The Privacy Request Interoperability Format includes reserved words to describe common types of Privacy Requests, categories of data, categories of data processing and other key concepts. This choice is made to facilitate their uniform interpretation by the implementing systems. Their [human-readable titles and descriptions](dictionary) are provided in json format for convenience. +- **Rich Semantics**. The Privacy Request Interchange Vocabulary includes `terms` - reserved words to describe common types of Privacy Requests, categories of data, categories of data processing and other key notions. This choice is made to facilitate their uniform interpretation by the implementing systems. Their [human-readable titles and descriptions](dictionary) are provided in json format for convenience. -- **Multiple User Identities**. The Privacy Request Interoperability Format allows for a Data Subject to be identified using more than one user identity. This choice is made to enable the Privacy Request to be easily exchanged across Systems that use different user identifiers. +- **Multiple User Identities**. The Privacy Request Interchange Vocabulary allows for a Data Subject to be identified using more than one user identity. This choice is made to enable the Privacy Request to be easily exchanged across Systems that use different user identifiers. - **System as a Target**. The Privacy Requests are interpreted at the level of a particular System. If an Organisation operates several systems, and if the Data Subject wants to have the Privacy Request transmitted to all of them, each System may respond differently. The target of a Privacy Request is thus the System exposing an API for Privacy Requests. -- **Decentralised IDs**. The Privacy Request Interoperability Format uses decentralised ways to uniquely identify Data Subjects, Systems, Requests and their elements. The exchange of Privacy Requests can happen without a centralised entity to control identity disambiguation. +- **Decentralised IDs**. The Privacy Request Interchange Vocabulary uses decentralised ways to uniquely identify Data Subjects, Systems, Requests and their elements. The exchange of Privacy Requests can happen without a centralised entity to control identity disambiguation. ## Proposal @@ -208,7 +216,7 @@ Convenient tables of `transitivity` values and corresponding user-facing descrip ### Privacy Request Response Systems SHOULD respond to [Privacy Requests](#privacy-request). -Regardless of the [scenario (Responding to the Data Subject directly or to the System)](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#different-rights-request-response-scenrarios) that should be defined by a protocol (**TO BE WRITTEN**), Systems SHOULD generate a response using the Privacy Request Interoperability Format. +Regardless of the [scenario (Responding to the Data Subject directly or to the System)](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#different-rights-request-response-scenrarios) that should be defined by a protocol (**TO BE WRITTEN** - the System SHOULD know when to wait for a response from another system), Systems SHOULD generate a response using the Privacy Request Interchange Vocabulary. | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | @@ -216,7 +224,7 @@ Regardless of the [scenario (Responding to the Data Subject directly or to the S | `in-response-to` | 1 | `request-id` of the Privacy Request to which response is made or `demand-id` of the particular Demand to which response is made, in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Privacy Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `by` | 1 | **TBD ID of the System having generated the response** | -| `status` | 1 | One of {`GRANTED`, `DENIED`, `UNDER-REVIEW`} | +| `status` | 1 | One of {`GRANTED`, `PARTIALLY-GRANTED`, `DENIED`, `UNDER-REVIEW`} | | `motive` | 0-1 | Optionally one of {`IDENTITY-UNCONFIRMED`, `USER-UNKNOWN`, `LEGAL-OBLIGATIONS`, `LEGAL-GROUNDS`, `LANGUAGE-UNSUPPORTED`, `REQUEST-UNSUPPORTED`} | | `terms` | 0-* | Any of the terms the meaning of which is defined by the present format and its dictionaries | | `message` | 0-1 | Optional string comment, motivation or explanation of Demand | @@ -235,7 +243,7 @@ A separate document gives a list of [examples](examples.md) on how to represent ### JSON format -We provide a [JSON Schema document](./prif.schema.json) for machine-readable interpretation of Privacy Requests compliant with [v4 (or ideally lower) of IETF specification](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#:~:text=JSON%20Schema%20is%20a%20JSON,interaction%20control%20of%20JSON%20data.) +We provide a [JSON Schema document](./PRIV.schema.json) for machine-readable interpretation of Privacy Requests compliant with [v4 (or ideally lower) of IETF specification](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#:~:text=JSON%20Schema%20is%20a%20JSON,interaction%20control%20of%20JSON%20data.) ### Authenticated exchanges @@ -293,6 +301,7 @@ When processing Rights Request, Systems MAY automatically disregard the (`dsid`, However, the authentication does not necessarily have to be performed during the collection of the Rights Request. It can be done separately. + #### Matching Multiple Data Subject Identities Systems MAY keep track of Data Subject Identities that refer to the same Data Subject. In some cases, valid reasons MAY exist for Systems to ignore such information. @@ -315,7 +324,17 @@ The lists of Data Categories, Treatment Types, Actions, and Purposes SHOULD be d - **Unambiguous** : The developer using the schema knows without ambiguity which one (of which ones) to use in any given situation, AND - **Complete** : They allow to express the totality of possible needs in the context of a user wanting to [regulate their privacy/connectedness](https://github.com/blindnet-io/product-management/blob/dogma/refs/notion-of-privacy/notion-of-privacy.md), as well as the totality of requests defined by the [supported legilsation](#supported-legilsation). -## Design Implications for Systems Implementing PRIF +### Extending the vocabulary + +Systems MAY specify the vocabulary used to express data being exchanged. The value indicating this version of this vocabulary is `priv.1.0`. + +| Property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `vocab` | 0-1 | The name of the vocabulary used to describe data. In absence of indication `priv.1.0` is assumed. | + +This vocabulary can be extended by defining a new identifier for the new vocabulary. New vocabularies MAY include other vocabularies as long as their sets of concepts, properties and terms are disjoint. + +## Design Implications for Systems Implementing PRIV ### Remembering Transfers @@ -367,7 +386,7 @@ In order to automatically respond to data-specific demands, Systems should store ### Exposing Privacy Request API -The Systems that implementing the Privacy Request Interoperability Format SHOULD expose an API to: +The Systems that implementing the Privacy Request Interchange Vocabulary SHOULD expose an API to: - Receive Privacy Requests from other Systems and acknowledge their reception - Receive Privacy Request Responses from other Systems and acknowledge their reception @@ -389,6 +408,10 @@ Systems SHOULD keep a log of received [Privacy Requests](#privacy-request), gene We could imagine an alternative design, where we would force systems to use an [UUID]([uuid](https://en.wikipedia.org/wiki/Universally_unique_identifier)) (according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html)), to identify the users. That would require us to provide some way for systems to match UUIDs with their local IDs (usernames, or e-mails), and would potentially limit the ability of 3rd party systems to interpret Rights Request made at another system. This goal of proposed design is to allow for flexibility. However it is a very important aspect of the proposal, that deserves further debate. +### Zero-knowledge proof Data Subject authentication + +PRIF MUST be agnostic of the authentication method, and as such MUST be compatible with Zero-knowledge proof authentication, biometric methods, password-based authentication and any other method. We should check whether this is the case with the current design. + ### Mandatory properties and value constrains Should we include rescissions in the schema according to the [JSON-schema-validation vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#page-4) in order to make certain properties mandatory and ensure to limit string values to the values we support? @@ -423,6 +446,10 @@ Disadvantage: using a non-standard notation we expose ourselves to unpredictable Is there a better way to unambiguously refer, in a machine-readable way, to parts of legislations? +The current way is not good. It does not clearly distinguish countries. + +We can simply include a set of terms for all supported articles of all supported legislation. + ### Schema elegance and modularity We need a way to make enums different categories and types more elegant, and reusable in the perspective of using them to also represent Data Captures, Consents and responses to Privacy Requests. @@ -478,6 +505,9 @@ Should `message`, `lang`, `transitivity` be properties of Privacy Request, Deman Should we implement the Accept-Language logic from HTTP? Data Subjects arent' supposed to all speak English? +### Extending the vocabulary + +Is the mechanism for extending the vocabulary appropriate? ## References diff --git a/refs/schemas/prif/dictionary/actions/en.actions.json b/refs/schemas/priv/dictionary/actions/en.actions.json similarity index 100% rename from refs/schemas/prif/dictionary/actions/en.actions.json rename to refs/schemas/priv/dictionary/actions/en.actions.json diff --git a/refs/schemas/prif/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json similarity index 100% rename from refs/schemas/prif/dictionary/data-categories/en.data-categories.json rename to refs/schemas/priv/dictionary/data-categories/en.data-categories.json diff --git a/refs/schemas/prif/dictionary/processing-categories/en.processing-categories.json b/refs/schemas/priv/dictionary/processing-categories/en.processing-categories.json similarity index 100% rename from refs/schemas/prif/dictionary/processing-categories/en.processing-categories.json rename to refs/schemas/priv/dictionary/processing-categories/en.processing-categories.json diff --git a/refs/schemas/prif/dictionary/purposes/en.purposes.json b/refs/schemas/priv/dictionary/purposes/en.purposes.json similarity index 100% rename from refs/schemas/prif/dictionary/purposes/en.purposes.json rename to refs/schemas/priv/dictionary/purposes/en.purposes.json diff --git a/refs/schemas/prif/dictionary/transitivity/en.transitivity.json b/refs/schemas/priv/dictionary/transitivity/en.transitivity.json similarity index 100% rename from refs/schemas/prif/dictionary/transitivity/en.transitivity.json rename to refs/schemas/priv/dictionary/transitivity/en.transitivity.json diff --git a/refs/schemas/prif/examples.md b/refs/schemas/priv/examples.md similarity index 98% rename from refs/schemas/prif/examples.md rename to refs/schemas/priv/examples.md index c4e6b5aa..9ad8173f 100644 --- a/refs/schemas/prif/examples.md +++ b/refs/schemas/priv/examples.md @@ -1,15 +1,13 @@ -# Privacy Request Interoperability Format : Examples +# Privacy Request Interchange Vocabulary : Examples | Status | draft | | :------------ | :------------------------------------------------------------------------------------- | -| **PR #** | [NNN](https://github.com/blindnet-io/PROJECT/pull/NNN) (update when you have PR #) | | **Author(s)** | milstan (milstan@blindnet.io), Clémentine VINCENT (clementine@blindnet.io) | -| **Sponsor** | milstan (milstan@blindnet.io) | | **Updated** | 2022-05-25 | ## Introduction -This document examines how the [Privacy Request Interoperability Format](./RFC-prif.md) can be used to represent Privacy Requests: +This document examines how the [Privacy Request Interchange Vocabulary](./RFC-PRIV.md) can be used to represent Privacy Requests: - introduced by the [supported legislation](#supported-legislation), - illustrated by tutorials and request templates from regulatory bodies (e.g. [CNIL](https://www.cnil.fr/)), - or made possible by existing software solutions with which interoperability SHOULD be achieved (e.g. Transcend, Alias.dev) @@ -17,7 +15,7 @@ This document examines how the [Privacy Request Interoperability Format](./RFC-p ## Motivation -Elaborating the examples in detail should allow us to test the Privacy Request Interoperability Format for exhaustivity. +Elaborating the examples in detail should allow us to test the Privacy Request Interchange Vocabulary for exhaustivity. ## Terminology @@ -32,7 +30,7 @@ Elaborating the examples in detail should allow us to test the Privacy Request I ## Examples -In the following examples we show how, requests introduced by different regulations and systems can be modeled using the Privacy Request Interoperability Format. +In the following examples we show how, requests introduced by different regulations and systems can be modeled using the Privacy Request Interchange Vocabulary. ### BASIC GDPR REQUESTS diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md new file mode 100644 index 00000000..0c386105 --- /dev/null +++ b/refs/schemas/priv/expected-behavior.md @@ -0,0 +1,65 @@ +# Privacy Request Interchange Vocabulary : Expected Behavior of Implementing Systems + +| Status | draft | +| :------------ | :------------------------------------------------------------------------------------- | +| **PR #** | [NNN](https://github.com/blindnet-io/PROJECT/pull/NNN) (update when you have PR #) | +| **Author(s)** | milstan (milstan@blindnet.io) | +| **Updated** | 2022-05-25 | + +## Introduction + +This document specifies the expected behaviour of Systems implementing [Privacy Request Interchange Vocabulary](./RFC-PRIV.md). It defines actions that the systems SHOULD undertake with regards to particular Privacy Requests and particular situations. + +It is a first step towards the specification of the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler), formerly known as Data Rights Compiler. + + +## Motivation + +**TBD** + +## Terminology + +>**TBD** + +- We use the term Privacy Request interchangeably with the (deprecated) terms Rights Request and Data Rights Request as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) +- We use the terms Individual, Person, You, and Data Subject as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) +- We use the term System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) +- We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) +- We use the terms Organization, Submitter, Data Consumer as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) as defined there. + + +## **TBD** + + +**TBD** + + +### Alternatives Considered + +**TBD** + + +## Questions and Discussion Topics + +**TBD** + + +## References + +### Normative References + +- **[RFC8259]** Bray, T., ["The JavaScript Object Notation (JSON) Data Interchange Format"](https://datatracker.ietf.org/doc/html/rfc8259), STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. + +### Informative References + +- + +### Supported Legislation + +- [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) +- [CCPA](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5) + +### Yet to be Supported Legilsation + +- [CPRA]([https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://vig.cdn.sos.ca.gov/2020/general/pdf/topl-prop24.pdf)) +- [HIPPA]([https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5](https://www.govinfo.gov/content/pkg/PLAW-104publ191/pdf/PLAW-104publ191.pdf)) diff --git a/refs/schemas/prif/prif.schema.json b/refs/schemas/priv/priv.schema.json similarity index 100% rename from refs/schemas/prif/prif.schema.json rename to refs/schemas/priv/priv.schema.json From 0979418a4685224bf6ed221396a3d044b7eb3e89 Mon Sep 17 00:00:00 2001 From: milstan Date: Sun, 29 May 2022 14:42:10 +0200 Subject: [PATCH 067/204] Privacy Scope and Consent --- refs/schemas/priv/RFC-PRIV.md | 107 ++++++++++++------ .../priv/dictionary/motives/en.motives.json | 8 ++ .../priv/dictionary/other/en.other.json | 4 + .../priv/dictionary/purposes/en.purposes.json | 2 +- .../priv/dictionary/statuses/en.statuses.json | 6 + refs/schemas/priv/expected-behavior.md | 2 +- refs/schemas/priv/priv.schema.json | 4 +- 7 files changed, 94 insertions(+), 39 deletions(-) create mode 100644 refs/schemas/priv/dictionary/motives/en.motives.json create mode 100644 refs/schemas/priv/dictionary/other/en.other.json create mode 100644 refs/schemas/priv/dictionary/statuses/en.statuses.json diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 46bd90e4..f0face2b 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -53,6 +53,7 @@ With this design we seek: - Allowing developers to be fully comply with [supported legislation](#supported-legislation) related to Privacy Requests quickly and easily - Exhaustivity with regards to situations we need to support in response to [supported legislation](#supported-legislation) yet Extensibility in case new situations arise in the future. - Highly normative minimal specification, using as much as possible the [Plain Language](https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf) while at the same time making clear references to the (often misfortunate) language of the [supported legislations](#supported-legislation) +- Limit, as much as possible, the possibility of representing the same meaning in more than one way - Decentralised design compatible with both the Internet's Client-Server Architecture and Metaverse/Web3 Architecture ### Design Choices @@ -102,13 +103,12 @@ A Demand is a concrete action that the user requests. | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `demande-id` | 1 | Unique ID for referring to this demande in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `demand-id` | 1 | Unique ID for referring to this demand in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `action` | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | -| `legal-grounds`| 0-* | Optional strings representing legal grounds that support the Demand. E.g. "GDPR.13" indicates Article 13 of GDPR, "CCPA.1798.105" indicates Section 1798.105 of CCPA | | `message` | 0-1 | Optional string comment, motivation or explanation of Demand | | `lang` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | -The key element that defines the nature of the Demand is the `action`. A Demande MUST have one and only one `action`. +The key element that defines the nature of the Demand is the `action`. A Demand MUST have one and only one `action`. Actions are hierarchical. Their relationships are denoted with a dot "." separating two actions, the more general one being written on the left. @@ -118,48 +118,60 @@ When `TRANSPARENCY` is demanded, Systems MUST interpret the demand as if all the ##### Demand Restrictions The `action` that the Data Subject requests with a particular Demand MUST be interpreted in the context of restrictions. -A Demand MAY refer to only certain categories of data, or certain types of processing, certain purposes of processing etc. +A Demand MAY refer to only certain Privacy Scope (categories of data, certain types of processing, certain purposes of processing) or may only refer to particular Consents (e.g. those that the Data Subject wants to revoke) or to particular Data Captures (e.g. those that the Data Subject want to delete). -###### Data Categories +| Property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `restrictions` | 0-* | An optional array of restriction objects, each being either a [Privacy Scope](#privacy-scope), [Consent Restriction](#consent-restriction), [Capture Restriction](#capture-restriction), [Data Range](#data-range)| + +When more than one restriction is specified, the System MUST interpret the Demand as referring to the intersection of restrictions. For example let us consider a `DELETE` demand having two restrictions: `LOCATION` `data-category` as Privacy Scope, and from 11th to 15th of June 2022 as Data Range. The System SHOULD understand that the Data Subject wants the System to delete only their location data processed in this precise period. + +###### Privacy Scope + +A Privacy Scope MAY be defined by three dimensions: Data Categories, Categories of Processing, and Purposes of Processing. +A Data Subject can formulate a Demand or give Consent within a particular Privacy Scope, e.g. only referring to `COLLECTING` (Category of Processing) `CONTACT` data (Category of Data) for `PERSONALISATION` (Purpose of Processing). + +Privacy Scope can be understood as a vector space defined by those three dimensions. + +``` + +Privacy Scope = (Data Categories) x (Categories of Processing) x (Purposes of Processing) -A Demand MAY be restricted to one or more data categories. For example, a Data Subject can request to access to all data concerning his location. +``` + +**Data Categories** | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `data-category` | 0-* | `AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER` | -When several values are given, Systems MUST interpret the `data-category` restriction as a union of all the categories indicated. +When several values are given, Systems MUST interpret the `data-category` dimension as a union of all the categories indicated. Categories are organised as a hierarchy, denoted with a dot ".", the more general category being written on the left. E.g. the following two `data-category` restrictions are equivalent: - `CONTACT`,`CONTACT.EMAIL` - `CONTACT` -In the absence of indication of any `data-category` restriction, Systems MUST interpret the Demand as being related to all categories of data. +In the absence of indication of any `data-category` dimension, Systems MUST interpret the Privacy Scope as being related to all categories of data. [A list of eligible `data-category` values with corresponding user-facing descriptions is provided](dictionary/data-categories/) for convenience. -###### Categories of Processing - -A Demand can be restricted to particular kinds of data processing. -For example, a Data Subject can oppose to automatic inference but continue to accept their data being collected and stored. +**Categories of Processing** -| Schema propery | Expected cardinality | Expected values | +| Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `processing-categories` | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `USING`, `OTHER`} | -When several values are given, Systems MUST interpret the `processing-categories` restriction as a union of all the processing categories indicated. +When several values are given, Systems MUST interpret the `processing-categories` dimension as a union of all the processing categories indicated. -In the absence of indication of any `processing-categories` restriction, Systems MUST interpret the Demand as being related to all and any `processing-categories` of treatment. +In the absence of indication of any `processing-categories` dimension, Systems MUST interpret the Demand as being related to all and any `processing-categories` of treatment. [A list of eligible `processing-categories` values with corresponding user-facing descriptions is provided](dictionary/purposes) for convenience. -###### Purposes of Processing - -A Demand can be restricted to particular purpose of data processing. For example, a Data Subject can oppose to any data processing done for marketing purposes, but still accept their data being processed for the sake of personalisation of their experience. +**Purposes of Processing** | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `purposes` | 0-* | `ADVERTISING`, `CONTRACT`, `CONTRACT.BASIC-SERVICE`, `CONTRACT.ADDITIONAL-SERVICES`, `NECESSARY`, `NECESSARY.JUSTICE`, `NECESSARY.LEGAL`, `NECESSARY.MEDICAL`, `NECESSARY.PUBLIC-INTERESTS`, `NECESSARY.VITAL-INTERESTS`, `NECESSARY.SOCIAL-PROTECTION`, `MARKETING`, `PERSONNALISATION`, `SALE`, `SECURITY`, `TRACKING`, `OTHER`, `ANY` | +| `purposes` | 0-* | `ADVERTISING`, `CONTRACT`, `CONTRACT.BASIC-SERVICE`, `CONTRACT.ADDITIONAL-SERVICES`, `NECESSARY`, `NECESSARY.JUSTICE`, `NECESSARY.LEGAL`, `NECESSARY.MEDICAL`, `NECESSARY.PUBLIC-INTERESTS`, `NECESSARY.VITAL-INTERESTS`, `NECESSARY.SOCIAL-PROTECTION`, `MARKETING`, `PERSONALISATION`, `SALE`, `SECURITY`, `TRACKING`, `OTHER`, `ANY` | When several values are given, Systems MUST interpret the `purposes` restriction as a union of all the purposes indicated. @@ -171,7 +183,7 @@ In the absence of indication of any `purpose` restriction, Systems MUST interpre [A list of eligible `purposes` values with corresponding user-facing descriptions is provided](./dictionary/purposes/) for convenience. -###### Consent IDs +###### Consent Restriction A Demand can be restricted to particular Consent ID(s). For example, a Data Subject revokes a particular consent only (the one related to his data being shared with 3rd parties) but maintains other consents they may have given. @@ -181,7 +193,7 @@ A Demand can be restricted to particular Consent ID(s). For example, a Data Subj When one or more `consent-ids` are indicated, Systems MUST interpret the Demand as related to all Consents related to indicated `consent-ids`. -###### Capture IDs +###### Capture Restriction A Demand can be restricted to particular Capture ID(s). For example, a Data Subject to delete a particular data, they indicate the data capture concerned by their Demand. @@ -189,7 +201,19 @@ A Demand can be restricted to particular Capture ID(s). For example, a Data Subj | --------------- | ------ | -------------------- | | `capture-ids` | 0-* | Optional array of Data Capture IDs to indicate that the Demand (e.g. a `DELETE` Demand) is restricted to data captured within particular Data Captures. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -When one or more `capture-ids` are indicated, Systems MUST interpret the demande all related to all the data captured as part of those Data Captures. +When one or more `capture-ids` are indicated, Systems MUST interpret the demand all related to all the data captured as part of those Data Captures. + +###### Data Range + +A Demand can be restricted to particular Data Range, for example the Data Subject may `OBJECT` to data collection in a particular time period, or they might want to `DELETE` only data collected at certain dates. + +| Property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `from` | 0-* | Date and Time when the Data Range starts in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `to` | 0-* | Date and Time when the Data Range ends in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | + + +A Data Range defined by only one of the {`from`, `to`} properties indicates a period of time after or before a certain data, unbounded on the other end. #### Transitive Privacy Request @@ -224,15 +248,36 @@ Regardless of the [scenario (Responding to the Data Subject directly or to the S | `in-response-to` | 1 | `request-id` of the Privacy Request to which response is made or `demand-id` of the particular Demand to which response is made, in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Privacy Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `by` | 1 | **TBD ID of the System having generated the response** | -| `status` | 1 | One of {`GRANTED`, `PARTIALLY-GRANTED`, `DENIED`, `UNDER-REVIEW`} | -| `motive` | 0-1 | Optionally one of {`IDENTITY-UNCONFIRMED`, `USER-UNKNOWN`, `LEGAL-OBLIGATIONS`, `LEGAL-GROUNDS`, `LANGUAGE-UNSUPPORTED`, `REQUEST-UNSUPPORTED`} | -| `terms` | 0-* | Any of the terms the meaning of which is defined by the present format and its dictionaries | +| `requested-action` | 0-1 | Optional information about the action that was demanded, and to which the response is made. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | +| `data-subject` | 0-* | Optional indication of the [Data Subject Identities](#decentralized-identity-of-data-subjects) to which the response refers to | +| `status` | 1 | One of {`GRANTED`, `DENIED`, `PARTIALLY-GRANTED`, `UNDER-REVIEW`} | +| `motive` | 0-* | Optionally one of {`IDENTITY-UNCONFIRMED`, `LANGUAGE-UNSUPPORTED`, `LEGAL-BASES`, `LEGAL-OBLIGATIONS`, `REQUEST-UNSUPPORTED`, `USER-UNKNOWN`} | +| `answers` | 0-* | Any of the terms the meaning of which is defined by the present format and its dictionaries or an object representing a Legal Base, a Retention Policy | | `message` | 0-1 | Optional string comment, motivation or explanation of Demand | | `lang` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | | `includes` | 0-* | Optionally an array of one or more [Privacy Request Response](#privacy-request-response)s | +| `data` | 0-* | Optionally concrete data to which access is being given (Format **TBD**) | -//**TODO** make dictionaries for statuses, motives. Add defined TERMS for Yes and No, check if it covers all possible responses. Make Expected behavior document +A Privacy Request Response MUST have: +- a unique ID, +- a clear indication of the particular Privacy Request or the particular Demand to which its content refers, +- a date, +- a status. +Privacy Request Responses can be nested. One can imagine a Privacy Request Response to a particular Privacy Request, that `includes` Privacy Request Responses to the particular Demands made in that Privacy Request. Several Systems MAY respond to the same Privacy Request or Demand, and one System MAY nest them in order to gather them and send them back to the Data Subject. + +When a Demand is being denied, the Privacy Request Response MUST provide a `motive`. + +### Consent + +A Consent is given by one Data Subject which can be identified by one or more [Data Subject Identities](#decentralized-identity-of-data-subjects). + +| Property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `data-subject` | 1-* | [Data Subject Identities](#decentralized-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| +| `consent-id` | 1 | Optional array of consent ids to indicate that the Demand (e.g. a `REVOKE-CONSENT` Demand) is restricted to particular consents. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `date` | 1 | Date and Time when Consent was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the Consent SHOULD be interpreted as unlimited | ## Detailed Design @@ -442,14 +487,6 @@ Or if none (which would be surprising) we could define our syntax using [Backus- We would need to ensure: that any string used on any side of any dot, it is not contained in any other string not containing a dot. Disadvantage: using a non-standard notation we expose ourselves to unpredictable risks. -### Representation of Legal Articles - -Is there a better way to unambiguously refer, in a machine-readable way, to parts of legislations? - -The current way is not good. It does not clearly distinguish countries. - -We can simply include a set of terms for all supported articles of all supported legislation. - ### Schema elegance and modularity We need a way to make enums different categories and types more elegant, and reusable in the perspective of using them to also represent Data Captures, Consents and responses to Privacy Requests. @@ -503,7 +540,7 @@ Should `message`, `lang`, `transitivity` be properties of Privacy Request, Deman ### Expect Language -Should we implement the Accept-Language logic from HTTP? Data Subjects arent' supposed to all speak English? +Should we implement the Accept-Language logic from HTTP? Or can we assume that the 'lang' of request is the language in which the response is expected? ### Extending the vocabulary diff --git a/refs/schemas/priv/dictionary/motives/en.motives.json b/refs/schemas/priv/dictionary/motives/en.motives.json new file mode 100644 index 00000000..e5c35944 --- /dev/null +++ b/refs/schemas/priv/dictionary/motives/en.motives.json @@ -0,0 +1,8 @@ +{ + "IDENTITY-UNCONFIRMED": "Can't confirm the Data Subject Indentity", + "LANGUAGE-UNSUPPORTED": "The language of the request is not understood by the Organization", + "LEGAL-GROUNDS": "The System has legal grounds to repsond in the way it responds", + "LEGAL-OBLIGATIONS": "The System has legal obligation to repsond in the way it responds", + "REQUEST-UNSUPPORTED": "The System does not recongize the particular type of request that is made", + "USER-UNKNOWN":"The System does not recongize the Data Subject havign made the request", + } diff --git a/refs/schemas/priv/dictionary/other/en.other.json b/refs/schemas/priv/dictionary/other/en.other.json new file mode 100644 index 00000000..e8578118 --- /dev/null +++ b/refs/schemas/priv/dictionary/other/en.other.json @@ -0,0 +1,4 @@ +{ + "YES": "Yes", + "NO": "No", + } diff --git a/refs/schemas/priv/dictionary/purposes/en.purposes.json b/refs/schemas/priv/dictionary/purposes/en.purposes.json index 89a9e5ff..276b45d3 100644 --- a/refs/schemas/priv/dictionary/purposes/en.purposes.json +++ b/refs/schemas/priv/dictionary/purposes/en.purposes.json @@ -11,7 +11,7 @@ "NECESSARY.PUBLIC-INTERESTS": "Processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority", "NECESSARY.SOCIAL-PROTECTION": "Processing is necessary for the purposes of employment and social security and social protection", "NECESSARY.VITAL-INTERESTS": "Processing is necessary in order to protect the vital interests of the data subject or of another natural person", - "PERSONNALISATION": "For providing user with a personalized experience", + "PERSONALISATION": "For providing user with a personalized experience", "SALE": "Selling data to third parties", "SECURITY": "For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. ", "TRACKING": "Tracking information about user behavior and activity online", diff --git a/refs/schemas/priv/dictionary/statuses/en.statuses.json b/refs/schemas/priv/dictionary/statuses/en.statuses.json new file mode 100644 index 00000000..cfaa9518 --- /dev/null +++ b/refs/schemas/priv/dictionary/statuses/en.statuses.json @@ -0,0 +1,6 @@ +{ + "GRANTED": "Granted", + "DENIED": "Denied", + "PARTIALLY-GRANTED": "Partially granted", + "UNDER-REVIEW": "Under review" + } diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 0c386105..07dfa424 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -10,7 +10,7 @@ This document specifies the expected behaviour of Systems implementing [Privacy Request Interchange Vocabulary](./RFC-PRIV.md). It defines actions that the systems SHOULD undertake with regards to particular Privacy Requests and particular situations. -It is a first step towards the specification of the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler), formerly known as Data Rights Compiler. +It is a first step towards the specification of the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler), formerly known as Data Rights Compiler in the [High Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). ## Motivation diff --git a/refs/schemas/priv/priv.schema.json b/refs/schemas/priv/priv.schema.json index e728d490..5e3f52d1 100644 --- a/refs/schemas/priv/priv.schema.json +++ b/refs/schemas/priv/priv.schema.json @@ -67,7 +67,7 @@ "type": "object", "properties": { - "demande-id": { + "demand-id": { "type": "string" }, @@ -181,7 +181,7 @@ "NECESSARY.PUBLIC-INTERESTS", "NECESSARY.VITAL-INTERESTS", "MARKETING", - "PERSONNALISATION", + "PERSONALISATION", "SALE", "SECURITY", "TRACKING", From e500de93b4e2c4318b1650f50e2387235232cf80 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 30 May 2022 14:53:16 +0200 Subject: [PATCH 068/204] Update examples.md --- refs/schemas/priv/examples.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 9ad8173f..614d1469 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -109,9 +109,16 @@ In the following examples we show how, requests introduced by different regulati *[Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant)* -| LAW | Demande | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | +| LAW | Demande | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Additional element | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | -| `GDPR.15` | Access to video surveillance data from 01 Feb 2021 to 03 Feb 2021 | `ACCESS` | `IMAGE` | `null` | `SECURITY` | video surveillance data from 01 Feb 2021 to 03 Feb 2021 | +| `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | `ACCESS` | `IMAGE` | `null` | `SECURITY` | video surveillance data from 01 Feb 2021 to 03 Feb 2021 | `ID`,`date`,`time.begining`,`time.ending` | +| `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | `ACCESS` | `HEALTH` | `null` | `null` | `null` | `ID` | +| `GDPR.15` | [Access to data "Preventel" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel) | `ACCESS` | `null` | `null` | `null` | `null` | `ID` | +| `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier) | `ACCESS`, `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID`,`account number` | +| `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | +| `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | +| `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`,`date`,`time.begining`,`time.ending` | +| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite) | `ACCESS` | `X` | `null` | `null` | `null` | `null` | >**Note** > @@ -135,8 +142,8 @@ In the following examples we show how, requests introduced by different regulati | Nb | Request | Description | Associated treatment | Associated data category | Advised elements to provide | Legal ground | CNIL reference | ---------- | ---- | ---- | ---- | ---- | ---- | ---- |---- | | -- | ACCESS TYPE | ---- | ---- | ---- | ---- | ---- | ---- | -| 01 | **Access** | Access to all data the organization has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | -| 15 | **Access to my medical record** | Acces to my medical record | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | +| OK | **Access** | Access to all data the organization has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | +| 15 | **Access to my medical record** | Acces to my medical record | ---- | ---- | ID | art. L. 1111-7 du code de la santé publique | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | | 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | | 07 | **Access to data a financial organization has on me** *-> to delete and let user make access request + provenance request to the financial organization* | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me *(access+provenance info request)* | ---- | ---- | ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | | 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** *-> to delete and let user make access request to the "Fichier central des Chèques (FCC)" ?*| Access to all data Fichier central des Chèques (FCC) has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | From 853e496c6c082393409b3e2fb5e460de3585e785 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 30 May 2022 14:58:19 +0200 Subject: [PATCH 069/204] Update examples.md --- refs/schemas/priv/examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 614d1469..dd3c3c68 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -110,7 +110,7 @@ In the following examples we show how, requests introduced by different regulati *[Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant)* | LAW | Demande | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Additional element | -| -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | +| -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | | `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | `ACCESS` | `IMAGE` | `null` | `SECURITY` | video surveillance data from 01 Feb 2021 to 03 Feb 2021 | `ID`,`date`,`time.begining`,`time.ending` | | `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | `ACCESS` | `HEALTH` | `null` | `null` | `null` | `ID` | | `GDPR.15` | [Access to data "Preventel" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel) | `ACCESS` | `null` | `null` | `null` | `null` | `ID` | From 19fffb8e5210262a2232bf2effc6e69bbff85580 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 30 May 2022 14:58:56 +0200 Subject: [PATCH 070/204] Update examples.md --- refs/schemas/priv/examples.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index dd3c3c68..055c3400 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -107,8 +107,6 @@ In the following examples we show how, requests introduced by different regulati ### GDPR REQUEST TEMPLATES FROM CNIL -*[Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant)* - | LAW | Demande | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Additional element | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | | `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | `ACCESS` | `IMAGE` | `null` | `SECURITY` | video surveillance data from 01 Feb 2021 to 03 Feb 2021 | `ID`,`date`,`time.begining`,`time.ending` | From cf281b2e9ae972e04d3f2fdb17ad1316cb1e8673 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 30 May 2022 15:02:33 +0200 Subject: [PATCH 071/204] Update examples.md --- refs/schemas/priv/examples.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 055c3400..559b34c1 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -112,11 +112,11 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | `ACCESS` | `IMAGE` | `null` | `SECURITY` | video surveillance data from 01 Feb 2021 to 03 Feb 2021 | `ID`,`date`,`time.begining`,`time.ending` | | `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | `ACCESS` | `HEALTH` | `null` | `null` | `null` | `ID` | | `GDPR.15` | [Access to data "Preventel" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel) | `ACCESS` | `null` | `null` | `null` | `null` | `ID` | -| `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier) | `ACCESS`, `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID`,`account number` | +| `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier) Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me | `ACCESS`, `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID`,`account number` | | `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | | `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | -| `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`,`date`,`time.begining`,`time.ending` | -| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite) | `ACCESS` | `X` | `null` | `null` | `null` | `null` | +| `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | `ACCESS` | `null` | `null` | `null` | `null` | `ID`,`date`,`time.begining`,`time.ending` | +| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite) Receive the data that concerns me to reuse them and transmit them to another data controller| `ACCESS` | `X` | `null` | `null` | `null` | `null` | >**Note** > @@ -143,7 +143,7 @@ In the following examples we show how, requests introduced by different regulati | OK | **Access** | Access to all data the organization has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | | 15 | **Access to my medical record** | Acces to my medical record | ---- | ---- | ID | art. L. 1111-7 du code de la santé publique | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | | 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | -| 07 | **Access to data a financial organization has on me** *-> to delete and let user make access request + provenance request to the financial organization* | Access to all data the (financial) organization has on me, Provide with any available information on the origin of this data concerning me *(access+provenance info request)* | ---- | ---- | ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | +| 07 | **Access to data a financial organization has on me** *-> to delete and let user make access request + provenance request to the financial organization* | Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me *(access+provenance info request)* | ---- | ---- | ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | | 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** *-> to delete and let user make access request to the "Fichier central des Chèques (FCC)" ?*| Access to all data Fichier central des Chèques (FCC) has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | | 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** *-> to delete and let user make access request to the "Fichier national des Incidents de remboursement de Crédit (FICP)" ?*| Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | | 11 | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time *access request to geolocation data and device data* | ---- | ---- | ID, Device type, Date and time | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | From 631fdff1c73ac2976a2bd8f323f6ed4bf72b908e Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 30 May 2022 15:13:46 +0200 Subject: [PATCH 072/204] Update examples.md --- refs/schemas/priv/examples.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 559b34c1..970a5d01 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -109,14 +109,17 @@ In the following examples we show how, requests introduced by different regulati | LAW | Demande | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Additional element | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | +| `GDPR.15` | [Acces](https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces) | `ACCESS` | `null` | `null` | `null` | `null` | `ID` | | `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | `ACCESS` | `IMAGE` | `null` | `SECURITY` | video surveillance data from 01 Feb 2021 to 03 Feb 2021 | `ID`,`date`,`time.begining`,`time.ending` | | `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | `ACCESS` | `HEALTH` | `null` | `null` | `null` | `ID` | | `GDPR.15` | [Access to data "Preventel" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel) | `ACCESS` | `null` | `null` | `null` | `null` | `ID` | -| `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier) Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me | `ACCESS`, `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID`,`account number` | +| `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier): Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me | `ACCESS`, `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID`,`account number` | | `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | | `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | | `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | `ACCESS` | `null` | `null` | `null` | `null` | `ID`,`date`,`time.begining`,`time.ending` | -| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite) Receive the data that concerns me to reuse them and transmit them to another data controller| `ACCESS` | `X` | `null` | `null` | `null` | `null` | +| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| `ACCESS` | `X` | `null` | `null` | `null` | `ID` | +| `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| `MODIFY` | `X` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | +| `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | `MODIFY` | `X` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | >**Note** > From f4678d8b1b0bfe2c6ff975815a69079fe30988b1 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 30 May 2022 15:32:49 +0200 Subject: [PATCH 073/204] Update examples.md --- refs/schemas/priv/examples.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 970a5d01..cb428401 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -113,13 +113,17 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | `ACCESS` | `IMAGE` | `null` | `SECURITY` | video surveillance data from 01 Feb 2021 to 03 Feb 2021 | `ID`,`date`,`time.begining`,`time.ending` | | `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | `ACCESS` | `HEALTH` | `null` | `null` | `null` | `ID` | | `GDPR.15` | [Access to data "Preventel" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel) | `ACCESS` | `null` | `null` | `null` | `null` | `ID` | -| `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier): Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me | `ACCESS`, `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID`,`account number` | +| `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier): Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me | `ACCESS`, `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID`,`Account.number` | | `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | | `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | | `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | `ACCESS` | `null` | `null` | `null` | `null` | `ID`,`date`,`time.begining`,`time.ending` | | `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| `ACCESS` | `X` | `null` | `null` | `null` | `ID` | | `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| `MODIFY` | `X` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | | `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | `MODIFY` | `X` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | +| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | `DELETE` | `X` | `null` | `null` | `null` | `ID`,`Information.to-delete*`, `Information.reason-of-deletion` | +| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | `DELETE` | `CONTACT` | `X` | `ADVERTISING` | `null` | `ID`,`Information.reason-of-deletion` | +| `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `DELETE` | `null` | `null` | `null` | `null` | `ID`,`Account.name`,`Information.to-delete` (Website name, URL of the pages with my data)| +| `` | []() | `X` | `null` | `null` | `null` | `null` | `ID` | >**Note** > From f47f7ec6e1ee6628d80776b9cf14ee0b60301a37 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 30 May 2022 16:46:52 +0200 Subject: [PATCH 074/204] Update examples.md --- refs/schemas/priv/examples.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index cb428401..a3bb7b31 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -117,12 +117,14 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | | `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | | `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | `ACCESS` | `null` | `null` | `null` | `null` | `ID`,`date`,`time.begining`,`time.ending` | -| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| `ACCESS` | `X` | `null` | `null` | `null` | `ID` | -| `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| `MODIFY` | `X` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | -| `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | `MODIFY` | `X` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | -| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | `DELETE` | `X` | `null` | `null` | `null` | `ID`,`Information.to-delete*`, `Information.reason-of-deletion` | -| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | `DELETE` | `CONTACT` | `X` | `ADVERTISING` | `null` | `ID`,`Information.reason-of-deletion` | +| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| `ACCESS` | ``**TBD**` | `null` | `null` | `null` | `ID` | +| `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| `MODIFY` | ``**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | +| `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | `MODIFY` | ``**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | +| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | `DELETE` | ``**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-delete*`, `Information.reason-of-deletion` | +| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | `DELETE` | `CONTACT` | ``**TBD**` | `ADVERTISING` | `null` | `ID`,`Information.reason-of-deletion` | | `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `DELETE` | `null` | `null` | `null` | `null` | `ID`,`Account.name`,`Information.to-delete` (Website name, URL of the pages with my data)| +| `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | `DELETE` | ``**TBD**` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`, (`**TBD** : URL of the pages with my data) | +| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne) | `DELETE` | `IMAGE` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`, (`**TBD** : URL of the pages with my data) | | `` | []() | `X` | `null` | `null` | `null` | `null` | `ID` | >**Note** @@ -136,6 +138,7 @@ In the following examples we show how, requests introduced by different regulati | LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | | `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | `MODIFY` | `CONTACT.ADDRESS` | `null` | `null` | `null` | +| `**TBD**` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | `**TBD**` | `**TBD**` | `null` | `null` | `null` | `ID` | >**Note** > From 8bacd8a0783cefbab244a7b7fd13e505c960e478 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 30 May 2022 17:09:42 +0200 Subject: [PATCH 075/204] Update examples.md --- refs/schemas/priv/examples.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index a3bb7b31..a9f9203f 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -117,14 +117,16 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | | `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | | `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | `ACCESS` | `null` | `null` | `null` | `null` | `ID`,`date`,`time.begining`,`time.ending` | -| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| `ACCESS` | ``**TBD**` | `null` | `null` | `null` | `ID` | -| `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| `MODIFY` | ``**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | -| `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | `MODIFY` | ``**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | -| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | `DELETE` | ``**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-delete*`, `Information.reason-of-deletion` | -| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | `DELETE` | `CONTACT` | ``**TBD**` | `ADVERTISING` | `null` | `ID`,`Information.reason-of-deletion` | +| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| `ACCESS`,`PORTABILITY`| `**TBD**` | `null` | `null` | `null` | `ID` | +| `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| `MODIFY` | `**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | +| `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | `MODIFY` | `**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | +| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | `DELETE` | `**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-delete*`, `Information.reason-of-deletion` | +| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | `DELETE` | `CONTACT` | `**TBD**` | `ADVERTISING` | `null` | `ID`,`Information.reason-of-deletion` | | `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `DELETE` | `null` | `null` | `null` | `null` | `ID`,`Account.name`,`Information.to-delete` (Website name, URL of the pages with my data)| -| `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | `DELETE` | ``**TBD**` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`, (`**TBD** : URL of the pages with my data) | -| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne) | `DELETE` | `IMAGE` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`, (`**TBD** : URL of the pages with my data) | +| `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | `DELETE` | `**TBD**` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`, (`**TBD** : URL of the pages with my data) | +| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne) | `DELETE` | `IMAGE` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`, (**TBD** : URL of the pages with my data) | +| `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | `RESTRICT`, `DELETE`, **+Propagation?**, | `**TBD**` | `null` | `ADVERTISING` | `null` | `ID`,`Account.number` | +| `` | [Opposition to treatment of all data an organization has on me](Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation) | `X` | `null` | `null` | `null` | `null` | `ID` | | `` | []() | `X` | `null` | `null` | `null` | `null` | `ID` | >**Note** From 5210ad714172503a81a1fa8d6bf4d0a96fa69eed Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 30 May 2022 17:47:41 +0200 Subject: [PATCH 076/204] Update examples.md --- refs/schemas/priv/examples.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index a9f9203f..a0ec22be 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -125,8 +125,10 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `DELETE` | `null` | `null` | `null` | `null` | `ID`,`Account.name`,`Information.to-delete` (Website name, URL of the pages with my data)| | `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | `DELETE` | `**TBD**` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`, (`**TBD** : URL of the pages with my data) | | `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne) | `DELETE` | `IMAGE` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`, (**TBD** : URL of the pages with my data) | -| `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | `RESTRICT`, `DELETE`, **+Propagation?**, | `**TBD**` | `null` | `ADVERTISING` | `null` | `ID`,`Account.number` | -| `` | [Opposition to treatment of all data an organization has on me](Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation) | `X` | `null` | `null` | `null` | `null` | `ID` | +| `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | `RESTRICT`, `DELETE`, **+Propagation?**, | `CONTACT` | `null` | `ADVERTISING` | `null` | `ID`,`Account.number` | +| `GDPR.21.1`,`GDPR.17.1.c`,,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | `RESTRIC`,`DELETE`, **+Propagation?** | `null` | `**all?**` | `null` | `null` | `ID`, `Information.reason-of-deletion` | +| `GDPR.21` | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | `RESTRICT` | `**choice?**` | `**choice?**` | `null` | `null` | `ID` | +| `GDRP.4`,`GDRP.6`,`GDRP.7` | [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | `REVOKE-CONSENT` | `**choice?**` | `**choice?**` | `**choice?**` | `null` | `ID` | | `` | []() | `X` | `null` | `null` | `null` | `null` | `ID` | >**Note** @@ -137,10 +139,13 @@ In the following examples we show how, requests introduced by different regulati *Change my address* -| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | -| -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | -| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | `MODIFY` | `CONTACT.ADDRESS` | `null` | `null` | `null` | -| `**TBD**` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | `**TBD**` | `**TBD**` | `null` | `null` | `null` | `ID` | +| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Additional element | +| -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | +| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | `MODIFY` | `CONTACT.ADDRESS` | `null` | `null` | `null` | `ID` | +| `**TBD**` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | `DELETE` | `**TBD**` | `null` | `null` | `null` | `ID` | +| `**TBD**` | Opt out of automated decision making | `RESTRICT` | `null` | `AUTOMATED-DECISION-MAKING` | `null` | `null` | `ID` | +| `**TBD**` | Opt out of sale of my data | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `ID` | +| `**TBD**` | Opt out of tracking on my data | `RESTRICT` | `null` | `COLLECTION` | `null` | `null` | `ID` | >**Note** > From 66e5cea9053cec71a276eda0b65eadbd5106671e Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Mon, 30 May 2022 18:44:12 +0200 Subject: [PATCH 077/204] Update examples.md --- refs/schemas/priv/examples.md | 62 +++++++++++++++++++---------------- 1 file changed, 34 insertions(+), 28 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index a0ec22be..f9dc6cd3 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -129,7 +129,7 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.21.1`,`GDPR.17.1.c`,,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | `RESTRIC`,`DELETE`, **+Propagation?** | `null` | `**all?**` | `null` | `null` | `ID`, `Information.reason-of-deletion` | | `GDPR.21` | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | `RESTRICT` | `**choice?**` | `**choice?**` | `null` | `null` | `ID` | | `GDRP.4`,`GDRP.6`,`GDRP.7` | [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | `REVOKE-CONSENT` | `**choice?**` | `**choice?**` | `**choice?**` | `null` | `ID` | -| `` | []() | `X` | `null` | `null` | `null` | `null` | `ID` | +| `**TBD**` | [For how long the data organization has on me will be kept](https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees) | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | `null` | `ID` | >**Note** > @@ -146,6 +146,12 @@ In the following examples we show how, requests introduced by different regulati | `**TBD**` | Opt out of automated decision making | `RESTRICT` | `null` | `AUTOMATED-DECISION-MAKING` | `null` | `null` | `ID` | | `**TBD**` | Opt out of sale of my data | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `ID` | | `**TBD**` | Opt out of tracking on my data | `RESTRICT` | `null` | `COLLECTION` | `null` | `null` | `ID` | +| `**TBD**` | Storage information : know where is stored the data organization has on me | `TRANSPARENCY.WHERE` | `null` | `null` | `null` | `null` | `ID` | +| `**TBD**` | Accessibility information : know who can access the data organization has on me | `TRANSPARENCY.WHO` | `null` | `null` | `null` | `null` | `ID` | +| `**TBD**` | Provenance information : know the provenance of data organization has on me | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID` | +| `**TBD**` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `**TBD**` | | `X` | `null` | `null` | `null` | `null` | `ID` | + >**Note** > @@ -158,37 +164,37 @@ In the following examples we show how, requests introduced by different regulati | ---------- | ---- | ---- | ---- | ---- | ---- | ---- |---- | | -- | ACCESS TYPE | ---- | ---- | ---- | ---- | ---- | ---- | | OK | **Access** | Access to all data the organization has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | -| 15 | **Access to my medical record** | Acces to my medical record | ---- | ---- | ID | art. L. 1111-7 du code de la santé publique | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | -| 16 | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | -| 07 | **Access to data a financial organization has on me** *-> to delete and let user make access request + provenance request to the financial organization* | Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me *(access+provenance info request)* | ---- | ---- | ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | -| 09 | **Access to data "Fichier central des Chèques (FCC)" has on me** *-> to delete and let user make access request to the "Fichier central des Chèques (FCC)" ?*| Access to all data Fichier central des Chèques (FCC) has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | -| 10 | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** *-> to delete and let user make access request to the "Fichier national des Incidents de remboursement de Crédit (FICP)" ?*| Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | -| 11 | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time *access request to geolocation data and device data* | ---- | ---- | ID, Device type, Date and time | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | -| 12 | **Access to video surveillance data** | Access to video data organization has on me on a specific period of time *access request to video surveillance data* | ---- | ---- | ID, Date and time | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | -| 34 | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller *access request + donwnload?* | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | +| OK | **Access to my medical record** | Acces to my medical record | ---- | ---- | ID | art. L. 1111-7 du code de la santé publique | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | +| OK | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | +| OK | **Access to data a financial organization has on me** *-> to delete and let user make access request + provenance request to the financial organization* | Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me *(access+provenance info request)* | ---- | ---- | ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | +| OK | **Access to data "Fichier central des Chèques (FCC)" has on me** *-> to delete and let user make access request to the "Fichier central des Chèques (FCC)" ?*| Access to all data Fichier central des Chèques (FCC) has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | +| OK | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** *-> to delete and let user make access request to the "Fichier national des Incidents de remboursement de Crédit (FICP)" ?*| Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | +| OK | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time *access request to geolocation data and device data* | ---- | ---- | ID, Device type, Date and time | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | +| OK | **Access to video surveillance data** | Access to video data organization has on me on a specific period of time *access request to video surveillance data* | ---- | ---- | ID, Date and time | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | +| OK | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller *access request + donwnload?* | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | | -- | MODIFICATION TYPE | ---- | ---- |---- | -| 02 | **Modification** | Rectify incorrect data organization has on me | ---- | ---- | ID, Information to modify, Information rectified | ---- | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | -| 03 | **Rectification** *to merge in one modification?* | Rectify incomplete data organization has on me | ---- | ---- | ID, Information to modify, Information rectified | ---- | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | +| OK | **Modification** | Rectify incorrect data organization has on me | ---- | ---- | ID, Information to modify, Information rectified | ---- | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | +| OK | **Rectification** *to merge in one modification?* | Rectify incomplete data organization has on me | ---- | ---- | ID, Information to modify, Information rectified | ---- | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | | -- | DELETION TYPE | ---- | ---- |---- | -| 04 | **Deletion** | Delete the data the organization has on me | ---- | ---- | ID, Information to delete*, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | -| 08 | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | ---- | ---- | ID, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | -| 13 | **Closing an online account** | Closing online account, Deletion of all data the organization has on me | ---- | ---- | ID, Account name, Website name, URL of the pages with my data, Data to delete | ---- | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | -| 14 | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | ---- | ---- | ID, URL of the pages with my data, Data to delete, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet, https://www.cnil.fr/fr/webmaster-ou-responsables-de-sites-comment-repondre-aux-demandes-de-suppression-de-donnees | -| 32 | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| ---- | ---- | ID | ---- | | -| 33 | **Removal of my image online** | Remove photo or video of me that has been published without my consent| ---- | ---- | ID | ---- | https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne | +| OK | **Deletion** | Delete the data the organization has on me | ---- | ---- | ID, Information to delete*, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | +| OK | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | ---- | ---- | ID, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | +| OK | **Closing an online account** | Closing online account, Deletion of all data the organization has on me | ---- | ---- | ID, Account name, Website name, URL of the pages with my data, Data to delete | ---- | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | +| OK | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | ---- | ---- | ID, URL of the pages with my data, Data to delete, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet, https://www.cnil.fr/fr/webmaster-ou-responsables-de-sites-comment-repondre-aux-demandes-de-suppression-de-donnees | +| OK | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| ---- | ---- | ID | ---- | | +| OK | **Removal of my image online** | Remove photo or video of me that has been published without my consent| ---- | ---- | ID | ---- | https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne | | -- | OPPOSITION TO TREATMENT TYPE | ---- | ---- |---- | -| 05 | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | ---- | ---- |ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | -| 06 | **Opposition to treatment of all data an organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | ---- | ---- | ID, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | -| 24 | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | *Type of treatment (to choose from possible type of treatment list)* | ---- | | ---- | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | -| 29 | **Opt out of automated decision making** *-> to delete to include in 24. Limit treatment* | Opposition to automated decision making on the data organizatio has on me | ---- | ---- | ID | ---- | | -| 30 | **Opt out of sale of my data** *-> to delete to include in 24. Limit treatment* | Opposition to sale of the data an organization has on me| ---- | ---- | ID | ---- | | -| 31 | **Opt out of tracking on my data** *-> to delete to include in 24. Limit treatment* | Opposition to the tracking of my data from an organization | ---- | ---- | ID | ---- | | -| 27 | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | *Type of treatment (to choose from possible type of treatment list)* | ---- | ID | ---- | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | +| OK | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | ---- | ---- |ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | +| OK | **Opposition to treatment of all data an organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | ---- | ---- | ID, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | +| OK | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | *Type of treatment (to choose from possible type of treatment list)* | ---- | | ---- | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | +| OK | **Opt out of automated decision making** *-> to delete to include in 24. Limit treatment* | Opposition to automated decision making on the data organizatio has on me | ---- | ---- | ID | ---- | | +| OK | **Opt out of sale of my data** *-> to delete to include in 24. Limit treatment* | Opposition to sale of the data an organization has on me| ---- | ---- | ID | ---- | | +| OK | **Opt out of tracking on my data** *-> to delete to include in 24. Limit treatment* | Opposition to the tracking of my data from an organization | ---- | ---- | ID | ---- | | +| OK | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | *Type of treatment (to choose from possible type of treatment list)* | ---- | ID | ---- | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | | -- | INFORMATIONNAL TYPE | ---- | ---- |---- | -| 17 | **Storage information** | Know where is stored the data organization has on me | ---- | ---- | ID | ---- | | -| 18 | **Accessibility information** | Know who can access the data organization has on me | ---- | ---- | ID | ---- | | -| 19 | **Provenance information** | Know the provenance of data organization has on me | ---- | ---- | ID | ---- | | -| 20 | **Retention information** | Know for how long the data organization has on me will be kept | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | +| OK | **Storage information** | Know where is stored the data organization has on me | ---- | ---- | ID | ---- | | +| OK | **Accessibility information** | Know who can access the data organization has on me | ---- | ---- | ID | ---- | | +| OK | **Provenance information** | Know the provenance of data organization has on me | ---- | ---- | ID | ---- | | +| OK | **Retention information** | Know for how long the data organization has on me will be kept | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | | 21 | **Deletion information** | Know when my data will be deleted | ---- | ---- | ID | ---- | | | 22 | **Policy information** | Know what is the policy of the organization to keep data it has on me | ---- | ---- | ID | ---- | | | 23 | **Purpose of treatment information** | Know the purpose of the treatment organization does on the data it has on me | ---- | ---- | ID | ---- | | From 2e6c52cf3e35d15904091c311a8a66be76e477d6 Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 31 May 2022 02:32:25 +0200 Subject: [PATCH 078/204] adding Data Capture Fragments --- refs/schemas/priv/RFC-PRIV.md | 144 +++++++++++++----- .../priv/dictionary/targets/en.targets.json | 7 + .../transitivity/en.transitivity.json | 6 - refs/schemas/priv/priv.schema.json | 2 +- 4 files changed, 114 insertions(+), 45 deletions(-) create mode 100644 refs/schemas/priv/dictionary/targets/en.targets.json delete mode 100644 refs/schemas/priv/dictionary/transitivity/en.transitivity.json diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index f0face2b..a81f294a 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -15,7 +15,7 @@ We propose a simple vocabulary for representing [Privacy Requests](https://githu The vocabulary introduces a finite set of `concepts`, `properties` and `terms`. `Concepts` define the objects of exchange, `properties` define their characteristics, and `terms` define commonly understood values of properties. -This vocabulary corresponds to the [Data Rights Request Schema](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#schemas) component of the [High- Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). +This vocabulary corresponds to the [Data Privacy Request Schema](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#schemas) component of the [High- Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). ## Motivation @@ -31,7 +31,7 @@ Different Systems, and different components of a single System, including differ >**TO BE Updated** once Lexicon and High Level Conceptualization are synchronised -- We use the term Privacy Request interchangeably with the (deprecated) terms Rights Request and Data Rights Request as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) +- We use the term Privacy Request interchangeably with the (deprecated) terms Privacy Request and Data Privacy Request as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) - We use the terms Individual, Person, You, and Data Subject as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) - We use the term System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) - We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) @@ -65,12 +65,17 @@ We have made the following choices: - **Multiple User Identities**. The Privacy Request Interchange Vocabulary allows for a Data Subject to be identified using more than one user identity. This choice is made to enable the Privacy Request to be easily exchanged across Systems that use different user identifiers. -- **System as a Target**. The Privacy Requests are interpreted at the level of a particular System. If an Organisation operates several systems, and if the Data Subject wants to have the Privacy Request transmitted to all of them, each System may respond differently. The target of a Privacy Request is thus the System exposing an API for Privacy Requests. +- **Systems resolve Privacy Requests**. The Privacy Requests are interpreted at the level of a particular System. If an Organisation operates several Systems, and if the Data Subject wants to have the Privacy Request transmitted to all of them, each System may respond differently. While a Privacy Request can target a group of Systems, the most atomic target of a Privacy Request is thus the System exposing an API for Privacy Requests, and it is only at this level that a Privacy Request can be resolved. - **Decentralised IDs**. The Privacy Request Interchange Vocabulary uses decentralised ways to uniquely identify Data Subjects, Systems, Requests and their elements. The exchange of Privacy Requests can happen without a centralised entity to control identity disambiguation. ## Proposal +The Privacy Request Interchange Vocabulary includes the following: +- Key Concepts: [Consent](#consent), [Data Capture](#data-capture), [Data Capture Fragment](#data-capture-fragments), [Demand](#demands), [Privacy Request](#privacy-request), [Privacy Scope](#privacy-scope) +- Properties: **TBD** full list of properties +- Terms: **TBD** full list of terms + ### Privacy Request Data Subject is the author of a Privacy Request. @@ -107,6 +112,8 @@ A Demand is a concrete action that the user requests. | `action` | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | | `message` | 0-1 | Optional string comment, motivation or explanation of Demand | | `lang` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | +| `data` | 0-* | Optionally concrete data (Format **TBD**) | + The key element that defines the nature of the Demand is the `action`. A Demand MUST have one and only one `action`. @@ -115,6 +122,8 @@ Their relationships are denoted with a dot "." separating two actions, the more `TRANSPARENCY` includes `TRANSPARENCY.WHERE`. When `TRANSPARENCY` is demanded, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` were demanded. +Certain Demands MAY include data, such as a `MODIFY` Demand where new data MAY be provided by the Data Subject. + ##### Demand Restrictions The `action` that the Data Subject requests with a particular Demand MUST be interpreted in the context of restrictions. @@ -139,7 +148,7 @@ Privacy Scope = (Data Categories) x (Categories of Processing) x (Purposes of Pr ``` -**Data Categories** +*Data Categories* | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | @@ -155,7 +164,7 @@ E.g. the following two `data-category` restrictions are equivalent: In the absence of indication of any `data-category` dimension, Systems MUST interpret the Privacy Scope as being related to all categories of data. [A list of eligible `data-category` values with corresponding user-facing descriptions is provided](dictionary/data-categories/) for convenience. -**Categories of Processing** +*Categories of Processing* | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | @@ -167,7 +176,7 @@ In the absence of indication of any `processing-categories` dimension, Systems M [A list of eligible `processing-categories` values with corresponding user-facing descriptions is provided](dictionary/purposes) for convenience. -**Purposes of Processing** +*Purposes of Processing* | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | @@ -181,6 +190,8 @@ Purposes are organised as a hierarchy, denoted with a dot ".", the more general In the absence of indication of any `purpose` restriction, Systems MUST interpret the Demand as being related to all and any purpose of treatment. +//**TODO** Decide if we need the `ANY` and in that case make sure all the dimensions of privacy scope have one. The downside of having it is that it introduces entropy as the same thing can be stated in two ways (by stating `ANY` and by ommitting any statement). We want to avoid this. Is there an upside? + [A list of eligible `purposes` values with corresponding user-facing descriptions is provided](./dictionary/purposes/) for convenience. ###### Consent Restriction @@ -213,29 +224,42 @@ A Demand can be restricted to particular Data Range, for example the Data Subjec | `to` | 0-* | Date and Time when the Data Range ends in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -A Data Range defined by only one of the {`from`, `to`} properties indicates a period of time after or before a certain data, unbounded on the other end. +A Data Range defined by only one of the {`from`, `to`} properties indicates a period of time after or before a certain date, unbounded on the other end. -#### Transitive Privacy Request +#### Targets -A Privacy Request can be transitive. -Transitive Privacy Requests are useful in a distributed context where System A gave information about the Data Subject to System B, and System B gave information about the Data Subject to System C. +It is common for Internet Systems to be distributed (organised in a set of connected websites and applications) and to exchange data among themselves. -When a System receives a transitive Rights Request, it SHOULD not only respond to it, but also transfer it to corresponding Systems with which it exchanged data about the Data Subject. +It is therefore convenient for a Data Subject to be able to formulate Privacy Requests (but also give Consents) targeting well-defined Systems. | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `transitivity` | 0-1 | Optionally one of {`DOWNWARD`, `UPWARD`, `BIDIRECTIONAL`, `INTRANSITIVE`} | +| `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `PARTNERS.DOWNWARD`, `PARTNERS.UPWARD`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | + +`SYSTEM` refers to the particular System with witch the Data Subject is in direct interaction while making the Privacy Request (or giving the Consent). + +`ORGANISATION` includes, in addition to the `SYSTEM`, all other Systems belonging to the same Organisation. Those are understood as being a part of the same First-Party Set (**TODO** ref and compatibility check) + +`PARTNERS.DOWNWARD` includes, in addition to the `SYSTEM`, all other Systems belonging to Organisations with which the data about the Data Subject has been shared. + +`PARTNERS.UPWARD` includes, in addition to the `SYSTEM`, all other Systems belonging to Organisations from which the data about the Data Subject has been obtained. + +`PARTNERS` includes, in addition to the `SYSTEM`, all other Systems belonging to Organisations with which any sort of exchange of data concerning the Data Subject has been performed. -Transitivity of Rights Requests can be `DOWNWARD` `UPWARD`, `BIDIRECTIONAL` or `INTRANSITIVE`. In the absence of any indication `INTRANSITIVE` SHOULD be assumed. +Different values of the `target` Property imply different obligations for the System receiving a Privacy Request to transfer that request to other Systems. -When System B receives a `DOWNWARD` transitive Rights Request, it MUST also send it to all systems to which it tranfered data about the Data Subject (System C). -When System B receives a `UPWARD` transitive Rights Request, it MUST also send it to all systems from which it obtained data about the Data Subject (System A). -When System B receives a `BIDIRECTIONAL` transitive Rights Request, it MUST also send it to all systems from which it obtained data about the Data Subject or to which it gave information about the Data Subject (System A and System C). -When System B receives an `INTRANSITIVE` Rights Request, it SHOULD NOT transfer it to any other system. +Let us imagine the following situation: System A gave information about the Data Subject to System B, and System B gave information about the Data Subject to System C. The same Organisation that operates System B, also operates System D. -Systems should interpret the transitivity of Rights Request the same way regardless of the Rights Request being received directly from the Data Subject or from a corresponding System. +When System B receives a Privacy Request having `target` value: +- `SYSTEM`, it SHOULD NOT transfer it to any other system. +- `ORGANISATION` for a `target`, it MUST transfer it to all other systems operated by the same Organisation (System D in our example). +- `PARTNERS.DOWNWARD` it MUST also send it to all systems to which it transferred data about the Data Subject (System C). +- `PARTNERS.UPWARD` it MUST also send it to all systems from which it obtained data about the Data Subject (System A). +- `PARTNERS`, it MUST also send it to all systems from which it obtained data about the Data Subject or to which it gave information about the Data Subject (System A and System C). -Convenient tables of `transitivity` values and corresponding user-facing descriptions, in different languages, are provided [here](dictionary/transitivity). +Systems should interpret the target of Privacy Request the same way regardless of the Privacy Request being received directly from the Data Subject or from a corresponding System. + +Convenient tables of `target` values and corresponding user-facing descriptions, in different languages, are provided [here](dictionary/targets). ### Privacy Request Response @@ -275,10 +299,48 @@ A Consent is given by one Data Subject which can be identified by one or more [D | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `data-subject` | 1-* | [Data Subject Identities](#decentralized-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| -| `consent-id` | 1 | Optional array of consent ids to indicate that the Demand (e.g. a `REVOKE-CONSENT` Demand) is restricted to particular consents. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `consent-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Consent was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | +| `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the Consent SHOULD be interpreted as unlimited | + +### Data Capture + +A Data Capture is given by one Data Subject which can be identified by one or more [Data Subject Identities](#decentralized-identity-of-data-subjects). + +| Property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `data-subject` | 1-* | [Data Subject Identities](#decentralized-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| +| `capture-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | +| `fragments` | 1-* | One or more [Data Capture Fragments](#data-capture-fragments) | + +#### Data Capture Fragments + +| Property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `fragment-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `selector` | 1 | a string used to uniquely identify a data field (in the System's data model) to which the fragment corresponds | +| `date` | 1 | Date and Time when data was Captured was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | | `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the Consent SHOULD be interpreted as unlimited | +| `legal-base` | 1-* | Legal bases for data processing associated to the particular fragment with regards to its particular Privacy Scope | +| `retention` | 1-* | one or more Retention Policies | + +| `data` | 0-* | Optionally concrete data (Format **TBD**) | +##### Legal bases + +**TBD** + +##### Retention Policy +| Property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `policy-type` | 1 | one of {NO-LONGER-THAN, "NO-LESS-THAN"} | +| `duration` | 1 | Duration in JSON Schema [duration](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `after` | 1 | Event to which the retention duration is relative to. One of {`DATA-COLLECTION`,`RELATIONSHIP-END`} + +If more than one Retention Policy is specified, then they are interpreted as a union. Data is kept, as long as the conditions of at least one of them are met. ## Detailed Design @@ -314,7 +376,7 @@ The (`dsid`,`dsid-schema`) pair denotes a globally unique reference to always th We refer to (`dsid`,`dsid-schema`) pairs as Data Subject Identities. -A Rights Request MAY include several (`dsid`,`dsid-schema`) pairs that refer to the same user, in order to facilitate the interoperability of Rights Requests across systems. +A Privacy Request MAY include several (`dsid`,`dsid-schema`) pairs that refer to the same user, in order to facilitate the interoperability of Privacy Requests across systems. #### Data Subject ID Schemas @@ -338,24 +400,24 @@ Additional Data Subject ID Schemes MAY be defined by convention. For example the #### Data Subject SHOULD be Authenticated -In some cases, valid reasons MAY exist for Systems to respond to Rights Requests even from anonymous Data Subjects. This is the case, for example, with request relative to general data treatment practices practiced by the system. +In some cases, valid reasons MAY exist for Systems to respond to Privacy Requests even from anonymous Data Subjects. This is the case, for example, with request relative to general data treatment practices practiced by the system. However, in most cases, Systems MUST require the Data Subject to be authenticated as being indeed the person corresponding to the (`dsid`,`dsid-schema`) pair. -When processing Rights Request, Systems MAY automatically disregard the (`dsid`,`dsid-schema`) paris for which they have not been able to establish Data Subject authentication. +When processing Privacy Request, Systems MAY automatically disregard the (`dsid`,`dsid-schema`) paris for which they have not been able to establish Data Subject authentication. -However, the authentication does not necessarily have to be performed during the collection of the Rights Request. It can be done separately. +However, the authentication does not necessarily have to be performed during the collection of the Privacy Request. It can be done separately. #### Matching Multiple Data Subject Identities Systems MAY keep track of Data Subject Identities that refer to the same Data Subject. In some cases, valid reasons MAY exist for Systems to ignore such information. -When Systems do know that one Data Subject Identity corresponds to the same user as another Data Subject Identity, then Systems SHOULD offer the Data Subject a possibility for their Rights Requests, expressed in relation to one Data Subject Identity to be automatically extended to include other equivalent Data Subject Identities. +When Systems do know that one Data Subject Identity corresponds to the same user as another Data Subject Identity, then Systems SHOULD offer the Data Subject a possibility for their Privacy Requests, expressed in relation to one Data Subject Identity to be automatically extended to include other equivalent Data Subject Identities. -Systems SHOULD NOT imply Data Subject Identity equivalence from Rights Requests, especially when granting Rights Requests that require authentication. +Systems SHOULD NOT imply Data Subject Identity equivalence from Privacy Requests, especially when granting Privacy Requests that require authentication. -### Data Capture IDs, Data Capture Fragment IDs, Consent IDs, Rights Request IDs, Demand IDs, Rights Request Response IDs are Globally Unique +### Data Capture IDs, Data Capture Fragment IDs, Consent IDs, Privacy Request IDs, Demand IDs, Privacy Request Response IDs are Globally Unique All of the following identifiers `data-capture-id`, `fragment-id`, `consent-id`, `rights-request-id`, `demand-id`, `rights-response-id` MUST be globally unique and be generated according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) in order for the corresponding objects to be easily identifiable across systems. The reason for using UUDIs is to allow Systems to independently generate globally unique identifiers while being autonomous from a central entity that would ensure identifier uniqueness. @@ -383,7 +445,7 @@ This vocabulary can be extended by defining a new identifier for the new vocabul ### Remembering Transfers -When data about Data Subjects is transmitted from one system to another, in order to be able to process [Transitive Rights Requests](#transitive-rights-request), and in order to reply to `TRANSPARENCY.WHO` and `TRANSPARENCY.PROVENANCE` demands, Systems MUST keep track of: +When data about Data Subjects is transmitted from one system to another, in order to be able to process the [Targets property](#targets), and in order to reply to `TRANSPARENCY.WHO` and `TRANSPARENCY.PROVENANCE` demands, Systems MUST keep track of: - System of destination/origin and addresses where their APIs can be reached - Categories of data being transferred - Identifiers (`data-capture-id`s,`fragment-id`s) associated to the data being transferred @@ -393,9 +455,9 @@ When data about Data Subjects is transmitted from one system to another, in orde > **Note** > > Systems that exchange Data Subject information with other Systems MUST: -> - expose an API for communicating with other systems about Rights Requests: -> - receiving Rights Requests from those other Systems, -> - receiving Rights Request Responses from other Systems in the case of [Nested Responses Scenario](https://github.com/blindnet-io/product-management/tree/devkit-schemas/refs/high-level-architecture#different-rights-request-response-scenrarios). +> - expose an API for communicating with other systems about Privacy Requests: +> - receiving Privacy Requests from those other Systems, +> - receiving Privacy Request Responses from other Systems in the case of [Nested Responses Scenario](https://github.com/blindnet-io/product-management/tree/devkit-schemas/refs/high-level-architecture#different-rights-request-response-scenrarios). ### Storing General Information @@ -451,17 +513,17 @@ Systems SHOULD keep a log of received [Privacy Requests](#privacy-request), gene ### Use UUID for identifying Data Subjects -We could imagine an alternative design, where we would force systems to use an [UUID]([uuid](https://en.wikipedia.org/wiki/Universally_unique_identifier)) (according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html)), to identify the users. That would require us to provide some way for systems to match UUIDs with their local IDs (usernames, or e-mails), and would potentially limit the ability of 3rd party systems to interpret Rights Request made at another system. This goal of proposed design is to allow for flexibility. However it is a very important aspect of the proposal, that deserves further debate. +We could imagine an alternative design, where we would force systems to use an [UUID]([uuid](https://en.wikipedia.org/wiki/Universally_unique_identifier)) (according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html)), to identify the users. That would require us to provide some way for systems to match UUIDs with their local IDs (usernames, or e-mails), and would potentially limit the ability of 3rd party systems to interpret Privacy Request made at another system. This goal of proposed design is to allow for flexibility. However it is a very important aspect of the proposal, that deserves further debate. ### Zero-knowledge proof Data Subject authentication -PRIF MUST be agnostic of the authentication method, and as such MUST be compatible with Zero-knowledge proof authentication, biometric methods, password-based authentication and any other method. We should check whether this is the case with the current design. +PRIV MUST be agnostic of the authentication method, and as such MUST be compatible with Zero-knowledge proof authentication, biometric methods, password-based authentication and any other method. We should check whether this is the case with the current design. ### Mandatory properties and value constrains Should we include rescissions in the schema according to the [JSON-schema-validation vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#page-4) in order to make certain properties mandatory and ensure to limit string values to the values we support? -In the curent proposal, this is the case for Transitivity, but not for request types, data categories, and user identity schemas. We might want to include more forma constraints there, or deliberately leave flexibility. This is a discussion we need to have. +In the current proposal, this is the case for target, but not for request types, data categories, and user identity schemas. We might want to include more forma constraints there, or deliberately leave flexibility. This is a discussion we need to have. ### Dot-notation for category hierarchies @@ -534,10 +596,6 @@ Even if a less than superprivate System does not want to dynamically negotiate c Should we include a way for systems to sign responses and allow to confirm their authenticity. Maybe it can be a set of optional variables for signatures and keys in the [Privacy Request Response](#privacy-request-response)) so that they can be easily nested as they only sign the body of the response? Or is there (certainly is, but should we use it) some standard way to handle this separately from the format of the requests and responses? -### Place of `message`, `lang`, `transitivity` - -Should `message`, `lang`, `transitivity` be properties of Privacy Request, Demand or both? - ### Expect Language Should we implement the Accept-Language logic from HTTP? Or can we assume that the 'lang' of request is the language in which the response is expected? @@ -546,6 +604,10 @@ Should we implement the Accept-Language logic from HTTP? Or can we assume that t Is the mechanism for extending the vocabulary appropriate? +### Format and encryption of the `data` values + +We need a way for Systems to encrypt the data (that compatible also with encryption libraries other then our own). + ## References ### Normative References @@ -557,6 +619,12 @@ Is the mechanism for extending the vocabulary appropriate? - +### Initiative with which PRIV seeks to be compatible + +- [Privacy Model for the Web](https://github.com/michaelkleber/privacy-model/blob/main/README.md) +- [First Party Sets](https://github.com/privacycg/first-party-sets) + + ### Supported Legislation - [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) diff --git a/refs/schemas/priv/dictionary/targets/en.targets.json b/refs/schemas/priv/dictionary/targets/en.targets.json new file mode 100644 index 00000000..0c3e6504 --- /dev/null +++ b/refs/schemas/priv/dictionary/targets/en.targets.json @@ -0,0 +1,7 @@ +{ + "ORGANISATION": "This System and all other Systems belonging to the same Organisation", + "PARTNERS": "Systems belinging to any Organisation with which the data is exchanged", + "PARTNERS.DOWNWARD": "Systems belinging to any Organisation with which the data is shared", + "PARTNERS.UPWARD": "Systems belinging to any Organisation from which the data is obtained", + "SYSTEM": "Only this System" +} diff --git a/refs/schemas/priv/dictionary/transitivity/en.transitivity.json b/refs/schemas/priv/dictionary/transitivity/en.transitivity.json deleted file mode 100644 index 31d80961..00000000 --- a/refs/schemas/priv/dictionary/transitivity/en.transitivity.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "INTRANSITIVE": "Do not transfer this Rights Request to any other system", - "BIDIRECTIONAL": "Transfer this Rights Request to systems that gave or that received data about me", - "DOWNWARD": "Transfer this Rights Request to all the systems which you have shared my data with", - "UPWARD": "Transfer this Rights Request to all the systems that have shared my data with you" -} diff --git a/refs/schemas/priv/priv.schema.json b/refs/schemas/priv/priv.schema.json index 5e3f52d1..d2e2baf3 100644 --- a/refs/schemas/priv/priv.schema.json +++ b/refs/schemas/priv/priv.schema.json @@ -24,7 +24,7 @@ "minItems": 1 }, - "transitivity": { + "target": { "enum": ["DOWNWARD","UPWARD","BIDIRECTIONAL","INTRANSITIVE"], "default": "INTRANSITIVE", }, From b5a0ebce5412334566ea57bc5a038a98cfdb6250 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 31 May 2022 10:39:58 +0200 Subject: [PATCH 079/204] Update examples.md --- refs/schemas/priv/examples.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index f9dc6cd3..c75e0d0c 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -149,9 +149,11 @@ In the following examples we show how, requests introduced by different regulati | `**TBD**` | Storage information : know where is stored the data organization has on me | `TRANSPARENCY.WHERE` | `null` | `null` | `null` | `null` | `ID` | | `**TBD**` | Accessibility information : know who can access the data organization has on me | `TRANSPARENCY.WHO` | `null` | `null` | `null` | `null` | `ID` | | `**TBD**` | Provenance information : know the provenance of data organization has on me | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID` | -| `**TBD**` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `**TBD**` | | `X` | `null` | `null` | `null` | `null` | `ID` | - +| `**TBD**` | Know when my data will be deleted | `**TRANSPARENCY.RETENTION?**` | `null` | `null` | `null` | `null` | `ID` | +| `**TBD**` | Know what is the policy of the organization to keep data it has on me | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | `null` | `ID` | +| `GDPR.15.1.a` | Know the purpose of the processing organization does on the data it has on me | `TRANSPARENCY.PURPOSE` | | `null` | `null` | `null` | `ID` | +| `**TBD**` | Know what type(s) of treatment organization does on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `**+all?**` | `null` | `null` | `ID` | +| `**TBD**` | Know if a particular type of treatment is done by organisation on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `**choice?**` | `null` | `null` | `ID` | >**Note** > @@ -195,13 +197,13 @@ In the following examples we show how, requests introduced by different regulati | OK | **Accessibility information** | Know who can access the data organization has on me | ---- | ---- | ID | ---- | | | OK | **Provenance information** | Know the provenance of data organization has on me | ---- | ---- | ID | ---- | | | OK | **Retention information** | Know for how long the data organization has on me will be kept | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | -| 21 | **Deletion information** | Know when my data will be deleted | ---- | ---- | ID | ---- | | -| 22 | **Policy information** | Know what is the policy of the organization to keep data it has on me | ---- | ---- | ID | ---- | | -| 23 | **Purpose of treatment information** | Know the purpose of the treatment organization does on the data it has on me | ---- | ---- | ID | ---- | | -| 25 | **Treatment information** | Know what type(s) of treatment organization does on the data it has on me | ---- | ---- | ID | ---- | | -| 26 | **Particular type(s) of treatment information** | Know if a particular type of treatment is done by organisation on the data it has on me | *Type of treatment (to choose from possible type of treatment list)* | ---- | ID | ---- | | +| OK | **Deletion information** | Know when my data will be deleted | ---- | ---- | ID | ---- | | +| OK | **Policy information** | Know what is the policy of the organization to keep data it has on me | ---- | ---- | ID | ---- | | +| OK | **Purpose of treatment information** | Know the purpose of the treatment organization does on the data it has on me | ---- | ---- | ID | ---- | | +| OK | **Treatment information** | Know what type(s) of treatment organization does on the data it has on me | ---- | ---- | ID | ---- | | +| OK | **Particular type(s) of treatment information** | Know if a particular type of treatment is done by organisation on the data it has on me | *Type of treatment (to choose from possible type of treatment list)* | ---- | ID | ---- | | | -- | OTHER TYPE | ---- | ---- |---- | -| 28 | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | ---- | ---- | | ---- | | +| - | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | ---- | ---- | | ---- | | ### Types of treatment list | Nb | Treatment | Description | CNIL reference From 19df5c52459a8444f2808a33f3e3de06878b6cf7 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 31 May 2022 14:35:45 +0200 Subject: [PATCH 080/204] Update examples.md --- refs/schemas/priv/examples.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index c75e0d0c..c4f094ea 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -127,9 +127,9 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne) | `DELETE` | `IMAGE` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`, (**TBD** : URL of the pages with my data) | | `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | `RESTRICT`, `DELETE`, **+Propagation?**, | `CONTACT` | `null` | `ADVERTISING` | `null` | `ID`,`Account.number` | | `GDPR.21.1`,`GDPR.17.1.c`,,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | `RESTRIC`,`DELETE`, **+Propagation?** | `null` | `**all?**` | `null` | `null` | `ID`, `Information.reason-of-deletion` | -| `GDPR.21` | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | `RESTRICT` | `**choice?**` | `**choice?**` | `null` | `null` | `ID` | -| `GDRP.4`,`GDRP.6`,`GDRP.7` | [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | `REVOKE-CONSENT` | `**choice?**` | `**choice?**` | `**choice?**` | `null` | `ID` | -| `**TBD**` | [For how long the data organization has on me will be kept](https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees) | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | `null` | `ID` | +| `GDPR.21`, GDPR.18.1 | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | `RESTRICT` | `**choice?**` | `**choice?**` | `null` | `null` | `ID` | +| `GDRP.4`,`GDRP.6`,`GDRP.7`, `GDPR.13.2.c`| [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | `REVOKE-CONSENT` | `**choice?**` | `**choice?**` | `**choice?**` | `null` | `ID` | +| `GDPR.13.2.a`, `GDPR.14.2.a` | [For how long the data organization has on me will be kept](https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees) | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | `null` | `ID` | >**Note** > @@ -142,18 +142,18 @@ In the following examples we show how, requests introduced by different regulati | LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Additional element | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | | `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | `MODIFY` | `CONTACT.ADDRESS` | `null` | `null` | `null` | `ID` | -| `**TBD**` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | `DELETE` | `**TBD**` | `null` | `null` | `null` | `ID` | -| `**TBD**` | Opt out of automated decision making | `RESTRICT` | `null` | `AUTOMATED-DECISION-MAKING` | `null` | `null` | `ID` | -| `**TBD**` | Opt out of sale of my data | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `ID` | -| `**TBD**` | Opt out of tracking on my data | `RESTRICT` | `null` | `COLLECTION` | `null` | `null` | `ID` | +| `**TBD**` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | `DELETE` | `CONTACT` | `null` | `null` | `null` | `ID` | +| `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | `RESTRICT` | `null` | `AUTOMATED-DECISION-MAKING` | `null` | `null` | `ID` | +| `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `ID` | +| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | `RESTRICT` | `null` | `COLLECTION` | `null` | `null` | `ID` | | `**TBD**` | Storage information : know where is stored the data organization has on me | `TRANSPARENCY.WHERE` | `null` | `null` | `null` | `null` | `ID` | | `**TBD**` | Accessibility information : know who can access the data organization has on me | `TRANSPARENCY.WHO` | `null` | `null` | `null` | `null` | `ID` | -| `**TBD**` | Provenance information : know the provenance of data organization has on me | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID` | -| `**TBD**` | Know when my data will be deleted | `**TRANSPARENCY.RETENTION?**` | `null` | `null` | `null` | `null` | `ID` | +| `GDPR.14.2.f` | Provenance information : know the provenance of data organization has on me | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID` | +| `GDPR.13.2.a`, `GDPR.14.2.a` | Know when my data will be deleted | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | `null` | `ID` | | `**TBD**` | Know what is the policy of the organization to keep data it has on me | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | `null` | `ID` | | `GDPR.15.1.a` | Know the purpose of the processing organization does on the data it has on me | `TRANSPARENCY.PURPOSE` | | `null` | `null` | `null` | `ID` | -| `**TBD**` | Know what type(s) of treatment organization does on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `**+all?**` | `null` | `null` | `ID` | -| `**TBD**` | Know if a particular type of treatment is done by organisation on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `**choice?**` | `null` | `null` | `ID` | +| `GDPR.12.1` | Know what type(s) of treatment organization does on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `**+all?**` | `null` | `null` | `ID` | +| `GDPR.12.1` | Know if a particular type of treatment is done by organisation on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `**choice?**` | `null` | `null` | `ID` | >**Note** > From d3b352302eb53b02654aae17ef99f7d6c48824ab Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 31 May 2022 14:40:30 +0200 Subject: [PATCH 081/204] Update examples.md Added Supported Legislation GDPR CHAPTER III Rights of the data subjects from CNIL website --- refs/schemas/priv/examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index c4f094ea..d3a17472 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -333,7 +333,7 @@ Transced proposes the following [data categories](https://github.com/transcend-i ### Supported Legislation -- [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) +- [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj), [CHAPTER III - Rights of the data subject](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre3#Article13) - [CCPA](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5) ### Yet to be Supported Legilsation From ebaa925ec28aa48f0fd9436e4d9dc31ef845c5da Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 31 May 2022 14:50:59 +0200 Subject: [PATCH 082/204] Update examples.md --- refs/schemas/priv/examples.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index d3a17472..77f357bf 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -58,8 +58,6 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.13.2.f`, `GDPR.14.2.g` | the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject. | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | | `GDPR.14.2.f` | from which source the personal data originate, and if applicable, whether it came from publicly accessible sources; | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | - - #### Article 15.1 *The data subject shall have the right to obtain from the controller confirmation as to whether or not personal data concerning him or her are being processed* @@ -142,15 +140,15 @@ In the following examples we show how, requests introduced by different regulati | LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Additional element | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | | `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | `MODIFY` | `CONTACT.ADDRESS` | `null` | `null` | `null` | `ID` | -| `**TBD**` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | `DELETE` | `CONTACT` | `null` | `null` | `null` | `ID` | +| `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `ID` | | `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | `RESTRICT` | `null` | `AUTOMATED-DECISION-MAKING` | `null` | `null` | `ID` | | `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `ID` | | `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | `RESTRICT` | `null` | `COLLECTION` | `null` | `null` | `ID` | -| `**TBD**` | Storage information : know where is stored the data organization has on me | `TRANSPARENCY.WHERE` | `null` | `null` | `null` | `null` | `ID` | -| `**TBD**` | Accessibility information : know who can access the data organization has on me | `TRANSPARENCY.WHO` | `null` | `null` | `null` | `null` | `ID` | +| `GDPR.13.1.f`, `GDPR.14.1.f` | Storage information : know where is stored the data organization has on me | `TRANSPARENCY.WHERE` | `null` | `null` | `null` | `null` | `ID` | +| `GDPR.14.1.e` | Accessibility information : know who can access the data organization has on me | `TRANSPARENCY.WHO` | `null` | `null` | `null` | `null` | `ID` | | `GDPR.14.2.f` | Provenance information : know the provenance of data organization has on me | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID` | | `GDPR.13.2.a`, `GDPR.14.2.a` | Know when my data will be deleted | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | `null` | `ID` | -| `**TBD**` | Know what is the policy of the organization to keep data it has on me | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | `null` | `ID` | +| `**GDPR.13?**` | Know what is the policy of the organization to keep data it has on me | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | `null` | `ID` | | `GDPR.15.1.a` | Know the purpose of the processing organization does on the data it has on me | `TRANSPARENCY.PURPOSE` | | `null` | `null` | `null` | `ID` | | `GDPR.12.1` | Know what type(s) of treatment organization does on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `**+all?**` | `null` | `null` | `ID` | | `GDPR.12.1` | Know if a particular type of treatment is done by organisation on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `**choice?**` | `null` | `null` | `ID` | From a6980a31b3c12424700745a9d2d79874a177248b Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 31 May 2022 14:59:49 +0200 Subject: [PATCH 083/204] Update examples.md --- refs/schemas/priv/examples.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 77f357bf..82e3dcca 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -97,9 +97,9 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.16` | The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. 2Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement. | `MODIFY` | `null` | `null` | `null` | | `GDPR.17` | The data subject shall have the right to obtain from the controller the erasure of personal data concerning him | `DELETE` | `null` | `null` | `null` | | `GDPR.18` | The data subject shall have the right to obtain from the controller restriction of processing | `RESTRICT` | `null` | `null` | `null` | -| `GDPR.20` | **TBD** | `**TBD**` | `null` | `null` | `null` | -| `GDPR.21` | **TBD** (note: 21.2 is not yet supported by the schema)| `**TBD**` | `null` | `null` | `null` | -| `GDPR.22` | **TBD** | `**TBD**` | `null` | `null` | `null` | +| `GDPR.20` | The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided | `PORTABILITY` | `null` | `null` | `null` | +| `GDPR.21` | The data subject shall have the right to object, on grounds relating to his or her particular situation, at any time to processing of personal data concerning him or her which is based on point (e) or (f) of Article 6(1), including profiling based on those provisions. *(note: 21.2 is not yet supported by the schema)*| `**RESTRICT?**` | `null` | `**+all?**` | `null` | +| `GDPR.22` | The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her | `RESTRICT` | `null` | `AUTOMATED-DECISION-MAKING` | `null` | From b6fc0efde56342a93466f1f2f0ac127e8a996e74 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 31 May 2022 17:26:14 +0200 Subject: [PATCH 084/204] Update examples.md --- refs/schemas/priv/examples.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 82e3dcca..42777591 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -105,7 +105,7 @@ In the following examples we show how, requests introduced by different regulati ### GDPR REQUEST TEMPLATES FROM CNIL -| LAW | Demande | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Additional element | +| LAW | Demande | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | `Additional element` | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | | `GDPR.15` | [Acces](https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces) | `ACCESS` | `null` | `null` | `null` | `null` | `ID` | | `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | `ACCESS` | `IMAGE` | `null` | `SECURITY` | video surveillance data from 01 Feb 2021 to 03 Feb 2021 | `ID`,`date`,`time.begining`,`time.ending` | @@ -119,14 +119,14 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| `MODIFY` | `**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | | `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | `MODIFY` | `**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | | `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | `DELETE` | `**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-delete*`, `Information.reason-of-deletion` | -| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | `DELETE` | `CONTACT` | `**TBD**` | `ADVERTISING` | `null` | `ID`,`Information.reason-of-deletion` | -| `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `DELETE` | `null` | `null` | `null` | `null` | `ID`,`Account.name`,`Information.to-delete` (Website name, URL of the pages with my data)| -| `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | `DELETE` | `**TBD**` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`, (`**TBD** : URL of the pages with my data) | -| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne) | `DELETE` | `IMAGE` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`, (**TBD** : URL of the pages with my data) | +| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | `DELETE` | `CONTACT` | `null` | `ADVERTISING` | `null` | `ID`,`Information.reason-of-deletion` | +| `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `DELETE` | `null` | `null` | `null` | `null` | `ID`,`Account.name`,`Information.to-delete`, `Information.URL`| +| `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | `DELETE` | `**TBD**` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`, `Information.URL` | +| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne) | `DELETE` | `IMAGE` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`,`Information.URL`| | `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | `RESTRICT`, `DELETE`, **+Propagation?**, | `CONTACT` | `null` | `ADVERTISING` | `null` | `ID`,`Account.number` | -| `GDPR.21.1`,`GDPR.17.1.c`,,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | `RESTRIC`,`DELETE`, **+Propagation?** | `null` | `**all?**` | `null` | `null` | `ID`, `Information.reason-of-deletion` | +| `GDPR.21.1`,`GDPR.17.1.c`,,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | `RESTRICT`,`DELETE`, **+Propagation?** | `null` | `**all?**` | `null` | `null` | `ID`, `Information.reason-of-deletion` | | `GDPR.21`, GDPR.18.1 | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | `RESTRICT` | `**choice?**` | `**choice?**` | `null` | `null` | `ID` | -| `GDRP.4`,`GDRP.6`,`GDRP.7`, `GDPR.13.2.c`| [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | `REVOKE-CONSENT` | `**choice?**` | `**choice?**` | `**choice?**` | `null` | `ID` | +| `GDRP.4`,`GDRP.6`,`GDRP.7`, `GDPR.13.2.c`| [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | `REVOKE-CONSENT` | `null` | `**choice?**` | `**choice?**` | `null` | `ID` | | `GDPR.13.2.a`, `GDPR.14.2.a` | [For how long the data organization has on me will be kept](https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees) | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | `null` | `ID` | >**Note** From 174827e88a24336484304b9a2baf9f124c48cb50 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 31 May 2022 17:43:03 +0200 Subject: [PATCH 085/204] Update examples.md Added CCPA link in a more digestible format --- refs/schemas/priv/examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 42777591..c996d8b1 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -332,7 +332,7 @@ Transced proposes the following [data categories](https://github.com/transcend-i ### Supported Legislation - [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj), [CHAPTER III - Rights of the data subject](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre3#Article13) -- [CCPA](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5) +- [CCPA](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5), [CCPA(more digestible format)](https://ccpa-info.com/california-consumer-privacy-act-full-text/) ### Yet to be Supported Legilsation From 362732b666632700afe5013d22f5462cd2012b8c Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 31 May 2022 18:22:41 +0200 Subject: [PATCH 086/204] Update examples.md Created table for collaborative working Nicolas -> 161-180 Clem -> 181-200 --- refs/schemas/priv/examples.md | 42 +++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index c996d8b1..c042fe38 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -157,6 +157,48 @@ In the following examples we show how, requests introduced by different regulati > >we need to add a schema field for providing new data, and date of validity of new data (not necessairly the date of trnasmission) +### CCPA REQUESTS +| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Additional element | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | ### Requests list (**TO BE TRANSFORMED IN THE ABOVE FORMAT**) From b091d98ecf6b23b4a9dcf282a1ddd204d3bc054b Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 31 May 2022 18:25:45 +0200 Subject: [PATCH 087/204] Update examples.md --- refs/schemas/priv/examples.md | 81 ++++++++++++++++++----------------- 1 file changed, 41 insertions(+), 40 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index c042fe38..ce4335d1 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -159,46 +159,47 @@ In the following examples we show how, requests introduced by different regulati ### CCPA REQUESTS | LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Additional element | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | | `X` | `null` | `null` | `null` | `null` | `ID` | +| -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | ### Requests list (**TO BE TRANSFORMED IN THE ABOVE FORMAT**) From 225b663b3ca999b0da8eb722e6ebc02f1fad1ecb Mon Sep 17 00:00:00 2001 From: Nicolas Timillero <83829768+timnicblind@users.noreply.github.com> Date: Tue, 31 May 2022 18:32:44 +0200 Subject: [PATCH 088/204] Update examples.md --- refs/schemas/priv/examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index ce4335d1..614c3b39 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -199,7 +199,7 @@ In the following examples we show how, requests introduced by different regulati | `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | | `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | | `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `article` | X | `X` | `null` | `null` | `null` | `null` | `ID` | ### Requests list (**TO BE TRANSFORMED IN THE ABOVE FORMAT**) From f882b9296a6f67114644cfd05de14bf495786b53 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 31 May 2022 18:56:59 +0200 Subject: [PATCH 089/204] Update examples.md --- refs/schemas/priv/examples.md | 80 +++++++++++++++++------------------ 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 614c3b39..a917278a 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -160,46 +160,46 @@ In the following examples we show how, requests introduced by different regulati ### CCPA REQUESTS | LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Additional element | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `ID` | -| `article` | X | `X` | `null` | `null` | `null` | `null` | `ID` | +| `CCPA.1798.100.1` | A consumer shall have the right to request that a business that collects a consumer’s personal information disclose to that consumer the categories and specific pieces of personal information the business has collected | `TRANSPARENCY.KNOWN`,`TRANSPARENCY.DATA-CATEGORIES` | `null` | `null` | `null` | `null` | `null` | +| `CCPA.1798.100.4` | A business that receives a verifiable consumer request from a consumer to access personal information shall promptly take steps to disclose and deliver, free of charge to the consumer, the personal information required by this section. | `ACCESS` | `null` | `null` | `null` | `null` | `ID` | +| `1798.105.1` | A consumer shall have the right to request that a business delete any personal information about the consumer which the business has collected from the consumer. | `DELETE` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `article` | X | `X` | `null` | `null` | `null` | `null` | `null` | ### Requests list (**TO BE TRANSFORMED IN THE ABOVE FORMAT**) From 952e68dcdea9dea2bfdebc9c546894b5f95f61ff Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Wed, 1 Jun 2022 12:56:15 +0200 Subject: [PATCH 090/204] Update examples.md Added CCPA example reading CCPA up to art. 1798.135 --- refs/schemas/priv/examples.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index a917278a..266a7d0f 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -143,7 +143,7 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `ID` | | `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | `RESTRICT` | `null` | `AUTOMATED-DECISION-MAKING` | `null` | `null` | `ID` | | `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `ID` | -| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | `RESTRICT` | `null` | `COLLECTION` | `null` | `null` | `ID` | +| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | `RESTRICT` | `BEHAVIOR,`DEVICE`,`LOCATION` | `COLLECTION` | `null` | `null` | `ID` | | `GDPR.13.1.f`, `GDPR.14.1.f` | Storage information : know where is stored the data organization has on me | `TRANSPARENCY.WHERE` | `null` | `null` | `null` | `null` | `ID` | | `GDPR.14.1.e` | Accessibility information : know who can access the data organization has on me | `TRANSPARENCY.WHO` | `null` | `null` | `null` | `null` | `ID` | | `GDPR.14.2.f` | Provenance information : know the provenance of data organization has on me | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID` | @@ -162,16 +162,16 @@ In the following examples we show how, requests introduced by different regulati | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | | `CCPA.1798.100.1` | A consumer shall have the right to request that a business that collects a consumer’s personal information disclose to that consumer the categories and specific pieces of personal information the business has collected | `TRANSPARENCY.KNOWN`,`TRANSPARENCY.DATA-CATEGORIES` | `null` | `null` | `null` | `null` | `null` | | `CCPA.1798.100.4` | A business that receives a verifiable consumer request from a consumer to access personal information shall promptly take steps to disclose and deliver, free of charge to the consumer, the personal information required by this section. | `ACCESS` | `null` | `null` | `null` | `null` | `ID` | -| `1798.105.1` | A consumer shall have the right to request that a business delete any personal information about the consumer which the business has collected from the consumer. | `DELETE` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `1798.105.1` | A consumer shall have the right to request that a business delete any personal information about the consumer which the business has collected from the consumer | `DELETE` | `null` | `null` | `null` | `null` | `null` | +| `1798.110.1.1` | A consumer shall have the right to request that a business that collects personal information about the consumer disclose to the consumer the following: The categories of personal information it has collected about that consumer | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `null` | `null` | `null` | `null` | +| `1798.110.1.2` | ...The categories of sources from which the personal information is collected | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `null` | +| `1798.110.1.3` | ...The business or commercial purpose for collecting or selling personal information | `TRANSPARENCY.PURPOSE` | `null` | `null` | `null` | `null` | `null` | +| `1798.110.1.4` | The categories of third parties with whom the business shares personal information | `**to add?**` | `null` | `SHARING` | `null` | `null` | `null` | +| `1798.110.1.5` | The specific pieces of personal information it has collected about that consumer | `ACCESS` | `null` | `null` | `null` | `null` | `null` | +| `1798.115.1.1` | A consumer shall have the right to request that a business that sells the consumer’s personal information, or that discloses it for a business purpose, disclose to that consumer: The categories of personal information that the business collected about the consumer | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `SHARING` | `SALE` | `null` | `null` | +| `1798.115.1.2` | ...The categories of personal information that the business sold about the consumer and the categories of third parties to whom the personal information was sold, by category or categories of personal information for each category of third parties to whom the personal information was sold | `**TBD**` | `null` | `SHARING` | `SALE` | `null` | `null` | +| `1798.115.1.3` | ...The categories of personal information that the business disclosed about the consumer for a business purpose | `**TBD**` | `null` | `SHARING` | `SALE` | `null` | `null` | +| `1798.120.1` | A consumer shall have the right, at any time, to direct a business that sells personal information about the consumer to third parties not to sell the consumer’s personal information. This right may be referred to as the right to opt-out | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `null` | | `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | | `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | | `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | From 3f7ff3b439fc35eae6505aac61eee31568f9f635 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Wed, 1 Jun 2022 12:57:30 +0200 Subject: [PATCH 091/204] Update examples.md --- refs/schemas/priv/examples.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 266a7d0f..ccc30895 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -166,8 +166,8 @@ In the following examples we show how, requests introduced by different regulati | `1798.110.1.1` | A consumer shall have the right to request that a business that collects personal information about the consumer disclose to the consumer the following: The categories of personal information it has collected about that consumer | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `null` | `null` | `null` | `null` | | `1798.110.1.2` | ...The categories of sources from which the personal information is collected | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `null` | | `1798.110.1.3` | ...The business or commercial purpose for collecting or selling personal information | `TRANSPARENCY.PURPOSE` | `null` | `null` | `null` | `null` | `null` | -| `1798.110.1.4` | The categories of third parties with whom the business shares personal information | `**to add?**` | `null` | `SHARING` | `null` | `null` | `null` | -| `1798.110.1.5` | The specific pieces of personal information it has collected about that consumer | `ACCESS` | `null` | `null` | `null` | `null` | `null` | +| `1798.110.1.4` | ...The categories of third parties with whom the business shares personal information | `**to add?**` | `null` | `SHARING` | `null` | `null` | `null` | +| `1798.110.1.5` | ...The specific pieces of personal information it has collected about that consumer | `ACCESS` | `null` | `null` | `null` | `null` | `null` | | `1798.115.1.1` | A consumer shall have the right to request that a business that sells the consumer’s personal information, or that discloses it for a business purpose, disclose to that consumer: The categories of personal information that the business collected about the consumer | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `SHARING` | `SALE` | `null` | `null` | | `1798.115.1.2` | ...The categories of personal information that the business sold about the consumer and the categories of third parties to whom the personal information was sold, by category or categories of personal information for each category of third parties to whom the personal information was sold | `**TBD**` | `null` | `SHARING` | `SALE` | `null` | `null` | | `1798.115.1.3` | ...The categories of personal information that the business disclosed about the consumer for a business purpose | `**TBD**` | `null` | `SHARING` | `SALE` | `null` | `null` | From 5a718c95a0fc52430a4201d6e726209013e538ba Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Wed, 1 Jun 2022 12:58:53 +0200 Subject: [PATCH 092/204] Update examples.md --- refs/schemas/priv/examples.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index ccc30895..000318db 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -169,8 +169,8 @@ In the following examples we show how, requests introduced by different regulati | `1798.110.1.4` | ...The categories of third parties with whom the business shares personal information | `**to add?**` | `null` | `SHARING` | `null` | `null` | `null` | | `1798.110.1.5` | ...The specific pieces of personal information it has collected about that consumer | `ACCESS` | `null` | `null` | `null` | `null` | `null` | | `1798.115.1.1` | A consumer shall have the right to request that a business that sells the consumer’s personal information, or that discloses it for a business purpose, disclose to that consumer: The categories of personal information that the business collected about the consumer | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `SHARING` | `SALE` | `null` | `null` | -| `1798.115.1.2` | ...The categories of personal information that the business sold about the consumer and the categories of third parties to whom the personal information was sold, by category or categories of personal information for each category of third parties to whom the personal information was sold | `**TBD**` | `null` | `SHARING` | `SALE` | `null` | `null` | -| `1798.115.1.3` | ...The categories of personal information that the business disclosed about the consumer for a business purpose | `**TBD**` | `null` | `SHARING` | `SALE` | `null` | `null` | +| `1798.115.1.2` | ...The categories of personal information that the business sold about the consumer and the categories of third parties to whom the personal information was sold, by category or categories of personal information for each category of third parties to whom the personal information was sold | `TRANSPARENCY.DATA-CATEGORIES`,+`**TBD**` | `null` | `SHARING` | `SALE` | `null` | `null` | +| `1798.115.1.3` | ...The categories of personal information that the business disclosed about the consumer for a business purpose | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `SHARING` | `SALE` | `null` | `null` | | `1798.120.1` | A consumer shall have the right, at any time, to direct a business that sells personal information about the consumer to third parties not to sell the consumer’s personal information. This right may be referred to as the right to opt-out | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `null` | | `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | | `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | From bfe5f37a6ee429382ba8ba66a961650621637e37 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Wed, 1 Jun 2022 14:27:46 +0200 Subject: [PATCH 093/204] Update examples.md --- refs/schemas/priv/examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 000318db..566e06d9 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -143,7 +143,7 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `ID` | | `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | `RESTRICT` | `null` | `AUTOMATED-DECISION-MAKING` | `null` | `null` | `ID` | | `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `ID` | -| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | `RESTRICT` | `BEHAVIOR,`DEVICE`,`LOCATION` | `COLLECTION` | `null` | `null` | `ID` | +| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | `RESTRICT` | `BEHAVIOR,`DEVICE`,`LOCATION` | `COLLECTION` | `TRACKING` | `null` | `ID` | | `GDPR.13.1.f`, `GDPR.14.1.f` | Storage information : know where is stored the data organization has on me | `TRANSPARENCY.WHERE` | `null` | `null` | `null` | `null` | `ID` | | `GDPR.14.1.e` | Accessibility information : know who can access the data organization has on me | `TRANSPARENCY.WHO` | `null` | `null` | `null` | `null` | `ID` | | `GDPR.14.2.f` | Provenance information : know the provenance of data organization has on me | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID` | From 158596873843a520031d4138b78b37afff9d7873 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Wed, 1 Jun 2022 17:18:46 +0200 Subject: [PATCH 094/204] Update examples.md --- refs/schemas/priv/examples.md | 78 +++++++++++++++++------------------ 1 file changed, 39 insertions(+), 39 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 566e06d9..a913c0ca 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -105,29 +105,29 @@ In the following examples we show how, requests introduced by different regulati ### GDPR REQUEST TEMPLATES FROM CNIL -| LAW | Demande | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | `Additional element` | +| LAW | Demande | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | `Other properties` | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | -| `GDPR.15` | [Acces](https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces) | `ACCESS` | `null` | `null` | `null` | `null` | `ID` | -| `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | `ACCESS` | `IMAGE` | `null` | `SECURITY` | video surveillance data from 01 Feb 2021 to 03 Feb 2021 | `ID`,`date`,`time.begining`,`time.ending` | -| `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | `ACCESS` | `HEALTH` | `null` | `null` | `null` | `ID` | -| `GDPR.15` | [Access to data "Preventel" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel) | `ACCESS` | `null` | `null` | `null` | `null` | `ID` | -| `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier): Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me | `ACCESS`, `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID`,`Account.number` | -| `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | -| `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | `ACCESS` | `null` | `null` | `null` | `null` | `ID`, (birthdate) | -| `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | `ACCESS` | `null` | `null` | `null` | `null` | `ID`,`date`,`time.begining`,`time.ending` | -| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| `ACCESS`,`PORTABILITY`| `**TBD**` | `null` | `null` | `null` | `ID` | -| `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| `MODIFY` | `**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | -| `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | `MODIFY` | `**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-modify`,`Information.rectified` | -| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | `DELETE` | `**TBD**` | `null` | `null` | `null` | `ID`,`Information.to-delete*`, `Information.reason-of-deletion` | -| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | `DELETE` | `CONTACT` | `null` | `ADVERTISING` | `null` | `ID`,`Information.reason-of-deletion` | -| `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `DELETE` | `null` | `null` | `null` | `null` | `ID`,`Account.name`,`Information.to-delete`, `Information.URL`| -| `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | `DELETE` | `**TBD**` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`, `Information.URL` | -| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne) | `DELETE` | `IMAGE` | `null` | `null` | `null` | `ID`, `Information.to-delete`, `Information.reason-of-deletion`,`Information.URL`| -| `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | `RESTRICT`, `DELETE`, **+Propagation?**, | `CONTACT` | `null` | `ADVERTISING` | `null` | `ID`,`Account.number` | -| `GDPR.21.1`,`GDPR.17.1.c`,,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | `RESTRICT`,`DELETE`, **+Propagation?** | `null` | `**all?**` | `null` | `null` | `ID`, `Information.reason-of-deletion` | -| `GDPR.21`, GDPR.18.1 | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | `RESTRICT` | `**choice?**` | `**choice?**` | `null` | `null` | `ID` | -| `GDRP.4`,`GDRP.6`,`GDRP.7`, `GDPR.13.2.c`| [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | `REVOKE-CONSENT` | `null` | `**choice?**` | `**choice?**` | `null` | `ID` | -| `GDPR.13.2.a`, `GDPR.14.2.a` | [For how long the data organization has on me will be kept](https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees) | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | `null` | `ID` | +| `GDPR.15` | [Acces](https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces) | `ACCESS` | `null` | `null` | `null` | `null` | | +| `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | `ACCESS` | `IMAGE` | `null` | `SECURITY` | ~~video surveillance data from 01 Feb 2021 to 03 Feb 2021~~ | `from-to` | +| `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | `ACCESS` | `HEALTH` | `null` | `null` | `null` | | +| `GDPR.15` | [Access to data "Preventel" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel) | `ACCESS` | `null` | `null` | `null` | `null` | | +| `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier): Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me | `ACCESS`, `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `null` | +| `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | `ACCESS` | `null` | `null` | `null` | `null` | `null` | +| `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | `ACCESS` | `null` | `null` | `null` | `null` | `null` | +| `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | `ACCESS` | `null` | `null` | `null` | `null` | `from-to` | +| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| `ACCESS`,`PORTABILITY`| `null` | `null` | `null` | `null` | `null` | +| `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| `MODIFY` | `**TBD**` | `null` | `null` | `null` | `Selector.to-modify`,`data.rectified` | +| `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | `MODIFY` | `**TBD**` | `null` | `null` | `null` | `Selector.to-modify`,`data.rectified` | +| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | `DELETE` | `null` | `null` | `null` | `Reason of deletion` | `Data.identifier'=Information to delete* (can be one or several data capture, or limited to a field , Data cat., Process cat. , Purpose, URL, ...) | +| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `Data.identifier'=data cat.+purpose | +| `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `OTHER` | `null` | `null` | `null` | `null` | `null` | +| `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | `DELETE` | `**TBD**` | `null` | `null` | `Reason of deletion` | `Data.identifier`=URL | +| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne) | `DELETE` | `IMAGE` | `null` | `null` | `Reason of deletion` | `Data.identifier`=data cat.+URL| +| `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | `RESTRICT`, `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `target`= `ORGANISATION`, `PARTNERS`(propagation) | +| `GDPR.21.1`,`GDPR.17.1.c`,,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | `RESTRICT`,`DELETE` | `null` | `null` | `null` | `Reason of deletion` | `Data.identifier`=all,`target`= `ORGANISATION`+`PARTNERS`(propagation) | +| `GDPR.21`, GDPR.18.1 | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | `RESTRICT` | `**choice?**` | `**choice?**` | `**choice?**` | `null` | `null` | +| `GDRP.4`,`GDRP.6`,`GDRP.7`, `GDPR.13.2.c`| [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | `REVOKE-CONSENT` | `null` | `**choice?**` | `**choice?**` | `null` | `null` | +| `GDPR.13.2.a`, `GDPR.14.2.a` | [For how long the data organization has on me will be kept](https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees) | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | `null` | `null` | >**Note** > @@ -137,39 +137,39 @@ In the following examples we show how, requests introduced by different regulati *Change my address* -| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Additional element | +| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Other properties | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | -| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | `MODIFY` | `CONTACT.ADDRESS` | `null` | `null` | `null` | `ID` | -| `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `ID` | -| `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | `RESTRICT` | `null` | `AUTOMATED-DECISION-MAKING` | `null` | `null` | `ID` | -| `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `ID` | -| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | `RESTRICT` | `BEHAVIOR,`DEVICE`,`LOCATION` | `COLLECTION` | `TRACKING` | `null` | `ID` | -| `GDPR.13.1.f`, `GDPR.14.1.f` | Storage information : know where is stored the data organization has on me | `TRANSPARENCY.WHERE` | `null` | `null` | `null` | `null` | `ID` | -| `GDPR.14.1.e` | Accessibility information : know who can access the data organization has on me | `TRANSPARENCY.WHO` | `null` | `null` | `null` | `null` | `ID` | -| `GDPR.14.2.f` | Provenance information : know the provenance of data organization has on me | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `ID` | +| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | `MODIFY` | `CONTACT.ADDRESS` | `null` | `null` | `null` | `null` | +| `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `null` | +| `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | `RESTRICT` | `null` | `AUTOMATED-DECISION-MAKING` | `null` | `null` | `null` | +| `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `null` | +| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | `RESTRICT` | `BEHAVIOR,`DEVICE`,`LOCATION` | `COLLECTION` | `TRACKING` | `null` | `null` | +| `GDPR.13.1.f`, `GDPR.14.1.f` | Storage information : know where is stored the data organization has on me | `TRANSPARENCY.WHERE` | `null` | `null` | `null` | `null` | `null` | +| `GDPR.14.1.e` | Accessibility information : know who can access the data organization has on me | `TRANSPARENCY.WHO` | `null` | `null` | `null` | `null` | `null` | +| `GDPR.14.2.f` | Provenance information : know the provenance of data organization has on me | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `null` | | `GDPR.13.2.a`, `GDPR.14.2.a` | Know when my data will be deleted | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | `null` | `ID` | -| `**GDPR.13?**` | Know what is the policy of the organization to keep data it has on me | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | `null` | `ID` | -| `GDPR.15.1.a` | Know the purpose of the processing organization does on the data it has on me | `TRANSPARENCY.PURPOSE` | | `null` | `null` | `null` | `ID` | -| `GDPR.12.1` | Know what type(s) of treatment organization does on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `**+all?**` | `null` | `null` | `ID` | -| `GDPR.12.1` | Know if a particular type of treatment is done by organisation on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `**choice?**` | `null` | `null` | `ID` | +| `**GDPR.13?**` | Know what is the policy of the organization to keep data it has on me | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | `null` | `null` | +| `GDPR.15.1.a` | Know the purpose of the processing organization does on the data it has on me | `TRANSPARENCY.PURPOSE` | | `null` | `null` | `null` | `null` | +| `GDPR.12.1` | Know what type(s) of treatment organization does on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `null` | `null` | `null` | `null` | +| `GDPR.12.1` | Know if a particular type of treatment is done by organisation on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `**choice?**` | `null` | `null` | `null` | >**Note** > >we need to add a schema field for providing new data, and date of validity of new data (not necessairly the date of trnasmission) ### CCPA REQUESTS -| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Additional element | +| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Other properties | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | | `CCPA.1798.100.1` | A consumer shall have the right to request that a business that collects a consumer’s personal information disclose to that consumer the categories and specific pieces of personal information the business has collected | `TRANSPARENCY.KNOWN`,`TRANSPARENCY.DATA-CATEGORIES` | `null` | `null` | `null` | `null` | `null` | -| `CCPA.1798.100.4` | A business that receives a verifiable consumer request from a consumer to access personal information shall promptly take steps to disclose and deliver, free of charge to the consumer, the personal information required by this section. | `ACCESS` | `null` | `null` | `null` | `null` | `ID` | +| `CCPA.1798.100.4` | A business that receives a verifiable consumer request from a consumer to access personal information shall promptly take steps to disclose and deliver, free of charge to the consumer, the personal information required by this section. | `ACCESS` | `null` | `null` | `null` | `null` | `null` | | `1798.105.1` | A consumer shall have the right to request that a business delete any personal information about the consumer which the business has collected from the consumer | `DELETE` | `null` | `null` | `null` | `null` | `null` | | `1798.110.1.1` | A consumer shall have the right to request that a business that collects personal information about the consumer disclose to the consumer the following: The categories of personal information it has collected about that consumer | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `null` | `null` | `null` | `null` | | `1798.110.1.2` | ...The categories of sources from which the personal information is collected | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `null` | | `1798.110.1.3` | ...The business or commercial purpose for collecting or selling personal information | `TRANSPARENCY.PURPOSE` | `null` | `null` | `null` | `null` | `null` | -| `1798.110.1.4` | ...The categories of third parties with whom the business shares personal information | `**to add?**` | `null` | `SHARING` | `null` | `null` | `null` | +| `1798.110.1.4` | ...The categories of third parties with whom the business shares personal information | `TRANSPARENCY.WHO` | `null` | `SHARING` | `null` | `null` | `target`=`PARTNERS` | | `1798.110.1.5` | ...The specific pieces of personal information it has collected about that consumer | `ACCESS` | `null` | `null` | `null` | `null` | `null` | | `1798.115.1.1` | A consumer shall have the right to request that a business that sells the consumer’s personal information, or that discloses it for a business purpose, disclose to that consumer: The categories of personal information that the business collected about the consumer | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `SHARING` | `SALE` | `null` | `null` | -| `1798.115.1.2` | ...The categories of personal information that the business sold about the consumer and the categories of third parties to whom the personal information was sold, by category or categories of personal information for each category of third parties to whom the personal information was sold | `TRANSPARENCY.DATA-CATEGORIES`,+`**TBD**` | `null` | `SHARING` | `SALE` | `null` | `null` | +| `1798.115.1.2` | ...The categories of personal information that the business sold about the consumer and the categories of third parties to whom the personal information was sold, by category or categories of personal information for each category of third parties to whom the personal information was sold | `TRANSPARENCY.DATA-CATEGORIES`,`TRANSPARENCY.WHO` | `null` | `SHARING` | `SALE` | `null` | `null` | | `1798.115.1.3` | ...The categories of personal information that the business disclosed about the consumer for a business purpose | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `SHARING` | `SALE` | `null` | `null` | | `1798.120.1` | A consumer shall have the right, at any time, to direct a business that sells personal information about the consumer to third parties not to sell the consumer’s personal information. This right may be referred to as the right to opt-out | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `null` | | `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | From 171825c5486026c9b41c7ea81d9f8e1f111ae14e Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 1 Jun 2022 17:59:18 +0200 Subject: [PATCH 095/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index a81f294a..5c0a6ed7 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -608,6 +608,10 @@ Is the mechanism for extending the vocabulary appropriate? We need a way for Systems to encrypt the data (that compatible also with encryption libraries other then our own). +### Motivation or explanation of Demand +>**Note** +> +> The motivation or explanation of Demand is modeled by a message, and the message is optional. If law regulations state that motivation or explanation of Demand is mandatory, it is not supported. ## References ### Normative References From 5a1bd19c969d2d5e55aa2cc7763603050f3290f7 Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 1 Jun 2022 17:59:41 +0200 Subject: [PATCH 096/204] Update refs/schemas/priv/dictionary/actions/en.actions.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- refs/schemas/priv/dictionary/actions/en.actions.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/dictionary/actions/en.actions.json b/refs/schemas/priv/dictionary/actions/en.actions.json index bba8832d..398a6d3d 100644 --- a/refs/schemas/priv/dictionary/actions/en.actions.json +++ b/refs/schemas/priv/dictionary/actions/en.actions.json @@ -7,7 +7,7 @@ "RESTRICT": "To restrict processing of my data", "REVOKE-CONSENT": "To revoke prviousely given consent for data processing", "TRANSPARENCY": "To demand information related to data processing practices and know if the system has data on me", - "TRANSPARENCY.DATA-CATEGORIES": "To know the categories of processing being done on the data the System has on me", + "TRANSPARENCY.DATA-CATEGORIES": "To know the categories of the data the system has on me", "TRANSPARENCY.DPO": "To know the contact details of the data protection officer", "TRANSPARENCY.KNOWN": "To know if the System has data on me", "TRANSPARENCY.LEGAL-BASES": "To know the legal bases for processing my data (including legitimate interests)", From 40bb3504ab9427b30c43d9bd280fe97d0dbb3a21 Mon Sep 17 00:00:00 2001 From: Nicolas Timillero <83829768+timnicblind@users.noreply.github.com> Date: Wed, 1 Jun 2022 18:34:52 +0200 Subject: [PATCH 097/204] Update examples.md --- refs/schemas/priv/examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index a913c0ca..76df119d 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -199,7 +199,7 @@ In the following examples we show how, requests introduced by different regulati | `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | | `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | | `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `article` | X | `X` | `null` | `null` | `null` | `null` | `null` | +| `1798.130.1.1` | Make available to consumers two or more designated methods for submitting requests for information required to be disclosed pursuant to Sections 1798.110 and 1798.115, including, at a minimum, a toll-free telephone number. | `X` | `null` | `null` | `null` | `null` | `null` | ### Requests list (**TO BE TRANSFORMED IN THE ABOVE FORMAT**) From 1cd4c839f8894f50121bc2912a808460f30d4800 Mon Sep 17 00:00:00 2001 From: Nicolas Timillero <83829768+timnicblind@users.noreply.github.com> Date: Wed, 1 Jun 2022 18:47:52 +0200 Subject: [PATCH 098/204] Update examples.md --- refs/schemas/priv/examples.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 76df119d..3918cfe7 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -197,9 +197,11 @@ In the following examples we show how, requests introduced by different regulati | `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | | `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | | `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `1798.130.1.1` | Make available to consumers two or more designated methods for submitting requests for information required to be disclosed pursuant to Sections 1798.110 and 1798.115, including, at a minimum, a toll-free telephone number. | `X` | `null` | `null` | `null` | `null` | `null` | +| `1798.125.1.1` | A business shall not discriminate against a consumer because the consumer exercised any of the consumer’s rights | `X` | `null` | `null` | `null` | `null` | `null` | +| `1798.130.1.1` | Make available to consumers two or more designated methods for submitting requests for information, including, at a minimum, a toll-free telephone number. | `X` | `null` | `null` | `null` | `null` | `null` | +| `1798.130.1.2` | Disclose and deliver the required information to a consumer free of charge within 45 days of receiving a verifiable consumer request from the consumer. | `X` | `null` | `null` | `null` | `null` | `null` | + + ### Requests list (**TO BE TRANSFORMED IN THE ABOVE FORMAT**) From 4316af644c077216b954906efae6250ed0118519 Mon Sep 17 00:00:00 2001 From: milstan Date: Fri, 3 Jun 2022 08:02:19 +0200 Subject: [PATCH 099/204] about ethyca + example json --- refs/schemas/priv/RFC-PRIV.md | 54 ++++- .../priv/json-schema/priv-terms.schema.json | 138 +++++++++++ .../schemas/priv/json-schema/priv.schema.json | 229 ++++++++++++++++++ refs/schemas/priv/priv.schema.json | 201 --------------- 4 files changed, 417 insertions(+), 205 deletions(-) create mode 100644 refs/schemas/priv/json-schema/priv-terms.schema.json create mode 100644 refs/schemas/priv/json-schema/priv.schema.json delete mode 100644 refs/schemas/priv/priv.schema.json diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 5c0a6ed7..4204c533 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -152,7 +152,7 @@ Privacy Scope = (Data Categories) x (Categories of Processing) x (Purposes of Pr | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-category` | 0-* | `AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER` | +| `data-categories` | 0-* | `AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER` | When several values are given, Systems MUST interpret the `data-category` dimension as a union of all the categories indicated. @@ -350,7 +350,7 @@ A separate document gives a list of [examples](examples.md) on how to represent ### JSON format -We provide a [JSON Schema document](./PRIV.schema.json) for machine-readable interpretation of Privacy Requests compliant with [v4 (or ideally lower) of IETF specification](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#:~:text=JSON%20Schema%20is%20a%20JSON,interaction%20control%20of%20JSON%20data.) +We provide a [JSON Schema document](./priv.schema.json) for machine-readable interpretation of Privacy Requests compliant with [v4 (or ideally lower) of IETF specification](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#:~:text=JSON%20Schema%20is%20a%20JSON,interaction%20control%20of%20JSON%20data.) ### Authenticated exchanges @@ -441,6 +441,37 @@ Systems MAY specify the vocabulary used to express data being exchanged. The val This vocabulary can be extended by defining a new identifier for the new vocabulary. New vocabularies MAY include other vocabularies as long as their sets of concepts, properties and terms are disjoint. +## Examples + +A [JSON schema of the PRIV](./priv.schema.json) is provided for convenience. To illustrate a request, let us take the example of a data subject wanting to know if a an organisation (and any of its partners if applicable) have any data on them, and if so, have their contact data deleted. + +This request can be represented with the following json data: +``` +{ + "$schema":"https://blindnet.io/schemas/priv.schema.json", + "request-id": "8f9066c6-1c6c-42a0-9993-e88c98d0e84d", + "date": "2022-06-02T14:40:39+0000", + "data-subject":[{ + "dsid-schema": "email-sha-256", + "dsid":"7cac89a56bbf998c996f33e0b2d3bad578e05f3af8d64793c0bcac46b8c260dc" + }], + "demands":[{ + "demand-id":"496294eb-5293-47dd-aaf8-494a0cb09134", + "action":"TRANSPARENCY.KNOWN" + },{ + "demand-id":"86bbb28a-eee6-45e6-81d6-7101de32374b", + "action":"DELETE", + "restrictions":[{ + "data-categories":["CONTACT"] + }] + }], + "target":"PARTNERS" + +} + +``` +In [here](./examples.md) we provide an overview of various Privacy Requests that a Data Subject might want to formulate according to [supported legislation](#supported-legislation) and we give indications on how each of those can be modelled with the Privacy Request Interchange Vocabulary. + ## Design Implications for Systems Implementing PRIV ### Remembering Transfers @@ -521,7 +552,7 @@ PRIV MUST be agnostic of the authentication method, and as such MUST be compatib ### Mandatory properties and value constrains -Should we include rescissions in the schema according to the [JSON-schema-validation vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#page-4) in order to make certain properties mandatory and ensure to limit string values to the values we support? +Should we include restrictions in the schema according to the [JSON-schema-validation vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#page-4) in order to make certain properties mandatory and ensure to limit string values to the values we support? In the current proposal, this is the case for target, but not for request types, data categories, and user identity schemas. We might want to include more forma constraints there, or deliberately leave flexibility. This is a discussion we need to have. @@ -611,7 +642,22 @@ We need a way for Systems to encrypt the data (that compatible also with encrypt ### Motivation or explanation of Demand >**Note** > -> The motivation or explanation of Demand is modeled by a message, and the message is optional. If law regulations state that motivation or explanation of Demand is mandatory, it is not supported. +> The motivation or explanation of Demand is modeled by a message, and the message is optional. If law regulations state that motivation or explanation of Demand is mandatory, it is not supported. + +## Alternatives + +### Ethyca + +Ethyca has their (also open-soruce) [FIDES language](https://ethyca.github.io/fideslang/). Their language is less modular. Data provenance and data category are mixed together, which means that terms are long, and each has quite particular, complicated meaning. + +We aim here for a simpler way to express requests and rights, and for a more automated Privacy Request resolution algebra. + +Their support for purposes, and per-purpose consents is limited. + +Yet, we want to be compatible with them. + +Still the question remains, should we fully reuse what they have built (in terms of categories of data) and try to extend it? My view is that that would limit our ability to offer automation in many use-cases. + ## References ### Normative References diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json new file mode 100644 index 00000000..74c0050f --- /dev/null +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -0,0 +1,138 @@ +{"$id": "https://blindnet.io/schemas/priv-terms.schema.json", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "title": "Privacy Request Interchange Vocabulary - Terms", + "description": "Terms of the Privacy Request Interchange Vocabulary", + "$defs": { + "actions": { + "enum": [ + "ACCESS", + "DELETE", + "MODIFY", + "OBJECT", + "PORTABILITY", + "RESTRICT", + "REVOKE-CONSENT", + "TRANSPARENCY", + "TRANSPARENCY.DATA-CATEGORIES", + "TRANSPARENCY.DPO", + "TRANSPARENCY.KNOWN", + "TRANSPARENCY.LEGAL-BASES", + "TRANSPARENCY.ORGANISATION", + "TRANSPARENCY.POLICY", + "TRANSPARENCY.PROCESSING-CATEGORIES", + "TRANSPARENCY.PROVENANCE", + "TRANSPARENCY.PURPOSE", + "TRANSPARENCY.RETENTION", + "TRANSPARENCY.WHERE", + "TRANSPARENCY.WHO", + "OTHER" + ] + }, + "data-categories": { + "enum": [ + "AFFILIATION", + "BEHAVIOR", + "BEHAVIOR.ACTIVITY", + "BEHAVIOR.CONNECTION", + "BEHAVIOR.PREFERENCE", + "BIOMETRIC", + "CONTACT", + "CONTACT.EMAIL", + "CONTACT.ADDRESS", + "CONTACT.PHONE", + "DEMOGRAPHIC", + "DEMOGRAPHIC.AGE", + "DEMOGRAPHIC.BELIEFS", + "DEMOGRAPHIC.GENDER", + "DEMOGRAPHIC.ORIGIN", + "DEMOGRAPHIC.RACE", + "DEVICE", + "FINANCIAL", + "FINANCIAL.BANK-ACCOUNT", + "GENETIC", + "HEALTH", + "IMAGE", + "LOCATION", + "NAME", + "RELATIONSHIPS", + "PROFILING", + "UID" + ] + }, + "processing-categories": { + "enum": [ + "ANONYMIZATION", + "AUTOMATED-INFERENCE", + "AUTOMATED-DECISION-MAKING", + "COLLECTION", + "GENERATING", + "PUBLISHING", + "STORING", + "SHARING", + "USING" + ] + }, + "purposes": { + "enum": [ + "ADVERTISING", + "CONTRACT", + "CONTRACT.BASIC-SERVICE", + "CONTRACT.ADDITIONAL-SERVICES", + "NECESSARY", + "NECESSARY.JUSTICE", + "NECESSARY.LEGAL", + "NECESSARY.MEDICAL", + "NECESSARY.PUBLIC-INTERESTS", + "NECESSARY.VITAL-INTERESTS", + "NECESSARY.SOCIAL-PROTECTION", + "MARKETING", + "PERSONALISATION", + "SALE", + "SECURITY", + "TRACKING", + "ANY" + ] + }, + "targets": { + "enum": [ + "ORGANISATION", + "PARTNERS", + "SYSTEM" + ] + }, + "targets-directional": { + "enum": [ + "PARTNERS.DOWNWARD", + "PARTNERS.UPWARD" + ] + }, + "motives": { + "enum": [ + "IDENTITY-UNCONFIRMED", + "LANGUAGE-UNSUPPORTED", + "LEGAL-BASES", + "LEGAL-OBLIGATIONS", + "REQUEST-UNSUPPORTED", + "USER-UNKNOWN" + ] + }, + "retentions": { + "enum": [ + "NO-LONGER-THAN", + "NO-LESS-THAN" + ] + }, + "events": { + "enum": [ + "DATA-COLLECTION", + "RELATIONSHIP-END" + ] + }, + "other": { + "enum": [ + "YES", + "NO" + ] + } + } +} diff --git a/refs/schemas/priv/json-schema/priv.schema.json b/refs/schemas/priv/json-schema/priv.schema.json new file mode 100644 index 00000000..47c990d3 --- /dev/null +++ b/refs/schemas/priv/json-schema/priv.schema.json @@ -0,0 +1,229 @@ +{ + "$id": "https://blindnet.io/schemas/priv.schema.json", + "$schema": "https://json-schema.org/draft/2019-09/schema", + "title": "Privacy Request Interchange Vocabulary", + "description": "Terms of the Privacy Request Interchange Vocabulary", + + "properties": { + "request-id": { + "type": "string", + "format": "uuid" + }, + "data-subject": { + "type": "array", + "items": { + "$ref": "#/$defs/data-subject-identity" + }, + "minItems": 1 + }, + + "date": { + "type": "string", + "format": "date-time" + }, + + "demands": { + "type": "array", + "items": { + "type": "object", + "properties": { + "demand-id": { + "type": "string", + "format": "uuid" + }, + "action": { + "enum": { + "$ref": "./priv-terms.schema.jso#/defs/actions" + } + }, + "data": { + "type": "object" + }, + "restrictions": { + "type": "array", + "items": { + "oneOf": [ + { + "$ref": "#/$defs/privacy-scope" + }, + { + "type": "object", + "properties": { + "consent-id": { + "type": "string", + "format": "uuid" + } + } + }, + { + "type": "object", + "properties": { + "capture-id": { + "type": "string", + "format": "uuid" + } + } + }, + { + "type": "object", + "properties": { + "from": { + "type": "string", + "format": "date-time" + }, + "to": { + "type": "string", + "format": "date-time" + } + } + } + ] + } + }, + "target": { + "enum": { + "oneOf": [ + { + "$ref": "./priv-terms.schema.json#/$defs/targets" + }, + { + "$ref": "./priv-terms.schema.json#/$defs/targets-directional" + } + ] + } + } + }, + "required": [ + "action", + "demand-id" + ] + }, + "minItems": 1 + } + }, + + "required": [ + "request-id", + "date", + "demands" + ], + + "$defs": { + "data-subject-identity": { + "$id": "/schemas/data-subject-identity", + "$schema": "https://json-schema.org/draft/2020-12/schema#", + "type": "object", + "properties": { + "dsid-schema": { + "type": "string" + }, + "dsid": { + "type": "string" + } + }, + "required": [ + "dsid-schema", + "dsid" + ] + }, + "privacy-scope": { + "$id": "/schemas/privacy-scope", + "$schema": "https://json-schema.org/draft/2020-12/schema#", + "type": "object", + "properties": { + "oneOf": [ + { + "allOf": [ + { + "data-categories": { + "const": "OTHER" + } + }, + { + "$ref": "#/$defs/message" + } + ] + }, + { + "data-categories": { + "type": "array", + "items": { + "enum": { + "$ref": "./priv-terms.schema.json#/defs/data-categories" + } + } + } + } + ], + + "oneOf": [ + { + "allOf": [ + { + "processing-categories": { + "const": "OTHER" + } + }, + { + "$ref": "#/$defs/message" + } + ] + }, + { + "processing-categories": { + "type": "array", + "items": { + "enum": { + "$ref": "./priv-terms.schema.json#/defs/processing-categories" + } + } + } + } + ], + + "oneOf": [ + { + "allOf": [ + { + "purposes": { + "const": "OTHER" + } + }, + { + "$ref": "#/$defs/message" + } + ] + }, + { + "purposes": { + "type": "array", + "items": { + "enum": { + "$ref": "./priv-terms.schema.json#/defs/purposes" + } + } + } + } + ], + + "message": { + "$id": "/schemas/message", + "$schema": "https://json-schema.org/draft/2020-12/schema#", + "type": "object", + "properties": { + "message": { + "type": "string" + }, + "lang": { + "type": "string" + }, + "required": [ + "message" + ] + } + } + } + } + } + +} diff --git a/refs/schemas/priv/priv.schema.json b/refs/schemas/priv/priv.schema.json deleted file mode 100644 index d2e2baf3..00000000 --- a/refs/schemas/priv/priv.schema.json +++ /dev/null @@ -1,201 +0,0 @@ -{ - "$id": "https://blindnet.io/schemas/rights-request", - "$schema": "https://json-schema.org/draft/2020-12/schema", - - "title": "Privacy Request", - "description": "This document defines a format for interoperability of Privacy Requests", - - "type": "object", - "properties": { - "request-id": { - "type": "string", - "format": "uuid" - }, - - "data-subject": { - "type": "array", - "items": { "$ref": "#/$defs/data-subject-identity" }, - "minItems": 1 - }, - - "demands": { - "type": "array", - "items": { "$ref": "#/$defs/demand" }, - "minItems": 1 - }, - - "target": { - "enum": ["DOWNWARD","UPWARD","BIDIRECTIONAL","INTRANSITIVE"], - "default": "INTRANSITIVE", - }, - - "date": { - "type": "string", - "format": "date-time" - }, - - - - - - }, - - "required": ["rights-request-id", "timestamp"], - - "definitions": { - - }, - - "$defs": { - "data-subject-identity": { - "$id": "/schemas/data-subject-identity", - "$schema": "https://json-schema.org/draft/2020-12/schema#", - "type": "object", - - "properties": { - "dsid-schema": { "type": "string" }, - "dsid": { "type": "string" }, - }, - - "required": ["dsid-schema", "dsid"], - - }, - - "demand": { - "$id": "/schemas/demand", - "$schema": "https://json-schema.org/draft/2020-12/schema#", - "type": "object", - - "properties": { - "demand-id": { - "type": "string" - }, - - "message": { - "type": "string" - }, - - "language": { - "type": "string" - }, - - "legal-grounds": { - "type": "array", - "items": { "type": "string" } - }, - - "consent-ids": { - "type": "array", - "items": { - "type": "string", - "format": "uuid" - } - }, - "capture-ids": { - "type": "array", - "items": { - "type": "string", - "format": "uuid" - } - } - - "action": { - "enum":["ACCESS", - "DELETE", - "MODIFY", - "OBJECT", - "PORTABILITY", - "RESTRICT", - "REVOKE-CONSENT", - "TRANSPARENCY", - "TRANSPARENCY.DATA-CATEGORIES", - "TRANSPARENCY.DPO", - "TRANSPARENCY.KNOWN", - "TRANSPARENCY.LEGAL-BASES", - "TRANSPARENCY.ORGANISATION", - "TRANSPARENCY.POLICY", - "TRANSPARENCY.PROCESSING-CATEGORIES", - "TRANSPARENCY.PROVENANCE", - "TRANSPARENCY.PURPOSE", - "TRANSPARENCY.RETENTION", - "TRANSPARENCY.WHERE", - "TRANSPARENCY.WHO", - "OTHER"] - }, - - "data-categories": { - "enum": ["AFFILIATION", - "BEHAVIOR", - "BEHAVIOR.ACTIVITY", - "BEHAVIOR.CONNECTION", - "BEHAVIOR.PREFERENCE", - "BIOMETRIC", - "CONTACT", - "CONTACT.EMAIL", - "CONTACT.ADDRESS", - "CONTACT.PHONE", - "DEMOGRAPHIC", - "DEMOGRAPHIC.AGE", - "DEMOGRAPHIC.BELIEFS", - "DEMOGRAPHIC.GENDER", - "DEMOGRAPHIC.ORIGIN", - "DEMOGRAPHIC.RACE", - "DEVICE", - "FINANCIAL", - "FINANCIAL.BANK-ACCOUNT", - "GENETIC", - "HEALTH", - "IMAGE", - "LOCATION", - "NAME", - "RELATIONSHIPS", - "PROFILING", - "UID", - "OTHER"] - }, - - "processing-categories": { - "enum": ["ANONYMIZATION", - "AUTOMATED-INFERENCE", - "AUTOMATED-DECISION-MAKING", - "COLLECTION", - "GENERATING", - "MATCHING", - "PUBLISHING", - "STORING", - "SHARING", - "USING", - "OTHER"] - }, - - "purposes": { - "enum": ["ADVERTISING", - "CONTRACT", - "CONTRACT.BASIC-SERVICE", - "CONTRACT.ADDITIONAL-SERVICES", - "NECESSARY", - "NECESSARY.JUSTICE" - "NECESSARY.LEGAL", - "NECESSARY.MEDICAL", - "NECESSARY.SOCIAL-PROTECTION", - "NECESSARY.PUBLIC-INTERESTS", - "NECESSARY.VITAL-INTERESTS", - "MARKETING", - "PERSONALISATION", - "SALE", - "SECURITY", - "TRACKING", - "ANY"] - }, - - - - }, - - - - }, - -} - - } From 8351276cbc9d793b781d385357e5be9a8c860572 Mon Sep 17 00:00:00 2001 From: milstan Date: Sun, 5 Jun 2022 10:11:15 +0200 Subject: [PATCH 100/204] dding legal bases + change to purposes --- refs/schemas/priv/RFC-PRIV.md | 38 ++- .../legal-bases/en.legal-bases.json | 7 + .../priv/dictionary/purposes/en.purposes.json | 24 +- refs/schemas/priv/expected-behavior.md | 275 +++++++++++++++++- 4 files changed, 316 insertions(+), 28 deletions(-) create mode 100644 refs/schemas/priv/dictionary/legal-bases/en.legal-bases.json diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 4204c533..5d510633 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -131,7 +131,7 @@ A Demand MAY refer to only certain Privacy Scope (categories of data, certain ty | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `restrictions` | 0-* | An optional array of restriction objects, each being either a [Privacy Scope](#privacy-scope), [Consent Restriction](#consent-restriction), [Capture Restriction](#capture-restriction), [Data Range](#data-range)| +| `restrictions` | 0-* | An optional array of restriction objects, each being one of [Privacy Scope](#privacy-scope), [Consent Restriction](#consent-restriction), [Capture Restriction](#capture-restriction), [Data Range](#data-range)| When more than one restriction is specified, the System MUST interpret the Demand as referring to the intersection of restrictions. For example let us consider a `DELETE` demand having two restrictions: `LOCATION` `data-category` as Privacy Scope, and from 11th to 15th of June 2022 as Data Range. The System SHOULD understand that the Data Subject wants the System to delete only their location data processed in this precise period. @@ -152,7 +152,7 @@ Privacy Scope = (Data Categories) x (Categories of Processing) x (Purposes of Pr | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-categories` | 0-* | `AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER` | +| `data-categories` | 0-* | `AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | When several values are given, Systems MUST interpret the `data-category` dimension as a union of all the categories indicated. @@ -180,18 +180,16 @@ In the absence of indication of any `processing-categories` dimension, Systems M | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `purposes` | 0-* | `ADVERTISING`, `CONTRACT`, `CONTRACT.BASIC-SERVICE`, `CONTRACT.ADDITIONAL-SERVICES`, `NECESSARY`, `NECESSARY.JUSTICE`, `NECESSARY.LEGAL`, `NECESSARY.MEDICAL`, `NECESSARY.PUBLIC-INTERESTS`, `NECESSARY.VITAL-INTERESTS`, `NECESSARY.SOCIAL-PROTECTION`, `MARKETING`, `PERSONALISATION`, `SALE`, `SECURITY`, `TRACKING`, `OTHER`, `ANY` | +| `purposes` | 0-* | `ADVERTISING`, `COMPLIANCE`, `JUSTICE`, `MARKETING`, `MEDICAL`, `PERSONALISATION`, `PUBLIC-INTERESTS`, `RESEARCH`, `SALE`, `SECURITY`, `SERVICES`, `SERVICES.ADDITIONAL-SERVICES`, `SERVICES.BASIC-SERVICE`, `SOCIAL-PROTECTION`, `TRACKING`, `VITAL-INTERESTS`, `OTHER` | When several values are given, Systems MUST interpret the `purposes` restriction as a union of all the purposes indicated. Purposes are organised as a hierarchy, denoted with a dot ".", the more general purpose being written on the left. E.g. the following two `pruposes` restrictions are equivalent: -- `NECESSARY`,`NECESSARY.LEGAL` -- `NECESSARY` +- `SERVICES`,`SERVICES.BASIC-SERVICE` +- `SERVICES` In the absence of indication of any `purpose` restriction, Systems MUST interpret the Demand as being related to all and any purpose of treatment. -//**TODO** Decide if we need the `ANY` and in that case make sure all the dimensions of privacy scope have one. The downside of having it is that it introduces entropy as the same thing can be stated in two ways (by stating `ANY` and by ommitting any statement). We want to avoid this. Is there an upside? - [A list of eligible `purposes` values with corresponding user-facing descriptions is provided](./dictionary/purposes/) for convenience. ###### Consent Restriction @@ -301,8 +299,11 @@ A Consent is given by one Data Subject which can be identified by one or more [D | `data-subject` | 1-* | [Data Subject Identities](#decentralized-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| | `consent-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Consent was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `expires` | 0-1 | Date and Time when Consent expires in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | | `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the Consent SHOULD be interpreted as unlimited | +| `replaces` | 0-* | Optionally one or more 'consent-id's of previous consents that have became void when this consent was made | +| `replaced-by` | 0-* | Optionally one or more 'consent-id's of previous consents that have became void when this consent was made | ### Data Capture @@ -323,15 +324,21 @@ A Data Capture is given by one Data Subject which can be identified by one or mo | `selector` | 1 | a string used to uniquely identify a data field (in the System's data model) to which the fragment corresponds | | `date` | 1 | Date and Time when data was Captured was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | -| `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the Consent SHOULD be interpreted as unlimited | -| `legal-base` | 1-* | Legal bases for data processing associated to the particular fragment with regards to its particular Privacy Scope | | `retention` | 1-* | one or more Retention Policies | - | `data` | 0-* | Optionally concrete data (Format **TBD**) | +`selector`s MUST include the data category of the data. For example selectors 'CONTACT.ADDRESS.SHIPPING' and 'CONTACT.ADDRESS.BILLING' indicate that the data being captured by a particular fragment belong to the `CONTACT.ADDRESS` data category. + +While the Data Categories are global, the selectors are defined by the Systems. + ##### Legal bases +| Property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `type` | 0-* | Optionally an array of values among `CONTRACT`, `CONSENT`, `LEGITIMATE-INTEREST`, `NECESSARY`, `OTHER` | + +Processing MAY be legitimate according to several legal bases for treatment. For example, a Data Subject can give explicit `CONSENT` when creating and account with a particular online service, and at the time, the System providing some service to the Data Subject might need to process their data in order to deliver a service or honour a `CONTRACT` (e.g. deliver the purchased goods to the Data Subjects address and issue an invoice). -**TBD** +Certain processing is made legitimate (`LEGITIMATE-INTEREST`) or mandatory (`NECESSARY`) by law, e.g. [Article 6 og GDPR](https://gdpr-info.eu/art-6-gdpr/). ##### Retention Policy | Property | Expected cardinality | Expected values | @@ -631,6 +638,7 @@ Should we include a way for systems to sign responses and allow to confirm their Should we implement the Accept-Language logic from HTTP? Or can we assume that the 'lang' of request is the language in which the response is expected? + ### Extending the vocabulary Is the mechanism for extending the vocabulary appropriate? @@ -642,7 +650,7 @@ We need a way for Systems to encrypt the data (that compatible also with encrypt ### Motivation or explanation of Demand >**Note** > -> The motivation or explanation of Demand is modeled by a message, and the message is optional. If law regulations state that motivation or explanation of Demand is mandatory, it is not supported. +> The motivation or explanation of Demand is modelled by a message, and the message is optional. If law regulations state that motivation or explanation of Demand is mandatory, it is not supported. ## Alternatives @@ -658,6 +666,12 @@ Yet, we want to be compatible with them. Still the question remains, should we fully reuse what they have built (in terms of categories of data) and try to extend it? My view is that that would limit our ability to offer automation in many use-cases. +### ISO 19944 + +There is an ISO standard for data categories and processing categories. They are mostly very broad, many overlap, and they are of almost no use for resolving Privacy Requests in the context of GDPR. + +However, we might want to allow developers to use our format (properties and concepts) with ISO 19944 categories instead of our terms. + ## References ### Normative References diff --git a/refs/schemas/priv/dictionary/legal-bases/en.legal-bases.json b/refs/schemas/priv/dictionary/legal-bases/en.legal-bases.json new file mode 100644 index 00000000..6729343c --- /dev/null +++ b/refs/schemas/priv/dictionary/legal-bases/en.legal-bases.json @@ -0,0 +1,7 @@ +{ + "CONSENT": "The Data Subject gave Consent for processing", + "CONTRACT": "Processing is necessary for providing services to the Data Subject or withing a for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract", + "LEGITIMATE-INTEREST": "Processing is necessary for the purposes of the legitimate interests", + "NECESSARY": "Processing is necessary for security reasons, legal reasons or protection of rights", + "OTHER": "Other legal base", +} diff --git a/refs/schemas/priv/dictionary/purposes/en.purposes.json b/refs/schemas/priv/dictionary/purposes/en.purposes.json index 276b45d3..7edb7f58 100644 --- a/refs/schemas/priv/dictionary/purposes/en.purposes.json +++ b/refs/schemas/priv/dictionary/purposes/en.purposes.json @@ -1,21 +1,19 @@ { "ADVERTISING": "To show ads that are either targeted to the specific user or not targeted", - "CONTRACT": "Processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract", - "CONTRACT.BASIC-SERVICE": "Providing the basic service to the person", - "CONTRACT.ADDITIONAL-SERVICES": "Providing the services that the person requires that are not part of the basic service", + "COMPLIANCE": "Processing is performed to comply with a legal obligation", + "JUSTICE": "processing is necessary for the establishment, exercise or defence of legal claims or whenever courts are acting in their judicial capacity", "MARKETING": "To contact the user to offer products, services, or other promotions", - "NECESSARY": "Processing is necessary for security reasons, legal reasons or protection of rights", - "NECESSARY.JUSTICE": "processing is necessary for the establishment, exercise or defence of legal claims or whenever courts are acting in their judicial capacity", - "NECESSARY.LEGAL": "Processing is necessary for compliance with a legal obligation", - "NECESSARY.MEDICAL": "Processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services", - "NECESSARY.PUBLIC-INTERESTS": "Processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority", - "NECESSARY.SOCIAL-PROTECTION": "Processing is necessary for the purposes of employment and social security and social protection", - "NECESSARY.VITAL-INTERESTS": "Processing is necessary in order to protect the vital interests of the data subject or of another natural person", + "MEDICAL": "Processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services", "PERSONALISATION": "For providing user with a personalized experience", + "PUBLIC-INTERESTS": "Processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority", + "RESEARCH": "Scientific and Market Research", "SALE": "Selling data to third parties", - "SECURITY": "For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. ", + "SECURITY": "For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. ", + "SERVICES": "Processing is necessary performed in the context of services provided to the Data Subject or transactions being concluded with them", + "SERVICES.ADDITIONAL-SERVICES": "Providing the services that the person requires that are not part of the basic service", + "SERVICES.BASIC-SERVICE": "Providing the basic service to the person", + "SOCIAL-PROTECTION": "Processing is necessary for the purposes of employment and social security and social protection", "TRACKING": "Tracking information about user behavior and activity online", + "VITAL-INTERESTS": "Processing is necessary in order to protect the vital interests of the data subject or of another natural person", "OTHER": "Other specific purpose", - "ANY": "Any purpose", } - diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 07dfa424..365e26b1 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -28,13 +28,282 @@ It is a first step towards the specification of the [Privacy Compiler](https://g - We use the terms Organization, Submitter, Data Consumer as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) as defined there. -## **TBD** +## Scope of automation +Privacy Requests can be resolved more or less automatically. +Privacy Requests that are expressed in unambiguous terms, may be fully processed automatically. +Those that include the term "OTHER" or a textual message with more details about the request likely require human intervention. -**TBD** +Systems MAY be configured to treat Privacy Requests eligible for automation with or without human validation. In any case, the role of the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) is to calculate the appropriate action, given particular Privacy Request in a particular situation. + +## Configuration & Prerequisites + +A [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) serving a particular system MUST have the knowledge of: +- The exhaustive list of [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) `selector`s that the System works with, +- For each `selector` (or Data Category implying every `selector` used within that Data Category) a data [Retention Policy](./RFC-PRIV.md#retention-policy), +- A set of Privacy Scope triples that describe the usage the System is likely to make with data. Each triple consists of: + - a `selector` (or Data Category implying every `selector` used within that Data Category) + - a Processing Category that the System is likely to perform on that data + - a Purpose +- For each Privacy Scope triple, one or more [Legal Bases](./RFC-PRIV.md#legal-bases). + +Legal Bases live a life of their own, regardless of the presence or absence of data, so Privacy Compilers MUST at all times, keep track of: +- All Legal Bases +- Active Legal Bases, which consist of: + - active Consents, a list that is modified when Consent is collected and within [Operations over consents](#operations-over-consents), + - other Legal Bases that have their validity conditions met at the given time + +In addition, in order to resolve `TRANSPARENCY` requests, a Privacy Compiler MUST also know a set of parameters defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV). + +## Privacy Algebra + +### Set Operations over Privacy Scope + +#### Operations over consents + +The scope of Consents can be modified by Privacy Request that include `OBJECT`, `RESTRICT`, and `REVOKE-CONSENT` actions. + +The System SHOULD, at all times, keep track of active Consents. We call a Consent active if its scope has not been modified or the Consent totally revoked. When the scope of a Consent is modified, a new Consent (that is now active) is made that replaces the old Consent (no longer active). + +When the System has more then one active consent, the System considers the union of their scopes as being the Privacy Scope to which the Data Subject consents. + +We illustrate this on the following example. + +Let us imagine a System, processing data about a Data Subject, and having collected the following consent from the Data Subject: + +``` +{ + "consent-id": "6b3ad78c-2d4a-4575-8a9f-a69c2bfe0bd2", + "date": "2022-06-01T14:40:39+0000", + "data-subject":[{ + "dsid-schema": "email-sha-256", + "dsid":"7cac89a56bbf998c996f33e0b2d3bad578e05f3af8d64793c0bcac46b8c260dc" + }], + "scope": { + "data-categories":["CONTACT"], + "processing-categories": ["SHARING", "STORING"], + "purposes":["PERSONALISATION", "MARKETING", "ADVERTISING"] + } +} +``` + +Now this same Data Subject, makes a Privacy Request. In their request, they don't make a reference to the concrete `consent-id` but rather simply state that they no longer want their contact data processed in any way for marketing and advertising purposes. + +``` +{ + "request-id": "1a5c41f2-606f-4722-b852-4ba57cc9617c", + "date": "2022-06-02T12:50:00+0000", + "data-subject":[{ + "dsid-schema": "email-sha-256", + "dsid":"7cac89a56bbf998c996f33e0b2d3bad578e05f3af8d64793c0bcac46b8c260dc" + }], + "demands":[{ + "demand-id":"3173e329-ef64-4cb0-b87e-ba7d5d41fb8a", + "action":"REVOKE-CONSENT", + "restrictions":[{ + "data-categories":["CONTACT"], + "purposes":["MARKETING", "ADVERTISING"] + }] + }], +} +``` + +The [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) SHOULD resolve this request by: +- Generating a Privacy Request Response with the `GRANTED` Status, + +``` +{ + "response-id": "3b425097-3664-484c-95e1-015cbc126dff", + "in-response-to": "3173e329-ef64-4cb0-b87e-ba7d5d41fb8a", + "date": "2022-06-05T14:40:39+0000", + "status": "GRANTED" +} +``` + +- Amending the consent to restrict its scope. For this purpose a new consent (that overrides the existing one) is produced: + +``` +{ + "consent-id": "4ec28dc8-8714-45a3-a710-c72cea6e6da4", + "replaces": ["6b3ad78c-2d4a-4575-8a9f-a69c2bfe0bd2"], + "date": "2022-06-05T14:40:39+0000", + "data-subject":[{ + "dsid-schema": "email-sha-256", + "dsid":"7cac89a56bbf998c996f33e0b2d3bad578e05f3af8d64793c0bcac46b8c260dc" + }], + "scope": { + "data-categories":["CONTACT"], + "processing-categories": ["SHARING", "STORING"], + "purposes":["PERSONALISATION"] + } +} +``` +- Keep track of the changes to the original consent by adding metadata about change to it: + +``` +{ + "consent-id": "6b3ad78c-2d4a-4575-8a9f-a69c2bfe0bd2", + "replaced-by": ["4ec28dc8-8714-45a3-a710-c72cea6e6da4"], +} +``` +- Consider active the new consent: `4ec28dc8-8714-45a3-a710-c72cea6e6da4` + +The System MAY continue to use the Data Subjects' data for personalising their experience but no longer has consent to use the data for marketing and advertising. + +Let us now imagine the Data Subject making another Privacy Request, this time to object to any sharing of their e-mail address. For this, the following Privacy Request is made: + +``` +{ + "request-id": "fe54a89f-99f8-4a8c-bc14-830bfd99d651", + "date": "2022-06-07T16:20:00+0000", + "data-subject":[{ + "dsid-schema": "email-sha-256", + "dsid":"7cac89a56bbf998c996f33e0b2d3bad578e05f3af8d64793c0bcac46b8c260dc" + }], + "demands":[{ + "demand-id":"64fec4cc-e879-4624-a3d7-df0c170fc862", + "action":"OBJECT", + "restrictions":[{ + "data-categories":["CONTACT.EMAIL"], + "processing-categories": ["SHARING"], + }] + }], +} +``` +At the time of receiving this request, the System has consent for `STORING` and `SHARING` all `CONTACT` data for `PERSONALISATION` purposes. +When the System gets this request, the scope of the consent MUST change. The remaining scope of the consent will only include: +- `SHARING` of all `CONTACT` data other then `CONTACT.EMAIL`, for `PERSONALISATION` purposes, and +- `STORING` of all `CONTACT` for `PERSONALISATION` purposes + +The [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) SHOULD resolve this request by: +- Generating a Privacy Request Response with the `GRANTED` Status, + +``` +{ + "response-id": "12f77337-0e06-4619-bfb7-8759a6c5e95a", + "in-response-to": "64fec4cc-e879-4624-a3d7-df0c170fc862", + "date": "2022-06-15T11:30:00+0000", + "status": "GRANTED" +} +``` + +- Amending the consent to restrict its scope. For this purpose two new consents (that override the existing one) are produced: + +``` +{ + "consent-id": "6c8211c7-c152-4ef4-b264-098ee6533f75", + "replaces": ["4ec28dc8-8714-45a3-a710-c72cea6e6da4"], + "date": "2022-06-15T11:30:00+0000", + "data-subject":[{ + "dsid-schema": "email-sha-256", + "dsid":"7cac89a56bbf998c996f33e0b2d3bad578e05f3af8d64793c0bcac46b8c260dc" + }], + "scope": { + "data-categories":["CONTACT"], + "processing-categories": ["STORING"], + "purposes":["PERSONALISATION"] + } +} + +{ + "consent-id": "1f899305-235e-4fd4-b3c4-ff92dd67d769", + "replaces": ["4ec28dc8-8714-45a3-a710-c72cea6e6da4"], + "date": "2022-06-15T11:30:00+0000", + "data-subject":[{ + "dsid-schema": "email-sha-256", + "dsid":"7cac89a56bbf998c996f33e0b2d3bad578e05f3af8d64793c0bcac46b8c260dc" + }], + "scope": { + "data-categories":["CONTACT.ADDRESS", "CONTACT.PHONE"], + "processing-categories": ["SHARING"], + "purposes":["PERSONALISATION"] + } +} +``` +- Keep track of the changes to the amended consent by adding metadata about changes made to it: + +``` +{ + "consent-id": "4ec28dc8-8714-45a3-a710-c72cea6e6da4", + "replaced-by": ["6c8211c7-c152-4ef4-b264-098ee6533f75","1f899305-235e-4fd4-b3c4-ff92dd67d769"], +} +``` +- Consider active the new consents: `6c8211c7-c152-4ef4-b264-098ee6533f75`,`1f899305-235e-4fd4-b3c4-ff92dd67d769` + +> **Note** +> +> When making derived consents, limited to certain data categories the Privacy Compiler MUST take into account the complete list of [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) `selector`s that the Systems works with. + +Let us now imagine the Data Subject making another Privacy Request, this time to restrict data processing only to storing of their data. For this, the following Privacy Request is made: + +``` +{ + "request-id": "e848d0e0-41ab-492c-ae90-ca891b70abc1", + "date": "2022-06-17T15:10:00+0000", + "data-subject":[{ + "dsid-schema": "email-sha-256", + "dsid":"7cac89a56bbf998c996f33e0b2d3bad578e05f3af8d64793c0bcac46b8c260dc" + }], + "demands":[{ + "demand-id":"f3fb39df-9f25-44c9-8aaa-5ddac3833e6a", + "action":"RESTRICT", + "restrictions":[{ + "processing-categories": ["STORING"], + }] + }], +} +``` + +At the time of receiving this request, the System has consent for `STORING` of all `CONTACT` for `PERSONALISATION` purposes, and for `SHARING` of all `CONTACT` data other then `CONTACT.EMAIL`, for `PERSONALISATION` purposes. + +Afther processing the `RESTRICT` request, only the consent for `STORING` of all `CONTACT` for `PERSONALISATION` purposes remains valid. + +The [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) SHOULD resolve this request by: +- Generating a Privacy Request Response with the `GRANTED` Status, + +``` +{ + "response-id": "82d27b4d-44f5-484c-9656-2e41fc2d9bf3", + "in-response-to": "f3fb39df-9f25-44c9-8aaa-5ddac3833e6a", + "date": "2022-06-18T14:30:00+0000", + "status": "GRANTED" +} +``` +- Consider active the only the consent: `6c8211c7-c152-4ef4-b264-098ee6533f75` + +Finally, let us imagine the user now want to revoke the initial consent that they gave in the very beginning. +The system receives the following Privacy Request: + +``` +{ + "request-id": "e4585ec4-f566-45cd-9495-af622ff5e6fb", + "date": "2022-06-17T15:10:00+0000", + "data-subject":[{ + "dsid-schema": "email-sha-256", + "dsid":"7cac89a56bbf998c996f33e0b2d3bad578e05f3af8d64793c0bcac46b8c260dc" + }], + "demands":[{ + "demand-id":"90303838-f134-4387-a59c-032b7b993ee6", + "action":"REVOKE-CONSENT", + "restrictions":[{ + "consent-id": "6b3ad78c-2d4a-4575-8a9f-a69c2bfe0bd2", + }] + }], +} +``` +The System MUST no longer consider this Consent (nor any other consent derived from it) active. The list of active consents MUST now become empty, because the only active consent `6c8211c7-c152-4ef4-b264-098ee6533f75` is derived from `4ec28dc8-8714-45a3-a710-c72cea6e6da4` which is derived from +`6b3ad78c-2d4a-4575-8a9f-a69c2bfe0bd2` that the user now revokes. + +The System SHOULD be able to deliver a timeline of Consents, Requests and Responses, that may serve as a proof of compliance and good faith. + +> **Note** +> +> When Consent is used as one of legal bases for processing, it is not enough to only keep track of `RESTRICT` and `OBJECT` Privacy Requests to limit the eligible scope of data processing, but it is necessary to modify the Consents. This is due to the fact that Consents are not the only legal bases for data processing (i.e. Systems may have right to process data without consent). Different legal bases may evolve (be acquired and lost) independently. +> +>In other words, a `RESTRICT` Privacy Request may affect the scope of consent, but have no impact on actual processing being done. Another legal base for processing MAY make processing possible despite the `RESTRICT` request, yet the consent would still need to be amended in response to the `RESTRICT` Privacy Request. -### Alternatives Considered +## Alternatives Considered **TBD** From c9b17cf1040ae15c04a3946bceb91b8cc457227b Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 7 Jun 2022 15:12:22 +0200 Subject: [PATCH 101/204] Created Ethyca table template --- refs/schemas/priv/examples.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 3918cfe7..e07280fb 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -201,7 +201,13 @@ In the following examples we show how, requests introduced by different regulati | `1798.130.1.1` | Make available to consumers two or more designated methods for submitting requests for information, including, at a minimum, a toll-free telephone number. | `X` | `null` | `null` | `null` | `null` | `null` | | `1798.130.1.2` | Disclose and deliver the required information to a consumer free of charge within 45 days of receiving a verifiable consumer request from the consumer. | `X` | `null` | `null` | `null` | `null` | `null` | +### Ethyca data categories +> [Ethyca data categories reference](https://ethyca.github.io/fideslang/data_categories/) + +| Ethyca categories | Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | +| -------- | ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | +| **Account** Data related to an account on the system | **Account** | **Contact** | Contact data related to a system account | X | `null` | `null` | ### Requests list (**TO BE TRANSFORMED IN THE ABOVE FORMAT**) From 9ab2b32450c36a0c7b68b6ceb7baa6960e1a32ce Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 7 Jun 2022 15:35:40 +0200 Subject: [PATCH 102/204] Added Ethyca Account data cat and System data cat --- refs/schemas/priv/examples.md | 32 +++++++++++++++++++++++++++++--- 1 file changed, 29 insertions(+), 3 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index e07280fb..f42f5155 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -205,9 +205,35 @@ In the following examples we show how, requests introduced by different regulati > [Ethyca data categories reference](https://ethyca.github.io/fideslang/data_categories/) -| Ethyca categories | Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | -| -------- | ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | -| **Account** Data related to an account on the system | **Account** | **Contact** | Contact data related to a system account | X | `null` | `null` | +#### Account Data Categories +> Data related to an account on the system + +##### Account Contact Data + +| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | Comment | +| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | +| **account** | **Contact** | Contact data related to a system account | `CONTACT` | `null` | `null` | `null` | +| **account.contact** | **email** | Account's email address | `CONTACT.EMAIL` | `null` | `null` | `null` | +| **account.contact** | **phone_number** | Account's phone number | `CONTACT.PHONE` | `null` | `null` | `null` | +| **account.contact** | **City** | Account's city level address data | `CONTACT.ADDRESS` | `null` | `null` | Need more detail ? | +| **account.contact** | **Country** | Account's country level address data | `CONTACT.ADDRESS` | `null` | `null` | Need more detail ? | +| **account.contact** | **postal_code** | Account's postal code | `CONTACT.ADDRESS` | `null` | `null` | Need more detail ? | +| **account.contact** | **state** | Account's state level address data | `CONTACT.ADDRESS` | `null` | `null` | Need more detail ? | +| **account.contact** | **street** | Account's street level address | `CONTACT.ADDRESS` | `null` | `null` | Need more detail ? | + +##### Account Payment Data +| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | Comment | +| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | +| **account** | **payment** | Payment data related to system account | `FINANCIAL` | `null` | `null` | Broader definition ? | +| **account.payment** | **financial_account_number** | Payment data related to system account | `FINANCIAL.BANK-ACCOUNT` | `null` | `null` | `null` | + +#### System Data Categories +> Data unique to, and under control of the system. + +| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | Comment | +| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | +| **system** | **authentication** | Data used to manage access to the system | `**TBD**` | `null` | `null` | Add AUTHENTICATION ? (as a meta cat of biometric ?) | +| **system** | **operations** | Data used for system operations | `**Any/all**` | `**Any/all**` | `null` | Ok ? | ### Requests list (**TO BE TRANSFORMED IN THE ABOVE FORMAT**) From 1a6158f5d443cbd5586c107dca61499a42530847 Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 7 Jun 2022 15:55:40 +0200 Subject: [PATCH 103/204] finishing first draft of expected behavior --- refs/schemas/priv/RFC-PRIV.md | 36 +++-- refs/schemas/priv/expected-behavior.md | 211 +++++++++++++++++++++++-- 2 files changed, 216 insertions(+), 31 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 5d510633..02233271 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -20,7 +20,7 @@ This vocabulary corresponds to the [Data Privacy Request Schema](https://github. ## Motivation An individual is in connection with software Systems (and Organisations operating them) that process the individual's data. -In order to [regulate the relationship](https://github.com/blindnet-io/product-management/blob/10bebeefc14f7db7bf7a491932d62a4a5d18ad70/refs/notion-of-privacy/notion-of-privacy.md) with those Systems (and Organisations), the individual makes requests related to their privacy. +In order to [regulate the relationship](https://github.com/blindnet-io/product-management/blob/main/refs/notion-of-privacy/notion-of-privacy.md) with those Systems (and Organisations), the individual makes requests related to their privacy. With a Privacy Request the individual aims to gain a degree of transparency about data processing and a degree of control over the data and over the data processing. Allowing individuals to make Privacy Requests is becoming more and more a legal obligation. @@ -43,6 +43,12 @@ This document defines the version `1.0` of the Privacy Request Interchange Vocab ## Design Considerations +### Design Inspiration + +- **Smart data structures and dumb code works a lot better than the other way around.** lesson No 9 from Raymond, Eric Steven. "The Cathedral and the Bazaar". We want PRIF to embody a smart way of thinking about privacy, solving common challenges through the data structure itself. + +- **Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.** lesson No 12 from Raymond, Eric Steven. "The Cathedral and the Bazaar". We indeed now have novel understanding of the [problem of Privacy in Software Systems](https://github.com/blindnet-io/product-management/blob/main/refs/notion-of-privacy/notion-of-privacy.md). + ### Design Goals With this design we seek: @@ -135,6 +141,8 @@ A Demand MAY refer to only certain Privacy Scope (categories of data, certain ty When more than one restriction is specified, the System MUST interpret the Demand as referring to the intersection of restrictions. For example let us consider a `DELETE` demand having two restrictions: `LOCATION` `data-category` as Privacy Scope, and from 11th to 15th of June 2022 as Data Range. The System SHOULD understand that the Data Subject wants the System to delete only their location data processed in this precise period. +A demand with multiple restrictions MUST NOT have more than one restriction of the same type. + ###### Privacy Scope A Privacy Scope MAY be defined by three dimensions: Data Categories, Categories of Processing, and Purposes of Processing. @@ -273,7 +281,7 @@ Regardless of the [scenario (Responding to the Data Subject directly or to the S | `requested-action` | 0-1 | Optional information about the action that was demanded, and to which the response is made. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | | `data-subject` | 0-* | Optional indication of the [Data Subject Identities](#decentralized-identity-of-data-subjects) to which the response refers to | | `status` | 1 | One of {`GRANTED`, `DENIED`, `PARTIALLY-GRANTED`, `UNDER-REVIEW`} | -| `motive` | 0-* | Optionally one of {`IDENTITY-UNCONFIRMED`, `LANGUAGE-UNSUPPORTED`, `LEGAL-BASES`, `LEGAL-OBLIGATIONS`, `REQUEST-UNSUPPORTED`, `USER-UNKNOWN`} | +| `motive` | 0-* | Optionally one of {`IDENTITY-UNCONFIRMED`, `LANGUAGE-UNSUPPORTED`, `LEGAL-BASES`, `LEGAL-OBLIGATIONS`, `NO-SUCH-DATA`, `REQUEST-UNSUPPORTED`, `USER-UNKNOWN`} | | `answers` | 0-* | Any of the terms the meaning of which is defined by the present format and its dictionaries or an object representing a Legal Base, a Retention Policy | | `message` | 0-1 | Optional string comment, motivation or explanation of Demand | | `lang` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | @@ -340,15 +348,6 @@ Processing MAY be legitimate according to several legal bases for treatment. For Certain processing is made legitimate (`LEGITIMATE-INTEREST`) or mandatory (`NECESSARY`) by law, e.g. [Article 6 og GDPR](https://gdpr-info.eu/art-6-gdpr/). -##### Retention Policy -| Property | Expected cardinality | Expected values | -| --------------- | ------ | -------------------- | -| `policy-type` | 1 | one of {NO-LONGER-THAN, "NO-LESS-THAN"} | -| `duration` | 1 | Duration in JSON Schema [duration](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| `after` | 1 | Event to which the retention duration is relative to. One of {`DATA-COLLECTION`,`RELATIONSHIP-END`} - -If more than one Retention Policy is specified, then they are interpreted as a union. Data is kept, as long as the conditions of at least one of them are met. - ## Detailed Design A separate document gives a list of [examples](examples.md) on how to represent real-life Privacy Requests, as defined in [supported legislation](#supported-legislation), or as modelled in existing systems with which we seek interoperability. @@ -448,6 +447,8 @@ Systems MAY specify the vocabulary used to express data being exchanged. The val This vocabulary can be extended by defining a new identifier for the new vocabulary. New vocabularies MAY include other vocabularies as long as their sets of concepts, properties and terms are disjoint. +In addition, the Systems implementing PRIV can simply define their own subcategories of terms (not properties not concepts) defined by PRIV. This might be useful for their own internal operation, however the interoperability with other system can only be expected at the level of the particular, shared, version of the vocabulary. + ## Examples A [JSON schema of the PRIV](./priv.schema.json) is provided for convenience. To illustrate a request, let us take the example of a data subject wanting to know if a an organisation (and any of its partners if applicable) have any data on them, and if so, have their contact data deleted. @@ -672,6 +673,12 @@ There is an ISO standard for data categories and processing categories. They are However, we might want to allow developers to use our format (properties and concepts) with ISO 19944 categories instead of our terms. +## See also + +This document comes with the following support documents: +- [Examples of use](./examples.md) +- [Expected Behavior of Implementing Systems](./expected-behavior.md) + ## References ### Normative References @@ -679,9 +686,6 @@ However, we might want to allow developers to use our format (properties and con - **[RFC8259]** Bray, T., ["The JavaScript Object Notation (JSON) Data Interchange Format"](https://datatracker.ietf.org/doc/html/rfc8259), STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. - **[RFC2119]** Bradner, S., ["Key words for use in RFCs to Indicate Requirement Levels"](https://datatracker.ietf.org/doc/html/rfc2119), BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, -### Informative References - -- ### Initiative with which PRIV seeks to be compatible @@ -696,5 +700,5 @@ However, we might want to allow developers to use our format (properties and con ### Yet to be Supported Legislation -- [CPRA]([https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://vig.cdn.sos.ca.gov/2020/general/pdf/topl-prop24.pdf)) -- [HIPPA]([https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5](https://www.govinfo.gov/content/pkg/PLAW-104publ191/pdf/PLAW-104publ191.pdf)) +- CPRA +- HIPPA diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 365e26b1..1d7551da 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -8,19 +8,21 @@ ## Introduction -This document specifies the expected behaviour of Systems implementing [Privacy Request Interchange Vocabulary](./RFC-PRIV.md). It defines actions that the systems SHOULD undertake with regards to particular Privacy Requests and particular situations. +This document specifies the expected behaviour of Systems implementing [Privacy Request Interchange Vocabulary](./RFC-PRIV.md). It defines actions that the systems MAY undertake with regards to particular Privacy Requests and particular situations. It is a first step towards the specification of the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler), formerly known as Data Rights Compiler in the [High Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). ## Motivation -**TBD** +While this document is a first step in the definition of the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler), it is not intended to be its formal specification nor to influence the design choices related to formalisation of rules and configurations. + +The purpose of the document is primarily illustrate a possible behaviour Systems (And their Privacy Compilers) MAY implement in response to Privacy Requests, in order to test the completeness of the [Privacy Request Interchange Vocabulary](./RFC-PRIV.md). ## Terminology ->**TBD** +- We use all the terms of the [Privacy Request Interchange Vocabulary](./RFC-PRIV.md) as defined there - We use the term Privacy Request interchangeably with the (deprecated) terms Rights Request and Data Rights Request as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) - We use the terms Individual, Person, You, and Data Subject as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) - We use the term System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) @@ -41,25 +43,66 @@ Systems MAY be configured to treat Privacy Requests eligible for automation with A [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) serving a particular system MUST have the knowledge of: - The exhaustive list of [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) `selector`s that the System works with, - For each `selector` (or Data Category implying every `selector` used within that Data Category) a data [Retention Policy](./RFC-PRIV.md#retention-policy), -- A set of Privacy Scope triples that describe the usage the System is likely to make with data. Each triple consists of: +- **Intended Privacy Scope**: A set of **Privacy Scope Triple**s that describe the usage the System is likely to make with data. Each triple consists of: - a `selector` (or Data Category implying every `selector` used within that Data Category) - a Processing Category that the System is likely to perform on that data - a Purpose - For each Privacy Scope triple, one or more [Legal Bases](./RFC-PRIV.md#legal-bases). + Legal Bases live a life of their own, regardless of the presence or absence of data, so Privacy Compilers MUST at all times, keep track of: - All Legal Bases - Active Legal Bases, which consist of: - active Consents, a list that is modified when Consent is collected and within [Operations over consents](#operations-over-consents), - - other Legal Bases that have their validity conditions met at the given time + - other Legal Bases that have their validity conditions met at the given time. + - For `CONTRACT` - Contracts/Services being provided, they constitute an active Legal base for as long as the user has not closed the account/ended commercial relationship `RELATIONSHIP-END` + - When `LEGITIMATE-INTEREST` is used, it is active from the moment of data collection and for as long as the Data Subject has not made a `DELETE`, `OBJECT`, or `RESTRICT` Privacy Request + +To keep track of active Legal Bases (but also in order to apply [Retention Policies](./RFC-PRIV.md#retention-policy) the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) MUST be able to register events related to the relationship with the data subject and save, for each Data Subject identity: +- One or more relationship IDs (e.g., this may be an ID of a user account on an e-commerce website, or an ID of a particular contract like a legal file for a lawfirm.), each having an activity status indicating if the relationship is ongoing or has been ended. + +The Privacy Compiler MUST also keep track of every Privacy Request made to the System. In addition, in order to resolve `TRANSPARENCY` requests, a Privacy Compiler MUST also know a set of parameters defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV). ## Privacy Algebra +For each Data Capture Fragment, at all times, the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) maintains an **Eligible Privacy Scope**. + +For each Data Capture Fragment `selector`, the Privacy Compiler knows the **Intended Privacy Scope**. +At the same time the Privacy Compiler knows about a set of Privacy Scope triples that are associated with an active Legal Base. + +The **Eligible Privacy Scope**, is a set of Privacy Scope triples, that is the INTERSECTION of: +- set of Privacy Scope triples in the **Intended Privacy Scope**, +- AND the set of Privacy Scope triples for which at least one of the following statements is true: + - They are associated with `CONSENT` legal base, and there is an active Consent such that the Privacy Scope triple is contained in the Privacy Scope of that Consent + - They are associated with `CONTRACT` legal base, and there is an active relationship with the Data Subject in question for which no `RELATIONSHIP-END` event has been registered + - They are associated with `LEGITIMATE-INTEREST` legal base, and + - IF the Data Subject made any `OBJECT` Demand, they are not part of Privacy Scope of any such Demand + - IF the Data Subject made any `RESTRICT` Demand, they are a part of the intersection of Privacy Scopes of all such Demands + - They are associated with `NECESSARY` legal base + +The Privacy Compilers can be configured to evaluate Eligible Privacy Scopes in the context of particular regulations. +In this case, Privacy Compilers maintain a list of Privacy Scope triples prohibited by that regulation and they exclude them from the Eligible Privacy Scope. +E.g. under GDPR, it is prohibited to process gender and genetic data under any Legal Base other than Consent. + +For convenience, Privacy Compilers MAY also keep track of a set of **Prohibited (Privacy Scope)-(Legal Base) Pairs**, in which they SHOULD include Privacy Scope triples made illegal by the legislation that they want to support. It might also be convenient, when Data Subject's `OBJECT` or `RESTRICT` Demands are granted over a particular Privacy Scope, to list that scope under `LEGITIMATE-INTEREST` in the **Prohibited (Privacy Scope)-(Legal Base) Pairs** for making sure not to re-include them in the **Eligible Privacy Scope** unless the user gives explicit consent, signs a contract or becomes subject to mandatory data keeping. + +> E.g. under GDPR, as processing of RACE data is only allowed under 'CONSENT' for medical research purposes, examples of **Prohibited (Privacy Scope)-(Legal Base) Pairs** include +> +> (`data-category`=`DEMOGRAPHIC.RACE`, `purpose`=`ADVERTISING`) - CONSENT +> +> (`data-category`=`DEMOGRAPHIC.RACE`) - CONTRACT +> +> (`data-category`=`DEMOGRAPHIC.RACE`) - LEGITIMATE-INTEREST + +The **Eligible Privacy Scope** is recalculated with every Data Capture, or whenever a Privacy Request Demand (other than `ACCESS` and `TRANSPARENCY`) is granted. + +Yet, the **Eligible Privacy Scope** is independent to Retention Policy. A particular Data Capture Fragment MAY be associated with a non-empty Eligible Privacy Scope yet [be evaluated as expired under its Retention Policy](#resolving-retention-policies) and as such may need to be deleted anyway. + ### Set Operations over Privacy Scope -#### Operations over consents +#### Operations over consents The scope of Consents can be modified by Privacy Request that include `OBJECT`, `RESTRICT`, and `REVOKE-CONSENT` actions. @@ -302,16 +345,157 @@ The System SHOULD be able to deliver a timeline of Consents, Requests and Respon > >In other words, a `RESTRICT` Privacy Request may affect the scope of consent, but have no impact on actual processing being done. Another legal base for processing MAY make processing possible despite the `RESTRICT` request, yet the consent would still need to be amended in response to the `RESTRICT` Privacy Request. +### Updating the Eligible Privacy Scope upon `OBJECT` and `RESTRICT` Privacy Request Demands + +Gained and lost consent modify the Eligible Privacy Scope. +Also, as [we have seen](#updateConsent), `OBJECT` and `RESTRICT` Privacy Request Demands SHOULD affect the scope of existing consents. +In addition, when such Demands are received, the Eligible Privacy Scope SHOULD be recalculated. -## Alternatives Considered +However, it is important to note that the `OBJECT` and `RESTRICT` Privacy Request Demands behave in very specific ways. Concretely: +- They don't affect Privacy Scope Triples that are included in the Eligible Privacy Scope under `CONTRACT` or `NECESSARY` legal bases, -**TBD** +- with regards to Consents, they affect only existing Consents, not the future ones. + - Let us imagine for example that the Data Subject gave consent for processing of their data for any purpose. + - Then later, the Data Subject makes an `OBJECT` Demand related to `SALE` purposes. + At this point all Privacy Scope Triples having `SALE` as purpose exit the Eligible Privacy Scope. + - This same Data Subject MAY again give consent for processing of their data for any purpose in which case the Privacy Scope Triples having `SALE` as purpose re-enter the Eligible Privacy Scope. +- with regards to Privacy Scope Triples that are integrated in the Eligible Privacy Scope under `LEGITIMATE-INTEREST`, once `OBJECT` or `RESTRICT` Demands are made, they affect present and future Eligible Privacy Scope. In other words, the Privacy Scope Triples that have exited the Eligible Privacy Scope due to `OBJECT` or `RESTRICT` Demands, can't re-enter Eligible Privacy Scope under `LEGITIMATE-INTEREST`. When several `OBJECT` or `RESTRICT` Demands are made over time, a particular Privacy Scope Triple that entered the Eligible Privacy Scope under `LEGITIMATE-INTEREST`, can remain in the Eligible Privacy Scope if and only if: + - It is not a part of union of Privacy Scopes of all `OBJECT` Demands, AND if + - It is a part of the intersection of Privacy Scopes of all `RESTRICT` Demands -## Questions and Discussion Topics +Let us take an example to illustrate updating of Eligible Privacy Scope. At the beginning the System holds the Data Subjects e-mail address for prospecting purposes, under `LEGITIMATE-INTEREST` Legal Base. +``` +Eligible Privacy Scope: +CONTACT.EMAIL x ALL x MARKETING (LEGITIMATE-INTEREST) +``` -**TBD** +The Data Subject, after receiving a marketing e-mail, decides to open an account and start using the service. They provide their postal address for billing. While creating an account, they also give consent for their postal address to be used for advertising purposes. + +``` +Eligible Privacy Scope: +CONTACT.EMAIL x ALL x MARKETING (LEGITIMATE-INTEREST) +CONTACT.EMAIL x ALL x SERVICES (CONTRACT) +CONTACT.ADDRESS x ALL x SERVICES (CONTRACT) +CONTACT.ADDRESS x ALL x ADVERTISING (CONSENT) +``` +The Data Subject realises that they are receiving too much advertising material and they formulate a Privacy Request with one `REVOKE-CONSENT` demand targeting particular consent that they gave. + +``` +Eligible Privacy Scope: +CONTACT.EMAIL x ALL x MARKETING (LEGITIMATE-INTEREST) +CONTACT.EMAIL x ALL x SERVICES (CONTRACT) +CONTACT.ADDRESS x ALL x SERVICES (CONTRACT) +``` + +The Data Subject realises that they are still receiving maketing e-mail and they formulate a Privacy Request with one `OBJECT` demand with `CONTACT.EMAIL` being defined as its Privacy Scope. Yet, this Demand only affects the Privacy Scope Triples held under `LEGITIMATE-INTEREST`. The System can still, continue to keep the `CONTACT.EMAIL` and `CONTACT.ADDRESS` for the same of the ongoing contractual relationship with the user. + +``` +Eligible Privacy Scope: +CONTACT.EMAIL x ALL x SERVICES (CONTRACT) +CONTACT.ADDRESS x ALL x SERVICES (CONTRACT) +``` +However, the remaining purpose (`SERVICES`) now only allows the System to send e-mail related to the services being provided, and no longer supports sending marketing e-mail to this Data Subject. + +### Calculating Permissions + +Since the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) maintains the Eligible Privacy Scope at any time, it can (given a Data Capture ID, or a Data Capture Fragment ID) answer whether at that time, a particular data processing operation is permitted. + +For example, the System can inquire whether a particular data fragment, corresponding to `CONTACT.EMAIL` data category, can be used to invoice the user (processing = `USING`; purpose = `SERVICES`), or whether it can be shared with some other partner system for user profiling (processing = `SHARING`; purpose = `AUTOMATED-INFERENCE`). + + +## Resolving requests + +The [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) evaluates Privacy Request Demands and issues recommendations to the System. The Systems can then be configured to respond to Privacy Requests automatically, blindly following those recommendations (whenever possible), or to await human input just in case. + +Here is how the Privacy Request Response recommendations are calculated: + +When no Data Subject ID is provided in the Privacy Request: +- `TRANSPARENCY` Demands: recommend status = `GRANTED`. Provide requested information: Data Categories, Processing Categories, Purposes, and Legal Bases from Intended Privacy Scope, as well as other ifnromation from general settings as defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV). +- `OTHER` Demands: recommend human review and status = `UNDER-REVIEW` +- For any other action : recommend status = `DENIED`, motive=`IDENTITY-UNCONFIRMED` + +When Data Subject ID is provided, Data Subject is authenticated but is unknown by the System: +- `OTHER` Demands: recommend human review and status = `UNDER-REVIEW` +- For any other action : recommend status = `DENIED`, motive=`USER-UNKNOWN` + +When Data Subject ID is provided, the Data Subject is known by the System but filed to authenticate: +- `OTHER` Demands: recommend human review and status = `UNDER-REVIEW` +- `TRANSPARENCY.KNOWN` Demands: recommend status = `GRANTED`, and data = `NO`. +- For any other action : recommend status = `DENIED`, motive=`IDENTITY-UNCONFIRMED` + +When Data Subject ID is provided, the Data Subject is known by the System and authenticated: +- Regardless of restrictions + - `OTHER` Demands: recommend human review and status = `UNDER-REVIEW` + - `TRANSPARENCY.KNOWN` Demands: recommend status = `GRANTED`, and data = `YES`. + - `TRANSPARENCY.DATA-CATEGORIES` Demands: recommend status = `GRANTED`, and data = list of Data Categories that are included in any of the Privacy Scope Triples included in the Eligible Privacy Scope. + - `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.DPO`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO` Demands: recommend status = `GRANTED`, and data = information corresponding to the request taken from configuration settings as defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV). + +- With regards to Demand restrictions (if any) limiting the scope of the Demand + - `TRANSPARENCY.LEGAL-BASES` Demands: recommend status = `GRANTED`, and data = list of Legal Bases under which any of the Privacy Scope Triples are included in the Eligible Privacy Scope (or its intersection with the Privacy Scope of the Demand if restricted). + - `TRANSPARENCY.PROCESSING-CATEGORIES` Demands: recommend status = `GRANTED`, and data = list of Processing Categories that are included in any of the Privacy Scope Triples included in the Eligible Privacy Scope (or its intersection with the Privacy Scope of the Demand if restricted). + - `TRANSPARENCY.PURPOSE` Demands: recommend status = `GRANTED`, and data = list of Purposes that are included in any of the Privacy Scope Triples included in the Eligible Privacy Scope (or its intersection with the Privacy Scope of the Demand if restricted). + - `REVOKE-CONSENT` Demands: + - If restricted to concrete consent IDs, recommend status = `GRANTED` and recalculate Eligible Privacy Scope to drop any Privacy Scope Triples that have been included as a result of Consents being revoked. + - If Demand is restricted by a Privacy Scope, recommend status = `GRANTED` and [update consents](#updateConsent) + - If no Restriction is given in the Demand, revoke all consents given by this Data Subject + - If only a Data Range restriction is present, recommend status = `GRANTED` and revoke all consents that have been collected in the given Data Range + - If only a Data Capture Restriction is present, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` + - If several restrictions of the same type are present, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` + - If more restrictions (other than Data Capture Restriction) are present, interpret them as an intersection i.e. take only the consents collected within the from-to dates of the Data Range Restriction, then do an intersection of their Privacy Scopes with the scope of the Privacy Scope restriction. The resulting Privacy Scope can be used as if there were only one Privacy Scope demand. Recommend status = `GRANTED` and [update consents](#updateConsent) + - `OBJECT`, `RESTRICT` Demands: + - Recommend status = `GRANTED`, and then, upon granting [update consents](#updateConsent), [recalculate Eligible Privacy Scope](#updateScope) + - Recommend deletion of Data Capture Fragments the categories of which are not longer included in the Eligible Privacy Scope. + - `DELETE` Demands: + - If restricted to concrete consent IDs, , recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` + - If restricted to a privacy scope having a `processing-category` or a `purpose`, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` (A Delete request can only be relative to a category of data, not to a category of processing or a particular purpose.) + - If restricted to a clearly identifiable data scope (such a Privacy Scope with a `processing-category`, or a concrete Data Capture Fragment `selector`, or to a Data Capture Fragment ID (or set of IDs), potentially limited to a Data Range): + - if data corresponding to that scope does not exist, recommend status = `DENIED`, motive = `NO-SUCH-DATA` + - if data corresponding to that scope does exist, AND: + - the data is associated with Privacy Scope Triples that are introduced in the Eligible Privacy Scope under at least one Legal Base other than {`LEGITIMATE-INTEREST`, `CONSENT`}, recommend status = `ACCEPT` + - the data is associated with Privacy Scope Triples that are introduced in the Eligible Privacy Scope under Legal Bases all of which belong to {`LEGITIMATE-INTEREST`, `CONSENT`}, recommend status = `DENIED`, and one or more motive = `LEGAL-BASES` when data is included in the Eligible Privacy Scope under `CONTRACT`, and `LEGAL-OBLIGATIONS` when data is included in the Eligible Privacy Scope under `NECESSARY` + + - `MODIFY` Demands: + - If restricted to concrete consent IDs, , recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` + - If restricted to a privacy scope having a `processing-category` or a `purpose`, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` (A Delete request can only be relative to a category of data, not to a category of processing or a particular purpose.) + - If restricted to a clearly identifiable data scope (such a Privacy Scope with a `processing-category`, or a concrete Data Capture Fragment `selector`, or to a Data Capture Fragment ID (or set of IDs), potentially limited to a Data Range): + - if data corresponding to that scope is not being collected by the System as is not part of the Intended Privacy Scope, status = `DENIED`, motive = `NO-SUCH-DATA` + - if data corresponding to that scope is not being collected by the System (regardless of data being already collected or empty): + - Recommend status = `ACCEPT` (potentially upon human validation) + + - `ACCESS` Demands: + - Recommend status = `ACCEPT`, and data = data corresponding to the Privacy Scope of the Demand (NB. contrary to MODIFY and DELETE, the Data Subject SHOULD be able to request access to data being used for particular `purpose` or being subject to particular `processing-category`) + + - `PORTABILITY` Demands: + - Recommend status = `ACCEPT`, and data = data corresponding to the Privacy Scope of the Demand + + +## Resolving Retention Policies + +[Privacy Compilers](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) SHOULD store and resolve Retention Policies. + +| Property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `data-category` | 1-* | Any of the any Data Category terms or concrete Data Capture Fragment `selector`s within those categories | +| `policy-type` | 1 | one of {NO-LONGER-THAN, "NO-LESS-THAN"} | +| `duration` | 1 | Duration in JSON Schema [duration](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `after` | 1 | Event to which the retention duration is relative to. One of {`DATA-COLLECTION`,`RELATIONSHIP-END`} + +When several `data-category` values are given, they are interpreted as a union. + +Systems SHOULD define Retention Policies at the time of configuration, and SHOULD cover all Data Categories and Data Capture Fragment `selector`s from the Intended Privacy Scope with at least one Retention Policy. + +Retention Policies are resolved upon concrete instances of data. A particular instance of data, given the Data Capture Fragment `selector` to which it corresponds, is considered `EXPIRED` if all of the following is true: +- There is a Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular data, that is of type `NO-LONGER-THAN`, such that the date of the event defined under `after` has passed for a more then the time defined under `duration` +- AND There is no Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular data, that is of type `NO-LESS-THAN`, such that the event defined under `after` is yet to happen or has happened before a period of time inferior to `duration` + +Privacy Compilers SHOULD be able to: +- provide lists of active policies, in the context of answering to the `TRANSPARENCY.RETENTION` requests +- resolve policies and generate `EXPIRED` alerts, upon which the Systems MAY chose to implement automatic data deletion, or other protocols for data archiving or similar +- resolve policies for Systems configured not to automatically delete data, but to automatically grant `DELETE` requests only when data is `EXPIRED` + +Optionally, for systems wanting to automatically deni `DELETE` requests when data MUST be kept, Privacy Compilers MAY be able deliver resolve policies giving `HOLD` status, when there is at least one Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular data, that is of type `NO-LESS-THAN`, such that the event defined under `after` is yet to happen or has happened before a period of time inferior to `duration`. ## References @@ -319,9 +503,6 @@ The System SHOULD be able to deliver a timeline of Consents, Requests and Respon - **[RFC8259]** Bray, T., ["The JavaScript Object Notation (JSON) Data Interchange Format"](https://datatracker.ietf.org/doc/html/rfc8259), STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. -### Informative References - -- ### Supported Legislation @@ -330,5 +511,5 @@ The System SHOULD be able to deliver a timeline of Consents, Requests and Respon ### Yet to be Supported Legilsation -- [CPRA]([https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://vig.cdn.sos.ca.gov/2020/general/pdf/topl-prop24.pdf)) -- [HIPPA]([https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5](https://www.govinfo.gov/content/pkg/PLAW-104publ191/pdf/PLAW-104publ191.pdf)) +- CPRA +- HIPPA From df7c171d5304cc59f7e5d3ddd5f8c85d0a400185 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 7 Jun 2022 16:08:53 +0200 Subject: [PATCH 104/204] Added User derived data cat --- refs/schemas/priv/examples.md | 55 ++++++++++++++++++++++++++++++----- 1 file changed, 47 insertions(+), 8 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index f42f5155..b0f32cab 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -210,31 +210,70 @@ In the following examples we show how, requests introduced by different regulati ##### Account Contact Data -| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | Comment | +| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment | | ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | | **account** | **Contact** | Contact data related to a system account | `CONTACT` | `null` | `null` | `null` | | **account.contact** | **email** | Account's email address | `CONTACT.EMAIL` | `null` | `null` | `null` | | **account.contact** | **phone_number** | Account's phone number | `CONTACT.PHONE` | `null` | `null` | `null` | -| **account.contact** | **City** | Account's city level address data | `CONTACT.ADDRESS` | `null` | `null` | Need more detail ? | -| **account.contact** | **Country** | Account's country level address data | `CONTACT.ADDRESS` | `null` | `null` | Need more detail ? | +| **account.contact** | **City** | Account's city level address data | `CONTACT.ADDRESS` | `null` | `null` | Need a more detailed cat ? | +| **account.contact** | **Country** | Account's country level address data | `CONTACT.ADDRESS` | `null` | `null` | Need a more detailed cat ? | | **account.contact** | **postal_code** | Account's postal code | `CONTACT.ADDRESS` | `null` | `null` | Need more detail ? | -| **account.contact** | **state** | Account's state level address data | `CONTACT.ADDRESS` | `null` | `null` | Need more detail ? | -| **account.contact** | **street** | Account's street level address | `CONTACT.ADDRESS` | `null` | `null` | Need more detail ? | +| **account.contact** | **state** | Account's state level address data | `CONTACT.ADDRESS` | `null` | `null` | Need a more detailed cat ? | +| **account.contact** | **street** | Account's street level address | `CONTACT.ADDRESS` | `null` | `null` | Need a more detailed cat ? | ##### Account Payment Data -| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | Comment | +| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | | ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | | **account** | **payment** | Payment data related to system account | `FINANCIAL` | `null` | `null` | Broader definition ? | | **account.payment** | **financial_account_number** | Payment data related to system account | `FINANCIAL.BANK-ACCOUNT` | `null` | `null` | `null` | #### System Data Categories -> Data unique to, and under control of the system. +> Data unique to, and under control of the system -| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | Comment | +| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | | ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | | **system** | **authentication** | Data used to manage access to the system | `**TBD**` | `null` | `null` | Add AUTHENTICATION ? (as a meta cat of biometric ?) | | **system** | **operations** | Data used for system operations | `**Any/all**` | `**Any/all**` | `null` | Ok ? | +#### User Data Categories +> Data related to the user of the system +> The "User" data category has two important subcategories for derived and provided data +> In turn, derived and provided both have subcategories for identifiable and nonidentifiable data, to make it clear what data is considered identifiable in your systems + +##### User Derived Data +> Data derived from user provided data or as a result of user actions in the system + +| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | +| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | +| **user.derived** | **identifiable** | Derived data that is linked to, or identifies a user | `**TBD**` | `null` | `null` | TBD, isn't it all the data for us ? | +| **user.derived.identifable** | **biometric_health** | Encoded characteristic collected about a user | `BIOMETRIC`,`HEALTH` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **browsing_history** | Content browsing history of a user | `BEHAVIOR` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **contact** | Contact data collected about a user | `CONTACT` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **demographic** | Demographic data about a user | `DEMOGRAPHIC` | `null` | `null` | `null` | +| **user.derived.identifable** | **gender** | Gender of an individual | `DEMOGRAPHIC.GENDER` | `null` | `null` | `null` | +| **user.derived.identifable** | **location** | Records of the location of a user | `LOCATION` | `null` | `null` | `null` | +| **user.derived.identifable** | **media_consumption** | Media type consumption data of a user | `BEHAVIOR` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **non_specific_age** | Age range data | `DEMOGRAPHIC.AGE` | `null` | `null` | `null` | +| **user.derived.identifable** | **observed** | Data collected through observation of use of the system | `BEHAVIOR` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **organization** | Derived data that is linked to, or identifies an organization | `AFFILIATION` | `null` | `null` | OK ? Or here does Ethyca means user = organisation ? | +| **user.derived.identifable** | **profiling** | Preference and interest data about a user | `BEHAVIOR.PREFERENCE` | `null` | `null` | /!\ not same meaning for our profiling cat | +| **user.derived.identifable** | **race** | Racial or ethnic origin data | `DEMOGRAPHIC.RACE` | `null` | `null` | `null` | +| **user.derived.identifable** | **religious_belief** | Religion or religious belief | `DEMOGRAPHIC.BELIEFS` | `null` | `null` | `null` | +| **user.derived.identifable** | **search_history** | Records of search history and queries of a user | `BEHAVIOR` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **sexual_orientation** | Personal sex life or sexual data | `DEMOGRAPHIC` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **social** | Social activity and interaction data | `BEHAVIOR` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **telemetry** | User identifiable measurement data from system sensors and monitoring | `BEHAVIOR`,`OTHER` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **unique_id** | Unique identifier for a user assigned through system use | `UID` | `null` | `null` | `null` | +| **user.derived.identifable** | **user_sensor** | Measurement data derived about a user's environment through system use | `BEHAVIOR`,`OTHER` | `null` | `null` | `null` | +| **user.derived.identifable** | **workplace** | Organization of employment | `AFFILIATION` | `null` | `null` | `null` | +| **user.derived.identifable** | **device** | Data related to a user's device, configuration and setting | `DEVICE` | `null` | `null` | `null` | +| **user.derived.identifable** | **cookie_id** | Cookie unique identification number | `BEHAVIOR` | `null` | `null` | Need a more detailed cat ? | +| **user.derived.identifable** | **device_id** | Device unique identification number | `DEVICE` | `null` | `null` | Need a more detailed cat ? | +| **user.derived.identifable** | **ip_address** | Unique identifier related to device connection | `DEVICE` | `null` | `null` | Need a more detailed cat ? | +| **user.derived** | **nonidentifiable** | Non-user identifiable data derived related to a user as a result of user actions in the system | `**TBD**` | `null` | `null` | TBD, do we need that ? | +| **user.derived.nonidentifiable** | **nonsensor** | Non-user identifiable measurement data derived from sensors and monitoring systems | `**TBD**` | `null` | `null` | TBD, do we need that ? | + + ### Requests list (**TO BE TRANSFORMED IN THE ABOVE FORMAT**) | Nb | Request | Description | Associated treatment | Associated data category | Advised elements to provide | Legal ground | CNIL reference From 7ba09ccaa5355799d4de875d38f3d8d17e8b3aec Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 7 Jun 2022 16:43:35 +0200 Subject: [PATCH 105/204] Added User Provided data cat (until "credentials") --- refs/schemas/priv/examples.md | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index b0f32cab..ea61bfb7 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -260,7 +260,7 @@ In the following examples we show how, requests introduced by different regulati | **user.derived.identifable** | **race** | Racial or ethnic origin data | `DEMOGRAPHIC.RACE` | `null` | `null` | `null` | | **user.derived.identifable** | **religious_belief** | Religion or religious belief | `DEMOGRAPHIC.BELIEFS` | `null` | `null` | `null` | | **user.derived.identifable** | **search_history** | Records of search history and queries of a user | `BEHAVIOR` | `null` | `null` | Ok ? | -| **user.derived.identifable** | **sexual_orientation** | Personal sex life or sexual data | `DEMOGRAPHIC` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **sexual_orientation** | Personal sex life or sexual data | `DEMOGRAPHIC` | `null` | `null` | Ok ? Need a more detailed cat ? | | **user.derived.identifable** | **social** | Social activity and interaction data | `BEHAVIOR` | `null` | `null` | Ok ? | | **user.derived.identifable** | **telemetry** | User identifiable measurement data from system sensors and monitoring | `BEHAVIOR`,`OTHER` | `null` | `null` | Ok ? | | **user.derived.identifable** | **unique_id** | Unique identifier for a user assigned through system use | `UID` | `null` | `null` | `null` | @@ -273,6 +273,37 @@ In the following examples we show how, requests introduced by different regulati | **user.derived** | **nonidentifiable** | Non-user identifiable data derived related to a user as a result of user actions in the system | `**TBD**` | `null` | `null` | TBD, do we need that ? | | **user.derived.nonidentifiable** | **nonsensor** | Non-user identifiable measurement data derived from sensors and monitoring systems | `**TBD**` | `null` | `null` | TBD, do we need that ? | +##### User Provided Data +> Data provided or created directly by a user of the system + +| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | +| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | +| **user.provided** | **identifiable** | Data provided or created directly by a user that is linked to or identifies a user | `**TBD**` | `null` | `null` | TBD, isn't it all the data for us ? | +| **user.provided.identifiable** | **identifiable** | Encoded characteristics provided by a user | `BIOMETRIC` | `null` | `null` | `null` | +| **user.provided.identifiable** | **children** | Data relating to children | `OTHER`,`RELATIONSHIP` | `null` | `null` | Ok ? Need a more detailed cat ? | +| **user.provided.identifiable** | **health_and_medical** | Health records or individual's personal medical information | `HEALTH` | `null` | `null` | `null` | +| **user.provided.identifiable** | **job_title** | Professional data | `OTHER` | `null` | `null` | Ok ? | +| **user.provided.identifiable** | **name** | User's real name | `NAME` | `null` | `null` | Ok ? Need a more detailed cat ? (our cat includes nicknames and other names) | +| **user.provided.identifiable** | **non_specific_age** | Age range data | `DEMOGRAPHIC.AGE` | `null` | `null` | `null` | +| **user.provided.identifiable** | **political_opinion** | Data related to the individual's political opinions | `DEMOGRAPHIC.BELIEFS` | `null` | `null` | `null` | +| **user.provided.identifiable** | **race** | Racial or ethnic origin data | `DEMOGRAPHIC.RACE` | `null` | `null` | `null` | +| **user.provided.identifiable** | **religious_belief** | Religion or religious belief | `DEMOGRAPHIC.BELIEFS` | `null` | `null` | `null` | +| **user.provided.identifiable** | **sexual_orientation** | Personal sex life or sexual data | `DEMOGRAPHIC` | `null` | `null` | Ok ? Need a more detailed cat ? | +| **user.provided.identifiable** | **workplace** | Organization of employment | `AFFILIATION` | `null` | `null` | `null` | +| **user.provided.identifiable** | **date_of_birth** | User's date of birth | `OTHER` | `null` | `null` | Ok ? Need a more detailed cat ? | +| **user.provided.identifiable** | **gender** | Gender of an individual | `DEMOGRAPHIC.GENDER` | `null` | `null` | `null` | +| **user.provided.identifiable** | **genetic** | Data about the genetic makeup provided by a user | `OTHER` | `null` | `null` | Ok ? Need a more detailed cat ? | +| **user.provided.identifiable** | **contact** | User provided contact data for purposes other than account management | `CONTACT` | `null` | `null` | `null` | +| **user.provided.identifiable** | **city** | User's city level address data | `CONTACT.ADDRESS` | `null` | `null` | Ok ? Need a more detailed cat ? | +| **user.provided.identifiable** | **country** | User's country level address data | `CONTACT.ADDRESS` | `null` | `null` | Ok ? Need a more detailed cat ? | +| **user.provided.identifiable** | **email** | User's provided email address | `CONTACT.EMAIL` | `null` | `null` | `null` | +| **user.provided.identifiable** | **phone_number** | User's phone number | `CONTACT.PHONE` | `null` | `null` | `null` | +| **user.provided.identifiable** | **postal_code** | User's postal code | `CONTACT.ADDRESS` | `null` | `null` | Ok ? Need a more detailed cat ? | +| **user.provided.identifiable** | **state** | User's state level address data | `CONTACT.ADDRESS` | `null` | `null` | Ok ? Need a more detailed cat ? | +| **user.provided.identifiable** | **street** | User's street level address data | `CONTACT.ADDRESS` | `null` | `null` | Ok ? Need a more detailed cat ? | + + + ### Requests list (**TO BE TRANSFORMED IN THE ABOVE FORMAT**) From 27b7e35f63e894b803d3747db4af05208cb5dc92 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 7 Jun 2022 16:54:38 +0200 Subject: [PATCH 106/204] Added User Provided Data --- refs/schemas/priv/examples.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index ea61bfb7..3ae2b7a7 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -301,9 +301,16 @@ In the following examples we show how, requests introduced by different regulati | **user.provided.identifiable** | **postal_code** | User's postal code | `CONTACT.ADDRESS` | `null` | `null` | Ok ? Need a more detailed cat ? | | **user.provided.identifiable** | **state** | User's state level address data | `CONTACT.ADDRESS` | `null` | `null` | Ok ? Need a more detailed cat ? | | **user.provided.identifiable** | **street** | User's street level address data | `CONTACT.ADDRESS` | `null` | `null` | Ok ? Need a more detailed cat ? | - - - +| **user.provided.identifiable** | **credentials** | User provided authentication data | `**TBD**` | `null` | `null` | Add AUTHENTICATION ? (as a meta cat of biometric ?) | +| **user.provided.identifiable** | **biometric_credentials** | User provided authentication data | `**TBD**`,`BIOMETRIC` | `null` | `null` | Add AUTHENTICATION ? (as a meta cat of biometric ?) | +| **user.provided.identifiable** | **password** | Password for system authentication | `**TBD**` | `null` | `null` | Add AUTHENTICATION ? (as a meta cat of biometric ?) | +| **user.provided.identifiable** | **financial** | Payment data and financial history | `FINANCIAL` | `null` | `null` | `Broader definition ?`| +| **user.provided.identifiable** | **account_number** | User's account number for a payment card, bank account, or other financial system | `FINANCIAL.BANK-ACCOUNT` | `null` | `null` | `Ok ? Need a more detailed cat ?`| +| **user.provided.identifiable** | **government_id** | State provided identification data | `OTHER` | `null` | `null` | `Ok ?`| +| **user.provided.identifiable** | **drivers_license_number** | State issued driving identification number | `UID` | `null` | `null` | `Ok ?`| +| **user.provided.identifiable** | **national_identification_number** | State issued personal identification number | `UID` | `null` | `null` | `null`| +| **user.provided.identifiable** | **passport_number** | State issued passport data | `UID` | `null` | `null` | `null`| +| **user.provided** | **nonidentifiable** | Data provided or created directly by a user that is not identifiable | `**TBD**` | `null` | `null` | TBD: Do we need that ?| ### Requests list (**TO BE TRANSFORMED IN THE ABOVE FORMAT**) From c6e79d0febb8f5aa0749a43763c2677ca875cf2d Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 7 Jun 2022 17:49:00 +0200 Subject: [PATCH 107/204] Update refs/schemas/priv/dictionary/data-categories/en.data-categories.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- .../priv/dictionary/data-categories/en.data-categories.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index c64ddd72..8763ff7c 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -18,7 +18,7 @@ "DEVICE": "Data about the device used by a person", "FINANCIAL": "Data about the financial situation of a person", "FINANCIAL.BANK-ACCOUNT": "Bank account number and Bank identifier", - "GENIC": "Generic data", + "GENETIC": "Genetic data", "HEALTH": "Data about the health", "IMAGE": "Any graphic representation (e.g., image, video) of the person", "LOCATION": "Geographic location", From e172e4dc9b1e959ab1665fc55af77edd401b739c Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 7 Jun 2022 17:49:23 +0200 Subject: [PATCH 108/204] Update refs/schemas/priv/dictionary/data-categories/en.data-categories.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- .../priv/dictionary/data-categories/en.data-categories.json | 1 + 1 file changed, 1 insertion(+) diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index 8763ff7c..4c3e74bc 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -15,6 +15,7 @@ "DEMOGRAPHIC.GENDER": "Data related to gender and gender identity", "DEMOGRAPHIC.ORIGIN": "Data related to ethnic origin and nationality", "DEMOGRAPHIC.RACE": "Data related to race", + "DEMOGRAPHIC.SEXUAL-ORIENTATION": "Data related to sexual orientation" "DEVICE": "Data about the device used by a person", "FINANCIAL": "Data about the financial situation of a person", "FINANCIAL.BANK-ACCOUNT": "Bank account number and Bank identifier", From 0f573d9fb1f133235c03162fab135832dbf8a64a Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 7 Jun 2022 18:29:40 +0200 Subject: [PATCH 109/204] Update refs/schemas/priv/dictionary/data-categories/en.data-categories.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- .../priv/dictionary/data-categories/en.data-categories.json | 2 ++ 1 file changed, 2 insertions(+) diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index 4c3e74bc..40a60bf9 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -4,6 +4,8 @@ "BEHAVIOR.CONNECTION": "Times of connection", "BEHAVIOR.ACTIVITY": "Activities perfomed online or off-line", "BEHAVIOR.PREFERENCE": "Data about the person's preferences", + "BEHAVIOR.RELATIONSHIPS": "Social activity and interaction data", + "BEHAVIOR.TELEMETRY": "Measurement data from system sensors and monitoring", "BIOMETRIC": "Biometric data", "CONTACT": "Data allowing to contact the person", "CONTACT.EMAIL": "E-mail address", From 3c7f6e5293b91f0b10f0b27e5e12aecd05be18ee Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 7 Jun 2022 18:29:55 +0200 Subject: [PATCH 110/204] Update refs/schemas/priv/dictionary/data-categories/en.data-categories.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- .../priv/dictionary/data-categories/en.data-categories.json | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index 40a60bf9..9b8c04f8 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -1,5 +1,8 @@ { - "AFFILIATION": "Goups and Organisations the person is linked to through work, studies, or membership", + "AFFILIATION": "Groups and Organisations the person is linked to through work, studies, or membership", + "AFFILIATION.WORKPLACE": "Work organisation", + "AFFILIATION.SCHOOL": "Studies organisation", + "AFFILIATION.MEMBERSHIP": "Groups and organisations memberships", "BEHAVIOR": "Data about the person's behavior", "BEHAVIOR.CONNECTION": "Times of connection", "BEHAVIOR.ACTIVITY": "Activities perfomed online or off-line", From e1dfb10187e13f323622a94472d4917386eaa863 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Tue, 7 Jun 2022 18:30:02 +0200 Subject: [PATCH 111/204] Update cat. for Ethyca example + delete old list - Update categories for Ethyca example - Delete old list of CNIL request, treatment, data categories (now in GDPR examples) --- refs/schemas/priv/examples.md | 136 +++++----------------------------- 1 file changed, 19 insertions(+), 117 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 3ae2b7a7..469cd8cb 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -260,12 +260,12 @@ In the following examples we show how, requests introduced by different regulati | **user.derived.identifable** | **race** | Racial or ethnic origin data | `DEMOGRAPHIC.RACE` | `null` | `null` | `null` | | **user.derived.identifable** | **religious_belief** | Religion or religious belief | `DEMOGRAPHIC.BELIEFS` | `null` | `null` | `null` | | **user.derived.identifable** | **search_history** | Records of search history and queries of a user | `BEHAVIOR` | `null` | `null` | Ok ? | -| **user.derived.identifable** | **sexual_orientation** | Personal sex life or sexual data | `DEMOGRAPHIC` | `null` | `null` | Ok ? Need a more detailed cat ? | -| **user.derived.identifable** | **social** | Social activity and interaction data | `BEHAVIOR` | `null` | `null` | Ok ? | -| **user.derived.identifable** | **telemetry** | User identifiable measurement data from system sensors and monitoring | `BEHAVIOR`,`OTHER` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **sexual_orientation** | Personal sex life or sexual data | `DEMOGRAPHIC.SEXUAL-ORIENTATION` | `null` | `null` | `null` | +| **user.derived.identifable** | **social** | Social activity and interaction data | `BEHAVIOR.RELATIONSHIPS` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **telemetry** | User identifiable measurement data from system sensors and monitoring | `BEHAVIOR.TELEMETRY` | `null` | `null` | `null` | | **user.derived.identifable** | **unique_id** | Unique identifier for a user assigned through system use | `UID` | `null` | `null` | `null` | -| **user.derived.identifable** | **user_sensor** | Measurement data derived about a user's environment through system use | `BEHAVIOR`,`OTHER` | `null` | `null` | `null` | -| **user.derived.identifable** | **workplace** | Organization of employment | `AFFILIATION` | `null` | `null` | `null` | +| **user.derived.identifable** | **user_sensor** | Measurement data derived about a user's environment through system use | `BEHAVIOR`,`OTHER` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **workplace** | Organization of employment | `AFFILIATION.WORK` | `null` | `null` | `null` | | **user.derived.identifable** | **device** | Data related to a user's device, configuration and setting | `DEVICE` | `null` | `null` | `null` | | **user.derived.identifable** | **cookie_id** | Cookie unique identification number | `BEHAVIOR` | `null` | `null` | Need a more detailed cat ? | | **user.derived.identifable** | **device_id** | Device unique identification number | `DEVICE` | `null` | `null` | Need a more detailed cat ? | @@ -279,31 +279,31 @@ In the following examples we show how, requests introduced by different regulati | Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | | ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | | **user.provided** | **identifiable** | Data provided or created directly by a user that is linked to or identifies a user | `**TBD**` | `null` | `null` | TBD, isn't it all the data for us ? | -| **user.provided.identifiable** | **identifiable** | Encoded characteristics provided by a user | `BIOMETRIC` | `null` | `null` | `null` | +| **user.provided.identifiable** | **identifiable** | Encoded characteristics provided by a user | `**TBD**` | `null` | `null` | `null` | | **user.provided.identifiable** | **children** | Data relating to children | `OTHER`,`RELATIONSHIP` | `null` | `null` | Ok ? Need a more detailed cat ? | | **user.provided.identifiable** | **health_and_medical** | Health records or individual's personal medical information | `HEALTH` | `null` | `null` | `null` | | **user.provided.identifiable** | **job_title** | Professional data | `OTHER` | `null` | `null` | Ok ? | -| **user.provided.identifiable** | **name** | User's real name | `NAME` | `null` | `null` | Ok ? Need a more detailed cat ? (our cat includes nicknames and other names) | +| **user.provided.identifiable** | **name** | User's real name | `NAME` | `null` | `null` | `null` | | **user.provided.identifiable** | **non_specific_age** | Age range data | `DEMOGRAPHIC.AGE` | `null` | `null` | `null` | | **user.provided.identifiable** | **political_opinion** | Data related to the individual's political opinions | `DEMOGRAPHIC.BELIEFS` | `null` | `null` | `null` | | **user.provided.identifiable** | **race** | Racial or ethnic origin data | `DEMOGRAPHIC.RACE` | `null` | `null` | `null` | | **user.provided.identifiable** | **religious_belief** | Religion or religious belief | `DEMOGRAPHIC.BELIEFS` | `null` | `null` | `null` | -| **user.provided.identifiable** | **sexual_orientation** | Personal sex life or sexual data | `DEMOGRAPHIC` | `null` | `null` | Ok ? Need a more detailed cat ? | -| **user.provided.identifiable** | **workplace** | Organization of employment | `AFFILIATION` | `null` | `null` | `null` | -| **user.provided.identifiable** | **date_of_birth** | User's date of birth | `OTHER` | `null` | `null` | Ok ? Need a more detailed cat ? | +| **user.provided.identifiable** | **sexual_orientation** | Personal sex life or sexual data | `DEMOGRAPHIC.SEXUAL-ORIENTATION` | `null` | `null` | Ok ? Need a more detailed cat ? | +| **user.provided.identifiable** | **workplace** | Organization of employment | `AFFILIATION.WORK` | `null` | `null` | `null` | +| **user.provided.identifiable** | **date_of_birth** | User's date of birth | `DEMOGRAPHIC.AGE` | `null` | `null` | `null` | | **user.provided.identifiable** | **gender** | Gender of an individual | `DEMOGRAPHIC.GENDER` | `null` | `null` | `null` | -| **user.provided.identifiable** | **genetic** | Data about the genetic makeup provided by a user | `OTHER` | `null` | `null` | Ok ? Need a more detailed cat ? | +| **user.provided.identifiable** | **genetic** | Data about the genetic makeup provided by a user | `GENETIC` | `null` | `null` | `null` | | **user.provided.identifiable** | **contact** | User provided contact data for purposes other than account management | `CONTACT` | `null` | `null` | `null` | -| **user.provided.identifiable** | **city** | User's city level address data | `CONTACT.ADDRESS` | `null` | `null` | Ok ? Need a more detailed cat ? | -| **user.provided.identifiable** | **country** | User's country level address data | `CONTACT.ADDRESS` | `null` | `null` | Ok ? Need a more detailed cat ? | +| **user.provided.identifiable** | **city** | User's city level address data | `CONTACT.ADDRESS` | `null` | `null` | `null` | +| **user.provided.identifiable** | **country** | User's country level address data | `CONTACT.ADDRESS` | `null` | `null` | `null` | | **user.provided.identifiable** | **email** | User's provided email address | `CONTACT.EMAIL` | `null` | `null` | `null` | | **user.provided.identifiable** | **phone_number** | User's phone number | `CONTACT.PHONE` | `null` | `null` | `null` | -| **user.provided.identifiable** | **postal_code** | User's postal code | `CONTACT.ADDRESS` | `null` | `null` | Ok ? Need a more detailed cat ? | -| **user.provided.identifiable** | **state** | User's state level address data | `CONTACT.ADDRESS` | `null` | `null` | Ok ? Need a more detailed cat ? | -| **user.provided.identifiable** | **street** | User's street level address data | `CONTACT.ADDRESS` | `null` | `null` | Ok ? Need a more detailed cat ? | -| **user.provided.identifiable** | **credentials** | User provided authentication data | `**TBD**` | `null` | `null` | Add AUTHENTICATION ? (as a meta cat of biometric ?) | -| **user.provided.identifiable** | **biometric_credentials** | User provided authentication data | `**TBD**`,`BIOMETRIC` | `null` | `null` | Add AUTHENTICATION ? (as a meta cat of biometric ?) | -| **user.provided.identifiable** | **password** | Password for system authentication | `**TBD**` | `null` | `null` | Add AUTHENTICATION ? (as a meta cat of biometric ?) | +| **user.provided.identifiable** | **postal_code** | User's postal code | `CONTACT.ADDRESS` | `null` | `null` | `null` | +| **user.provided.identifiable** | **state** | User's state level address data | `CONTACT.ADDRESS` | `null` | `null` | `null` | +| **user.provided.identifiable** | **street** | User's street level address data | `CONTACT.ADDRESS` | `null` | `null` | `null` | +| **user.provided.identifiable** | **credentials** | User provided authentication data | `OTHER` | `null` | `null` | Ok ? | +| **user.provided.identifiable** | **biometric_credentials** | User provided authentication data | `OTHER`,`BIOMETRIC` | `null` | `null` | Ok ? | +| **user.provided.identifiable** | **password** | Password for system authentication | `OTHER` | `null` | `null` | Ok ? | | **user.provided.identifiable** | **financial** | Payment data and financial history | `FINANCIAL` | `null` | `null` | `Broader definition ?`| | **user.provided.identifiable** | **account_number** | User's account number for a payment card, bank account, or other financial system | `FINANCIAL.BANK-ACCOUNT` | `null` | `null` | `Ok ? Need a more detailed cat ?`| | **user.provided.identifiable** | **government_id** | State provided identification data | `OTHER` | `null` | `null` | `Ok ?`| @@ -312,104 +312,6 @@ In the following examples we show how, requests introduced by different regulati | **user.provided.identifiable** | **passport_number** | State issued passport data | `UID` | `null` | `null` | `null`| | **user.provided** | **nonidentifiable** | Data provided or created directly by a user that is not identifiable | `**TBD**` | `null` | `null` | TBD: Do we need that ?| -### Requests list (**TO BE TRANSFORMED IN THE ABOVE FORMAT**) - -| Nb | Request | Description | Associated treatment | Associated data category | Advised elements to provide | Legal ground | CNIL reference -| ---------- | ---- | ---- | ---- | ---- | ---- | ---- |---- | -| -- | ACCESS TYPE | ---- | ---- | ---- | ---- | ---- | ---- | -| OK | **Access** | Access to all data the organization has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces | -| OK | **Access to my medical record** | Acces to my medical record | ---- | ---- | ID | art. L. 1111-7 du code de la santé publique | https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical | -| OK | **Access to data "Preventel" has on me** | Access to data "Preventel" has on me | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel | -| OK | **Access to data a financial organization has on me** *-> to delete and let user make access request + provenance request to the financial organization* | Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me *(access+provenance info request)* | ---- | ---- | ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier | -| OK | **Access to data "Fichier central des Chèques (FCC)" has on me** *-> to delete and let user make access request to the "Fichier central des Chèques (FCC)" ?*| Access to all data Fichier central des Chèques (FCC) has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc | -| OK | **Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me** *-> to delete and let user make access request to the "Fichier national des Incidents de remboursement de Crédit (FICP)" ?*| Access to all data "Fichier national des Incidents de remboursement de Crédit (FICP)" has on me | ---- | ---- | ID, Birthdate | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit | -| OK | **Access to geolocation data or an access control device an organization has on me** | Access to data organization has on me on a device on a specific period of time *access request to geolocation data and device data* | ---- | ---- | ID, Device type, Date and time | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces | -| OK | **Access to video surveillance data** | Access to video data organization has on me on a specific period of time *access request to video surveillance data* | ---- | ---- | ID, Date and time | ---- | https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant | -| OK | **Exerce my right to portability** | Receive the data that concerns me and reuse them, transmit them to another data controller *access request + donwnload?* | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite | -| -- | MODIFICATION TYPE | ---- | ---- |---- | -| OK | **Modification** | Rectify incorrect data organization has on me | ---- | ---- | ID, Information to modify, Information rectified | ---- | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes | -| OK | **Rectification** *to merge in one modification?* | Rectify incomplete data organization has on me | ---- | ---- | ID, Information to modify, Information rectified | ---- | https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes | -| -- | DELETION TYPE | ---- | ---- |---- | -| OK | **Deletion** | Delete the data the organization has on me | ---- | ---- | ID, Information to delete*, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles | -| OK | **Stop receiving advertising from organization** | Deletion of my contact details from organization avdertising contact list | ---- | ---- | ID, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites | -| OK | **Closing an online account** | Closing online account, Deletion of all data the organization has on me | ---- | ---- | ID, Account name, Website name, URL of the pages with my data, Data to delete | ---- | https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne | -| OK | **Delete my data that are published on a webiste** | Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | ---- | ---- | ID, URL of the pages with my data, Data to delete, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet, https://www.cnil.fr/fr/webmaster-ou-responsables-de-sites-comment-repondre-aux-demandes-de-suppression-de-donnees | -| OK | **Opt out of contact lists** | Delete my contact details from all contact lists an ornaginzation has with my contact details| ---- | ---- | ID | ---- | | -| OK | **Removal of my image online** | Remove photo or video of me that has been published without my consent| ---- | ---- | ID | ---- | https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne | -| -- | OPPOSITION TO TREATMENT TYPE | ---- | ---- |---- | -| OK | **Opposition to commercial prospecting** | Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | ---- | ---- |ID, Account number | ---- | https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers | -| OK | **Opposition to treatment of all data an organization has on me** | Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | ---- | ---- | ID, Reason of deletion | ---- | https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees | -| OK | **Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me** | I refuse the use of my data or of certain data but I don't want to delete my account or all my data | *Type of treatment (to choose from possible type of treatment list)* | ---- | | ---- | https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees | -| OK | **Opt out of automated decision making** *-> to delete to include in 24. Limit treatment* | Opposition to automated decision making on the data organizatio has on me | ---- | ---- | ID | ---- | | -| OK | **Opt out of sale of my data** *-> to delete to include in 24. Limit treatment* | Opposition to sale of the data an organization has on me| ---- | ---- | ID | ---- | | -| OK | **Opt out of tracking on my data** *-> to delete to include in 24. Limit treatment* | Opposition to the tracking of my data from an organization | ---- | ---- | ID | ---- | | -| OK | **Revoke consent** | Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | *Type of treatment (to choose from possible type of treatment list)* | ---- | ID | ---- | https://www.cnil.fr/fr/les-bases-legales/consentement "Droit au retrait : la personne doit avoir la possibilité de retirer son consentement à tout moment, par le biais d’une modalité simple et équivalente à celle utilisée pour recueillir le consentement (par exemple, si le recueil s’est fait en ligne, il doit pouvoir être retiré en ligne également)." | -| -- | INFORMATIONNAL TYPE | ---- | ---- |---- | -| OK | **Storage information** | Know where is stored the data organization has on me | ---- | ---- | ID | ---- | | -| OK | **Accessibility information** | Know who can access the data organization has on me | ---- | ---- | ID | ---- | | -| OK | **Provenance information** | Know the provenance of data organization has on me | ---- | ---- | ID | ---- | | -| OK | **Retention information** | Know for how long the data organization has on me will be kept | ---- | ---- | ID | ---- | https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees | -| OK | **Deletion information** | Know when my data will be deleted | ---- | ---- | ID | ---- | | -| OK | **Policy information** | Know what is the policy of the organization to keep data it has on me | ---- | ---- | ID | ---- | | -| OK | **Purpose of treatment information** | Know the purpose of the treatment organization does on the data it has on me | ---- | ---- | ID | ---- | | -| OK | **Treatment information** | Know what type(s) of treatment organization does on the data it has on me | ---- | ---- | ID | ---- | | -| OK | **Particular type(s) of treatment information** | Know if a particular type of treatment is done by organisation on the data it has on me | *Type of treatment (to choose from possible type of treatment list)* | ---- | ID | ---- | | -| -- | OTHER TYPE | ---- | ---- |---- | -| - | **Propagation of request** (can only be ask in addition of another request) | Send the request to other organizations the organization may have shared the data it has me with | ---- | ---- | | ---- | | - -### Types of treatment list -| Nb | Treatment | Description | CNIL reference -| ---------- | ---- | ---- | ---- | -| 01 | **Collection** | Data collection | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 02 | **Recording** | Data recording | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 03 | **Organisation** | Data organisation | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 04 | **Retention** | Data retention | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 05 | **Adapation** | Data adaptation | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 07 | **Modification** | Data modification | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 08 | **Extraction** | Data extraction | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 09 | **Consultation** | Data consultation| https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 10 | **Usage** | Data usage | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 11 | **Communication** | Data communication by transmission or broadcast or any other form of data communication | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 12| *FR: "Rapprochement" -> EN: "Matching" or "Reconciliation" ?* | | https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles#:~:text=Exemples%20de%20traitements%20%3A%20tenue%20du,information%20(selon%20le%20cas | -| 13 | **Automatic Inference and Descisionmaking** | Any automatic inference made on the data | [GDPR chap3 art. 13 section 2. c)](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre3#Article13)| -| 14 | **Basic service** | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality | | -| 15 | **Additonal service** | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | | -| 16 | **Tracking** | Tracking information about user behavior and activity online | | -| 17 | **Advertising** | To show ads that are either targeted to the specific user or not targeted | | -| 18 | **Marketing** | To contact the user to offer products, services, or other promotions | | -| 19 | **Analytics** | For understanding the product’s audience, improving the product, inform company strategy, or general research | | -| 20 | **Personnalisation** | For providing user with a personalized experience | | -| 21 | **Operation security** | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | -| 22 | **Legal** | For compliance with legal obligations | | -| 23 | **Ongoing contract** | For ongoing contract purpose | | -| 24 | **Data transfer** | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | -| 25 | **Sale** | Selling data to third parties | | -| 26 | **OTHER** | Other specific purpose not covered above | | -| 27 | **UNSPECIFIED** | The purpose is not explicitly stated or is unclear | | -| 28 | **ALL** | | | - -### Data categories list -| Nb | Data category | Description | CNIL reference -| ---------- | ---- | ---- | ---- | -| 01 | **Name** | Firstname, Surname | | -| 02 | **Postal address** | *contact information* | | -| 03 | **Email address** | *contact information* | | -| 04 | **Phone number** | *contact information* | | -| 04 | **ID data** | Identifiers that uniquely identify a person | | -| 05 | **Financial data** | Financial information | | -| 06 | **Connection data** | Information associated to connection | | -| 07 | **Geoocation data** | Location information | | -| 08 | **Health data** | Health information | | -| 09 | **Tracking data** | Cookies and tracking information about user behavior and activity online| | -| 10 | **User profile** | User’s profile on the first-party website/app and its contents | | -| 11 | **Device data** | Device (desktop, tablet, mobile...) information | | -| 12 | **Form data** | Information collected through forms | | -| 13 | **Image data** | Photo or video | | -| 14 | **Video surveillance data** | Video from video surveillance | | -| 15 | **OTHER** | A specific type of information not covered by the above categories | | -| 16 | **UNSPECIFIED** | The type of information is not explicitly stated or unclear| -| 17 | **ALL** | | | - ### Alternatives Considered #### Transcend From a164057243af429c188b49407a7407f2cbc0680c Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 7 Jun 2022 19:41:25 +0200 Subject: [PATCH 112/204] date fix --- refs/schemas/priv/RFC-PRIV.md | 10 ++++++---- refs/schemas/priv/expected-behavior.md | 3 +-- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 02233271..1981e7d5 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -2,10 +2,9 @@ | Status | draft | | :------------ | :------------------------------------------------------------------------------------- | -| **PR #** | [NNN](https://github.com/blindnet-io/PROJECT/pull/NNN) (update when you have PR #) | +| **PR #** | [659](https://github.com/blindnet-io/product-management/pull/659) | | **Author(s)** | [milstan](https://github.com/milstan) (milstan@blindnet.io) | -| **Sponsor** | [milstan](https://github.com/milstan) (milstan@blindnet.io) | -| **Updated** | 2022-05-25 | +| **Updated** | 2022-06-07 | @@ -17,6 +16,9 @@ The vocabulary introduces a finite set of `concepts`, `properties` and `terms`. This vocabulary corresponds to the [Data Privacy Request Schema](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#schemas) component of the [High- Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). +Two additional documents: [Examples of use](./examples.md) and [Expected Behavior of Implementing Systems](./expected-behavior.md), complement this document. + + ## Motivation An individual is in connection with software Systems (and Organisations operating them) that process the individual's data. @@ -412,7 +414,7 @@ However, in most cases, Systems MUST require the Data Subject to be authenticate When processing Privacy Request, Systems MAY automatically disregard the (`dsid`,`dsid-schema`) paris for which they have not been able to establish Data Subject authentication. -However, the authentication does not necessarily have to be performed during the collection of the Privacy Request. It can be done separately. +However, the authentication does not necessarily have to be performed during the collection of the Privacy Request. It can be done separately. The design of PRIV aims to support several authentication workflows, as many as possible authentication methods (i.e. be as much as possible agnostic from the authentication method). #### Matching Multiple Data Subject Identities diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 1d7551da..f40aa9d9 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -2,9 +2,8 @@ | Status | draft | | :------------ | :------------------------------------------------------------------------------------- | -| **PR #** | [NNN](https://github.com/blindnet-io/PROJECT/pull/NNN) (update when you have PR #) | | **Author(s)** | milstan (milstan@blindnet.io) | -| **Updated** | 2022-05-25 | +| **Updated** | 2022-06-07 | ## Introduction From 49600fe3e99dbc209a7aaf20d23e831695dd5c19 Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 7 Jun 2022 20:44:31 +0200 Subject: [PATCH 113/204] updating /notion of privacy to match main branch the idea of this branch was not to interfeer with the work on the notion of privacy. However an error happned and there was some dubious file replacing the notion-of-privacy.md. This commit fixes it --- refs/notion-of-privacy/img/connectedness.png | Bin 0 -> 20290 bytes refs/notion-of-privacy/notion-of-privacy.md | 228 +++++++++++++++++++ 2 files changed, 228 insertions(+) create mode 100644 refs/notion-of-privacy/img/connectedness.png diff --git a/refs/notion-of-privacy/img/connectedness.png b/refs/notion-of-privacy/img/connectedness.png new file mode 100644 index 0000000000000000000000000000000000000000..0879ade48a30554d53d91e4a21bdd9063cb5ba15 GIT binary patch literal 20290 zcmeIac{tSX7e9}!OQEy|j8B4eNIdzS1=iYUvFE!ndZ5<`?GOJv_d z*0FChc<#|>N#D=&T-WpO@0TvuynEmKeV_ZB*Xx`!LN(NsPLeT@5fBiZym9@SCIJBn z2>}729qCcdoYeGOEoyT7^OA-_Wn(N-MP*o+k1fEF=NC;08905;+;2!}Y0|CA_@I;_Y z$oS8*CLz~fb%+QEg5dVJ$o~AJ~vwjd@BM;H*xT2 zYwl#q=4NYS=P2$b#ePsj96aM+^Ru%ZRB^JFV%JsGV3W6hV9qAYC%`AbE=|V9#wPjT zo`tyPHO0T0ga1jfTRJ&8i1YKiy1MeYUgooZaGxJ4CML!&AjmH$$O~%lI=b6AnY!`X zIdc5$oE+3^GY^Ye3_PH>BVN3wJLYgu4{{P+@n zD4ziTe>F3Aga5xY!y3 zv4cBF3;xyQx7WY7(*3vmmvMf5`+E!Z2XJ$+l|N_p*C4;X`=vg9ec~E$H**`^Yj9h0 zJI9072n&Ga{AbbcP37%v>>p@3n8M7Zp?@{`<<;-C4+hfvcObFD z06(Sc;4Kg@X);Ove?(Q9tZl}LmViK(;KsG9x7`RAhK?s$bS2A-!j9_?w6gV(UJaxv z=6q&qbM{OiB{9T8pjjYP>MF-N`Sic8Pm+TV1=VI=JD z)Z5>29(p}n?TlRAert$%fUcdEp4L8(=@r{l>H5lbTv{@j&68tgY+`9~T5u`7S9{V!MpkEH$pm;b?&e=yh|Wc;5XKTAo&*3Y`2>Vl!? zLK!^2tVh|pu-2ta-6BNacc4~1Gnt}}ZD9$8n9&MvkK4m`)^vt_(}< z-5f>)-yZ$$Xs^8bdH6gflcu=@=P&w4c9(d3<2HXi?!m6wAbqqrVcO`cIZaL~tsoJ- z-F=$VXMY>(s8(u%vSb3bl%J@PmyL?a4$;CW=$9aPcToOI?ATdYIqX*u*lon7ety_I zu5`75wz9=!p)hEch?FFEz*T=(eze+vwJn$Y1hMBkw;P8RB+p)iarv0J#rK->)ysz( zMPapB?N5(4k!c`|k3BlP*W}r9c~6zfhKB>W_jZ5Oq;ZeVz}0=RkIiO;?3p4gSf2rN8(vZj;qw^KWpI z+~3LYif*8eFWxdg)AAI;ZIUq>vcPb1?&jz|QA1t%n%H52N$24gZ|u`2bu>7o4|4Rz zyXy^C{Yw+a&V)exmxG0a?sFfeuqGL#UX@Fe+}kVx)_JAZ1kD^W)*@U=!K%u&mWM;A zLu4H~2cE7>G|H57l;sx6002<3RyEr&a14JIe~{lk*p%rsKZaJAz!{yzLT z%-45;hqo`{wqK-j1N+#Ksny!9kZ4L(luqbQ<`4#fL`#>FnDGKH(56fxds0gaG=(+o7(1_~3#3Us`sq@NtW7*f4O5f46jklq7g$5Rxs+7Nm!%8G4|l(U|qy zwtYX|G+$B4`%DgOASsEGvbv>`2#`lF6e~u>prGbj#bzyjLVh`%OTG1bLQ*RqIA-dw zi#P4-wx_zSLpaX-HQh^Glv<%2bc5TYCkA0f{<|U!iSsG`>BTzSK57us=Av0TqvXzn zFl6KuXp!1aL?O8(D?Xj%*opDo$F^#t6Yr+nX#Q#EDBPf(@$*}jmU$FQaGmtdVcN1RoSzpb?=uB2wml4tJ;P|k0M_Ttwn zkVJGJ>Fv^Q7S5}Q^V*(_UroE8glN9vGXD*S%ZxWt)-m>W-f7dRd*ae(9>0cLMN`~g zwQ|hMPVu;u?6uN56RV~6e0CbQScA!u*_~0}Uf#oE)YmsGf6n36YgwExw^nFwzh`>( zkRn-BN?jiAc@t^FR-h8aY{A~grDoMJ14W(Qo{_`L}%%z3N(7>7K$2A!2?bT zUx$hdC=>fv47nJHFE^d(3ZRfq*xPE6$x3$VznJXYqX*yUyN@2&y6-@o;x-<-Ho>|t z>iwOA^~U}R|GuE8L>cW*m0|LltjV$=)~K~%l!2Q!M*FTsLry=-vBGSyG3)c25Z4|E zshWqUrjOTF3!+KrRsh%>4Mx9x9D3j8sDExjwN>?~|B24>0lNWm;v?+u8%~N03K%|U zJr9qT+V~($A%k<+>Gj?1U8|_y%@@{Ii~Z{^2x$0iEgIx0GmV5&|D)8bxhXd(lUz3n zyzC#9GrB#+*9}r&%L+1b{(5IyH_@&dzSD>Hd1jGlTOQStV(|jrS-+31&o1;{uy#+B z+22Ob1TotEsH~;-Tpt%mZRyD9lQyq&5ei zvL5N%=PrEv#IAZK%V~dilfo@?CdV8%?1{;2Ve#at*as4$R#?C1QBQYFztC8s0&<|> zekiahk~e><0ye7gbyKbAw&fDZpq9gu>OwJ+2o*az5y~e)Y)w>%5 ztB|_A^}=l3+ZpxdpAw+(l6K*nK#UcuSK7E8uZt{{4($)XBIIy|`#XhHS5>X)D!<5` z$c)o567!xj7*Td?r{3(HF*2hX&n>KbfpM$^C!Gb061!lCKv569FBSFSaXYPry#E58 zWhcR9Q2$MjC*yP)JV}XX?^dh=t>KmY(oSXfJHy~M*0_1TK_-8eS)|^Y^^PVGk|DeUae&eC%J288m%ham$B`xix!(sYVTeC{&w~AO0V~91xCC&r!c)oln)JpR+<2wtx(MB-EZO;3y4^aqpPHy_OU**L zfd_86Wwi#9$5+;^S!D}NzPQLtUmncjVR8v6|mfFIg`#{N_pfDTcz8hBLZ z7sEl>pdD)-Z&)ryEn44!_8s5zhj4B1)Z-@kyEegH!flXo=RI!BjrPS&Y&%Ezgcre) z-Wxa2Qk!>;zMOksJiglF&FqU?-Zsw*WJ>P|i-~|Fc~47>w1%f&BcMq$iC~!5JE||^ zUus+4cR_)amV?lDtC2P9tF}RY71q+XlrxLScRklwwSK$ZUNbOAVP*jbOT;7Jg&Itq z`wMHH?$f!_Ew|_QcSrVB4Gj(5*DN9)Ci(2lByM^}c(CsNP?}KU8`)iS?RtJcuxeGi+y#|pr^qK({d%}J7B~-tnU2ga zL6uf36fHT`=qXHrg3dpc#hd0^Jm`2gi z^$I_^rr2&$_{%&XjPB=5AX6w$=r}*os}i)dMD$u%j2omn+2Q^1<>h?%BV9`W9syoE@XYxw5Fw(h&Piky}ept)PM^!`K_u!hD=;`!doGAD9duQO9-ffs9f*%R3bm7VjY=a#MBj(K403U z2Cv`Uu-+974k*TuUV=55MOZ|blqFa&cRl9N2*3CZV!~ICTN#?=f4lU41{nJ`Y~;I= zLczgi1m=CEuUYK!M2qVQ;)z;PQg!L=@1=V?bJIQ%kYr=rIBl2g97_7Y1h5Ij5}|I7 z<7o`95JqAqKc0oYtub!c_0CF2C#N`>E5O|6lNss*?`$a~+0UHpDx+nUQ0`8~>k-9h z*@)|mVHyJ3{83Bi-`DF_W(ZN*d<`GH@IHgCikjoQS@r$FV+Cc`=qf())s)tKU2q?a z=T|(}96RV@&bAJlohPBa``DG%^d4HaNc3}y^hPn$JZkq8T6`{#=`)IIcrRriSl7fO zHKbePzG#E&N}84*YnT1s(jn-(%r^%e(Q1j4XfrB{B&|SC1Dj%n6c^_8^gv_K+c&)k z&4{{CtU?{wdDOtu-6V!)Q<`4;Sh|^S1%awb1}bTLAC32($T#@)SXcOB4nU+|8s)cp z>m*%v`(n~kuKSoEv&{`Wj_!DHvWY9eEn@972T2Rk!?FLt(0Lv{!A^;rSW?PYak6>C z27{Qw1YvPH0?7Mop$dFqG4{zDH8WX>SqVN2=_Ihpft0k-7uE%R(AyE-%^~GnPld+PhvLQ3>TIS8_ zxq^?ZEz7V{<7`0y$0T1s<=)|MoETNaOb=@IEktEQ+bqMB=k|les%e)&8!NgNU>}n? z=py0WoGET*VV>F>JY$RlR1IsgbL)eJ2Y64`go}7FaZ7n;QY=2(utLAA80!`>czXZp zWftXi;s~ldBV?H^g4jQp>B02@wBmT84sQ8#%r_oec5styNz59ebhkKYURWBsm-Bo` zkCuMn+F|##Hw7CdAh@_mliNbGu3vGH=Ch@D;krAtU6^Jls zL85xRH@sNV?&f(hrhj=!HQj++jYdJop_!RK3Q6DV)3U=WkaWwm=lwr&p|&3l0bu%U zWNrbeYhG2M;b29l#8wFmes;o?cMG#?2Ec!uwv}T+@JOMa>j;XEBs98gNX@&(`F@*V z%~KPX55S**E>ZpSrQ18}@QGvAuJU!PX`_$NP_z;T`pdt!%Jx3q6xk0`$kf$42tNA7 zoYf#UE-q@4Z3D*btIcW;fDHTAjji#9*#@ z)vueM$EN8iot6xbBHlq-*w0K?J^NL3lxfsLCnmCkInDI!^QKNFPdXDDK3fiw{uKW!D0oZ%T zMux}Fb+|FohO2{M9+n(zR5k(Q`DwIV&vc?q1hloo7;`QifO}^WGt>xhVF(ZT?(bey z99U<9_v*}WHx=w6~a{B&CCqiS+nib`e?~HwYITlH~5Q04t#VArR5*!xi7hZiU zN3_rflZs?4XW>xXX_v;%@4nU}eg#byR*uMd**jKA-Z%f4$<20Pj0SEI3lrk>lDKkw2$f+iWVRbc$SF(2|Fdz<<$fnSKVcb zslA18S#@A6)ggt!s%(27P!lcLyJ?6|I>Z5u7cjD*i6#G1j=J|HUrH@w7@2+E7xDAw zwVfkR`|0v9od&mR>Ad0_R7j1w&&pHp#R9tLIuUg9CGRQiHB_V`V=PeqOuJIwWk1)~ zWBJO%u~!s}sL$FBs`F=kRJ(Ce`$ZH=X-7+(cf1o>om_qqHt2{f`7CZ-hcO+*;t2=> zjRL^z@<`z_K;GAbS$*8ft@0(lc;sW3k`ADLEVbzV>)_7kEnfNacHNv`?ET=_+RT&3 z$z$FPOYFf|SfsAiR2bmp@kh37o|{47HR#C_-HtMuudrDM9wW$kqEap>Lq6%|;@c98 zXKVAa+1D{Hs1@Q|Y$e((77SQv%u>9v#P72l?gTbkb$J^Ag1&8Ox7z%o!LD;e4Q9&r z#+zp%syhlSjRWu93fqf9>5X^jRBaA>V*Brf$?(INjwK41%CV5pP4|>Eb&u)Z*?xb5 z|5Nx-(=^0QDMb8>hg9^K&`&E%?)UM6Wb$}Tv7Cu0NuYmY&Vnv8iCM^6M}0Ln$^m}h zD9MVFRXK?_)T<4wfV^2abR&D1oV#zeYrxYZg{`zNW(_Ki-WfD5+%}Eo)G=~5cQlQ9 zX%wv*v}+Fa5L8T3z6P>yZMKw?Z^}FKPddj$xcq`FfeMBU+fsmdC#?1xZ`T zK{^0r%MrV`6ik>Lm0PoW(Nk=;mg{CrW^7JFIIE5&zj+g65q)uLn1kHOeuCi4I- z0it2kVsTBDSt~sKEzlaCS*-l#*xhB3VSdvIwlo8EKq>&Vvhq339zQPP8j@|3~r19%XF4DeIl%gYqo-K zs%XHjCXEA{x1mn|9Pv6CDd&19qUywg>E8 zeExW&Zc!%b5v=DP)QUH&N>R_TU1$|Oj_kqiQ-_C9AyH_1uL;I&bDkhgo`Q}Y_hp>_ z2|mjLwYw^Xk)D)xWnZ=3pZ;hW&N_w!eEi}Lyy&Lh1fJT6%sex&n{l3;$MY?FTCIMV zX`EjV}{2HYu=nZ3U)+l;~R(6(z_#1g}Af}B2mm{PIqGyUb_P{KQ)b#fz;UmqP}e&ac{uB zepi#&GXMO>>eoV_GJ0LqtHPMucr-MaBoNYJQT*D$Iy7|&kbLW-nh;`|Oqprl-SysV zdqBvl+VGx^9=-d?FFp1EMRF82rfo1?jck588E-6||EBHIcK+_>h)go@rslIwPvd<9 zJFV(IPmnFUEPxX3P6CsM+1Y2QVlB*h=3u3s3a68Wih2}sP!lRQaJQL2|+ zg%o}HkSfsM3S^{cMmNrF;wvrPr=fmY{Fbe0u`ON({*39#BK}1bO_#+41Vg*&8~$+q ztB$elB2;mc8PNo>l}}H2!lV@pyD|nyOHx7Qco@??RNW$=i&PwgW;?S9P}mAI+o?Fh zf+Ofht1@?f>?!H3QKm~Msdck+BiX>!f+G!}OVcKPWMEfi-tW|!3 zV#LRDSem9Lq$5^J=hCTc(pq+}h=;=3^eKpD`mUL5j$P`0&n?hP%8OJ6RF!>pmuJ+wWsxsOXT|M%#5(ktIRgH!7kYQN{INTt{=q?E=1!Mim0lfB^1X;445%MPbbc<) z^!L9PT~u5{rI$5bucU+1aO{S`3-XaItKW2pgP?NU?_XyleZ+^{CL-J0*@?pmE|rIR z4zBa$6KbQ;`o^>as8?E+W3^kJCZfi*@g2td}GdFn5Jhh>kw=GJ@=sN1ckyDTk6Fo|`{| zYllBB;(BDbT-}8>t7#B6vaen5L<5%L<*iWPbg6NfOPPuPvoD~1Dku2gIxM>|Sk_LR zlKkn}*W%J3_NSqKE+?8u5&G^*lRzMFZ#^ZWaLIJ`^!Iic&nl`zu+I z_Q3tzdEkCdjg*aG^IYptT9uT_Y^TeX8}WR>Y3=$yN_*ow;o#Sz1%re0Jdqz&GDfcgO4e$EdH~%aa}~ zY1%LI1f04Av37@vqn~zQGy5%ev1S`*Mg>zbjFPrG*|}2^{bnE*>N6h7sVOwJJ-`X6$$09For%s8>~{?9=+==!qpmlkup32l`2nBH!0mC! zR}KdGhq8twQ%K)Es^|tTphJ7_g~Q34eS)o7p%3^KKU1H$qcVdy=CRkMCSf}e6DSqU zntqPfmdE9Ev|lV~r}XM`^!FCoSqjBu!DfibsdG(CmbDF{#@GY@ZU;Xl2k`_p|6*f$ zePOOskX*y1b?uV_3|gV-O;Sf;O{3W~iMc^!YR?a#z~4cE*O!2(8#$ywwdo72IHNjU zPLL?UTcWbME-gaov_dDMb4(nrtQR=`8mM{qgT`&G>PD*+v63sR&iZ_y|DA;@hH{A@ zeRYP*IfyB{0KLXV*S3Rw`O8cHD(Rj1nG`j=V}G(gzhRv+p`0aqhDRwtHi8b1uBb#T zA|U|>3jObyky6ry{&c5>512(Zxman{0xQ41xZjrSje|zUy)fGphxev zb);g2bsdvri)d;Mhn`ZAX;)yZhE^(BaXJJMixM>5z+!i)Tfjcw93OKTb*_ z(dy>gbb?ANRLM(T=8|+A z9J5t-xn^>SjH{NJwrpXS1nmMe?gzIyC*`tI%I5iV*0 zO@~+)8)kKG{|4X!z#)F$D~;olJA>!6f`Z9xj7j-zw#Cq=FC#{RD`1S$C= zS+AA|Od^DorlOc3Y~mXy2w4GNaqt@$d5tU%5tTU#6Rj|D__ob_=z!8SM{&6<%8Yqp zYHXsHJS%)S&r{_YBYS5fIOrl~ntqclE)Ivj!0aLUBJ$K~4z+huBuaPVRrCUS^sVzt zH~OvB^)g@BGRxOQ?|oH;fArOVIq<4sVA1=M?LKPqZOc37QP;EEo{#CS>{WC)zhm3u ze=_&bZ;p)^L{?YKNA1l%V&p!_T{hopoO?N4{~$Dl{j0l_s!sat>?(cbL+AZ--LiTh zko1x4wfg^-rJ4bu33E=E`ZW;sS2ZqfHYy(OSJHT!{?GOuJotqHS?2CBeeoX&oT+&r zqL`Pu^Lrc6%cTo!RC&6=@c&5U^Lqp4@y37lkO=*}AFmQXhi1%KRsYdr8yP9dpN0J` z+LV7z?2w@T5ygKb)`!#hkJfvMe8Gu~T?&#oLcxdZ%T zjGaE%g?QBJfK~8^N|l8%lrpnvV!*co-nm~o=y&Nu5l2I}y*t3!LOoXAfLMkanFN1f|k4yO(flg6G2NjfXn zAk=%eWH9Pz@rK4EDF~SA0;g|DCtxk{$N1N6Ry3F^rV(%L_<Dh@9%l zlrzyMdX1k!ULV~`4C>!jPTAmZydMnXv0&ogmsjbm~ne|>{^%K0M8pG()F8yyFVQ23gl2byWedAP{qZ%7EJ~dHp z>tA)cCZc6hjDSny3R-gYJGlvP_S#j!Q`r=xARe&$vW@i`UJ2K~k0fC9PhBjCbU#cA_2SJ@}pP-NY^Z{^Ve;S!-41F=5ja_ z8a9i-`B!kG#PC^DVyO`dcg9n~bMxLP>jO%^%0FdO(*DehWa`G#3uOb3HV-MOhXj7Y zL`PZ)^j$B1!R+K?e{AFIeX$1OyK7xtnm2jlj-B?Nx{SOrmtSENhKxC8Q`B&D2KdG2 zv=@+jGsp*g#goqrrZz`_chh1K($@l3lQe?iu6NrUa_s_%2uR=osk(xlFUh9XxeLW` zrWAtk(+mhDEVvBz(5{4QN1j46(k69Y9UU0ibI}RNx9(7&T_{q(*rP>8ysGxxr;~f< zf+CIk-x@OIE`RJ9+yLnZKdg9e4de2lVTHMnHD@8d`GRJCqt#t%ZQZn7$UC9AWV~Ch zqCGy%v(Qm`XQB7CQ`i{JL9f+z1+D7l2>LD@&zq=}=;qf=?gPV7 zj00EX-dPMatF#uNeKtxABd=<yD>&4&s9XyYw-*7FPYtL^qaC4Hu~yP6<2C}XvF*(YXyCBFX3oWeuemWU;& zPci$v^{%8ak55jR@edG!%Qax5AN#&BU_T<+d@(zzbFiNC@Wo7BBmz-4KMR5}J#ZPa zna1MlaptR7Zy5Dh0XUr!gUumFw3IvBoqNQQ^il2T6pz`Q0#2mYo7`{qx||2p(X{xKk4_+TPgjFJz!*xnYM3Pi z!}s?v`)ZMdnpIYk(FP^XmsY|z1mzkw_=bif#pWT;)~6wa<0f&6{wc0PKu^02PEIA- zr^qCVBFwBZrkE?jDWarzeo*=HjAtd`lYVL*x#v?)NE70t%JXXyl-=+)hG6)(VR>1^&4}f4L#^_cb>r0=jA%LCg))otdueFVaO#|zr#*y2#XZz1TNF3VIKL;VKUnJm@?_;%+~a# zOA0aHHifQKmK99@cFXMWvKEG!4_G#=&vqaDoLAPQ(v|@Erb~QIh6UJxwOr%f*UnEn z(c!D11IZ|^`Z{IAFhZh&&bF^43iq-kRimh+{r3JjzVDUU??6&dikaRrK4nPerD;r1 z3+0gRQ7_=2y%`zz(9;&Pik3kd0juz~9XRoa=gLvRC>Ip}y=5Ow2XKkyA~`5vj&XBbgF>eGy0ir zkjT>wr`_KDR>uWWF|w%!%6b;mr3QXKaxFfAOnTY5&Gm5!FJmR%a_jtooX?MFjS?7g z$)+`yfJ*srBvu-vXk~*msLRP9C(Yez89490*qU~$VP`Q|g_|1*(2bs0U`WoQKnSq479>pP9nyuKF9@C6AHyz5H;iPWtx9IxK97#=s^9 zEugr-3_z57Lri6_v2`eR3uW7QG?$A0TFi~LvXO+(Oky`;U)mWvd+nuxEIE0%^HiH1 zp1>A+NVPRm$Vm20$CM)7r=D*^xVK85ZIMKfC`N(!fYU^zNS1E0==-{G{<=!%5<4_Z z+w=$zfp>0oY^7YxB`5B7;g<}V>;gtbb{ank->|4NAJ?+)|2BHC4 zXjuX2=tqiS8hl3ayb4DlT7JgB&n)e#bB_u7Mj-1n_bx5SXBx2ztB4>`epz~AH!NA< z#qeTQ5&%7FEW5NE1h5dh?9(Ej?gEUm+5!;I{p|J?EFPuoxv#WxPIo-2wPoTar(WF( z_o%hS{0tobD~Kj0MCO7I$0e{PzPCZiW48vaK_oNv3h|sY9E8~Fg*ZL zx>*$tV&mfWTHSLc{wH4mc7FjiDx-HVMqx$GcQtXO)R0C(I^yEHGn{Hk^P>pZCwvlF zy>CA}TXn;Ij*&uYO~a>Zt@CC@omAgyz$tMqJjRovN${8kHCB%Myzy47SHBI5d> zNx(^Q+gb0!06{i2L-skj$*a0Ke2Uq2UJ8IDQTI2ywbV0#7rSU;8pWQ0D6A*l-qE7b zw@fR=C#6Jo4>6FauB9uUpJnT$m_Bg#;~zb%@bUvv-h33Y1~#53h_c9Hj-ez z0B>e7yADFzfoZX&(D^hZGZuKJ6WYRbx$opOmeCRp#}<8r$zAzsLYyK?%IVtEHgXn!PaYf&?^w*0j$) zb_8it)CEFY&wD_SXANi&VdesWB<#jU0HjNn2{(wP?utod++6woMV>+x&jO&9aG>7N zC-TefSg_&33jjNAF971gkCJ~b=(p$^ob;x;d{N#6u!S2+%+9xs-bnEMprfwrROX)S z@DLevkgo>e(=Gs=;`yq+KPd(IgzDuL7@y6Wi$P<}wYwWbt|M>XsOL#b0y)dNKI@Ae z7!jWC#eke5_}4o+$u_J~BckIW94p;pTIy0l$smDh21M_!=jNB|r?~opyOf33mBI1L zA8F;IC*swACmliBsVYYWs7BT~x%7lz5v z0E*9ru;c*z#qcK#t-f0>mk@ft41Q zTK#m{eMvL#DJ8waC!e<XLN`48+u zvqC>W{|1x0O?CRLkyt_(p+(wn)B{b}%bx_~bzrw*>?9)58vvIV0IZT}Fk~ikleg@4 z?+wo6?)=Zd@+DW;;#QnJ>(>=HC_hc#na|$ptAyUynTXHJh3J;s4STWB6x(u)+SK(f zw&HSr}yqlK^dHx|gB61(??Df1Qg0T@oYAZ=xGNuGz218b&i$CJYhcjNeUbD}wN zZu1t$ooM)bXsw9$2pqSP*-VmRmKGy838Kbrxuhs>f@dIxHkfsN;b%hDFB)c+H1;Rx zyGIWgjjspDjqJixr|~*ps6p|NRntP#xQi7&1JDDzP_cTw;lmXMLbDpxfx2Eg*|_@# z%|Dt%eN=3tgt;a`NNp0={j0nDFaE3{MtCCfcEQIh3BMC+klrH(axcVW%0No?zq9&j zMQ#gOU5647oRG)=EdVv}CHX48E|cF>4!-99=fG(ulhrB#|IvFa_!`2qRjtJTm=eCj zxH-X-|FsnSJU*-2{>L=p@ZZ+>|G&sT3;UIu15x>NV*i3D**~KA?`D9T`sa=vLM(r@ z;vri3M|m7FqJNafVMOsqdHhix|5su~zx`w8B-_v9hF>P)|1#VS1+{Ahawh)&4-eJI A=Kufz literal 0 HcmV?d00001 diff --git a/refs/notion-of-privacy/notion-of-privacy.md b/refs/notion-of-privacy/notion-of-privacy.md index e69de29b..6ba1d2fd 100644 --- a/refs/notion-of-privacy/notion-of-privacy.md +++ b/refs/notion-of-privacy/notion-of-privacy.md @@ -0,0 +1,228 @@ +# Notions of Privacy + +> The purpose of this document is to list definitions of privacy and related notions, sourced from literature, and provide fundamental understanding about the key concepts of interest for blindnet. +> +> We are interested in privacy from a perspective of builders of computer systems, who have to account for the human, its psychology and relationships with other humans and with the machines. +> +> In this document, we are not interested in the general perspectives related to politics, democracy and justice other than those views and findings that directly impact the building of a software system made for humans. + +## Definition + +Among the many definitions proposed in scientific literature, we use the following one: + +> « **Privacy is the selective control of access to the self** » &msdash; _Irwin Altman[^1]_ + +This definition captures the essential features of the concept, in particular: + +- Privacy is about the **self**. + +The _self_ is a very important element of human experience playing _"an integral part in human motivation, cognition, affect, and social identity"_[^2]. + +The self is not the same as identity. +While the _self is the totality of the individual_[^3], the _identity is an individual's sense of self defined by (a) a set of physical, psychological, and interpersonal characteristics that is not wholly shared with any other person and (b) a range of affiliations (e.g., ethnicity) and social roles_[^4]. + +Some scientists challenge the ability of an individual to know the _self_. +Under this view the self might only be intelligible through its manifestations or consequences. +It is generally accepted that the self is developed over time. +Also, undoubtedly, in part _"the self emerges through interaction with others"_[^5]. + +Due to the relational provenance of the knowledge of the self, privacy is one of the key features of the relationship of oneself with the surrounding world (other humans and artefacts) through which the knowledge of the self is formed. +Privacy is a "factor of connection to oneself and to others"[^6]. + +- Privacy is about **control of access**. + +As relationships play a key role in shaping the view on the self, it is of crucial importance for the individual to control the access to self, and thus maintain control over their own view of the self. + +- Privacy is **selective**. + +It is not an absolute binary "come in" vs. "go away". +It is a nuanced choice to control access to parts of the _self_. + +## Function + +### Privacy Enables Connection + +Privacy seems to trace its origins in biological processes. +"Withdrawal from others is ubiquitous across the animal kingdom" [^7]. +Researchers make an analogy with cell membrane[^1] that selectively allows material inputs and outputs, similarly as privacy selectively regulates external stimulation to one's self or the flow of information to others[^7]. + +Biology research suggests that, in social species, privacy might have emerged as the cost-benefit balance between the advantages offered by the life in a group and the interests of the individual's competition over scarce resources. In other words, **privacy balances the dangers and advantages of connection**, which makes connection possible. + +The practice of withholding information or actively sending deceiving signals might have had origins in a survival mechanism i.e. sending away the individuals competing for the same resources. +_"By increasing another individual's misinformation about the environment, an animal may increase its own fitness"_[^7]. + +In such primitive groups, privacy emerges as a strategy to establish **information asymmetry**[^8] and compensate for the power disbalance among individuals. +It is thus possible that the need for privacy in modern society remains still linked to the power differential. +Without privacy and the information asymmetry it creates, an individual is made vulnerable and its ability to ensure fitness for survival is diminished. + +Compelling animals to remain in contact contrary to their own privacy inclinations, in laboratory settings, has resulted in physiological changes, reproductive failure and adrenal dysfunction[^7]. + +Beyond the privacy of an individual, privacy also has a group-preserving function in the relationship between one group to another[^15]. + +### Connection is a prerequisite for Humans' Survival + +Humans are social species, hardwired for connection. + +> « **Connection is the energy that exists between people when they feel seen, heard and valued; when they can give and receive without judgement; and when they derive sustenance and strength from the relationship.** » — _Brené Brown_ + +Connection is crucial to development; without it, social animals experience distress and face severe developmental consequences[^10]. +Yet, connection can also expose the individual to existential vulnerabilities. + +The risk associated with connection has to be managed. +Without privacy, the need for connection conflicts with the goal of protecting vital interests. +Connection is **not** possible without privacy. + +connectedness + +Privacy is not the opposite of connectedness. + +Connectedness exists on the continuum between fusion and isolation. +Fusion is the state of total absence of boundaries and separateness. +Isolation is the psychological equivalent of death. +It leads to loneliness - correlated with negative effects on health[^11]. + +Humans need connectedness to avoid isolation. Privacy regulates connectedness to avoid fusion (where there is not enough separateness for anything to need connecting). + +To acheive different levels of connectedness on this continuum, an individual needs to balance and regulate, in other words control the access to self. Privacy is thus a necessary condition for connectedness. **There is no connectedness without privacy.** + +### Privacy Works Through Information Asymmetry + +Information asymmetry[^8] is clearly a key concept for privacy as identified by biological studies of privacy in animal societies. + +In the context of a power differential, where an individual interacts with a more powerful entity, the need for management of information asymmetry is twofold: + +- reduce the information given by the less powerfull +- increase the transparency about what the more powerful does with the information obtained.[^9] + +Indeed, in order to selectively control the access to self, the individual has to know what the other party will do if given access to a part of the self. +This two-way understanding of the information asymmetry that privacy seeks to create is the ground on which the legislation around _data minimization_, _transparency of treatment_ and _consent_ is formed. + +## Consequences + +As a key element of connection to others, privacy also impacts our connection to ourselves and our idea of our identity and self-efficacy. Functioning privacy creates a fertile ground for building trust and functional connectedness. Disfunctioning privacy is linked with despair. + +### Privacy Influences Identity + +As we derive the knowledge of self from our relationships with others, the freedom to engage and disengage from those relationships and selectively allow access to self is crucial to our ability to keep our identity safe. + +At the psychological level: + +- privacy supports social interaction, +- social interaction provides feedback on our competence to deal with the world, +- our competence to deal with the world affects our self-definition[^1][^16]. + +Inability to obtain privacy has important psychological consequences ranging from embarrassment and stigma to de-individuation and dehumanization[^16]. + +### Privacy is strongly linked with Trust + +> « **Trust is choosing to make something important to you vulnerable to the actions of someone else.** » — _Charles Feldman_[^20] + +Because privacy is about the access to _self_, and self is clearly of great importance, an individual is expected to choose a particular level of privacy in relation to the level of trust. + +### No Privacy leads to Privacy Fatigue + +Privacy fatigue reflects a sense of weariness toward privacy issues, in which individuals believe that there is no effective means of managing their personal information on the internet[^21]. + +This fatigue, brought on by casual data breaches and the complexity of online privacy control, can reduce users' attention to privacy issues. +Yet, being consistently exposed to a mismatch between what one hopes for and what the environment affords leads to increased psychological strain[^21]. + +Privacy fatigue is closely related to the concept of _learned helplessness_[^23]. +Learned helplessness is the behavior exhibited by a subject after enduring repeated aversive stimuli beyond their control. +The subject affected by this phenomenon discontinues attempts to escape or avoid the aversive stimulus, even when such alternatives are unambiguously presented. +Learned helplessness is linked to a degraded self-efficacy - the individual's belief in their innate ability to achieve goals. +Researchers suggest that clinical depression and related mental illnesses may result from a real or perceived absence of control over the outcome of a situation[^24]. + +Indeed, privacy is related to identity, and to our perception of our own competence to deal with the world[^1][^16]. +Repetetive exposure to technological limitations[^19], as well as the privacy paradox attitude-behavior gap[^12] might situate the explanation of privacy fatigue in the scope of learned helplessness. + + +## Privacy Paradox + +The privacy paradox is a phenomenon in which online users state that they are concerned about their privacy but behave as if they were not.[^12] +Anecdotal and empirical evidence indicates that individuals are willing to trade their personal information for relatively small rewards[^14]. + +However, as we have seen, privacy regulates the conflict of the need for connection with the need for competition, survival and overcoming the power diferential.Habits, and other needs, indeniably play a role in the persons choice of privacy related behavior and may yeald behavior inconsistent with the persons beliefs and interests (as outlined by the _privacy paradox_)[^18]. + +The existence of the privacy paradox is not indicative of a false concern for privacy, but rather of the context not favoring behavior aligned with this concern, as is common with attitude-behavior gap[^13]. +Researchers consider privacy-oblivious behavior to be a result of technological limitations as much as a consequence of users' deficiencies[^19]. + + +## Privacy in Software Systems + +### Internet Systems are Tools For Connection + +The rise of Internet Systems and of the Web[^29] is inspired by the concept of Memex, proposed by Vannevar Bush in 1945 in his article *As We May Think*[^25]. Memex is imagined as a tehorethical machine that humans can use to augment their cognitive powers. Memex can store information and provide access to it at later times. Also Memex is collaborative, as it can facilitate access to information provided by others - a *collective memory-extension tool*. + +Memex was the inspiration for: +- NLS[^26], a system that used the early internet infrastructure to demonstrate the pioneering use of videoconferencing, collaborative document editing, hypermedia, document version control and many other concepts prevalent in modern Internet Systems. Developed in 1968, by Doug Engelbart, it was the first system to implement practical use of hypertext links[^27] for connecting information +- The Wrold Wide Web[^28], created in 1990 by Tim Berners-Lee + +All of modern internet infrastructure and available applications and systems materialize the vision of Memex, where: +- human are connected to information, +- information is connected to information, +- humans are connected to humans. + +### Control is Essential to Human-Computer Interactions + +Having control (having the system respond predictably to user's actions) is one of the key features a user can expect from a properly designed human-computer interaction[^17]. + +Since *privacy is the selective **control** of access to the self*, a computer system, properly designed for connection, must also give the user control over their privacy. + +### Privacy-enabled Connectedness + +In essence, the available knowledge teaches us the following: +- **Internet Systems are tools for connection** +- **There is no connection without exposure of the self** +- **Privacy is the selective control of access to the self** +- **Properly designed computer systems put the user in control** +- **Privacy enables sustainable connection and trust (choosing to make something important to you vulnerable to the actions of someone else)** +- **Connectedness is dysfunctional without privacy** + +Therefore, we believe that a properly designed Internet System is designed for Privacy-enabled Connectedness. + +The Privacy-enabled Connectedness is achieved through the following design principles: + +#### **No Access without Control** + +The system is designed to prevent any form of access to the user or to the user’s data without giving user the control over such access. + +> **Examples** +> +> A system collecting user’s data over a web form and storing the data unencrypted in a database is not designed to prevent any form of access to the user or to the user’s data without giving user the control over such access. A system collecting data end-to-end encrypted for clearly identified target consumers, is. + +#### Distributed Control for Distributed Access + +A system collecting user’s data, that shares this data with other systems, is designed to propagate any access-related instruction given by the user across the receiving systems. (No loose ends) + +> **Examples** +> +> When a user deletes their data from one system, a properly designed system allows the user to have the delete action propagated to other systems to which the data was transmitted. A poorly designed system only deletes the data from its own storage. + +[^1]: Altman I (1975) The environment and social behavior. Wadsworth, Belmont +[^2]: Sedikides, C. & Spencer, S.J. (Eds.) (2007). The Self. New York: Psychology Press +[^3]: [Self in APA Dictionary](https://dictionary.apa.org/self) +[^4]: [Identity in APA Dictionary](https://dictionary.apa.org/identity) +[^5]: Colin Fraser, "Social Psychology" in Richard Gregory, The Oxford Companion to the Mind (Oxford 1987) p. 721-2 +[^6]: Darhl M.Pedersen, [PSYCHOLOGICAL FUNCTIONS OF PRIVACY](https://www.sciencedirect.com/science/article/abs/pii/S0272494497900499) +[^7]: Peter H. Klopfer & Daniel I Rubenstein [The Concept Privacy and Its Biological Basis](https://www.researchgate.net/profile/Daniel-Rubenstein/publication/227655770_The_Concept_Privacy_and_Its_Biological_Basis/links/5ba4eb2045851574f7dbcb99/The-Concept-Privacy-and-Its-Biological-Basis.pdf) +[^8]: [Information Asymmetry](https://en.wikipedia.org/wiki/Information_asymmetry) +[^9]: [Mininal Information Asymmetry](https://privacypatterns.org/patterns/Minimal-Information-Asymmetry) +[^10]: Jaak, Panksepp (2004). Affective Neuroscience : the Foundations of Human and Animal Emotions. Oxford University Press. +[^11]: [Loneliness](https://en.wikipedia.org/wiki/Loneliness) +[^12]: Bedrick, B., Lerner, B., Whitehead, B. "The privacy paradox: Introduction", "News Media and the Law", Washington, DC, Volume 22, Issue 2, Spring 1998, pp. P1–P3. +[^13]: [Attitude-behavior gap](https://en.wikipedia.org/wiki/Value-action_gap) +[^14]: Spyros Kokolakis [Privacy attitudes and privacy behaviour: A review of current research on the privacy paradox phenomenon](https://www.researchgate.net/profile/Spyros-Kokolakis/publication/280244291_Privacy_attitudes_and_privacy_behaviour_A_review_of_current_research_on_the_privacy_paradox_phenomenon/links/5a1bdb5a4585155c26ae08e2/Privacy-attitudes-and-privacy-behaviour-A-review-of-current-research-on-the-privacy-paradox-phenomenon.pdf) +[^15]: Barry Schwartz, [The_Social_Psychology_of_Privacy](https://www.researchgate.net/profile/Barry-Schwartz-2/publication/17491080_The_Social_Psychology_of_Privacy/links/583315c408aef19cb81c8c80/The-Social-Psychology-of-Privacy.pdf) +[^16]: Stephen T. Margulis, [Privacy as a Social Issue and Behavioral Concept](http://www.sfu.ca/~palys/Margulis-2003-PrivacyAsASocialIssue&BehavioralConcept.pdf) +[^17]: Shneiderman, [Eight Golden Rules of Interface Design](http://www.cs.umd.edu/~ben/goldenrules.html) +[^18]: Alessandro Acquisti, [Privacy in Electronic Commerce and the Economics of Immediate Gratification](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.580.5737&rep=rep1&type=pdf) +[^19]: Jochen Peter and Patti M. Valkenburg, [Adolescents' Online Privacy: Toward a Developmental Perspective](https://www.researchgate.net/profile/Patti-Valkenburg/publication/279190144_Adolescents'_Online_Privacy_Toward_a_Developmental_Perspective/links/567028d208ae2b1f87acd4ce/Adolescents-Online-Privacy-Toward-a-Developmental-Perspective.pdf) +[^20]: Charles Feltman, The Thin Book of Trust: An Essential Primer for Building Trust at Work +[^21]: Hanbyul Choia, Jonghwa Parka, Yoonhyuk Jung, [The role of privacy fatigue in online privacy behavior](https://iranarze.ir/wp-content/uploads/2018/04/E6393-IranArze.pdf) +[^23]: [Learned Helplessness](https://en.wikipedia.org/wiki/Learned_helplessness) +[^24]: Seligman ME (1975). Helplessness: On Depression, Development, and Death. San Francisco: W. H. Freeman +[^25]: Bush, Vannevar (1945-07-01). ["As We May Think"](https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/). The Atlantic +[^26]: [NLS](https://en.wikipedia.org/wiki/NLS_(computer_system)) by Doug Engelbart +[^27]: [Hypertext](https://en.wikipedia.org/wiki/Hypertext) +[^28]: [World Wide Web](https://en.wikipedia.org/wiki/World_Wide_Web) +[^29]: The **Internet** is a global network, while the **Web** is a structure of information that is accessed via the Internet From 4dbf32654c00891c13187b26aa72d7e24d2c3e37 Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 8 Jun 2022 10:16:06 +0200 Subject: [PATCH 114/204] Update refs/schemas/priv/dictionary/data-categories/en.data-categories.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- .../priv/dictionary/data-categories/en.data-categories.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index 9b8c04f8..5d2e2d89 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -22,7 +22,7 @@ "DEMOGRAPHIC.RACE": "Data related to race", "DEMOGRAPHIC.SEXUAL-ORIENTATION": "Data related to sexual orientation" "DEVICE": "Data about the device used by a person", - "FINANCIAL": "Data about the financial situation of a person", + "FINANCIAL": "Payment data, financial history and data about the financial situation of a person", "FINANCIAL.BANK-ACCOUNT": "Bank account number and Bank identifier", "GENETIC": "Genetic data", "HEALTH": "Data about the health", From 3e59dfd43689e19a6852d02c2108b4134ca54c86 Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 8 Jun 2022 10:16:15 +0200 Subject: [PATCH 115/204] Update refs/schemas/priv/dictionary/data-categories/en.data-categories.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- .../priv/dictionary/data-categories/en.data-categories.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index 5d2e2d89..8c5101a2 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -23,7 +23,7 @@ "DEMOGRAPHIC.SEXUAL-ORIENTATION": "Data related to sexual orientation" "DEVICE": "Data about the device used by a person", "FINANCIAL": "Payment data, financial history and data about the financial situation of a person", - "FINANCIAL.BANK-ACCOUNT": "Bank account number and Bank identifier", + "FINANCIAL.BANK-ACCOUNT": "Account number for a payment card, bank account, or other financial system", "GENETIC": "Genetic data", "HEALTH": "Data about the health", "IMAGE": "Any graphic representation (e.g., image, video) of the person", From d120f9737e2163ea052c2a60a1be50dfef80e8e2 Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 8 Jun 2022 10:16:32 +0200 Subject: [PATCH 116/204] Update refs/schemas/priv/dictionary/data-categories/en.data-categories.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- .../priv/dictionary/data-categories/en.data-categories.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index 8c5101a2..40406db8 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -1,8 +1,8 @@ { "AFFILIATION": "Groups and Organisations the person is linked to through work, studies, or membership", - "AFFILIATION.WORKPLACE": "Work organisation", - "AFFILIATION.SCHOOL": "Studies organisation", "AFFILIATION.MEMBERSHIP": "Groups and organisations memberships", + "AFFILIATION.SCHOOL": "Studies organisation", + "AFFILIATION.WORKPLACE": "Work organisation", "BEHAVIOR": "Data about the person's behavior", "BEHAVIOR.CONNECTION": "Times of connection", "BEHAVIOR.ACTIVITY": "Activities perfomed online or off-line", From e917222bac157a9a9155ce8d14a4af4525b911f2 Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 8 Jun 2022 10:16:43 +0200 Subject: [PATCH 117/204] Update refs/schemas/priv/dictionary/data-categories/en.data-categories.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- .../priv/dictionary/data-categories/en.data-categories.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index 40406db8..281a55e8 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -4,8 +4,8 @@ "AFFILIATION.SCHOOL": "Studies organisation", "AFFILIATION.WORKPLACE": "Work organisation", "BEHAVIOR": "Data about the person's behavior", - "BEHAVIOR.CONNECTION": "Times of connection", "BEHAVIOR.ACTIVITY": "Activities perfomed online or off-line", + "BEHAVIOR.CONNECTION": "Times of connection", "BEHAVIOR.PREFERENCE": "Data about the person's preferences", "BEHAVIOR.RELATIONSHIPS": "Social activity and interaction data", "BEHAVIOR.TELEMETRY": "Measurement data from system sensors and monitoring", From 1ce69b566486bc07579767d0d50234c5f5f19800 Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 8 Jun 2022 10:16:55 +0200 Subject: [PATCH 118/204] Update refs/schemas/priv/json-schema/priv-terms.schema.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- refs/schemas/priv/json-schema/priv-terms.schema.json | 2 ++ 1 file changed, 2 insertions(+) diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json index 74c0050f..3da5cde2 100644 --- a/refs/schemas/priv/json-schema/priv-terms.schema.json +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -35,6 +35,8 @@ "BEHAVIOR.ACTIVITY", "BEHAVIOR.CONNECTION", "BEHAVIOR.PREFERENCE", + "BEHAVIOR.RELATIONSHIPS", + "BEHAVIOR.TELEMETRY", "BIOMETRIC", "CONTACT", "CONTACT.EMAIL", From e3d051e50b8b6f611cf0a7d0aac3e16b032d783b Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 8 Jun 2022 10:17:08 +0200 Subject: [PATCH 119/204] Update refs/schemas/priv/json-schema/priv-terms.schema.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- refs/schemas/priv/json-schema/priv-terms.schema.json | 1 + 1 file changed, 1 insertion(+) diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json index 3da5cde2..f08a34ed 100644 --- a/refs/schemas/priv/json-schema/priv-terms.schema.json +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -48,6 +48,7 @@ "DEMOGRAPHIC.GENDER", "DEMOGRAPHIC.ORIGIN", "DEMOGRAPHIC.RACE", + "DEMOGRAPHIC.SEXUAL-ORIENTATION", "DEVICE", "FINANCIAL", "FINANCIAL.BANK-ACCOUNT", From 372eb19488ef6109544dcb6161ae73b18893f009 Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 8 Jun 2022 10:17:35 +0200 Subject: [PATCH 120/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 1981e7d5..eb00d359 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -162,7 +162,7 @@ Privacy Scope = (Data Categories) x (Categories of Processing) x (Purposes of Pr | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-categories` | 0-* | `AFFILIATION`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`,`RELATIONSHIPS`, `PROFILING`, `UID`, `OTHER` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | +| `data-categories` | 0-* | `AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.RELATIONSHIPS`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, `OTHER` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | When several values are given, Systems MUST interpret the `data-category` dimension as a union of all the categories indicated. From 3c4237df99c1fb5e8c7d6c702efb108f4712767c Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 8 Jun 2022 10:17:58 +0200 Subject: [PATCH 121/204] Update refs/schemas/priv/json-schema/priv-terms.schema.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- refs/schemas/priv/json-schema/priv-terms.schema.json | 3 +++ 1 file changed, 3 insertions(+) diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json index f08a34ed..6f9a2317 100644 --- a/refs/schemas/priv/json-schema/priv-terms.schema.json +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -31,6 +31,9 @@ "data-categories": { "enum": [ "AFFILIATION", + "AFFILIATION.WORKPLACE", + "AFFILIATION.SCHOOL", + "AFFILIATION.MEMBERSHIP", "BEHAVIOR", "BEHAVIOR.ACTIVITY", "BEHAVIOR.CONNECTION", From f8d4272c7703bbe81e75db32ae641a987c927bf2 Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 8 Jun 2022 10:18:13 +0200 Subject: [PATCH 122/204] Update refs/schemas/priv/json-schema/priv-terms.schema.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- refs/schemas/priv/json-schema/priv-terms.schema.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json index 6f9a2317..d21d9d99 100644 --- a/refs/schemas/priv/json-schema/priv-terms.schema.json +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -60,8 +60,8 @@ "IMAGE", "LOCATION", "NAME", - "RELATIONSHIPS", "PROFILING", + "RELATIONSHIPS", "UID" ] }, From 50c6357a5f018d830fd8ac7c8c12b7ae96d358fc Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Wed, 8 Jun 2022 16:47:46 +0200 Subject: [PATCH 123/204] Added Transcend demand type representation --- refs/schemas/priv/examples.md | 40 +++++++++++++++++------------------ 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 469cd8cb..e5e129f2 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -201,14 +201,16 @@ In the following examples we show how, requests introduced by different regulati | `1798.130.1.1` | Make available to consumers two or more designated methods for submitting requests for information, including, at a minimum, a toll-free telephone number. | `X` | `null` | `null` | `null` | `null` | `null` | | `1798.130.1.2` | Disclose and deliver the required information to a consumer free of charge within 45 days of receiving a verifiable consumer request from the consumer. | `X` | `null` | `null` | `null` | `null` | `null` | -### Ethyca data categories +### Alternatives Considered + +#### Ethyca data categories > [Ethyca data categories reference](https://ethyca.github.io/fideslang/data_categories/) -#### Account Data Categories +##### Account Data Categories > Data related to an account on the system -##### Account Contact Data +###### Account Contact Data | Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment | | ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | @@ -221,13 +223,13 @@ In the following examples we show how, requests introduced by different regulati | **account.contact** | **state** | Account's state level address data | `CONTACT.ADDRESS` | `null` | `null` | Need a more detailed cat ? | | **account.contact** | **street** | Account's street level address | `CONTACT.ADDRESS` | `null` | `null` | Need a more detailed cat ? | -##### Account Payment Data +###### Account Payment Data | Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | | ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | | **account** | **payment** | Payment data related to system account | `FINANCIAL` | `null` | `null` | Broader definition ? | | **account.payment** | **financial_account_number** | Payment data related to system account | `FINANCIAL.BANK-ACCOUNT` | `null` | `null` | `null` | -#### System Data Categories +##### System Data Categories > Data unique to, and under control of the system | Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | @@ -235,12 +237,12 @@ In the following examples we show how, requests introduced by different regulati | **system** | **authentication** | Data used to manage access to the system | `**TBD**` | `null` | `null` | Add AUTHENTICATION ? (as a meta cat of biometric ?) | | **system** | **operations** | Data used for system operations | `**Any/all**` | `**Any/all**` | `null` | Ok ? | -#### User Data Categories +##### User Data Categories > Data related to the user of the system > The "User" data category has two important subcategories for derived and provided data > In turn, derived and provided both have subcategories for identifiable and nonidentifiable data, to make it clear what data is considered identifiable in your systems -##### User Derived Data +###### User Derived Data > Data derived from user provided data or as a result of user actions in the system | Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | @@ -273,7 +275,7 @@ In the following examples we show how, requests introduced by different regulati | **user.derived** | **nonidentifiable** | Non-user identifiable data derived related to a user as a result of user actions in the system | `**TBD**` | `null` | `null` | TBD, do we need that ? | | **user.derived.nonidentifiable** | **nonsensor** | Non-user identifiable measurement data derived from sensors and monitoring systems | `**TBD**` | `null` | `null` | TBD, do we need that ? | -##### User Provided Data +###### User Provided Data > Data provided or created directly by a user of the system | Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | @@ -312,22 +314,20 @@ In the following examples we show how, requests introduced by different regulati | **user.provided.identifiable** | **passport_number** | State issued passport data | `UID` | `null` | `null` | `null`| | **user.provided** | **nonidentifiable** | Data provided or created directly by a user that is not identifiable | `**TBD**` | `null` | `null` | TBD: Do we need that ?| -### Alternatives Considered - #### Transcend Transcend proposes the following [action (demand) types](https://github.com/transcend-io/privacy-types/blob/main/src/actions.ts): -| Demand Type | Description | Observation | +| Transcend Demand Type | Transcend Description | Representation | | -------------- | ----------------------------------------- | ------------------------ | -| ACCESS | Data Download request | | -| ERASURE | Erase the file completely | | -| ACCOUNT_DELETION | Run an account deletion instead of a fully compliant deletion | | -| AUTOMATED_DECISION_MAKING_OPT_OUT | Opt out of automated decision making | | -| CONTACT_OPT_OUT | A contact opt out request | | -| SALE_OPT_OUT | Opt-out of the sale of personal data | | -| TRACKING_OPT_OUT | A tracking opt out request | | -| RECTIFICATION | Make an update to an inaccurate record | | -| RESTRICTION | A restriction of processing request | | +| ACCESS | Data Download request | action:`ACCESS` | +| ERASURE | Erase the file completely | action:`DELETE`, other properties:`Data-identifier` | +| ACCOUNT_DELETION | Run an account deletion instead of a fully compliant deletion | action:`DELETE`, other properties: `Data-identifier` | +| AUTOMATED_DECISION_MAKING_OPT_OUT | Opt out of automated decision making | action:`RESTRICT`, processing-categories:`AUTOMATED-DECISION-MAKING`| +| CONTACT_OPT_OUT | A contact opt out request | action:`RESTRICT`, data-category:`CONTACT`, processing-category:`USING`, purpose:`MARKETING`| +| SALE_OPT_OUT | Opt-out of the sale of personal data | action:`RESTRICT`, processing-category:`SHARE`, purpose:`SALE` | +| TRACKING_OPT_OUT | A tracking opt out request | action:`RESTRICT`, processing-category:`COLLECTION`, purpose:`TRACKING` | +| RECTIFICATION | Make an update to an inaccurate record | action:`MODIFY`, other properties: `Selector.to-modify`,`Data.rectified` | +| RESTRICTION | A restriction of processing request | action:`RESTRICT` | All of those can be modeled using our Demand Types. From f6601a4bb2b5011a3f38076b21e22352c3963c09 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Wed, 8 Jun 2022 17:07:41 +0200 Subject: [PATCH 124/204] Added Transcend treatment representation --- refs/schemas/priv/examples.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index e5e129f2..a63ccf56 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -331,22 +331,22 @@ Transcend proposes the following [action (demand) types](https://github.com/tran All of those can be modeled using our Demand Types. -Transced proposes the following [treatment types](https://github.com/transcend-io/privacy-types/blob/main/src/objects.ts): -| Treatment Type | Description | Observation | +Transcend proposes the following [treatment types](https://github.com/transcend-io/privacy-types/blob/main/src/objects.ts): +| Transcend Treatment Type | Transcend Description | Representation | | -------------- | ----------------------------------------- | ------------------------ | -| ESSENTIAL | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality| | -| ADDITIONAL_FUNCTIONALITY | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | | -| ADVERTISING | To show ads that are either targeted to the specific user or not targeted | | -| MARKETING | To contact the user to offer products, services, or other promotions | | -| ANALYTICS | For understanding the product’s audience, improving the product, inform company strategy, or general research | | -| PERSONALIZATION | For providing user with a personalized experience | | -| OPERATION_SECURITY | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | | -| LEGAL | For compliance with legal obligations | | -| TRANSFER | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | | -| SALE | For selling the data to third parties | | -| HR | For personnel training, recruitment, payroll, management, etc. | corresponds to ongoing contract in our terminology| -| OTHER | Other specific purpose not covered above | | -| UNSPECIFIED | The purpose is not explicitly stated or is unclear | | +| ESSENTIAL | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality| processing-category:`**any/all**`, purpose:`SERVICES.BASIC-SERVICE` | +| ADDITIONAL_FUNCTIONALITY | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | processing-category:`**any/all**`, purpose:`SERVICES.ADDITIONAL-SERVICE` | +| ADVERTISING | To show ads that are either targeted to the specific user or not targeted | processing-category:`**any/all**`, purpose:`ADVERTISING` | +| MARKETING | To contact the user to offer products, services, or other promotions | processing-category:`**any/all**`, purpose:`MARKETING` | +| ANALYTICS | For understanding the product’s audience, improving the product, inform company strategy, or general research | processing-category:`**any/all**`, purpose:`RESEARCH` | +| PERSONALIZATION | For providing user with a personalized experience | processing-category:`**any/all**`, purpose:`PERSONALISATION` | +| OPERATION_SECURITY | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | processing-category:`**any/all**`, purpose:`SECURITY` | +| LEGAL | For compliance with legal obligations | processing-category:`**any/all**`, purpose:`COMPLIANCE` | +| TRANSFER | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | processing-category:`**any/all**`, purpose:`OTHER` | +| SALE | For selling the data to third parties | processing-category:`**any/all**`, purpose:`SALE` | +| HR | For personnel training, recruitment, payroll, management, etc. | processing-category:`**any/all**`, purpose:`COMPLIANCE` | +| OTHER | Other specific purpose not covered above | processing-category:`**any/all**`, purpose:`OTHER` | +| UNSPECIFIED | The purpose is not explicitly stated or is unclear | processing-category:`**any/all**`, purpose:`OTHER` | All of those SHOULD be modeled using our Treatment Types. From c34884f499524b74a1fd9eb76f1d448d949f8f65 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Wed, 8 Jun 2022 17:18:32 +0200 Subject: [PATCH 125/204] Added Transcend data categories representation --- refs/schemas/priv/examples.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index a63ccf56..c48ef9b2 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -350,24 +350,24 @@ Transcend proposes the following [treatment types](https://github.com/transcend- All of those SHOULD be modeled using our Treatment Types. -Transced proposes the following [data categories](https://github.com/transcend-io/privacy-types/blob/main/src/objects.ts): -| Data Category | Description | Observation | +Transcend proposes the following [data categories](https://github.com/transcend-io/privacy-types/blob/main/src/objects.ts): +| Transcend Data Category | Transcend Description | Representation | | -------------- | ----------------------------------------- | ------------------------ | -| FINANCIAL | Financial information | | -| HEALTH | Health information | | -| CONTACT | Contact information | | -| LOCATION | Geo-location information | | -| DEMOGRAPHIC | Demographic Information | | -| ID | Identifiers that uniquely identify a person | | -| ONLINE_ACTIVITY | The user's online activities on the first party website/app or other websites/apps | | -| USER_PROFILE | he user’s profile on the first-party website/app and its contents | | -| SOCIAL_MEDIA | User profile and data from a social media website/app or other third party service | | -| CONNECTION | Connection information for the current browsing session, e.g. device IDs, MAC addresses, IP addresses, etc. | | -| TRACKING | Cookies and tracking elements | | -| DEVICE | Computer or device information | | -| SURVEY | Any data that is collected through surveys | | -| OTHER | A specific type of information not covered by the above categories | | -| UNSPECIFIED | The type of information is not explicitly stated or unclear| | +| FINANCIAL | Financial information | data-category:`FINANCIAL` | +| HEALTH | Health information | data-category:`HEALTH` | +| CONTACT | Contact information | data-category:`CONTACT` | +| LOCATION | Geo-location information | data-category:`LOCATION` | +| DEMOGRAPHIC | Demographic Information | data-category:`DEMOGRAPHIC` | +| ID | Identifiers that uniquely identify a person | data-category:`UID` | +| ONLINE_ACTIVITY | The user's online activities on the first party website/app or other websites/apps | data-category:`BEHAVIOR.ACTIVITY` | +| USER_PROFILE | he user’s profile on the first-party website/app and its contents | data-category:`OTHER` | +| SOCIAL_MEDIA | User profile and data from a social media website/app or other third party service | data-category:`OTHER`,`BEHAVIOR.RELATIONSHIPS` | +| CONNECTION | Connection information for the current browsing session, e.g. device IDs, MAC addresses, IP addresses, etc. | data-category:`DEVICE`,`BEHAVIOR.CONNECTION` | +| TRACKING | Cookies and tracking elements | data-category:`BEHAVIOR` | +| DEVICE | Computer or device information | data-category:`DEVICE` | +| SURVEY | Any data that is collected through surveys | data-category:`OTHER` | +| OTHER | A specific type of information not covered by the above categories | data-category:`OTHER` | +| UNSPECIFIED | The type of information is not explicitly stated or unclear| data-category:`OTHER` | From 3c29472b9f0b7fc288e123bad5b4901d8f1f4777 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Wed, 8 Jun 2022 17:54:52 +0200 Subject: [PATCH 126/204] Updated format for ### BASIC GDPR REQUESTS --- refs/schemas/priv/examples.md | 88 +++++++++++++++++------------------ 1 file changed, 44 insertions(+), 44 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index c48ef9b2..f340b726 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -38,68 +38,68 @@ In the following examples we show how, requests introduced by different regulati *...the controller shall, ..., provide the data subject with all of the following information:* -| CODENAME | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | -| -------- | ----------------------------------------------------- | ------------ | ------------ | ------------ | ------------ | -| `GDPR.13.1.a`, `GDPR.14.1.a` | the identity and the contact details of the controller and, where applicable, of the controller’s representative | `TRANSPARENCY.ORGANISATION` | `null` | `null` | `null` | -| `GDPR.13.1.b`, `GDPR.14.1.b` | the contact details of the data protection officer, where applicable; | `TRANSPARENCY.DPO` | `null` | `null` | `null` | -| `GDPR.13.1.c`, `GDPR.14.1.c` | the purposes of the processing for which the personal data are intended | `TRANSPARENCY.PURPOSE` | `null` | `null` | `null` | -| `GDPR.13.1.c`, `GDPR.14.1.c` | ... legal basis for the processing | `TRANSPARENCY.LEGAL-BASES` | `null` | `null` | `null` | -| `GDPR.13.1.d`, `GDPR.14.1.d` | where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party | `TRANSPARENCY.LEGAL-BASES` | `null` | `null` | `null` | -| `GDPR.13.1.e`, `GDPR.14.1.e` | the recipients or categories of recipients of the personal data, if any; | `TRANSPARENCY.WHO` | `null` | `null` | `null` | -| `GDPR.13.1.f`, `GDPR.14.1.f` | where applicable, the fact that the controller intends to transfer personal data to a third country or international organisation | `TRANSPARENCY.WHERE` | `null` | `null` | `null` | -| `GDPR.13.1.f`, `GDPR.14.1.f` | the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means by which to obtain a copy of them or where they have been made available. | `OTHER` | `null` | `null` | `null` | -| `GDPR.13.2.a`, `GDPR.14.2.a` | the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | -| `GDPR.13.2.b`, `GDPR.14.2.b` | the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | -| `GDPR.13.2.c`, `GDPR.14.2.c` | where the processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | -| `GDPR.13.2.d`, `GDPR.14.2.d` | the right to lodge a complaint with a supervisory authority | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | -| `GDPR.13.2.e`, `GDPR.14.2.e` | whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data | `TRANSPARENCY.PURPOSE` | `null` | `null` | `null` | -| `GDPR.13.2.e`, `GDPR.14.2.e` | ... and of the possible consequences of failure to provide such data | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | -| `GDPR.13.2.f`, `GDPR.14.2.f` | the existence of automated decision-making, including profiling | `TRANSPARENCY.PROCESSING` | `null` | `null` | `null` | -| `GDPR.13.2.f`, `GDPR.14.2.g` | the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject. | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | -| `GDPR.14.2.f` | from which source the personal data originate, and if applicable, whether it came from publicly accessible sources; | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | +| Law | Demande (as introduced by regulation) | Representation | +| -------- | ----------------------------------------------------- | ------------ | +| `GDPR.13.1.a`, `GDPR.14.1.a` | the identity and the contact details of the controller and, where applicable, of the controller’s representative | action:`TRANSPARENCY.ORGANISATION` | +| `GDPR.13.1.b`, `GDPR.14.1.b` | the contact details of the data protection officer, where applicable; | action:`TRANSPARENCY.DPO` | +| `GDPR.13.1.c`, `GDPR.14.1.c` | the purposes of the processing for which the personal data are intended | action:`TRANSPARENCY.PURPOSE` | +| `GDPR.13.1.c`, `GDPR.14.1.c` | ... legal basis for the processing | action:`TRANSPARENCY.LEGAL-BASES` | +| `GDPR.13.1.d`, `GDPR.14.1.d` | where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party | action:`TRANSPARENCY.LEGAL-BASES` | +| `GDPR.13.1.e`, `GDPR.14.1.e` | the recipients or categories of recipients of the personal data, if any; | action:`TRANSPARENCY.WHO` | +| `GDPR.13.1.f`, `GDPR.14.1.f` | where applicable, the fact that the controller intends to transfer personal data to a third country or international organisation | action:`TRANSPARENCY.WHERE` | +| `GDPR.13.1.f`, `GDPR.14.1.f` | the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means by which to obtain a copy of them or where they have been made available. | action:`OTHER` | +| `GDPR.13.2.a`, `GDPR.14.2.a` | the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period | action:`TRANSPARENCY.RETENTION` | +| `GDPR.13.2.b`, `GDPR.14.2.b` | the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability | action:`TRANSPARENCY.POLICY` | +| `GDPR.13.2.c`, `GDPR.14.2.c` | where the processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal | action:`TRANSPARENCY.POLICY` | +| `GDPR.13.2.d`, `GDPR.14.2.d` | the right to lodge a complaint with a supervisory authority | action:`TRANSPARENCY.POLICY` | +| `GDPR.13.2.e`, `GDPR.14.2.e` | whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data | action:`TRANSPARENCY.PURPOSE` | +| `GDPR.13.2.e`, `GDPR.14.2.e` | ... and of the possible consequences of failure to provide such data | action:`TRANSPARENCY.POLICY` | +| `GDPR.13.2.f`, `GDPR.14.2.f` | the existence of automated decision-making, including profiling | action:`TRANSPARENCY.PROCESSING` | +| `GDPR.13.2.f`, `GDPR.14.2.g` | the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject. | action:`TRANSPARENCY.POLICY` | +| `GDPR.14.2.f` | from which source the personal data originate, and if applicable, whether it came from publicly accessible sources; | action:`TRANSPARENCY.PROVENANCE` | #### Article 15.1 *The data subject shall have the right to obtain from the controller confirmation as to whether or not personal data concerning him or her are being processed* -| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | -| -------- | ----------------------------------------------------- | ------------ | ------------ | ------------ | ------------ | -| `GDPR.15.1` | confirmation as to whether or not personal data concerning him or her are being processed | `TRANSPARENCY.KNOW` | `null` | `null` | `null` | +| LAW | Demande (as introduced by regulation) | Representation | +| -------- | ----------------------------------------------------- | ------------ | +| `GDPR.15.1` | confirmation as to whether or not personal data concerning him or her are being processed | action:`TRANSPARENCY.KNOW` | *and, where that is the case, access to the personal data and the following information:* -| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | +| LAW | Demande (as introduced by regulation) | Representation | | -------- | ----------------------------------------------------- | ------------ | ------------ | ------------ | ------------ | -| `GDPR.15.1.a` | the purposes of the processing | `TRANSPARENCY.PURPOSE` | `null` | `null` | `null` | -| `GDPR.15.1.b` | the categories of personal data concerned | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `null` | `null` | -| `GDPR.15.1.c` | the recipients or categories of recipient to whom the personal data have been or will be disclosed, in particular recipients in third countries or international organisations; | `TRANSPARENCY.WHO` | `null` | `null` | `null` | -| `GDPR.15.1.d` | where possible, the envisaged period for which the personal data will be stored, or, if not possible, the criteria used to determine that period; | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | -| `GDPR.15.1.e` | the existence of the right to request from the controller rectification or erasure of personal data or restriction of processing of personal data concerning the data subject or to object to such processing; | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | -| `GDPR.15.1.f` | the right to lodge a complaint with a supervisory authority | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | -| `GDPR.15.1.g` | where the personal data are not collected from the data subject, any available information as to their source | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | -| `GDPR.15.1.h` | the existence of automated decision-making, including profiling | `TRANSPARENCY.PROCESSING` | `null` | `null` | `null` | -| `GDPR.15.1.h` | the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | +| `GDPR.15.1.a` | the purposes of the processing | action:`TRANSPARENCY.PURPOSE` | +| `GDPR.15.1.b` | the categories of personal data concerned | action:`TRANSPARENCY.DATA-CATEGORIES` | +| `GDPR.15.1.c` | the recipients or categories of recipient to whom the personal data have been or will be disclosed, in particular recipients in third countries or international organisations; | action:`TRANSPARENCY.WHO` | +| `GDPR.15.1.d` | where possible, the envisaged period for which the personal data will be stored, or, if not possible, the criteria used to determine that period; | action:`TRANSPARENCY.RETENTION` | +| `GDPR.15.1.e` | the existence of the right to request from the controller rectification or erasure of personal data or restriction of processing of personal data concerning the data subject or to object to such processing; | action:`TRANSPARENCY.POLICY` | +| `GDPR.15.1.f` | the right to lodge a complaint with a supervisory authority | action:`TRANSPARENCY.POLICY` | +| `GDPR.15.1.g` | where the personal data are not collected from the data subject, any available information as to their source | action:`TRANSPARENCY.PROVENANCE` | +| `GDPR.15.1.h` | the existence of automated decision-making, including profiling | action:`TRANSPARENCY.PROCESSING` | +| `GDPR.15.1.h` | the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject | action:`TRANSPARENCY.POLICY` | >**Note** > > To make a request to know if the System has data on them (`GDPR.15.1`) and know about the purposes of processing of that data, the Data Subject MUST make a request with two demands, one `TRANSPARENCY.KNOW` and one `TRANSPARENCY.PURPOSE` #### Article 15.2 and 15.3 -| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | -| -------- | ----------------------------------------------------- | ------------ | ------------ | ------------ | ------------ | -| `GDPR.15.2` | Where personal data are transferred to a third country or to an international organisation, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | -| `GDPR.15.3` | The controller shall provide a copy of the personal data undergoing processing. | `ACCESS` | `null` | `null` | `null` | +| LAW | Demande (as introduced by regulation) | Representation | +| -------- | ----------------------------------------------------- | ------------ | +| `GDPR.15.2` | Where personal data are transferred to a third country or to an international organisation, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer | action:`TRANSPARENCY.POLICY` | +| `GDPR.15.3` | The controller shall provide a copy of the personal data undergoing processing | action:`ACCESS` | #### Article 16-22 -| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | -| -------- | ----------------------------------------------------- | ------------ | ------------ | ------------ | ------------ | -| `GDPR.16` | The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. 2Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement. | `MODIFY` | `null` | `null` | `null` | -| `GDPR.17` | The data subject shall have the right to obtain from the controller the erasure of personal data concerning him | `DELETE` | `null` | `null` | `null` | -| `GDPR.18` | The data subject shall have the right to obtain from the controller restriction of processing | `RESTRICT` | `null` | `null` | `null` | -| `GDPR.20` | The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided | `PORTABILITY` | `null` | `null` | `null` | -| `GDPR.21` | The data subject shall have the right to object, on grounds relating to his or her particular situation, at any time to processing of personal data concerning him or her which is based on point (e) or (f) of Article 6(1), including profiling based on those provisions. *(note: 21.2 is not yet supported by the schema)*| `**RESTRICT?**` | `null` | `**+all?**` | `null` | -| `GDPR.22` | The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her | `RESTRICT` | `null` | `AUTOMATED-DECISION-MAKING` | `null` | +| LAW | Demande (as introduced by regulation) | Representation | +| -------- | ----------------------------------------------------- | ------------ | +| `GDPR.16` | The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. 2Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement. | action:`MODIFY` | +| `GDPR.17` | The data subject shall have the right to obtain from the controller the erasure of personal data concerning him | action:`DELETE` | +| `GDPR.18` | The data subject shall have the right to obtain from the controller restriction of processing | action:`RESTRICT` | +| `GDPR.20` | The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided | action:`PORTABILITY` | +| `GDPR.21` | The data subject shall have the right to object, on grounds relating to his or her particular situation, at any time to processing of personal data concerning him or her which is based on point (e) or (f) of Article 6(1), including profiling based on those provisions. *(note: 21.2 is not yet supported by the schema)*| action:`RESTRICT` | +| `GDPR.22` | The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her | action:`RESTRICT`, processing-category:`AUTOMATED-DECISION-MAKING` | From c446b5c6985b3fc25b2f8aa6576a1fed361af344 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Wed, 8 Jun 2022 17:55:49 +0200 Subject: [PATCH 127/204] Typo --- refs/schemas/priv/examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index f340b726..383415d8 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -69,7 +69,7 @@ In the following examples we show how, requests introduced by different regulati *and, where that is the case, access to the personal data and the following information:* | LAW | Demande (as introduced by regulation) | Representation | -| -------- | ----------------------------------------------------- | ------------ | ------------ | ------------ | ------------ | +| -------- | ----------------------------------------------------- | ------------ | | `GDPR.15.1.a` | the purposes of the processing | action:`TRANSPARENCY.PURPOSE` | | `GDPR.15.1.b` | the categories of personal data concerned | action:`TRANSPARENCY.DATA-CATEGORIES` | | `GDPR.15.1.c` | the recipients or categories of recipient to whom the personal data have been or will be disclosed, in particular recipients in third countries or international organisations; | action:`TRANSPARENCY.WHO` | From e824cff395808204574354be397ef08c44ec4b7d Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Wed, 8 Jun 2022 18:13:48 +0200 Subject: [PATCH 128/204] Update Transcend representation --- refs/schemas/priv/examples.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 383415d8..86eaa55a 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -342,9 +342,9 @@ Transcend proposes the following [treatment types](https://github.com/transcend- | PERSONALIZATION | For providing user with a personalized experience | processing-category:`**any/all**`, purpose:`PERSONALISATION` | | OPERATION_SECURITY | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | processing-category:`**any/all**`, purpose:`SECURITY` | | LEGAL | For compliance with legal obligations | processing-category:`**any/all**`, purpose:`COMPLIANCE` | -| TRANSFER | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | processing-category:`**any/all**`, purpose:`OTHER` | +| TRANSFER | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | processing-category:`COLLECTION`, provenance:`TRANSFERRED` | | SALE | For selling the data to third parties | processing-category:`**any/all**`, purpose:`SALE` | -| HR | For personnel training, recruitment, payroll, management, etc. | processing-category:`**any/all**`, purpose:`COMPLIANCE` | +| HR | For personnel training, recruitment, payroll, management, etc. | processing-category:`**any/all**`, purpose:`EMPLOYMENT` | | OTHER | Other specific purpose not covered above | processing-category:`**any/all**`, purpose:`OTHER` | | UNSPECIFIED | The purpose is not explicitly stated or is unclear | processing-category:`**any/all**`, purpose:`OTHER` | From f01477fa049da5aa2984c4d764d3ae21f3b21c42 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Wed, 8 Jun 2022 18:15:40 +0200 Subject: [PATCH 129/204] Update Transcend data cat representation --- refs/schemas/priv/examples.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 86eaa55a..9b5c790c 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -360,8 +360,8 @@ Transcend proposes the following [data categories](https://github.com/transcend- | DEMOGRAPHIC | Demographic Information | data-category:`DEMOGRAPHIC` | | ID | Identifiers that uniquely identify a person | data-category:`UID` | | ONLINE_ACTIVITY | The user's online activities on the first party website/app or other websites/apps | data-category:`BEHAVIOR.ACTIVITY` | -| USER_PROFILE | he user’s profile on the first-party website/app and its contents | data-category:`OTHER` | -| SOCIAL_MEDIA | User profile and data from a social media website/app or other third party service | data-category:`OTHER`,`BEHAVIOR.RELATIONSHIPS` | +| USER_PROFILE | he user’s profile on the first-party website/app and its contents | data-category:`UID.USER-ACCOUNT` | +| SOCIAL_MEDIA | User profile and data from a social media website/app or other third party service | data-category:`UID.SOCIAL-MEDIA` | | CONNECTION | Connection information for the current browsing session, e.g. device IDs, MAC addresses, IP addresses, etc. | data-category:`DEVICE`,`BEHAVIOR.CONNECTION` | | TRACKING | Cookies and tracking elements | data-category:`BEHAVIOR` | | DEVICE | Computer or device information | data-category:`DEVICE` | From 4da136331de357d6e499d0ed37375032287dc0cd Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Wed, 8 Jun 2022 18:24:23 +0200 Subject: [PATCH 130/204] Update examples.md --- refs/schemas/priv/examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 9b5c790c..54cbb007 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -363,7 +363,7 @@ Transcend proposes the following [data categories](https://github.com/transcend- | USER_PROFILE | he user’s profile on the first-party website/app and its contents | data-category:`UID.USER-ACCOUNT` | | SOCIAL_MEDIA | User profile and data from a social media website/app or other third party service | data-category:`UID.SOCIAL-MEDIA` | | CONNECTION | Connection information for the current browsing session, e.g. device IDs, MAC addresses, IP addresses, etc. | data-category:`DEVICE`,`BEHAVIOR.CONNECTION` | -| TRACKING | Cookies and tracking elements | data-category:`BEHAVIOR` | +| TRACKING | Cookies and tracking elements | data-category:`BEHAVIOR`, purpose:`TRACKING` | | DEVICE | Computer or device information | data-category:`DEVICE` | | SURVEY | Any data that is collected through surveys | data-category:`OTHER` | | OTHER | A specific type of information not covered by the above categories | data-category:`OTHER` | From 79dd41fb768ba46024f65ab94658ceb6dff9e245 Mon Sep 17 00:00:00 2001 From: Milan Date: Thu, 9 Jun 2022 00:50:34 +0200 Subject: [PATCH 131/204] Update refs/schemas/priv/dictionary/data-categories/en.data-categories.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- .../priv/dictionary/data-categories/en.data-categories.json | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index 281a55e8..d88323f3 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -31,6 +31,8 @@ "NAME": "First names, last names, nicknames, and other names", "PROFILING": "Any data establishing a degree of similarity of the person with others (e.g., clusters, user-profiles)", "RELATIONSHIPS": "Data about relationships of the person with others", - "UID": "Any data allowing to uniquely idnetify a person", + "UID": "Any data allowing to uniquely identify a person", + "UID.USER-ACCOUNT": "Data about a person's account or profile on the first-party website/app and its contents", + "UID.SOCIAL-MEDIA": "Data about a person's account or profile from a social media website/app or other third party service", "OTHER": "Other data" } From 241d09fed882f25bebd465c074f3a16506877ac4 Mon Sep 17 00:00:00 2001 From: Milan Date: Thu, 9 Jun 2022 00:51:02 +0200 Subject: [PATCH 132/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index eb00d359..dc94d277 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -162,7 +162,7 @@ Privacy Scope = (Data Categories) x (Categories of Processing) x (Purposes of Pr | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-categories` | 0-* | `AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.RELATIONSHIPS`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, `OTHER` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | +| `data-categories` | 0-* | `AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.RELATIONSHIPS`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, UID.USER-ACCOUNT , UID.SOCIAL-MEDIA , `OTHER` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | When several values are given, Systems MUST interpret the `data-category` dimension as a union of all the categories indicated. From 346d37f8d64eb5c702eb83eea943db47fd284ca5 Mon Sep 17 00:00:00 2001 From: Milan Date: Thu, 9 Jun 2022 00:51:19 +0200 Subject: [PATCH 133/204] Update refs/schemas/priv/dictionary/purposes/en.purposes.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- refs/schemas/priv/dictionary/purposes/en.purposes.json | 1 + 1 file changed, 1 insertion(+) diff --git a/refs/schemas/priv/dictionary/purposes/en.purposes.json b/refs/schemas/priv/dictionary/purposes/en.purposes.json index 7edb7f58..5f87e87d 100644 --- a/refs/schemas/priv/dictionary/purposes/en.purposes.json +++ b/refs/schemas/priv/dictionary/purposes/en.purposes.json @@ -1,6 +1,7 @@ { "ADVERTISING": "To show ads that are either targeted to the specific user or not targeted", "COMPLIANCE": "Processing is performed to comply with a legal obligation", + "EMPLOYMENT": " For personnel training, recruitment, payroll, management, etc", "JUSTICE": "processing is necessary for the establishment, exercise or defence of legal claims or whenever courts are acting in their judicial capacity", "MARKETING": "To contact the user to offer products, services, or other promotions", "MEDICAL": "Processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services", From 48d60c2be0912bbf504e6c81b6b3280db6298d79 Mon Sep 17 00:00:00 2001 From: Milan Date: Thu, 9 Jun 2022 00:52:17 +0200 Subject: [PATCH 134/204] Update refs/schemas/priv/json-schema/priv-terms.schema.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- .../priv/json-schema/priv-terms.schema.json | 35 ++++++++++--------- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json index d21d9d99..d079013e 100644 --- a/refs/schemas/priv/json-schema/priv-terms.schema.json +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -80,23 +80,24 @@ }, "purposes": { "enum": [ - "ADVERTISING", - "CONTRACT", - "CONTRACT.BASIC-SERVICE", - "CONTRACT.ADDITIONAL-SERVICES", - "NECESSARY", - "NECESSARY.JUSTICE", - "NECESSARY.LEGAL", - "NECESSARY.MEDICAL", - "NECESSARY.PUBLIC-INTERESTS", - "NECESSARY.VITAL-INTERESTS", - "NECESSARY.SOCIAL-PROTECTION", - "MARKETING", - "PERSONALISATION", - "SALE", - "SECURITY", - "TRACKING", - "ANY" + "ADVERTISING", + "COMPLIANCE", + "EMPLOYMENT", + "JUSTICE", + "MARKETING", + "MEDICAL", + "PERSONALISATION", + "PUBLIC-INTERESTS", + "RESEARCH", + "SALE", + "SECURITY", + "SERVICES", + "SERVICES.ADDITIONAL-SERVICES", + "SERVICES.BASIC-SERVICE", + "SOCIAL-PROTECTION", + "TRACKING", + "VITAL-INTERESTS", + "OTHER", ] }, "targets": { From 7182dcb28f6ad49bd8aef0768375d283fd5ffea4 Mon Sep 17 00:00:00 2001 From: Milan Date: Thu, 9 Jun 2022 00:54:36 +0200 Subject: [PATCH 135/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index dc94d277..2df5cd23 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -190,7 +190,7 @@ In the absence of indication of any `processing-categories` dimension, Systems M | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `purposes` | 0-* | `ADVERTISING`, `COMPLIANCE`, `JUSTICE`, `MARKETING`, `MEDICAL`, `PERSONALISATION`, `PUBLIC-INTERESTS`, `RESEARCH`, `SALE`, `SECURITY`, `SERVICES`, `SERVICES.ADDITIONAL-SERVICES`, `SERVICES.BASIC-SERVICE`, `SOCIAL-PROTECTION`, `TRACKING`, `VITAL-INTERESTS`, `OTHER` | +| `purposes` | 0-* | `ADVERTISING`, `COMPLIANCE`, `EMPLOYMENT`, `JUSTICE`, `MARKETING`, `MEDICAL`, `PERSONALISATION`, `PUBLIC-INTERESTS`, `RESEARCH`, `SALE`, `SECURITY`, `SERVICES`, `SERVICES.ADDITIONAL-SERVICES`, `SERVICES.BASIC-SERVICE`, `SOCIAL-PROTECTION`, `TRACKING`, `VITAL-INTERESTS`, `OTHER` | When several values are given, Systems MUST interpret the `purposes` restriction as a union of all the purposes indicated. From 5fc395f0aaf510b2a97dcf121a0270cb12a7a8af Mon Sep 17 00:00:00 2001 From: Milan Date: Thu, 9 Jun 2022 00:54:54 +0200 Subject: [PATCH 136/204] Update refs/schemas/priv/json-schema/priv-terms.schema.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- refs/schemas/priv/json-schema/priv-terms.schema.json | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json index d079013e..bc919770 100644 --- a/refs/schemas/priv/json-schema/priv-terms.schema.json +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -62,7 +62,10 @@ "NAME", "PROFILING", "RELATIONSHIPS", - "UID" + "UID", + "UID.USER-ACCOUNT", + "UID.SOCIAL-MEDIA", + "OTHER", ] }, "processing-categories": { From 5d222c9a4abee9f97e266a893790f2cfeff10a74 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 9 Jun 2022 14:30:39 +0200 Subject: [PATCH 137/204] Managind Data Provenance Closes issue: https://github.com/blindnet-io/product-ideas/issues/35 --- refs/schemas/priv/RFC-PRIV.md | 39 ++++- .../dictionary/provenance/en.provenance.json | 6 + .../priv/dictionary/purposes/en.purposes.json | 2 +- refs/schemas/priv/expected-behavior.md | 151 +++++++++++++----- .../priv/json-schema/priv-terms.schema.json | 10 +- 5 files changed, 154 insertions(+), 54 deletions(-) create mode 100644 refs/schemas/priv/dictionary/provenance/en.provenance.json diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index eb00d359..52811fce 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -14,7 +14,7 @@ We propose a simple vocabulary for representing [Privacy Requests](https://githu The vocabulary introduces a finite set of `concepts`, `properties` and `terms`. `Concepts` define the objects of exchange, `properties` define their characteristics, and `terms` define commonly understood values of properties. -This vocabulary corresponds to the [Data Privacy Request Schema](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#schemas) component of the [High- Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). +This vocabulary corresponds to the [Schemas](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#schemas) component of the [High-Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). Two additional documents: [Examples of use](./examples.md) and [Expected Behavior of Implementing Systems](./expected-behavior.md), complement this document. @@ -92,6 +92,8 @@ Data Subject is the author of a Privacy Request. | --------------- | ------ | -------------------- | | `data-subject` | 1-* | [Data Subject Identities](#decentralized-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| +A Privacy Request is made by one and only one Data Subject. + A System MAY have multiple ways to identify the Data Subject, especially when data about them came from some other System that uses different identifiers. The System capturing the Privacy Request MAY associate multiple Data Subject Identities to the Privacy Request, especially if the Privacy Request is likely to be transmitted to other systems. @@ -234,6 +236,17 @@ A Demand can be restricted to particular Data Range, for example the Data Subjec A Data Range defined by only one of the {`from`, `to`} properties indicates a period of time after or before a certain date, unbounded on the other end. +###### Provenance Restriction + +A Demand can be restricted to particular `provenance-category`, for example the Data Subject may `OBJECT` to data that is `DERIVED` about them being shared (`processing-category`:`SHARING`), or they may want to `RESTRICT` the `SHARING` of their data only to the data that came from themselves `USER`. + +| Property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `provenance-category` | 1 | one of {`DERIVED`, `TRANSFERRED`, `USER`, `USER.DATA-SUBJECT`} | +| `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | + +Optionally the Provenance Restriction may also include a particular [Target](#targets). E.g. the Data Subject might demand to have `ACCESS` to data that was `TRANSFERRED` by partner Systems (`target`:`PARTNERS`). + #### Targets It is common for Internet Systems to be distributed (organised in a set of connected websites and applications) and to exchange data among themselves. @@ -310,7 +323,7 @@ A Consent is given by one Data Subject which can be identified by one or more [D | `consent-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Consent was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `expires` | 0-1 | Date and Time when Consent expires in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | +| `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`} to indicate the category of Systems to which consent for processing is given. In absence of indication `SYSTEM` is assumed. | | `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the Consent SHOULD be interpreted as unlimited | | `replaces` | 0-* | Optionally one or more 'consent-id's of previous consents that have became void when this consent was made | | `replaced-by` | 0-* | Optionally one or more 'consent-id's of previous consents that have became void when this consent was made | @@ -326,6 +339,8 @@ A Data Capture is given by one Data Subject which can be identified by one or mo | `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | | `fragments` | 1-* | One or more [Data Capture Fragments](#data-capture-fragments) | +A Data Capture concerns one and only one Data Subject who MAY be identified by multiple Data Subject Identities. + #### Data Capture Fragments | Property | Expected cardinality | Expected values | @@ -333,22 +348,30 @@ A Data Capture is given by one Data Subject which can be identified by one or mo | `fragment-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `selector` | 1 | a string used to uniquely identify a data field (in the System's data model) to which the fragment corresponds | | `date` | 1 | Date and Time when data was Captured was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the fragment SHOULD be interpreted as unlimited | | `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | | `retention` | 1-* | one or more Retention Policies | +| `provenance` | 1-* | one or more [Provenance](#provenance) | | `data` | 0-* | Optionally concrete data (Format **TBD**) | +| `legal-base` | 0-* | Optionally an array of values among `CONTRACT`, `CONSENT`, `LEGITIMATE-INTEREST`, `NECESSARY`, `OTHER` | `selector`s MUST include the data category of the data. For example selectors 'CONTACT.ADDRESS.SHIPPING' and 'CONTACT.ADDRESS.BILLING' indicate that the data being captured by a particular fragment belong to the `CONTACT.ADDRESS` data category. -While the Data Categories are global, the selectors are defined by the Systems. +While the Data Categories are global, the selectors are defined by the Systems. A `selector` uniquely identifies a particular data field that the Systems works with. When several Systems exchange data among them, they SHOULD align on using the same `selectors` in the same way, in order to be able to correctly interoperate. + +Processing MAY be legitimate according to several legal bases for processing. For example, a Data Subject can give explicit `CONSENT` when creating and account with a particular online service, and at the time, the System providing some service to the Data Subject might need to process their data in order to deliver a service or honour a `CONTRACT` (e.g. deliver the purchased goods to the Data Subjects address and issue an invoice). + +Certain processing is made legitimate (`LEGITIMATE-INTEREST`) or mandatory (`NECESSARY`) by law, e.g. [Article 6 og GDPR](https://gdpr-info.eu/art-6-gdpr/). + +##### Provenance -##### Legal bases | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `type` | 0-* | Optionally an array of values among `CONTRACT`, `CONSENT`, `LEGITIMATE-INTEREST`, `NECESSARY`, `OTHER` | +| `provenance-category` | 1 | one of {`DERIVED`, `TRANSFERRED`, `USER`, `USER.DATA-SUBJECT`} | +| `system` | 1 | System ID (**Format TBD**) | -Processing MAY be legitimate according to several legal bases for treatment. For example, a Data Subject can give explicit `CONSENT` when creating and account with a particular online service, and at the time, the System providing some service to the Data Subject might need to process their data in order to deliver a service or honour a `CONTRACT` (e.g. deliver the purchased goods to the Data Subjects address and issue an invoice). - -Certain processing is made legitimate (`LEGITIMATE-INTEREST`) or mandatory (`NECESSARY`) by law, e.g. [Article 6 og GDPR](https://gdpr-info.eu/art-6-gdpr/). +Data provenance is interpreted in relation to a particular System. +The same Data Capture Fragment might be data collected from the `USER` for one System that is in direct interaction with the Data Subject, and be data `TRANSFERRED` in the eyes of another System that obtained in through transfer from the user-facing System. ## Detailed Design diff --git a/refs/schemas/priv/dictionary/provenance/en.provenance.json b/refs/schemas/priv/dictionary/provenance/en.provenance.json new file mode 100644 index 00000000..2c3ad2fa --- /dev/null +++ b/refs/schemas/priv/dictionary/provenance/en.provenance.json @@ -0,0 +1,6 @@ +{ + "USER": "The data is provided by a user of the system (potentially the Data Subject)", + "USER.DATA-SUBJECT": "The data is provided by the Data Subject", + "DERIVED": "The data is derived from users actions, extracted from other data or inferred", + "TRANSFERRED": "The data is obtained by transfer from another System", +} diff --git a/refs/schemas/priv/dictionary/purposes/en.purposes.json b/refs/schemas/priv/dictionary/purposes/en.purposes.json index 7edb7f58..1874f714 100644 --- a/refs/schemas/priv/dictionary/purposes/en.purposes.json +++ b/refs/schemas/priv/dictionary/purposes/en.purposes.json @@ -9,7 +9,7 @@ "RESEARCH": "Scientific and Market Research", "SALE": "Selling data to third parties", "SECURITY": "For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. ", - "SERVICES": "Processing is necessary performed in the context of services provided to the Data Subject or transactions being concluded with them", + "SERVICES": "Processing is necessary performed in the context of services provided to the Data Subject or contracts and transactions being concluded with them", "SERVICES.ADDITIONAL-SERVICES": "Providing the services that the person requires that are not part of the basic service", "SERVICES.BASIC-SERVICE": "Providing the basic service to the person", "SOCIAL-PROTECTION": "Processing is necessary for the purposes of employment and social security and social protection", diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index f40aa9d9..8c79858a 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -37,10 +37,10 @@ Those that include the term "OTHER" or a textual message with more details about Systems MAY be configured to treat Privacy Requests eligible for automation with or without human validation. In any case, the role of the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) is to calculate the appropriate action, given particular Privacy Request in a particular situation. -## Configuration & Prerequisites +## Configuration and Prerequisites A [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) serving a particular system MUST have the knowledge of: -- The exhaustive list of [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) `selector`s that the System works with, +- The exhaustive list of **Known Selectors**: For every data field that the System is likely to store (either a field of a data collection form, or simply a field in its database) the [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) `selector` corresponding to the , - For each `selector` (or Data Category implying every `selector` used within that Data Category) a data [Retention Policy](./RFC-PRIV.md#retention-policy), - **Intended Privacy Scope**: A set of **Privacy Scope Triple**s that describe the usage the System is likely to make with data. Each triple consists of: - a `selector` (or Data Category implying every `selector` used within that Data Category) @@ -411,7 +411,7 @@ The [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/ma Here is how the Privacy Request Response recommendations are calculated: When no Data Subject ID is provided in the Privacy Request: -- `TRANSPARENCY` Demands: recommend status = `GRANTED`. Provide requested information: Data Categories, Processing Categories, Purposes, and Legal Bases from Intended Privacy Scope, as well as other ifnromation from general settings as defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV). +- `TRANSPARENCY` Demands: recommend status = `GRANTED`. Provide requested information: Data Categories, Processing Categories, Purposes, and Legal Bases from Intended Privacy Scope, as well as other information from general settings as defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV) and under [Configuration and Prerequisites](#configuration-and-prerequisites). - `OTHER` Demands: recommend human review and status = `UNDER-REVIEW` - For any other action : recommend status = `DENIED`, motive=`IDENTITY-UNCONFIRMED` @@ -419,7 +419,7 @@ When Data Subject ID is provided, Data Subject is authenticated but is unknown b - `OTHER` Demands: recommend human review and status = `UNDER-REVIEW` - For any other action : recommend status = `DENIED`, motive=`USER-UNKNOWN` -When Data Subject ID is provided, the Data Subject is known by the System but filed to authenticate: +When Data Subject ID is provided, the Data Subject is known by the System but failed to authenticate: - `OTHER` Demands: recommend human review and status = `UNDER-REVIEW` - `TRANSPARENCY.KNOWN` Demands: recommend status = `GRANTED`, and data = `NO`. - For any other action : recommend status = `DENIED`, motive=`IDENTITY-UNCONFIRMED` @@ -429,45 +429,77 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - `OTHER` Demands: recommend human review and status = `UNDER-REVIEW` - `TRANSPARENCY.KNOWN` Demands: recommend status = `GRANTED`, and data = `YES`. - `TRANSPARENCY.DATA-CATEGORIES` Demands: recommend status = `GRANTED`, and data = list of Data Categories that are included in any of the Privacy Scope Triples included in the Eligible Privacy Scope. - - `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.DPO`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO` Demands: recommend status = `GRANTED`, and data = information corresponding to the request taken from configuration settings as defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV). - -- With regards to Demand restrictions (if any) limiting the scope of the Demand - - `TRANSPARENCY.LEGAL-BASES` Demands: recommend status = `GRANTED`, and data = list of Legal Bases under which any of the Privacy Scope Triples are included in the Eligible Privacy Scope (or its intersection with the Privacy Scope of the Demand if restricted). - - `TRANSPARENCY.PROCESSING-CATEGORIES` Demands: recommend status = `GRANTED`, and data = list of Processing Categories that are included in any of the Privacy Scope Triples included in the Eligible Privacy Scope (or its intersection with the Privacy Scope of the Demand if restricted). - - `TRANSPARENCY.PURPOSE` Demands: recommend status = `GRANTED`, and data = list of Purposes that are included in any of the Privacy Scope Triples included in the Eligible Privacy Scope (or its intersection with the Privacy Scope of the Demand if restricted). - - `REVOKE-CONSENT` Demands: - - If restricted to concrete consent IDs, recommend status = `GRANTED` and recalculate Eligible Privacy Scope to drop any Privacy Scope Triples that have been included as a result of Consents being revoked. - - If Demand is restricted by a Privacy Scope, recommend status = `GRANTED` and [update consents](#updateConsent) - - If no Restriction is given in the Demand, revoke all consents given by this Data Subject - - If only a Data Range restriction is present, recommend status = `GRANTED` and revoke all consents that have been collected in the given Data Range - - If only a Data Capture Restriction is present, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` - - If several restrictions of the same type are present, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` - - If more restrictions (other than Data Capture Restriction) are present, interpret them as an intersection i.e. take only the consents collected within the from-to dates of the Data Range Restriction, then do an intersection of their Privacy Scopes with the scope of the Privacy Scope restriction. The resulting Privacy Scope can be used as if there were only one Privacy Scope demand. Recommend status = `GRANTED` and [update consents](#updateConsent) - - `OBJECT`, `RESTRICT` Demands: - - Recommend status = `GRANTED`, and then, upon granting [update consents](#updateConsent), [recalculate Eligible Privacy Scope](#updateScope) - - Recommend deletion of Data Capture Fragments the categories of which are not longer included in the Eligible Privacy Scope. - - `DELETE` Demands: - - If restricted to concrete consent IDs, , recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` - - If restricted to a privacy scope having a `processing-category` or a `purpose`, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` (A Delete request can only be relative to a category of data, not to a category of processing or a particular purpose.) - - If restricted to a clearly identifiable data scope (such a Privacy Scope with a `processing-category`, or a concrete Data Capture Fragment `selector`, or to a Data Capture Fragment ID (or set of IDs), potentially limited to a Data Range): - - if data corresponding to that scope does not exist, recommend status = `DENIED`, motive = `NO-SUCH-DATA` - - if data corresponding to that scope does exist, AND: - - the data is associated with Privacy Scope Triples that are introduced in the Eligible Privacy Scope under at least one Legal Base other than {`LEGITIMATE-INTEREST`, `CONSENT`}, recommend status = `ACCEPT` - - the data is associated with Privacy Scope Triples that are introduced in the Eligible Privacy Scope under Legal Bases all of which belong to {`LEGITIMATE-INTEREST`, `CONSENT`}, recommend status = `DENIED`, and one or more motive = `LEGAL-BASES` when data is included in the Eligible Privacy Scope under `CONTRACT`, and `LEGAL-OBLIGATIONS` when data is included in the Eligible Privacy Scope under `NECESSARY` - - - `MODIFY` Demands: - - If restricted to concrete consent IDs, , recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` - - If restricted to a privacy scope having a `processing-category` or a `purpose`, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` (A Delete request can only be relative to a category of data, not to a category of processing or a particular purpose.) - - If restricted to a clearly identifiable data scope (such a Privacy Scope with a `processing-category`, or a concrete Data Capture Fragment `selector`, or to a Data Capture Fragment ID (or set of IDs), potentially limited to a Data Range): - - if data corresponding to that scope is not being collected by the System as is not part of the Intended Privacy Scope, status = `DENIED`, motive = `NO-SUCH-DATA` - - if data corresponding to that scope is not being collected by the System (regardless of data being already collected or empty): - - Recommend status = `ACCEPT` (potentially upon human validation) - - - `ACCESS` Demands: - - Recommend status = `ACCEPT`, and data = data corresponding to the Privacy Scope of the Demand (NB. contrary to MODIFY and DELETE, the Data Subject SHOULD be able to request access to data being used for particular `purpose` or being subject to particular `processing-category`) - - - `PORTABILITY` Demands: - - Recommend status = `ACCEPT`, and data = data corresponding to the Privacy Scope of the Demand + - `TRANSPARENCY.PROVENANCE`, see [Resolving provenance in requests](#resolving-provenance-in-requests) + - `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.DPO`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, Demands: recommend status = `GRANTED`, and data = information corresponding to the request taken from configuration settings as defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV) and under [Configuration and Prerequisites](#configuration-and-prerequisites). + +- With regards to Demand restrictions (if any) limiting the scope of the Demand: + - first, check for presence of incompatible restrictions (and if incompatible recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED`): + - [Consent Restriction](./RFC-PRIV.md#consent-restriction) with any other type of Restriction, + - [Consent Restriction](./RFC-PRIV.md#consent-restriction) within a Demand other than `REVOKE-CONSENT`, + - More than one [Capture Restriction](./RFC-PRIV.md#capture-restriction), + - A Capture Restriction and any other restriction that is not a Privacy Scope Restriction, + - More than one [Data Range](./RFC-PRIV.md#data-range) Restriction. + + - second, Calculate **Restriction Scope** and **Concerned Fragments**. This is done by processing every Restriction according to the following approach: + - at the beginning set **Restriction Scope** to be equal to the Eligible Privacy Scope of the Data Subject + **Concerned Fragments** is set to all Data Capture Fragments the `scope`s of which are included in the **Restriction Scope**. + + - when processing a [Privacy Scope](./RFC-PRIV.md#privacy-scope) Restriction, set the new **Restriction Scope** to be the intersection of the previous **Restriction Scope** with the Privacy Scope of the Restriction. + **Concerned Fragments** is set to all Data Capture Fragments the `scope`s of which are included in the **Restriction Scope**. + + - when processing a [Capture Restriction](./RFC-PRIV.md#capture-restriction) set the new **Restriction Scope** to be the intersection of the previous **Restriction Scope** with union of the [Privacy Scope](./RFC-PRIV.md#privacy-scope)s of each Data Capture Fragment of each Data Capture the `capture-id` of which is listed under `capture-ids` of that Capture Restriction + **Concerned Fragments** is set to all Data Capture Fragments that satisfy both of the criteria: + - their `scope` is included in the **Restriction Scope**, AND + - they are part of one of the Data Captures the `capture-id` of which is listed under `capture-ids` of that Capture Restriction + + - when processing a [Data Range](./RFC-PRIV.md#data-range), look for all the Data Capture Fragments the dates of which are within the given Data Range, and set the new **Restriction Scope** to be the intersection of the previous **Restriction Scope** with union of the [Privacy Scope](./RFC-PRIV.md#privacy-scope)s of each of those Data Capture fragments + **Concerned Fragments** is set to all Data Capture Fragments that satisfy both of the criteria: + - their `scope` is included in the **Restriction Scope**, AND + - their `date` falls within the Data Range of the Restriction + + - when processing a [Provenance Restriction](./RFC-PRIV.md#provenance-restriction) look for all the Data Capture Fragments that match the Provenance Restriction criteria (as seen in [Resolving provenance in requests](#resolving-provenance-in-requests)) and set the new **Restriction Scope** to be the intersection of the previous **Restriction Scope** with union of the [Privacy Scope](./RFC-PRIV.md#privacy-scope)s of each of those Data Capture fragments + **Concerned Fragments** is set to all Data Capture Fragments that satisfy both of the criteria: + - their `scope` is included in the **Restriction Scope**, AND + - they match the Provenance Restriction criteria (as seen in [Resolving provenance in requests](#resolving-provenance-in-requests)) + + - third, with regards to the `action` of the Demand: + - `TRANSPARENCY.LEGAL-BASES` Demands, recommend status = `GRANTED`, and data = list of Legal Bases under which any of the Privacy Scope Triples are included in the **Restriction Scope** + - `TRANSPARENCY.PROCESSING-CATEGORIES` Demands: recommend status = `GRANTED`, and data = list of Processing Categories that are included in any of the Privacy Scope Triples included in the **Restriction Scope**. + - `TRANSPARENCY.PURPOSE` Demands: recommend status = `GRANTED`, and data = list of Purposes that are included in any of the Privacy Scope Triples included in the **Restriction Scope** + - `REVOKE-CONSENT` Demands: + - If restricted to concrete consent IDs with a [Consent Restriction](./RFC-PRIV.md#consent-restriction), recommend status = `GRANTED` and recalculate Eligible Privacy Scope to drop any Privacy Scope Triples that have been included as a result of Consents being revoked. + - If Demand is restricted by a Privacy Scope, recommend status = `GRANTED` and [update consents](#updateConsent) + - If no Restriction is given in the Demand, revoke all consents given by this Data Subject + - If only a Data Range restriction is present, recommend status = `GRANTED` and revoke all consents that have been collected in the given Data Range + - In other combinations of Restrictions, take the resulting **Restriction Scope**, recommend status = `GRANTED` and [update consents](#updateConsent) as if an `OBJECT` Demand has been made with the **Restriction Scope** + + - `OBJECT`, `RESTRICT` Demands: + - Recommend status = `GRANTED`, and then, upon granting [update consents](#updateConsent), [recalculate Eligible Privacy Scope](#updateScope) by excluding **Restriction Scope** or limiting to the **Restriction Scope** + - Recommend deletion of the **Concerned Fragments**. + + - `DELETE` Demands: + - If the **Concerned Fragments** set is empty, recommend status = `DENIED`, motive = `NO-SUCH-DATA` + - If it is non-empty: + - recommend for deletion the Data Capture Fragments from that set, the `scope` of which only includes Privacy Scope Triples that are introduced in the Eligible Privacy Scope under Legal Bases belonging to {`LEGITIMATE-INTEREST`, `CONSENT`} + - if the set of Data Capture Fragments recommended for deletion is *the same as* the **Concerned Fragments** set, recommend status = `ACCEPT`, + - else, if the set of Data Capture Fragments recommended for deletion is *included in* the **Concerned Fragments** set, recommend status = `PARTIALLY-GRANTED`, + - else, recommend status = `DENIED`, + - when status is one of {`PARTIALLY-GRANTED`, `DENIED`} add one or more motives = `LEGAL-BASES` or `LEGAL-OBLIGATIONS` when **Concerned Fragments** that are not recommended for deletion, have in their `scope` Privacy Scope Triples included in the Eligible Privacy Scope under `CONTRACT` or `NECESSARY` Legal Bases, resepctively. + + - `MODIFY` Demands: + - If restricted to a Privacy Scope Restriction having a `processing-category` or a `purpose`, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` (A Delete request can only be relative to a category of data, not to a category of processing or a particular purpose.) + - If the **Concerned Fragments** set is empty, recommend status = `DENIED`, motive = `NO-SUCH-DATA` + - If it is non-empty, recommend status = `ACCEPT` (potentially upon human validation) + + - `ACCESS` Demands: + - If the **Concerned Fragments** set is empty, recommend status = `DENIED`, motive = `NO-SUCH-DATA` + - If it is non-empty, recommend status = `ACCEPT`, and data = data corresponding to the Privacy Scope of the Demand + + (NB. contrary to MODIFY and DELETE, the Data Subject SHOULD be able to request access to data being used for particular `purpose` or being subject to particular `processing-category`) + + - `PORTABILITY` Demands: + - If the **Concerned Fragments** set is empty, recommend status = `DENIED`, motive = `NO-SUCH-DATA` + - If it is non-empty, recommend status = `ACCEPT` and data = data corresponding to the Privacy Scope of the Demand ## Resolving Retention Policies @@ -494,7 +526,38 @@ Privacy Compilers SHOULD be able to: - resolve policies and generate `EXPIRED` alerts, upon which the Systems MAY chose to implement automatic data deletion, or other protocols for data archiving or similar - resolve policies for Systems configured not to automatically delete data, but to automatically grant `DELETE` requests only when data is `EXPIRED` -Optionally, for systems wanting to automatically deni `DELETE` requests when data MUST be kept, Privacy Compilers MAY be able deliver resolve policies giving `HOLD` status, when there is at least one Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular data, that is of type `NO-LESS-THAN`, such that the event defined under `after` is yet to happen or has happened before a period of time inferior to `duration`. +Optionally, for systems wanting to automatically deny `DELETE` requests when data MUST be kept, Privacy Compilers MAY be able deliver resolve policies giving `HOLD` status, when there is at least one Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular data, that is of type `NO-LESS-THAN`, such that the event defined under `after` is yet to happen or has happened before a period of time inferior to `duration`. + +## Working with Provenance + +### Remembering provenance +In order to correctly process `TRANSPARENCY.PROVENANCE` requests as well as requests that are intended to be transferred (`target` = `ORGANISATION`, `PARTNERS`), the Privacy Compiler MUST: +- Keep track of transfers, as described in [Implications for Systems](./RFC-PRIV.md#remembering-transfers) +- Keep track of System IDs that correspond to particular targets values, i.e. know which Systems are in `ORGANISATION`, and which are in `PARTNERS` +- For every data field that the System is likely to store (either a field of a data collection form, or simply a field in its database) given the `selector` corresponding to that data field, keep track of one or more [Provenance](./RFC-PRIV.md#provenance) objects. + +> When a System generates data about the Data Subject, it creates a Data Capture and associates its Fragments with a [Provenance](./RFC-PRIV.md#provenance) object having `provenance-category`: `DERIVED` +> +> When a System receives a Data Capture from another System, they associate to all of its Fragments an additional [Provenance](./RFC-PRIV.md#provenance) object having `provenance-category`: `TRANSFERRED` +> +> A Data Capture Fragment may end up having multiple [Provenance](./RFC-PRIV.md#provenance) objects to indicate that it has been given by a human user to one System, then transferred to another system. + +### Resolving provenance in requests + +In response to `TRANSPARENCY.PROVENANCE` Demands, the Privacy Compiler can: +- look for Data Capture Fragments related to particular Data Subject, +- specifically, when the `TRANSPARENCY.PROVENANCE` Demand is constrained to a particular Privacy Scope, look for only Data Capture Fragments corresponding to this particular Privacy Scope, and +- retrieve the [Provenance](./RFC-PRIV.md#provenance) objects provided in `provenance` of such Data Capture Fragments + +When a Demand is restricted by a [Provenance Restriction](./RFC-PRIV.md#provenance-restriction), the Privacy Compiler is tasked with a more complex interpretation: +- The [Provenance Restriction](./RFC-PRIV.md#provenance-restriction) either includes an explicit `target`, one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}, or `SYSTEM` is assumed. +- The Privacy Compiler MUST resolve this information in the context of the particular System that it serves. + - `SYSTEM` is understood as the System that the Privacy Compiler serves. + - To resolve `ORGANISATION` and `PARTNERS` The Privacy Compiler looks into the correspondence table it keeps, to know which System IDs are `ORGANISATION` and `PARTNERS` Systems to the System it serves. + +After having resolved the `target` value to concrete Systems IDs, the Privacy Compiler looks for Data Capture Fragments, the `provenance` of which matches both: +- the `provenance-category` of the Demand's [Provenance Restriction](./RFC-PRIV.md#provenance-restriction), AND +- the one of the System IDs to which the `target` value has been resolved. ## References diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json index d21d9d99..5af0c213 100644 --- a/refs/schemas/priv/json-schema/priv-terms.schema.json +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -38,7 +38,7 @@ "BEHAVIOR.ACTIVITY", "BEHAVIOR.CONNECTION", "BEHAVIOR.PREFERENCE", - "BEHAVIOR.RELATIONSHIPS", + "BEHAVIOR.RELATIONSHIPS", "BEHAVIOR.TELEMETRY", "BIOMETRIC", "CONTACT", @@ -139,6 +139,14 @@ "YES", "NO" ] + }, + "provenance": { + "enum": [ + "DERIVED", + "TRANSFERRED", + "USER", + "USER.DATA-SUBJECT" + ] } } } From 48e7899c4791a319813aa1ead9234db02907566a Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 9 Jun 2022 16:36:53 +0200 Subject: [PATCH 138/204] a better interoduction --- refs/schemas/priv/RFC-PRIV.md | 15 +++- refs/schemas/priv/expected-behavior.md | 117 +++++++++++++++---------- 2 files changed, 83 insertions(+), 49 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 00dccf34..7d54cde7 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -297,7 +297,7 @@ Regardless of the [scenario (Responding to the Data Subject directly or to the S | `data-subject` | 0-* | Optional indication of the [Data Subject Identities](#decentralized-identity-of-data-subjects) to which the response refers to | | `status` | 1 | One of {`GRANTED`, `DENIED`, `PARTIALLY-GRANTED`, `UNDER-REVIEW`} | | `motive` | 0-* | Optionally one of {`IDENTITY-UNCONFIRMED`, `LANGUAGE-UNSUPPORTED`, `LEGAL-BASES`, `LEGAL-OBLIGATIONS`, `NO-SUCH-DATA`, `REQUEST-UNSUPPORTED`, `USER-UNKNOWN`} | -| `answers` | 0-* | Any of the terms the meaning of which is defined by the present format and its dictionaries or an object representing a Legal Base, a Retention Policy | +| `answers` | 0-* | Any of the terms the meaning of which is defined by the present format and its dictionaries or an object representing a Legal Base, a [Retention Policy](#retention-policy) | | `message` | 0-1 | Optional string comment, motivation or explanation of Demand | | `lang` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | | `includes` | 0-* | Optionally an array of one or more [Privacy Request Response](#privacy-request-response)s | @@ -350,7 +350,7 @@ A Data Capture concerns one and only one Data Subject who MAY be identified by m | `date` | 1 | Date and Time when data was Captured was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the fragment SHOULD be interpreted as unlimited | | `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | -| `retention` | 1-* | one or more Retention Policies | +| `retention` | 1-* | one or more [Retention Policies](#retention-policy) | | `provenance` | 1-* | one or more [Provenance](#provenance) | | `data` | 0-* | Optionally concrete data (Format **TBD**) | | `legal-base` | 0-* | Optionally an array of values among `CONTRACT`, `CONSENT`, `LEGITIMATE-INTEREST`, `NECESSARY`, `OTHER` | @@ -373,6 +373,17 @@ Certain processing is made legitimate (`LEGITIMATE-INTEREST`) or mandatory (`NEC Data provenance is interpreted in relation to a particular System. The same Data Capture Fragment might be data collected from the `USER` for one System that is in direct interaction with the Data Subject, and be data `TRANSFERRED` in the eyes of another System that obtained in through transfer from the user-facing System. +##### Retention Policy + +| Property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `data-category` | 1-* | Any of the any Data Category terms or concrete Data Capture Fragment `selector`s within those categories | +| `policy-type` | 1 | one of {NO-LONGER-THAN, "NO-LESS-THAN"} | +| `duration` | 1 | Duration in JSON Schema [duration](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `after` | 1 | Event to which the retention duration is relative to. One of {`DATA-COLLECTION`,`RELATIONSHIP-END`} + +When several `data-category` values are given, they are interpreted as a union. + ## Detailed Design A separate document gives a list of [examples](examples.md) on how to represent real-life Privacy Requests, as defined in [supported legislation](#supported-legislation), or as modelled in existing systems with which we seek interoperability. diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 8c79858a..911ceded 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -39,43 +39,62 @@ Systems MAY be configured to treat Privacy Requests eligible for automation with ## Configuration and Prerequisites -A [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) serving a particular system MUST have the knowledge of: -- The exhaustive list of **Known Selectors**: For every data field that the System is likely to store (either a field of a data collection form, or simply a field in its database) the [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) `selector` corresponding to the , -- For each `selector` (or Data Category implying every `selector` used within that Data Category) a data [Retention Policy](./RFC-PRIV.md#retention-policy), -- **Intended Privacy Scope**: A set of **Privacy Scope Triple**s that describe the usage the System is likely to make with data. Each triple consists of: - - a `selector` (or Data Category implying every `selector` used within that Data Category) - - a Processing Category that the System is likely to perform on that data - - a Purpose -- For each Privacy Scope triple, one or more [Legal Bases](./RFC-PRIV.md#legal-bases). - - -Legal Bases live a life of their own, regardless of the presence or absence of data, so Privacy Compilers MUST at all times, keep track of: -- All Legal Bases -- Active Legal Bases, which consist of: - - active Consents, a list that is modified when Consent is collected and within [Operations over consents](#operations-over-consents), - - other Legal Bases that have their validity conditions met at the given time. - - For `CONTRACT` - Contracts/Services being provided, they constitute an active Legal base for as long as the user has not closed the account/ended commercial relationship `RELATIONSHIP-END` - - When `LEGITIMATE-INTEREST` is used, it is active from the moment of data collection and for as long as the Data Subject has not made a `DELETE`, `OBJECT`, or `RESTRICT` Privacy Request - -To keep track of active Legal Bases (but also in order to apply [Retention Policies](./RFC-PRIV.md#retention-policy) the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) MUST be able to register events related to the relationship with the data subject and save, for each Data Subject identity: -- One or more relationship IDs (e.g., this may be an ID of a user account on an e-commerce website, or an ID of a particular contract like a legal file for a lawfirm.), each having an activity status indicating if the relationship is ongoing or has been ended. - -The Privacy Compiler MUST also keep track of every Privacy Request made to the System. - -In addition, in order to resolve `TRANSPARENCY` requests, a Privacy Compiler MUST also know a set of parameters defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV). +A [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) serving a particular System MUST have the knowledge of the following key parameters and data structures: + +- **Parameters**: a set of parameters defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV) needed to resolve `TRANSPARENCY` requests. + +- **Known Selectors** : exhaustive list of [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) `selector` know by the System, including for every data field that the System is likely to store (either a field of a data collection form, or simply a field in its database) the [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) `selector` corresponding to it + +- **Configuration Maps**, defined at configuration time: + - *Retention Policies*: For each **Known Selector** (or Data Category implying every `selector` used within that Data Category) a data [Retention Policy](./RFC-PRIV.md#retention-policy), + + - *Provenance*: For every **Known Selector** keep track of one or more [Provenance](./RFC-PRIV.md#provenance) objects. + + - **Intended Privacy Scope** : A set of **Privacy Scope Triple**s that describe the usage the System is likely to make with data. Each triple consists of: + - a `selector` (or Data Category implying every `selector` used within that Data Category) + - a Processing Category that the System is likely to perform on that data + - a Purpose + Each **Known Selector** MUST be included in the The Intended Privacy Scope. + + - *Legal Bases*: For each **Privacy Scope Triple** from the **Intended Privacy Scope**, one or more [Legal Bases](./RFC-PRIV.md#legal-bases) + + - *Corresponding Systems**: A map of Other Systems with which data is being exchanged. For each System The Privacy Compiler MUST know if they are an `ORGANISATION` or `PARTNERS` System, and have a way to uniquely identify and address them (see [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV), [Working with Provenance](#working-with-provenance)) + +- **Privacy Metadata Store**, updated at runtime: + - *All Captures*: a list of all the [Data Capture](./RFC-PRIV.md#data-capture) objects that the Privacy Compiler is aware of + - *All Requests*: a list of all the [Privacy Request](./RFC-PRIV.md#privacy-request) objects that the Privacy Compiler is aware of + - *All Responses*: a list of all the [Privacy Request Response](./RFC-PRIV.md#privacy-request-response) objects that the Privacy Compiler is aware of + - Legal Bases: + - *All Consents*: a list of all the [Consent](./RFC-PRIV.md#consent) objects that the Privacy Compiler is aware of + - *All Contracts*: establishing a correspondence between a Data Subject and a `contract-id` being an identifier of a particular relationship that the Data Subject has with the system (e.g. a user account open with the system, employment contract, a court case treated by a lawfirm, etc.) with a `start` date and (optionally, if ended) a `end` date. + - *All Legitimate Interests*: establishing a correspondence between a Data Subject and each **Privacy Scope Triple** included in the **Intended Privacy Scope** under `LEGITIMATE-INTEREST` + - *Necessary*: establishing a correspondence between a Data Subject and each **Privacy Scope Triple** included in the **Intended Privacy Scope** under `NECESSARY` Legal Base + +- **Runtime Maps**, updated at runtime: + - Active Legal Bases: + - *Active Consents*: a list of `consent-id`s that is modified when Consent is collected and within [Operations over consents](#operations-over-consents) + - *Active Contracts*: a list of `contract-id`s of all active contracts that have not been subject to a `RELATIONSHIP-END` event + - *Active Legitimate Interests*: a subset of *All Legitimate Interests* + - Events: + - `RELATIONSHIP-END` events for contracts that end (e.g. user closes the account, or stops a service agreement), that directly impact *Active Contracts* the **Privacy Scope Triple**s of which have not been in the scope of any `DELETE`, `OBJECT`, or `RESTRICT` Privacy Request by the data Subject concerned + - Transfers: + - All the data exchanges with other Systems, as described in [Remembering Transfers](./RFC-PRIV.md#remembering-transfers). + - Privacy Scope: + - For each Data Subject, an **Eligible Privacy Scope**, according to [Privacy Algebra](#privacy-algebra). + This **Eligible Privacy Scope** is easily resolved at the level of each Data Capture Fragment (or `selector`) ## Privacy Algebra -For each Data Capture Fragment, at all times, the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) maintains an **Eligible Privacy Scope**. +For each Data Subject, at all times, the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) maintains an **Eligible Privacy Scope**. For each Data Capture Fragment `selector`, the Privacy Compiler knows the **Intended Privacy Scope**. -At the same time the Privacy Compiler knows about a set of Privacy Scope triples that are associated with an active Legal Base. +At the same time the Privacy Compiler knows about a set of Privacy Scope triples that are associated with an active Legal Base (in the **Runtime Maps**) -The **Eligible Privacy Scope**, is a set of Privacy Scope triples, that is the INTERSECTION of: +The **Eligible Privacy Scope**, is a set of Privacy Scope Triples, that is the INTERSECTION of: - set of Privacy Scope triples in the **Intended Privacy Scope**, - AND the set of Privacy Scope triples for which at least one of the following statements is true: - - They are associated with `CONSENT` legal base, and there is an active Consent such that the Privacy Scope triple is contained in the Privacy Scope of that Consent - - They are associated with `CONTRACT` legal base, and there is an active relationship with the Data Subject in question for which no `RELATIONSHIP-END` event has been registered + - They are associated with `CONSENT` legal base, and there is an active Consent such that the Privacy Scope Triple is contained in the Privacy Scope of that Consent + - They are associated with `CONTRACT` legal base, and there is an active relationship (`contract-id` in *Active Contracts*) with the Data Subject in question for which no `RELATIONSHIP-END` event has been registered - They are associated with `LEGITIMATE-INTEREST` legal base, and - IF the Data Subject made any `OBJECT` Demand, they are not part of Privacy Scope of any such Demand - IF the Data Subject made any `RESTRICT` Demand, they are a part of the intersection of Privacy Scopes of all such Demands @@ -97,7 +116,7 @@ For convenience, Privacy Compilers MAY also keep track of a set of **Prohibited The **Eligible Privacy Scope** is recalculated with every Data Capture, or whenever a Privacy Request Demand (other than `ACCESS` and `TRANSPARENCY`) is granted. -Yet, the **Eligible Privacy Scope** is independent to Retention Policy. A particular Data Capture Fragment MAY be associated with a non-empty Eligible Privacy Scope yet [be evaluated as expired under its Retention Policy](#resolving-retention-policies) and as such may need to be deleted anyway. +Yet, the **Eligible Privacy Scope** is independent to [Retention Policy](./RFC-PRIV.md#retention-policy). A particular Data Capture Fragment MAY be associated with a non-empty Eligible Privacy Scope yet [be evaluated as expired under its Retention Policy](#resolving-retention-policies) and as such may need to be deleted anyway. ### Set Operations over Privacy Scope @@ -105,7 +124,7 @@ Yet, the **Eligible Privacy Scope** is independent to Retention Policy. A partic The scope of Consents can be modified by Privacy Request that include `OBJECT`, `RESTRICT`, and `REVOKE-CONSENT` actions. -The System SHOULD, at all times, keep track of active Consents. We call a Consent active if its scope has not been modified or the Consent totally revoked. When the scope of a Consent is modified, a new Consent (that is now active) is made that replaces the old Consent (no longer active). +The System SHOULD, at all times, keep track of *Active Consents*. We call a Consent active if its scope has not been modified or the Consent totally revoked. When the scope of a Consent is modified, a new Consent (that is now active) is made that replaces the old Consent (no longer active). When the System has more then one active consent, the System considers the union of their scopes as being the Privacy Scope to which the Data Subject consents. @@ -462,6 +481,12 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - their `scope` is included in the **Restriction Scope**, AND - they match the Provenance Restriction criteria (as seen in [Resolving provenance in requests](#resolving-provenance-in-requests)) +> **Note** +> +> Data Capture Fragments the scopes of which fall under the **Restriction Scope** are not the same as (but are a superset of) the Data Capture Fragments included in the **Concerned Fragments** scope. +> +> This is due to [Data Range](./RFC-PRIV.md#data-range), [Capture Restriction](./RFC-PRIV.md#capture-restriction) and [Provenance Restriction](./RFC-PRIV.md#provenance-restriction), all of which might be used to select particular Data Capture Fragments out of many thay may be captured with the same Data Capture Fragment `selector`. + - third, with regards to the `action` of the Demand: - `TRANSPARENCY.LEGAL-BASES` Demands, recommend status = `GRANTED`, and data = list of Legal Bases under which any of the Privacy Scope Triples are included in the **Restriction Scope** - `TRANSPARENCY.PROCESSING-CATEGORIES` Demands: recommend status = `GRANTED`, and data = list of Processing Categories that are included in any of the Privacy Scope Triples included in the **Restriction Scope**. @@ -484,7 +509,7 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - if the set of Data Capture Fragments recommended for deletion is *the same as* the **Concerned Fragments** set, recommend status = `ACCEPT`, - else, if the set of Data Capture Fragments recommended for deletion is *included in* the **Concerned Fragments** set, recommend status = `PARTIALLY-GRANTED`, - else, recommend status = `DENIED`, - - when status is one of {`PARTIALLY-GRANTED`, `DENIED`} add one or more motives = `LEGAL-BASES` or `LEGAL-OBLIGATIONS` when **Concerned Fragments** that are not recommended for deletion, have in their `scope` Privacy Scope Triples included in the Eligible Privacy Scope under `CONTRACT` or `NECESSARY` Legal Bases, resepctively. + - when status is one of {`PARTIALLY-GRANTED`, `DENIED`} add one or more motives = `LEGAL-BASES` or `LEGAL-OBLIGATIONS` when **Concerned Fragments** that are not recommended for deletion, have in their `scope` Privacy Scope Triples included in the Eligible Privacy Scope under `CONTRACT` or `NECESSARY` Legal Bases, respectively. - `MODIFY` Demands: - If restricted to a Privacy Scope Restriction having a `processing-category` or a `purpose`, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` (A Delete request can only be relative to a category of data, not to a category of processing or a particular purpose.) @@ -498,22 +523,13 @@ When Data Subject ID is provided, the Data Subject is known by the System and au (NB. contrary to MODIFY and DELETE, the Data Subject SHOULD be able to request access to data being used for particular `purpose` or being subject to particular `processing-category`) - `PORTABILITY` Demands: - - If the **Concerned Fragments** set is empty, recommend status = `DENIED`, motive = `NO-SUCH-DATA` - - If it is non-empty, recommend status = `ACCEPT` and data = data corresponding to the Privacy Scope of the Demand + - If the **Concerned Fragments** set is empty, recommend status = `DENIED`, motive = `NO-SUCH-DATA` + - If it is non-empty, recommend status = `ACCEPT` and data = data corresponding to the Privacy Scope of the Demand ## Resolving Retention Policies -[Privacy Compilers](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) SHOULD store and resolve Retention Policies. - -| Property | Expected cardinality | Expected values | -| --------------- | ------ | -------------------- | -| `data-category` | 1-* | Any of the any Data Category terms or concrete Data Capture Fragment `selector`s within those categories | -| `policy-type` | 1 | one of {NO-LONGER-THAN, "NO-LESS-THAN"} | -| `duration` | 1 | Duration in JSON Schema [duration](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| `after` | 1 | Event to which the retention duration is relative to. One of {`DATA-COLLECTION`,`RELATIONSHIP-END`} - -When several `data-category` values are given, they are interpreted as a union. +[Privacy Compilers](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) SHOULD store and resolve [Retention Policies](./RFC-PRIV.md#retention-policy). Systems SHOULD define Retention Policies at the time of configuration, and SHOULD cover all Data Categories and Data Capture Fragment `selector`s from the Intended Privacy Scope with at least one Retention Policy. @@ -534,13 +550,14 @@ Optionally, for systems wanting to automatically deny `DELETE` requests when dat In order to correctly process `TRANSPARENCY.PROVENANCE` requests as well as requests that are intended to be transferred (`target` = `ORGANISATION`, `PARTNERS`), the Privacy Compiler MUST: - Keep track of transfers, as described in [Implications for Systems](./RFC-PRIV.md#remembering-transfers) - Keep track of System IDs that correspond to particular targets values, i.e. know which Systems are in `ORGANISATION`, and which are in `PARTNERS` -- For every data field that the System is likely to store (either a field of a data collection form, or simply a field in its database) given the `selector` corresponding to that data field, keep track of one or more [Provenance](./RFC-PRIV.md#provenance) objects. +- For every **Known Selector** keep track of one or more [Provenance](./RFC-PRIV.md#provenance) objects. > When a System generates data about the Data Subject, it creates a Data Capture and associates its Fragments with a [Provenance](./RFC-PRIV.md#provenance) object having `provenance-category`: `DERIVED` > -> When a System receives a Data Capture from another System, they associate to all of its Fragments an additional [Provenance](./RFC-PRIV.md#provenance) object having `provenance-category`: `TRANSFERRED` +> When a System A receives a Data Capture from another System B, they associate to all of its Fragments an additional [Provenance](./RFC-PRIV.md#provenance) object having `provenance-category`: `TRANSFERRED` > -> A Data Capture Fragment may end up having multiple [Provenance](./RFC-PRIV.md#provenance) objects to indicate that it has been given by a human user to one System, then transferred to another system. +> A Data Capture Fragment may end up having multiple [Provenance](./RFC-PRIV.md#provenance) objects to indicate that it has been given by a human user to one System (System B), then transferred to another System (System A). + ### Resolving provenance in requests @@ -559,6 +576,12 @@ After having resolved the `target` value to concrete Systems IDs, the Privacy Co - the `provenance-category` of the Demand's [Provenance Restriction](./RFC-PRIV.md#provenance-restriction), AND - the one of the System IDs to which the `target` value has been resolved. +> A Data Capture Fragment has been given by a human user to one System (System B), then transferred to another System (System A). +> +> A Data Subject may address a Demand to DELETE all Data Capture Fragments that have been `TRANSFERRED`. In the case of the above-mentioned Data Capture Fragment such Demand is interpreted differently by the System A (that should respond `GRANTED`) and by the System B (that should respond `DENIED`). +> +> The Systems A and B behave the same way when each of them receives this Demand directly from the Data Subject, and when the Data Subject formulates their Demand to only one System and marks it with the `target`: `PARTNERS` so that the Demand is transmitted from one System to another. + ## References ### Normative References From 2f436de6421f4b96b830fe0a9e1a4a2bfde11f80 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 9 Jun 2022 17:02:08 +0200 Subject: [PATCH 139/204] changes following Filip's comments --- .../HighLevelConceptualisation.pdf | Bin 262542 -> 0 bytes refs/notion-of-privacy.md | 159 ------------------ refs/notion-of-privacy/notion-of-privacy.md | 18 +- .../schemas/priv/json-schema/priv.schema.json | 2 +- 4 files changed, 10 insertions(+), 169 deletions(-) delete mode 100644 refs/high-level-conceptualization/HighLevelConceptualisation.pdf delete mode 100644 refs/notion-of-privacy.md diff --git a/refs/high-level-conceptualization/HighLevelConceptualisation.pdf b/refs/high-level-conceptualization/HighLevelConceptualisation.pdf deleted file mode 100644 index 94a709f298c3e4dd04a36fd5027a5e23f88a3bf0..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 262542 zcmb@tV{~rYwk;aX*tTtB#f36JC?c9)qxVha#M?-16Y1b1k-%VYIt9ust%k!yN=c#|-U()gJiGF&NB;i3?+xtVPm8+gq%UkEW9}jxLgH7lYmoY~}YW3}jB*@geoBPtn;pQ2R z$ykOL58Qns7=a-+6PG+}{!;L%Kau#9Munq@6AD|=cO3$tH<$Gd+)R`KW#NM(8!_p3 z-M)^BmxqhJJwKkNr&rHJZwPZj@W!`V(l~$r`N-DJcDFdKFaR)dY_(ulbz1i z=I!G0^!#`>O##RE)No>n56^X~vcQTs$KvF}-wCewoW0jFqFhE%j!Z(EXR9jFT8*5} z8aAoA3M=yEpEk2*btT=mC?87uO51t|_$@I4@&P(tpRL-n?U~T=g+ETQ*4vgFC@6eD zc|323w3euHJ7;+f?-A12R`%M(oFo_0t)=l~v~JoH(e2HG*CS)x z34wByCcvD^z2xtJDmZ9X(xP2_JQy5Ck62wG*IP_41Oz%PaL?V*dZ=LBC*umPW)w0P zu0c|AMCPoQ7qc*p7s@bXf3lWW>KD7poFy50q$sk*KiH#B8#oiw(lWs$6_`VYPLYxhHJcHHneb)3Sl{dRB6D~t+0L~YDfQtfDFS0&Vj7^hbR^p`Q`8*CZWM8*JqCdFoI&nI9Z}WPWVr1*HbR zsuWQ8S-K6}r*qN%MsikCL<<6*ZKpAL66ARW57&ayu<8!2>}V0AqQ^wUI@jJR%mlDs z4*3MtJ_YNg^<^a$8>)J2N(R}V8IZBy_nNK_oDte^sYPgEtigb59?GEGU|xyQxjMwj zTm9xF9FKgPfYNsW+Akthj3hXrngKLu!-7)qGbpZVUs@KDPTz_uQ>Gn=WqHpyn1g%a zG=hfM*q$;m;1=ZmYo2wMTilgBf!*i897E`?`O`$DfFFkWoxjBdgm)Ff3_*l5%E&{T z`SYav0$3fO)fmY~kGE(e0p*XK26qfsnUno;*wyQS6AekgyO3 z7oCs!lOf05nHm9OJXp(bh6(?{o#;zXAK}En+(H*$#Ou`VDDI#}5t#qhV0M#uEi~47 zd^>Swt4T}CA6fp4WF8i&3BsR(gBxW$k#^~(dysh#kiu{Rm~qhn#;zBvs8s@b;VCw% zKg%BFBE?&JONSkC1)r{aGPmOR^j0@~!uY3wp_q{C1CBl|*3f`Z+^W znUPwZ>_ z+i(!|w22GDM0q6BT(&dpS9tidtWi1O;-v)=lkdWUglm?-*|fl}s+96Vu7$NE4WOxv@_a{B zxp^kAGZBO?G?*p#Sm8GM;R3n&GjV{5tq&1~W7w9#a*<>29ulHH zRs{4yXL6NGW1dPQRa;2UK(3?XK<)|hUXXCUkp+$Nc$AXH(rocMz z`FTTTDd!a0>nuZEG}ktR3x3_UJO(Kw`~?cLWu%q8u_aAU+wvl5G}_+ch zNmtcuHP*IQgFL$LM`lL?q(1-L2^l((6#Lqoqgejh$x4S}1!9lrJ4ZCU=I#I@6$nQ~ z7`b+ZmIQr!l2Y5#vI#9qe9sRu6qQUmTqCjWEDu+R?j0)F+hgWDfJhPnf{B2+Y1p|I zFLmsn*y#$+theyhB@zegApSKXRWJ)MRiWeTh(p1L{d%$VqTS}W_F!p&5fqb<36l&E8Hk`E_rGBz%?K@K*h zzOI?|#Z;)TP0pS<5xdzOB^z>N^g71ZvgDiJm#7418EJLRxjuNPYVnVm{bdw_*R)BSV7g3BN2rviduKz`XoAL z$IhVu6nnH36d!>pBq=!rCW#hpY5FvrrUo3cRJRqN=Hfu}l@YC5WmBnpl{9k*F*E;} zDsEQVR(~Sm<7ZYLV`S}zmvnio$t(xF#w(r$n;Xf+HBg(_pO`Sl@bKZLO#2H;0J&JP zidaT8mT~gvVrXqcTTxsVp7Hc1Q|8^Q&Vy5VuA|r|h5}%mNUd22M}!n^6hvdKv6fCv z*lWPJ*&K>iDA!R>;^icH#XFDLg9=mWUS1qa-RE8X7m@&^H1dlwcC)VB2NxtbtRU;B z&8MUuY!&g>+lZ$Yk4-{B)hFWn7`eEZ=lR^%m| zZXAd1q+8JM`_I60ss%(BiZ22(r~>qVPfj6f#T{0aMGF47)x2^aFUzEMY-Ak(kd=h# zBsm?yCsxw;MJM|qogF~55ecH$XgTaLm)_dMMRlZg_N1Ore~OW^r{PKo6GSN8sDb)R2G-oxoqv}U+`9dxmO<%=3i}bio-~@LeXYAJ=c-T3y zut=CRmpPEQl?n?h(4Wr%b4P=@+f-6ZDMXv8kWm=bNtitUuOSR^^e*Aa>GA^=oB6G9sYLA--hGU zshAmllNSa?7JND}BQq1zZzr*T@8a7ZcD6Qu(HwjSJ4YkP|J=>ryTGSYl-9Gi!2c#a ze;X`d=3p;pWG852Wou*om#@EP`8P9SVrJ&}AGy=FC;p2rU92tFD=Q;{+I~Tz^UM2z zhu}l{Nx%yU*9`z76LEz2q4xp`C1m7>p^F>;AVJ0WjqMjmNbXlFrrZG^hIYi(Y&2PA z574?*&IETE+~4(ff4cbL__W;lxZ?-q^=3YsH|P(?)8h7Usw1QGV$tS&wbkY69=ELJ zyh+o%!Du{@f~M_~YkxF#Ii5)6e3a=-t5!E)4zqXPLNHlJz-GM|O09xr$wl^;O-caP(cK4U()8^BPLA2+~L9+Yf`KZn( zXBK_Y_sGRE<@WQsarI_vX%0p2;4FK(oxx!|Z!VK5Y}mESE%z(WgG3dV-ji4=y*C#rmgz_+M4?n7S1wa}I9Z+1SO@tthm zaikl(HBt#JqMtpS_k1jWf2)9Y19V@lGwP)sc&S0^+6|*h8H?CnkfIKVEeKq# z)N#LHd0Y=sB#}(=IL-}*Cw2Yl?@`w`XopuLxe$gzb$eM>UIoMnc5u<-3k(K_`@W=M z1HrxKyvi^EpC3-!CT2|@Z!jFy`StlW@O@CAw`e*Z@~d|Axin^aRV;Fx-`=RyXtv(! zNHwh6ZVmuO;=Fa<=?jGJKVsYVut$Bo>i**4Ba)3^a6DU5{>?0##g%$!)Ad4n4taFQF}TbH-lT9?zJ01Fj&{1Kn=n?=gcLs=a+=wsJR`VuV+RT>`~Yp3f%yhRy{8& zy(p3uC_Hhmq_Q_y5-R))kLRoNclfFJ%sKK#np^&@qS1UjiRSKba$X-48a*dLK=quu7UzIKMB!KcBs;UyxvF$F#`!SWvbMX` z$Lm8Re6dU>;*XkqwL8`GA25Z!(gXl7X;{prx);;DUm1<9O%g~|IJAO;HHl4e}^_WOwa%tSJ!8z@x2$WZ}alW>ofOBDiHdm)#l z(r25TF4j@ntT))jhMW$@lb>kD@+rKtgHrUG&F^_#O(BWC7LnG+N-Q>X$m>h^k8{Ipg3^1SMN^63ZN zk0^vP{G!Te945Xy&W{F)ujvRBjH16t!LCtA*q=ycLb(0>c&kkcRtm%rH%VnQ(jBMB z1c#v<0^v-p=)Dv-=PRLx(vrWN25jG4C0*=?ZXL@Xc?4tp^ZW`yPt4A_ES<1JQ#EnK4pb(Q;odSK45eh=@uPvQOx}Z;TMC+uN1yE zuHX(H+SEHeGSY-NJggEq2lc=9i*)WwY)o~Qt3ZCw)gX>eoHNIrJK2-t*FZA>C30YSMr`S<(Jp|_?p6|NG!TM786waJ0LUYr zh5!pgK>bRO&1eXo1y*XqO@?h8Lw2%-WIPk0jqCEqm-@U5ks{7xScaZ$nS-pXk=jAH zb=p_UP><7cg?_(+%=~ywv&EjL#$Km>K4N8p=mfHjEZgJuAX&$Wn7_W>WID+INcSiz z<9xljnim4N*Y4$H|Lt+zCf&m&tZP@}4|&-4{h@~5my}<$tmD1u<6GK*NRt)kv&roD zh17Jf%JX|ysKIzV5k(#4c` zMVbgO3PkXk3kCBw=6p6EOkL5l=l6WM3Y|u~3ABY#-LWoW+GLCfX2T)X8>o#>=HyKP zMjNYNo|?!BYz>Kc`p>wF0DnVtVmdBXq#F$w2NT0grW-mFIvR;h znRWxoKLs)>W-N=W+f#*(bWZrgNtV6vC~qK|=XHb@8FO(VcE*;zm$n)RTTCCz{y~=a z1GybojSOa`Hi?{%PPe#QI-QmG{aR3L4$d6d&`)cT*=8$a@@62VfL5xh&)f-xsE|KV zl22JP458o9uMc|Cd&Z;(R@Pw{bf21|SSl59or3x0gkx_y-cSlQBg`^+MFb~nOau}R zm+QE*kjAc#doBVH@oIlGzSO>#vJ;!{M~`^T{1uP*ZC|!2FQ3Q)rZ1lm-)c2HHiPb& z%MTM)A?BN6EnBT!ry8oqZe2K!Frao-@CIyvE(DbFo8*dTI(=a$bMMaRW1tD z*`bDr=kzMME^%I#cP4QW2~LPou&8L~ZO}cA=4cHML?23roYWveAq+>#DYSnye(cVh zimoikQ~LzRd93_y&zBJv2G&pc3wYinfqp;{mBevwo0+yXuuS4vhY^;{VtoAr1x*AUDAuJ zf!K-Q1xBGH2jmP37uP7a8(`XX%coj}Mg))9J6-T8z8j)oA;qB6bC^B{fSAh=Cl$#& z_T-3%wt|<5hkh-b@f}&htVQ6iU=;0@wqY4{LFdqoo5hx1pm4nx!oZ?gl$FnkFJTx} z&5MGLeA=*&c6I2y1dMe&i6>U!w0pjKJhm>|wYfTa&;>Z(f1;)J#5eS~4%H(>CsPzMM4tyyBLrJO<5rv84QKkH1&Po!bH>R#ld@%{w@qwG2TsnW z<_n+jcz-glrlHw=X*Su`L{u=amxj&CS_60kBq|H0a&A;}1Ah%$g1I2Err>1Cy}9UqRLA{L5|qZaw@#pp>+5%|J*v4E(ALF%{<~V2&O(}e3As&S~DjR$F8=#&*rof_RUh- zVN1m=jTNh7L0tgXTcPPswSgt!mwld)4z;j(kdHZZ>a7brUN3C@j+|}#ddPUbF?7av zM6|=fs~=v!_jul0UltT)IpR_T3}|FAr1a?1rwy-f55^N)Q^u@V(I2t(4EsWn$O5Q0 z_NzU8Rjhomc6?CR4yWwIIaiH{#g0}PV5O=;K!v>S88ETKo zrzatQfEv_;1#t}Rn;NHM+t>Bm=y*P$wEW4hf19uF^qTaoobXlViakX>Bp>}!)GVo^ z|0=&1f?ZidjZ(VrXYzDx!qT9kWz8oF%9N(gs`sq{nzf#yd0B4$Y6gGDqUw^X_#Zg* zUySbm6MOs*=1V7J+-1|08SsZy(t@lU$V)RWN&W z9&x}mMv80)!myMvz(j+_@^UhMm%5ps1u0uD*8W5(6DuY>^hj zB}tLjs5FCWTW$mc!T(4C0go8B@p3778v}s*mBRFt?cDvg>F#~y^`t?|56#RIJzg|> z&M0|2i3BdB@7wOv?*I!c<#k79<^^W;WoR)10L;gvn`T&%lQYJ}Eu`_}Q~ z-c}odAh39$El4^#g7}yNXTtIN7_HHA!bC3Cm_h3;1sgcFKl2>atg`!427@uSxY47# zp#$28cyP`Dj4ckVD#sKFuP!YNW(LuK?@J1Bv!-~prb1UW{ob#Y*$x{OBzj%M8|sH> zK3D7R2@@*02_wK{bP-7i4*WUQ13IVqFNw=c}v*UY2LKQJ^ z3SATJTH2fMTG;$E=<{3Ko}^bYtxelOZZh^}Ov|4vM{}FQWv?c_)HRYbW1Bkro3zTE z&t5^~$KV;7S`Ht<#c78dC&-h9f_+wpQB}D0Feug#Sy4OF+ha7Y9#3@I5eI>b(ig8h zP-PM?lk9$~85;8&)&K~(S=6+(C+f-u>Ai-H$11`R#=rHeN*XF%>fG$57Q|ELi_eZ( z)#Q7n&`3$*jDtfB=TULgUuZU5jUqsEi;#TtCe?$B%8B2Iy6|^m1%*nUD&Xu@BDESY z?xw3z!;{~4XE3|E>-Ml&kWi*_OldRuZ3A#g;;&U%1n8owG-EeqE@o4h4l)%T6ISev zrotqp6HHg|+79`+N%AtP!CnJ%X{96@`mH)&qn2c-1dP@xS|0hdGk>hULgP$Yu?8?7 zvA(ZGTNYhTEj4)sKs)oWsm7o*&}iAhXa%!6r&zJtH&;p9fL`)4Y^)XASXh>Pol1ut z&JpbV+VkJImz8~N>w!{7VB~!{w7s>yrk@Nf01b#(WQ!uZuxP;VhhtBHo~|;s!6dZZy(2RigKFek$x-0+SXAV30JiFMa`gm9{+}GWVLM=z$ zB)dYcM)mCofX3cCY1PKzCt$V1yFFtBsSK3$Okp^u#R_xBN`??hvlfg=2XN9v?;#Cj zs58xdg!rGVn}+m&JkLk%t@C@tprd2gJu%#maCZOnCbyXZH**rKg+@FhWq--x1gqC* zL~0432a>U7dy8-7@{_7|s^5+RcviobX&O0@kIL0Qwr9$JF34({ zRWe`LA9|9LZFs0Z-dy3cGbFa0pLZMk>dJmZCC81!#pD{Fl*%{XtHz2u8({SiEP(#G zo_~}h+UY!9BkhD(bx8c`wPpOSb-SQjlOZCOa4$K*EW>itWe)fSXXAG5WXC$eS8|y? z;QDwU7C+JJhiX_koEtP*)s>=TGl<1szY6*Ig+Z3;C&vEr6TERMpEG7KcaW*ByJ=_b z$nvH?*#We@B!9T|v=6!uuG^6Ex85u+I`+{KQhD3&wIE}bVFa5$#DasaCWnt+ACfH< zP$HT3Dk*4J2l}?{V)?S^jw`ifV=&FU`If86=BMAskx}WJ|302GVif z19((7(L2VLGO&@Gpb+z0ZR=?6&``l9Rr`us8b&vb^Jby7Ui-jxR|r){jb=YCMl>-7 z2v+jr*{H+a{71EZS4%2BZU*{OV7-Szh~}PZ!UangTfSd!rT{cOUt~M73^q@l%YN#f zY%l-~-lAPBK2>K)eG%)8p2u21JymAnRcdo_I`}D!;16WuaHO>Twi_Cq{$jQ;5jotF z)`s?*QVD5o`6;EHoN_IrscP#37cSS49bbFI4Q?iId^8A5W8W9Nj<}V{Y0%LJ++Ft4 zE3UCj9SMa+HW)pPfF*c5S^x>hOX(4|u}OC8Y%nl!9l~bhApv|AcnKtd3^on%3!DN0 zJNjzMog$UtS$|4$4dLX=WY8OsC%iNKe*hS4{{b*$zGLom{C}m@SpOAl{x@Dw5d99R z|C3n5%E0)42LhQ%&Ps}_sKL{nY@IWRg!m-)m~IgGbDUx*Ao8K&K5{@o0i;esKSYob zD1I3#^#F(!vn&q0`}|}8-s{G3jr;>cXFqumWU12KVH)M z7`CrdcgvC5FMWB(60!*rg91PbFS2rZk)j;{B`DSpVlaMzjNKQoX>12}jhpPzru zkOH7bPSu$>BF(i7WfVrnxD34o0sv1K;OMY}4S(S<%>r;KGT9FU2^H5bLRd~QJ2)OO ze!Zzze9>p1O6Zr~32~8{zHfkzqDS+own-8OBvG?UHI2Qf#J;#tTRJp->0aH&^-}!c z9&vk9z9BuI&f<^AQrosXub}Hh1$ZP@Psge6N>m1Duma^f*r|}c!Uwqh0no6OafcgZ zsU0`43rz+UetvFg514I1OLfflmhERV)*Zz0lsbO-_KUL!jn|h*9EHh9_@Jn`NK$BG z0va}X+VJBE{%fy?!)$W2pE@JE2kj>CSXur!0U{vOv^|i^S2c##5Hi4famO2-l?)8S zE7Jnm)KLe(Gmt~BMI3Czh8sYT2$zEC#gzE>&O&9!nkERghnf9T|8~Ff;}}j_+lLv;>{fzbsc!j{Ba-0kaKU%l|b8 zYzChh^aIc{03iivUJqskpvh;oh7%iHv~T>6kPAu%7+TNzjzkM84{UQE+78w=0Ck{F zUpzS92srSph$=YNjgUZ$Dls4efkiA~0Z^%MS`2IfR%@hK?C*VG(BNFX6m--fjJ;sB zh#mc3dQ18e^ouD5DZix94!^S$n0#OS3iTIji&V)fc%2|v5z-@R27c*A>uS^_*8;ET zopWNt4)QmH4t?+k6G*CBz6s9p4ulbcLveVGV9VjlGmY1j>qMxQ8s_(zcGAK{d5$7A% zj3`^mcTzJ)Qb>R)Fkk38*U})}@N>;*jUGpot>A4w{$%hT@3`|G!idC3YBJqXNn$jbYFwr;>FfqDJO4()+ zc`>uhs!Vo)-kj82&wSPVZIQM-a=LihIcqvohxu#&J@~YyE!3^$)%>CVl>0OuGYzu~ z69ZEjGnsja1tZNmZ8Ys5?TC4}!Bicp5k&n!{iso!J~8!jLdlq(hMHQ1$WjhRKi7yyzH9mm6%=>4YIr8*Z#GEGz%>Q&*32RJ%jqGqRqp`%2Jwbr|t_+&NQu>P1JUo_UT91N5VJK zHwG~7V3*)d*ryc-C-U|H&qai@76E!cLkw1%`1Ixe=k3(D(>d+KMe6Vl6(M@|D)1Dh+{s~;_IRB)1Tv7+I_3B~b8 znA1?&A<5M$u`1QgaZmbJ=2yi$KY2oVB6*OyoVv7MmIfIggFH}96Ok6xGGWI@`d9_EUrDm=m zJ$G$UcJXp?2BFax77`q27mFU58xakUM3qE!78w;C6kZgS7Iqg-7M4s_rBU;pQ9N!-N7I!p6brgA{^=$MW3z8gA7ceW7JfIb7AYLVoBEAPC%is9N zu}>Om}mIGw~_4XWO}Zp%c}D0@tP0^#s}KW*Q79B1@y^v#RKn8n%Aq|50u z=)ITa(gL^?F=nJkkhj+d6D(K|V*mrc2kf{_1c@ zpjAMAr;}z%1J-iT62^d-g$pd^c=YmSiLDY+KD!mGiD&dK$lV;mo29qZ=4Y>N+K=%|#cB zPYX_cF{9HCJ5Sx4FEZDL*O$Aut-R*}BY_9OcyN)iJG@7pKapd~Z+!+~ zC*Zi*9e&2U%7W%vbq(_@J0bhXer%di4^z)w+E@y0DquBpmvY}e@tM!WnZlvrP5<(^ zk9bT?s~#@!A zAnGd<3pgC~^^&&B{Y!g;`^0nWV-~CwPMdeajs3&)!{B@`j|@_lGOLWY@?-IN*|@ax z{yb+{ce*~rBs!=?knSt-rCPTC$8_m5l}Llgsc5C>bi_-(Zmuk>T*N!ToUT z$+_&aY+`mKud@fl`>hM9mGR;BQ^4KZ{|QY034DELc!&!M3h3Dz8R9ei1y&XCwf@Nn zVffG7ivKMioSB)G{lA5(8Z#{FH=7)Ty6;rz!-%htUasNsT`V?#hT2^@6je@3@d~}f z$S1C)=KoB}e7rhx1-u4A+(=i@usDoKPsi$M>pU9-`g1krP18+f@foS5)l@~x+d=i! z`Cfgy^YB#U@#bmv-hH)w8`R~=+x@hEb$UDc^;-Je_8xC@whwo8R<`8*u>#Y0=E;<9 zGN@Q8!qU=a2(rz9yqQ*aRc3v@DYq4E_44TXayLB3#+DFmgHhx?uEV@P{B+R2mro=0 z@?3oTba3z~>Rd=eM|Wj-gxVs{bHlt*}9SFO^)ZS@_9QO&g{6JqW;lz+62C7 zKEmv=Lgg8ty}j|VU)90p@Iv`rJSkcd3wx{W@R$-EzAmbU1D#!~Jzb*@A%7FuC6vH^ z?c(aD!u#q#DYOb6TNJ0#PFOPz5XTYYM&ohiFJPnFrCz(Aq}JH!uHJKp zy9uK~_2hjYZ-=wl{x}Hk{=6xDzmBZ1*07Q1Oc=TmSKxhr?41O3D!NYeHmWVbX(+cFnQ@?HF>X?r_u zB%Bo$=Dm*sbS*WIlZrmvI^xfV5gvSt8*(=hz05vzpJ&}v4Zc>t?56D&uynE}{gd{Az zr8Hf?&FE0HR}2no$FHh~UTq&zA})0gk*Jb6Q(t@FV^ z`2l)%J*|U^-wSLY);!h!W6Cn^7LfBMf$w!|(x0AJPkuc$YqO5A1O-{w(|S z1B(tlwUqoeiU&-|wMxpsfo_f!lTxQ7*eUQ-+k_YqENxiXNs=}OGVY#lW);XEu7>+* z!D{j#V(D8F-WE|$-YzQCp7FKHlVvC1fv5{sD(m}FqcH;0z}y)O%(mo9E=ne1U&cS& zofQN(@~T|O3Kz^WxVy%$#CueV;wcpVvy=De;>$KKk5DH%vYtHo&R-f{*ql985^gR{ zKc7BJfxod3X-*O(zaAW^tKTy^XOB1fw4 z9_(B#_o}JDs#=La0bO2(fh4vy*=1sg5Ki>7J{B=Rh-r87lM?$HyFed?1x4>iacung9s zD-{T)g8gLz%xc$-UX!ejP;(?;jDKdecJIn==&KaeAddV{@swguudU%+;5NhGBsFxV zwnsyy%0Y`?>^lq)p-wTdPNr|3S-D2~ST_Xoe7N>?{)X$`Wd^9rSR*Rw~@ z0qbAhcKN}NdRfvtH)fRmTjtF+fC#>y4+j!d&lbbce%-{Rpir%Fou3m&-wx@(ODzC|Zi+Jht{{+;D&(ow*3u3E@aW1X}-h!Fai zvSJbpHvxg=`#>YG+^{K3!=>+?yG^Z2SZ8EXc2}z_cI5NfI}18tBZxvk4mqe4fUE)g zJUoc(E4#PYgh^*v;v_|~ft*5|)H-taDTq3_7b(mP6gM|%;0Z=26kdKX)w-b2S?6r= zwl%bzw^Pc}%@H1t5%%~EjN!~=ETI9P2~%O7kwulkWf#d)MQd`uN=W!1Z)f=x>>$+_V#ZjWM_=Yd;4b?;a?^0+y2N5%Tey0(`2qbT%e`My4 zss*`RYkN@V+N)RQQ@asqKFj)Ia!haq2}>+0CD6$hJCPhT#7+*i;||cl&`ZlYU}x)f zK^(xN4BPw*=F~MJU)VYOpG3?eDm($`ti}=f#F9J(_GNAJ#!X5*;h?Q#XB{CEA2#rz zps@<8UB;4pm{5jK$aLjMf2Hxvs2|}I8JNeX7NWk5EY58>CQ0;!Jk>2V1JpL#ZD!Q= z9~A%wm0v@DQZ{n~)mR6JN#%6^+6g_Kvx+|5S+~NEtDiL4+@K!AySt!4K*C|vi(@x9 z6i-1w-~?mht`|X*ATc9*pvVX{j%A}+>Maf#Cfb9hUXH~2;wkL{Hsfa~R&)_5=DhY^;wf?$QoI z&%vI<^->Qh#H<}ms;DRjvE!)(gWf1JG`Z})Ovw!T7j&tfwaBe;`P@m19EY-5H?~7Q z3{nJ~&_uQ5Pq1hkW9c)K4pE(lzh{&JMuNG)Kb4NKHK~JK+)gcy>L%WXE|W z6R_4k%8&iD30QV3I~LvA0kIIJ^^kB5ihL=gADXMxrAd(ti|Av*p>m|{b}?(mw{uK; zG?y&D$``WsC#AE1!F#iQp_dx+d8DwwOZ3bEUYV-;9|OT(ytO9o$xZP%vUxS7Mse-4 z+mjA=>epfK1j)|}!h)6r$}DF64$*Z6XD;oUoqAA)6n_pW&@!5>$VsvzffJj1Ww6mR)+ez#7x7d@9X7u^rU%h;kwK2PZ)|9v0yiK{wv;*B z$t3}c*m)Ew>cHc_an4f_I+2m4XI#Nmhkfyzf$!2hID#M|meO?ErE? zy4VOLHokBVN$pg^7xPwq5lg=6WZPzPg|mb;p)qTK8o2#5$Lo^Sh9}m4m+0JX!Wi$2 z^3j__0gtVV2)hdaDY+=HqO08W8skU($D@=Y7a3oP@{)nkTR>v>K+L=UH2Hj=z2_w-Pjv@Q_&w%Vq|>HnOp^dcMwCs zvT6N*Vah|PrM9%0jS++j=X5!puIEO>H9rxu#b=n|Ub^*pW!oXNwOAEw4uS0m$>8Fp25(1|bHN0fY0g5ccM9RMn6Rd{ zE8iTRWRjIfS0c)ScQ)r1@sNOwd5aU`a|j8VbS>ZY7H=NldYiB@R3v{C!=Q;6ESt50 zAx`N5qdW@^JzX~4oCLjnyjHnZ?OsBd0ZTr;o|+1G)kSn{`$c5JC?iR;-rgcO^Ss)r z2J}BYl7u&-h)F1s2F;h|NM=cy#tky%0MHPCI145K=HtY$ z=VOi7oC}Er$qY18RqaR*@lk}<;_CgtGav4J1|g4X)I^>YaQwnkbc6wM-0_c!o(HvnPOUL0Ia*R(J166 zWNDXbkHCOx>~*)^?l+H|Om{oAwR8TvDl?5Ze2Eid*)%d{_DH2pyIlGH+zsLkE;~Tp zR>9+fkG7Tt?N|?UV6`zabBSkoK2%+8#+}1^?;RhWVd)Bs6@>#QsMPU%=%FoBW~2t~ zePuvf<64p$u8_9#i#{h>Ve+_oFF%jDc;H=-_ggAQSTR z`6w{Ey?w3V?13%7a9t@B$8*7*$c`6>Lw|4T3;om~0PL>XfaFuzvVWBR3I5d2H<5_e z--yM_2tVN!An>e2<8}Z^0U!NGUQLjZ8|+s5YYxw`O+cKEjIEc5VSCm`66aC-6~vMTE;L;!!3P6WC419u z2c~7-8a!i-cAdeR$>- zGq4-uh%e6U@c@t?>WF%wqL{xU!ef*D(y1sL+4vZdI@>BD8X>%$+MxbGRdLCcKMAV` zJzFwcp*udV-$ zryAmz+LXTDh|cv)291s4E3(?8X0Y9KA-=@%rDo!wl%45a`K(o!Zej!<E7nqfZNVFvuhdx`V5pS~e=d?$<;P#I(A10Z-FNt#(*lt?=3D7$233NTEb$h4*HS zjg{Nb^4XI|xa9VZ^wBW*;ah)y?%*W4=k#Z4u3M)U9q!u`StKX@B~Y47LOGY(Iw zbVqLHh&f)S3`3iow%0F+>xr+Vd}iT=)UCHQ-pX9pAo@$L^gjxS z{$A*xP5nzj^k3G{8R+5D(=u^?-M;YG!plBdScOc`$mAp;VKmozcQPmw)y6HLZU!pG!NFzvxx_)@cBpOXxcWQQa zE-JhDb!JEVWgmav>tVo?684o_DW#}#xYzm8{?gp)^)Q;&E<1GkRm|x&QXOs34dz)s z;UDEizLm!Ib9u^FMOkfBhpoX=+4<+BxWmf{IAI zfWRDaIBGsd_?LxX_0w%*)-07Npc+`rESH*+{h1dEjl3IR2ZAVl_rRz{v}-fkXwJGA zRQ%CK-yes_K|pP+FQE@fzh2?T+gzEK+1P#!ZFT@U1k+_ zH#ok(s6D3!TTSeY+IQV{a2H(a#nC-e#&6;ZKB3)`!_pO|Ug`{HSNBz$nYnpdSbv&& zc>|ACeYt(zTzt^}(igDy#H>{~5~1&^#y0{6>BD8r&-`9xp+|Oy zW;}KR4JxvhI0~N9e5qoE3>NSJ@q%Jr;n5YrMf!h;d*>ia!)?tov(mP0+qP})w9QJ} zwr$(CU1>YB(l)B=oYS}a^xWy_I}tN6|L*TwJKh~{#Ey8@`mN`|MzjJIQ6Y$734CWM2I6yMM*m@qacQe+Tr z-#0F#oWkb2jsVX##<3=A%M#I??zY^lXz{@=NvgQ^ENyt3dCp6b&>RwZbW35;{-yzR zGW@tV)mn9;B7Wn=9oH~;20WU&sChB9!7elD-$7|Dq!n=1TGZH!PJ_H(Kxd5EbT57FF7-8gEn-%Q#H>Cv#6KlRsb8V9$WUxW zA0@@!d)+0WVe76F?rMgjPLTf^UCedh3>>{KQ@EQn)YF~4pL5!_TER>yk#>6C`A0?v z>qv0gdj&v3oGH&tMf3qG0{>J@wJknfG&w8RHmc;>*e27(k1v3$(o+s0$)~Gw;?Y0@ zxK;D$xm*d7FUr)wNB=n1vt6 zI(n-VR9e%^X}7lj^FCCsK?LaLYJ1UJa+aj#xTA2O;uUiSBC1N|K{i8JvnYIc4ztio z$nXz22KPvXA@9Nh)xG1TV)o(F(7!9XXvgsvH-aZuNJXH`f+F6D#G<&4z;eIgfDz}3 zbF9~HW3ohjl;B~iy8PjGHyd#()e|`KeB#!($s0DH2Wk`aH&emXi`z6}j$#VAMJWby z%1L)_C((&pm%%EsF0t)e=X1p-;hN3uKq?=)Jv4N&`!faWjsj2=LGyp!A+_5@sAa`& zA}3dBUrjG-DLN4ucOoYH(#bPbQ_dgiplTA4{bXi^>G#A~9q%Bi*By3qd@Z3ZoEF>B ztO%{pB*?z=oK>y_A5v~WPbQ&Ivb^RdtGcs#Yd1jG6QzepwqBR>#nA{_@e z^WHFa30Mpkri}u!$*01gTk6; z&=R|RRkoVsgb{B<xf^|;dO4<``bv?;Nx~ga%T6$e>8e&hq)q5vp$jPCI@!4=o8+^O z>zVqRp!P>+X97_q<+Wv(Tqdr-xK@b7yiEuylcby?Y`0REli02@W210jBc+4vMpUvD zNUqhIwfn-)@_Cm=lxiRz2>cQ>mCBuDpZiUns$PY|lXw`zo1=0VEcR1Zeff91GRnbk zo6)8MisZrefSLIso<^!iPFc#6oBoFrxv67e$|6N;CUua~-XG(Cge{MUtkQ7^ zh{1=UqL;DQnn~SPZGHTT{QSwB&K@D$>Qeu}EbrhWF&`MG z1khabv}1L7|-5%DVFEJ0<(X6Tz5sG=`QUph>tIYdgMmOtGKqWbn^iC7PS1kI9( z``k;1PmD^sS`DF){&+|mdP`ABaF~{Ksmdme<*0EnNcQk4tNP2rXT4?@11u~d(t)cy zF>9pRgKJN7N%;w-O4uZn9aCwDFGl(4hDPDE@2C-j)arz_l4{kr$0hyK;m1ZdpLvPj zz;2D`Rt%t2(=1^MKy5pS)IJ2V#pLi(Gl#I!E_G_9Y!%ScCROiT25#;%qMc+()JKlF zylj!p=smVUGYD&Asx>0H;WsM!<%dP&8ql=p)Ni|Vr z=$3nQEY3bztxC&6#L*o)`BC218-X6TyA!qpd`y8k$T-0hSy%*Wk){Iqq&fA`tFge! z67Mdg{2uSc4q6ylre*pl=B z2nu#-dy$0&)JEHu9*X^*J6&7Lk@JoA2$BO4rrL7u}k0|)t=Mb>@JuDQ);y(meM zMdU)VI}3qNtI206PV&%|!f!U?GgNyF`9YE$P;mEM{Q^c-G1mJ|A|k89cx)e}WXViO zMWW|L`iOpP{KJXvOAsdB?CH9^u_U^SGnUp7A87K?wegzQZEoPP_1otBPX9o zv@Ov2Sd68;Mfkk_gDsyBS)#cRxD?pD&ODOA*16@-5K=}YC?vaAbmv>f*t|k~CAjU3 z;n7E6QmE11Un0evzdb%}`BUO9MvUbX+Gcxx&8W*QPk`)-a*u_=YG9ChQAU5j7c57O4 zI0sU_h^MejRf1apb6kQB1$b%n#roI6n?z3}D&b!{nQPADb+jY7^M{-csn)W>MYZ0- zMYEK)#UcfHx>|`Bv7T*+jK?KR-^1_1^|%Uq;RB7 zQts^4(cY{Wn9kDMg-4KkvP1`4hHiKh9RuOogxI=$bz^kyBX!)9!J^SbYMb?^Hz)ww z^PC2qL8mAikiIvouOvTNU~oIVSE`fD=`fqmgCAU+Gsk~cdCdQA+wfnpfnfgcCIvq_zT0b{L3Wb-?ZF6-Rb@} zT8`x(Lh-*Owm8@r{}-{Fo)QS{(^MrbjPtK^5g~7$C8YTd6tL7b$kF@RatX;5s$O+U$C>@qU%{ZvWJG zzL_SF_5L*1vXGaj&m!{u9)G%hQP$eK+ICZQb8(Zr62h?4EJyR_%@R}RG-Y~0(^Vfv z$*{I&e~&^lA+Fv8un5;$XJ1^k-QmwcbJvLvKR~g9gmpHzD1FXSQcsk9nwVPu2MFkLAn!>3z27MOI7u#|! z$X)N>9$ubSf6MQ1JKgv`##nbDap01(0`_+Y6ElWa%$7JFk+yWQA&NwAu5+|8>ev82 zkot`7E;G^xd>!Pa1GEpq$daA&?i0d6U9}D*TljfKT#i&v2yP`M6|!D ziU|j@iaqfnNX=50@d4C%_QY( zUwTc{h*U^Esz><)Xz2q)LQ_bOaN&dg&i`k?#`H>lfmIO;v&%InPKJSzA-9%;?91(L z63Q3TQ#)^yQF|fH8-zJu@^yNLU&H?8Jc0roiG2=}6oi`A&VcA4LQd8$eK>F1LO8PZ0xB*eeMk=}k} zj7OM9&_JMWHTE>w9s*pB%V!pqB)sclm?7$}yr=ieCZ-2;Of00erGXd32t~-tpFwD- zK;DE)x~e`AHJ3ZJOAai!(F7PYSMWC{>*UZ@x+LFpwAUqpJk~CmRfuu6jx=Xc78Ca* zuS|5%lW>(({FIA?qaMK%r7>!HiF0AcM1*NHPP`8SC2K)Pi>hAJfT(!JOl|}*+jy1G z8;_(5^7@UFSPJUKfSEAG%c6<_^rE!Tl{Kxs30vf;n5zC4BuK>bjZ0rrQq?PGv(!s% zTsB-omoef3pKj3Hq?vs7uGO>Git;xA=qjsY=oHNvtSBNUgLzhHH~L?e%5Jx85NVdH z2iqwe$HQhR@R$Bx@B}59+(6FfX%Rlvjf|zOscy!?n^Fc88iP1=7FgSK?W14DuG%$_ zMtJ!Kf7hqi&xpv52F6AeC3ZG5312GW%kvIfR55;`SgOKWE;=lpN^k0 zJ!rS933qjN)H=WfPYp-;JCQO_WoQ7mKrGA5H7(4r=WDxW6ud8kjUR*|Yq4|K(VUUb zi}Z^sV!J71VLY$@m=lC$S9OC$-&PKAG>{(0Nd5#XjW$&1lii~^^(fSlsFvJE&4I*K z6ECk|tgkPl?T3anMTbWDYf56{-!eUT2I^b-ciK+l>cK7}8FvH1h%pOQ5BkfSMv&Xq z7)APF6@}9FOd{a7O)zv!uX!?izof1y(N&2fkwXUx2C2Oe>cN3#O4=3T^P%tu?df45 zi_L0tCGW3&Gu`TLCl2~%8!j{qXW@K%Nqsxpk(qW)F>*(t(>=U{Lea8VaR;YjiOkn| zyHe;?khS5Bjr!A`lX>J7oE9uGsG51OiKGRYda0k5;e@~l_jZDiQv64<*dWN-De|w0 zWGp7Am1i@O4D9sUqif_2b)Q3ePsO?Z8ahX(fpr&?ARvv8WFae6)=)s>L5P`RZiBLM zWG+pk%q0N~w+%srHyhZa1srAd^`sqGoHT9QaM`B9>%THGaCa(!lU#oq0)iy6&jQwJ z9le?rUIN^#$j>Tmlx)gmU_VJ!>5WV;r+STKh@2)FEwrB9FA5W~wT|1VnmJ3nq)Iwk zG$jOOfg75hhe{t*4Nl1=D-9;`07!N@IOHw8Xpn}i6=KN z#MGz4IVlTec(cFguoyR-qP^%i7PTZ{b2c7%ds5xu&Y2G#$nxsEQ)vZS46D4W+G|nZ z@VGkO_%q}~a=EFJGsv=IiuGIyFo%9N=?lC64bv_}S* z5BuZGPK-*yrwwDi3$d%7HB03(IzI9R^K9nKK;Cq!HkwN0%=~=UHLmM*`YGmQTlLq; z_H{A!rpq_d_FT)*n%R>RwJ{KAc;jfc2@e76NLeuUltHmuU3~8;R&84}Z;rl)|0u9Y z%Y$O>C6p67KI;|k>z1Vf`(vNNi)1sSy&R9iZg^U*Gf60c#gRWMX2D^}A5AkARwdg8 znX7~Y9mje|XwC$+Dy>@Ae;I<%1mq+7MXqk<>RO4EHkZ86REd3%Z#*^S- zqQd=Cn^N|Kczy#Gbn__&Ath0oFuw%_vY@XG4^mgylALc~Ix;-A1r5>}IXu>t9I@IS zr-;s_TtdrP$t86Aikt{90!>Ve+(aMZI&!xzyWgoI|M8mR3B<^+S2< zsr-T4s~RU?4qe@)-H*#j`MTN#I3ZBaTQ5Ch$C$Ago6e!1R)(?9KT^C^W_VBr$f3mt zh^rN(+ES3cSR4XqLT!hKirjUuyQlTHz9uI!_my^Iz0bvmZX9r; zZAsFY1l3!oV|k*;cmB+lZu{c=@uZ7<=Ok&{p@O-* z)HFUVs<;@N`m1UwTZRs-=2Q9sHRrs9>#$Q;AtwdLTbJK@@QKe*K9)*RtDDWOnqpfy zS5bxGx~ZV_+=wmbu9WgZk<4CLPV>iDp{csN3O-FYRSyg|!=tL0y|BU`3j4_|(ps=Y z_9d4J4i9dw_UrVVkn~7v#?%}#gcNDXI((`CA9t_WjSRi}g%^_1uSREu%HX|p|Cayype+EqT}!Mx!42_PWspYaG);>c3-=kJkzBak*PGzk%ojOX;ykv zW>uBV2`e0_^fDh(%i_AeR}HC5;#CX{(nN)#FjloCadleLuBHery(Q^l;kN%Cgc5*C zL^oZPD>4aU6b}Wui4O5VCWV-q-o&1|@$7LGfHfHkEYyhfF?O+OM!l{kMz!QceHhft z9NSSo5sTz*($sNZ%3v0UAipc8!FVu95k;a*^|;dqcZYw2Fy|Fwc9Mz2IRw(dXZaO& z8A7rvjRH8S8LRxPCEX1eRh3ezE%Jhv-?;7Ot9MRQ3og{3hA}q8N43Nb_SnT>S==BK z`)d?%*zJ@~@rRhWMiabQT1f#c>u(_0Ny7n3&@zG)!L^N2c|Hn7VyXv`zP$R#@AmwX0N zq=%Ww*fi=Gwm_c4Bvj=3Uc%U3c>=L-?L+d|O=Rs$^@mawMJ-6~a{J{$ImvQ$EpVjj zOZI)m^Ln~fP?kB_%KXg*RwGQ$zFy?>A=CmL^?R!A?<|_72@_pOsM)%viS(Rv(&iL! z3Q*Q;uyChv^Q@Yh%{276n^bgtWz`;M2r5u*$X?U~%VRD=AuG78J&}n6wdZQw17kcN zk=F_IxCiNZ$zJjY$h-5YKfobIxyk=o{j>aINctao_rIe4S^kp?$e^x@4e{CfESJnT2bzgyngY$pgSD4ANPTCSj3+=nm7?0)XH`Si(M#Hb)^F>5ALTvKyiklyy0^_cUb-+rk5?DW=H`6Srr zw6Ov7`l)?aeD-$xehZ~A2qaH_{kcu#IjVa(^l`gZ0qk^?-9+9@uG&@SAmpA`ruuEq zKet?MF-BRB0H}f{56%vN_eZzOS?U^h{HeK>>E$A zJ`Ubb#3zC{>Za@`MO=MoH+y-#Cv`ONUwTu-qdtuO^xh7V_yHE z?5=VUnETVw{RViuz$puF*W`Izo_9Sn!l0qGyPh%$f$*WV|8B)CWqNYLEECQ`@?at) z7BFhiBPC@bAdopyRoG^0o=*aXeq^K z>|ASZDP``lm04V${Ao)AS(R0J8hL)3|EJm4IIfHielKTgDQ|XnOx)NHm8f+lf%@42*Gyd;b2D-TX$Sko@W$g?!pae9->mmZ1fhC!74T^CGTdu5O)_iafNDvGVDnZ;vB>x_?x^tG^kO3P$?G_9ir-IY%=!9g8BSE-;0UoN0uUnFm{{f#pLik4<_$ z=9|aiAsjbv%MkH;T)*IOFK#2Cg0u+Ngr{jlvrx!|EZo+C3TvYv@y71JZ+%;t`*92N z!j6p~fUSbdo%vPCk@t+^?fNP5pqRH#Na>ESfC<~=TBFMG^L!2n;N5~ND$i&rxpeWO z7#kmuILzCP(G$-j6;-o@M941`nt(R5D(hTVp+VqAPz|lOb4SeTuWxujMVwfZS@M-j zE9nYMxVV4m29h*fzFVo5jL)<&N)dI)!gfLXKU2#ll0$isCr~ngtL5@2v>y#jx}6LW z)ANP<#jTETZZeC6q>xuS&Xp_O1Yn5m+zQ4hxbg`l3FX#d>Ugmd zqETVh9VvDDMx%s>R|m8}b{sKUhL$qR)hkd}@Q<1E0|ic0=`d3|a+4GH-gl1ZtyE6N zBXBpBpget<()&)MTGO}E6|79JTz9x5EKP|}s1qYx$C1_HtTc$|RPfV!jY6J2295eO zSB`OBmmxl*gjqsQ3{IHBYs}WMpXOmoIk%aU3Q53U5`E<~M#PbIp;6ip5+je(+H17d zWs2X9M^_A+)bePaKSMGBaSk7#2~Q`g)>Z8Ub15@si{-3Rr-Mvcv;M{|WiqOeQsHOL zYPx{;2pOc^J8=jZ37*64k@6vgQlE8pVS!vIec%K2NtxyV6XH#i>NtrwFfkrzxl$5` zTi)ZfB62|grg88-kdjVC+EO33dlz-Fye?|8QIWPes#yz?~g`yftUu5A8{hX zFnkg@>;-m9rz$287FC{whA291>RyuR*0s13*dvQy$Xt&{5EB;-(02>3>!qiB#bG`s zT#q-9{7y_Dt6L;(;yL1KWy+M~Bv6LcmvPZ1zo3cc8TB~Mn|y(ySYf1)t_Zvddtu?ofeDHZ@-+z5ODZ3diegaXc$aiOTR1#O zlpsnUx+|pXKtoCjv}ava6rt0qKAB}nPfLUxs|@COLJerG}@I!`T&>Ck)3U3mcuEh!S34>dxUHc!|$T zCYK4gTl3zce16}J$rHYx=9?2IS&T! zY!T`4d?e6OoXiaw&CiyGi(afR%4K+s3VHw)nv$~s{qUpiGTAlA8&wN5vJ{6S&IE_z z30F{cbx-IiW0-7QC3Y7v&g#yAkzq&hU6-|yCxu`k(xfN*1~pf{G;`JLvjRDSfYYWY zu7Hzn+#mai9CSHr8%>LxN4<>1%^v*GnnlzX`JFyc*?;_X6t06GzFBWDLT7NHHRmtrQ_#oV)|DEJFk5EV|@irpf30mXmGQv9q<{8Tfio0luwK0V zP+xON5^K00UG!n68pdXsj`f;}58u406W1>3L)=2yQjNbOs}_^%ZH$d}2V*^=rMY&6 zMc^Kr#xF12F@>LyvNCD?())}teOjFDw#6_ZL6*N3A=g((M-{x_;%>WLWx_!~_++Q; zww;EvX{yV`M2H&;pahPF)k(Fs_jnB(c6{t)%XqSCR2D+D@p`m1Z0bLUlbmZdQdqpH zVIj#a#N)!4>N(EPc;ndG_7oni04PosjoC1@s^o|XS|DM}P%05aOil1NTY<_OdEV9Z{qug1lNggDBb|Hm3NM3l=5ZZ6SnH^1t*+`-{8T6^K(1RGj=Q3o zBKF1495&+^$Jsyz=-M$GwVpDA3?BP0Vovb=08&OE(Y|EtFVUrgdd!gzol7ITXz4Nm zDUy~KSrtT$>k!~Ur?Y>Mb|r=z$A>_db-P=Oh$_%()Hi%rb|T_2!LOfMcrl=er4J;E zFO~_HXc4&RJjwE?tgCh^&7AX2MI3GY6}+LSa>N_Nf|qSFIo-hV9Hr~tb<=B0syJu^ zDr27yI>$4~8-9hw{XktLY7k15pv7DcyxD8o05qr-5>S-2N)luTAs}+M+jTv{+R3=8 zu)61XCE13{3l00jXIKKWB~RCgEK`Gp)>K< z?Hf9dv(A3XHlkX#BaT;>2OXbNCL=@aVFxklgTaySHbA^0B`}EN*mU(#O-Is2LWDgqrc`jya!g6 z+o{PzD2G}=tU3PcNd5?OxkvJm<(bBhwa3gcznyBUzbITnl8CFeOz!IxCA1PK+c(Y5 zYq+^t^4f?HL`Fe!Q zBlEg&y0$)^I`l+~`$=TIRfuotPHokK>$CW1OrS3Bz9@ZkQ%=cgYWMnY3QIXhD$1Yz zUx4-fHhHGS61@hrIY4&U9l}luA5_~=|2wjAgY)q178@TX1KChq+8{9|zusTRx6wh4 z+|+POvFVB|PH67~3A_OQ2lsFRYj492*0M%Ha8R5~LN--!_^{)7k| z?}^V7s1iNpu!d+7!;qJ292Jbs2VmIUZro<}!@S z3DgkZ2kVDmxXPhAfa=H&Xj^(e+i+mm;5t=5)^TPCQVH{q(@+)F#U~`sXe0*4bdw0R z#3D`Vktp!QRr`oZk`&g`Syn8Ne6Xt{l%7w&ymIH6qB z`ob_x)dHRyq#L;4Z=d>rIn)Jp{%?8&|4%t^*8eL9&hoE8{r@Bc{`toLCq07yNnZbp z17{&*{qMYjgflB4>;G&A{GU*Qe~{pR^BP$H)!z7bEc_o2I0;$*gL?S)kcs~-BmU1r z{KpUePmH*bkfJQNkPxAnp^dZYzkwA0JnsLo>K~aC|6cT8ZDMe;{cY9!y_5eD!q=1Y zmlq#(9os!sAtWY)*VrJs?q72<(fNtHTX~SK=28E-r+g$y&m2oe@%H}qrJz3#$7)v3 zidPZIvI&!Y&HtkF@?G*S_moz7^5;TRLquO=*H`UJ=P7TwYOc?^lA*5(`{Pd+gNJaR z4^Ez!@$UI~OwZTJqwAAIkn8Qp*t_yY-x>F;s{mH|^4ggkS-!R|pdqlY9@WRT(z5r_ z*blF2%%if`Tj%T5wZtvUvs}+ls{!fDoD!`Qn`>Ro1@gjeSN;#*YO_nY~5)7{*|_f6GmU%Bu51|kyrCc<_} zZc<6@iks(GtMrQ7wZ3}YpJreuJO&Zy;r&XQOE<8%FW+J4y5$b9rv%#sds+a`w;)a3 z+QJYS;G^nqFJqIT@4c??`-Na9yZ1}n-5x^3l1D>sPGRt^DzDGBGVe2^W+m;Ldv&{o z&Ns-R?)#~V!|(NiWr0A4X! zD(3dx0TpdjGaBj9<@+(JX;bQgS9Wr$+ZEfo9(P07YUl%eeYtYH zIHt`c7kC|zO?}B1R1TLOy->TTzH5JXL6tS+U{mH^%EjI*hKFS5c`xI+-aLBeJP^0a zi(bxwJhoTFO`_@pb|wl~pk=c011{fp;64zy&sd6KVu#2-DMv~Qv8L7VR}NUaa8;)e zqy{wSBD=b!t@Qw#WdI+zIgg{s2zjhctis)prKt+I>Lgn}+y21Er^ANM8?Wy9jE zyPoiA%{k3e+;%Fe@J_KQaWj6VD-ejNY=a%VtvU!+HJC`UVP`$3iB2 ziX#%6u^`^s8G46GOHG!6PectL?O-R-y{tFNQ3prmpzykT!mk*@aYF8`^iE&YS_7J4 zXmXSvhes7&%W-K;N_iBYG*>tLZWCRdHMXS{J{ns&1bKc$N;{F;psgDzguBgEztD9U zoqc+yg*+1i>TgKoC0)N!(>0~n5QEE1(YEZe~?UQ=uM+VgN`v$6lxfy4BKCXiQ48T==*te%7L(4=uoq=aii+T zd$7ab27=pcxa~V*GD6+9cRzqr;X3_G-rexE%v!khDgn-yax~OnUa@;em(UU_1~8>QNE_j6AE5<* zE5oq)iy34QZ6K%uxXCU{vY$h2vBhxAqH{W*L}FhB)&iex>kQY<4AQP3iDPjoa&2uQ z7iQ5|t4H`O%)}!HYA@&S&Yqt_viIfQ@~aqn(S^cn$UV#g2+y6eKy+Gd|A?4QL&Ig8 zt(X8uT5UemG(|^^F6vWcfGl}*5TYN{x5PMHV4Mpfo38@SO=S=G4RuoN2PYrXO|Opv z>;NNd+DgSS=ZLh<$vC&Z47xR8?YV9<_5i1t8uTBhaN4IZao2PL(eSt8OQNS(UIY!@ z;rf#$cRZ(K`|$@UuJU+#EH4;|jg}Qk<|Xl+Tsa1Xd0g_)aRm8?8?Mj?RHMppp0obK zu`Z$Q970DctIsywmk36S5|T*8)OK{zVxC8#5BqQn7>yldaNKPVU=X%NLUE?5k?^luZfO_NRCUD^r_p$R zar6CMF{8i>yFAG$7Bg(jLk&Ws6buUGvl1%L^3?`ocrZ!ribbX?-EDwJZjNTI16Ovr zFgO-y6PD&hB)zQ{?wsXY*16zzA%^85tr?rqLYw2_#FOv6W2j{C7=T%oSuR6SRQv&| z{8P%(0=RvPaDh+LF8fT08rx!m6-YHmuy9-l*X}a9@BzeLQ;suWll#HM4 zdg2tdj?ahJ>qAi(wd6!d(d~nhtz$K433X_-{IIR5$f#Xygmt2ShoJPU{-?uR z1TNV*QPGGSxTe>V#Yfmb;x=E~DabUA5elJtWhhHBb1BIj3&_Jh77U3==I){!kn4j3 z!gQcVc6!w~7B0Qv|K|Ms3d5dTrx22WYnLLXI1EoyZ z75H}MS}&!bY4vy(u>^NwmnUbnXb9%+9Ds}^`O^6~si}@AL;X)hC-7WUf0B{y$BHRy ztEN^_M)KI9p`yTlLaI^QOJcW>UdZtQ#D^At?6~C6gw~n-`VfNhj_eyfa4+N6q@NWw zEaHgcnKeqy0bL>DdLQo6*)dlaLvJX&*Hhkwd-6#Oi%G&dlVPf9%k~wC?6Wq6z6pqz z^uWUaIjBu;B@t`AL2F0+~t{dO%dHzxsQnEKB55J?(gRT=4Z zdD!|XGS(KMJu7)lZ|x8d^1FJ*3LxiZ0Z^B8+PMlXuk(EdXnc*irJN|v^qlYIXLNgu z5w2(d{_}bWa?z==_-Ea%C!aRJO9sr6Id8W{tI~VKhpU0MLX9zDHMKHZRe9?}>i!o# zGgO|4Wt(FfINjoQVrXiMQEXWhUn~mpSvh=`*sOGMFA2j+CJnBeAs;ozi0?#~N=GyH zY3`DnyYk~~u_QARm6;U#z}x_+odWVuiTWWvE}1lvx`SbnSBKOqX}I(nc#TuWbc41e z5fU#pOS-tD$E0K!Dlhbonu*390-L_~er42n{5lFUUF7farg;LTOk2U^%s~E*oaoqy zr}XD_DKyxl&W~OS4s<9ZRR--UxaFJT>d;*G+fJ|@-50gl!TPx#Gq)KyFB_ietB}sH zO+jKe2qS3L4_`Ajq;8~Avaoci(2B>8UIAh_KpVDYu|oa?+b{kN46fVWHN56H7fBcN z&{I~vHF+nK@O*k&&?t5 zyK(i041vrG2CZ>GHMFQsqS90LtKi(ItHo&P6BO=KU&+Ot6Z&cp zh@!v97%}Mh9;ODjnkSA?5Jv-8Mt4q{wDE3t?Oq02e|WP`Q$BRFR7;zWbvus;aLuN)e_`H zw&kE$Ufdt7MOYN%t`W>t;5sb&uO4L&RkkNGr;pmbt3~C-Wc#Y`$wFQkQ-uaS{hDB~r!C5fi?HitV{^2gS-iuVoO@9{> z(l~4RI|C$6<12M%bkArb+LmKhO-b}9pdPMtHzrbR1%R$e_^Ug#-cf_9K5h3&bWL3u ze8neHi`yu2oqI^)sZw@|y1J!G^-^eM+H3O(lGAQ@xCacR$?t-8g-fxk0b5}387A&? z-|P(8v(U{*JhvdJYcYlScy~9ZLeSFXtyfztX#^sbHQ9)4b_S72J`b~3%R_^NA2PlS5xwQXC>oUS#fiZ|)%Zu($eu_dppaOQ zsI_I^wBv1m3U5%}M227+|!iVXG)$|#Rh*6Q>X~1*}pCqrBKTbM^3ARlCT(jF0 zPIc=yWKif2klU;uw#ucKU!xYh)cR1H_u|$~#@tY4P2b9r3?#O=&|=R-SQ|oYaxLLO zdVO5J7Md}KurHVgoMuTC6@rISI`|05x`nhPP-%Us$4h+p&V8q zb*0QZm}R9ShhRr1kYbBVewWq|PRa%O?2)h2KVogb`+=_nwk!{KT&S>F8Mt{YS9n42 z>6uufJ1YOgy`Ww(19m!c`@L?k)V16z7Z}C;v+ItBC~Yu)eHootTh3dz_JjP;e+3g( zN_Lq(-vSga!5(~|KEH>Uz#$`ha>}fWM3X+yj9WBnR1Sn;TTpE=L0$sXwCZ(@>7~3x z(FT&GZxyrfSuP54il=@;$a&W_=!Ptk*|LLCf2LE6R_kLkK!-!Nm%A5;L!74bMn}BM zR*C0{gl7}+_GZyNth=TPR3jFuw?!CPR6?96oM~6!6ys@vR~Hij?- z(^SWUwe4MldG_2I+O?NSu#5_FG}JYIr20+Wz3%d^bE`u7y|3(O+?J|{(@qDueWzSY z;w~=K_R{Q9tpSsPwhkSQbkDml@uykRgXR@3V}Kqc?nXWdy#vs>TA@$rBu#pmkQZXCR2S8lCXr|TKR)NGE` z-_8DPX>AWj>$VKbhc;SVOBUd2a4|=%&jxhfA+#9BHG>}u3e(Sxl54u?!0@SEijnBc z+XqQK5cA1%WEj+iRB%c&99-vfZFDmr^1u?s8IP!MJo*7G+i&HD6l9C^@^YXIbSl&! zwgCcTF$4C*Zxmr0KCi@s+}EujW`+b(tsT|04;8@^o7(-#-(U$j7z0cTdmK) zoQ_NTVQ-o;P2JEq`)Csn7)#L3Q48oP`wbr`%{pG>lOkkHk=Kdfr4~tB-qslZoIoFDJ zKtK?DExE!O{|FiSgy-%TMw8s9JSuJa6C>)up8j0=@{rU23i(tvb?O0J0I=%yq~aJ% z6?^0<_R4Pp6TyjnjC& zxjt{4^NS+3;EHE$A<=Wa(6(ng`J2w@T!_AjNY|mFuR@t3W7#;`V&ZF2n9RB4vs}3n z6oOdxyP?e_Ff-yEc6WF9hOXw(_Vij*r`Hegg)X3lr%58=+aVRj3s{sr?C&)5l;dP7 zx!x5*d-uF9cOGPQ>1Uo820-H8;ioomOkws&eMurkf(5%NOr-bm#N_fn;T+j2SEJH-FK*h{ z$N!eb>1}tP<|u|Mu0jIG?o0M_6d)utYHpEJMQYCd5|#Qyuz?zli8vCDhG(yihIWe? zL8TslsU)i%UVRi8T77gC__=kT`uHA)Zm^p!|MNRcFeUjAlL^B4p^gO$*{^ldgH5f^ zl+fc+>;XEajh5t|rx;$h*Bj)|sNBrbe1>S%PZn4TPFdL6k8Rbha_e{2J;u>@ny$U^ z`q5!S&$ceTy66Safv#wuD{*r>21`gP%&P#-U)0WEr@Rpj8Fl-%u`1BSwTdj!;0dHC zvBi864jWwI+6WRTSYl-j_&OvJI<;Gk6dmAGJ1f{_89jTtA#A?}q}fLCFSrB^fI0*f zJsc;1?oayYj1#*pN%4hGEK>;!7UP0yxsJLq@F{bg4WnTY4mBb4E*y_S2af>)=oC+r zf0OBrk=y&9ttH7Ej1-d61Yhv})a3+cbw=vvfYSRDTC5^H^@*tj!-Y1O1UV~Y(Nj18 zq3_C#7Hh{+&V_3TjC9rNW4rl)kxC6qvHD&TUJ_eEC_ufouA5m>jb_9L=efvk2H#Sc zx%*9GCYDW|Xh%>GujeD6SLnbC$~sE%r8}FiXJ4E&(suSB%9O;F#JD<&|AAU2CW7Gp z(}+G(LN#G`&g%b>;%j938JUXqwMTGd>XOU~LSPdhLd~6@Pob;7hFpDUp9*S-B_n2J zMGq&DFs4d+u$C1P<$|8lEu7>e%lxbw3#IZ2-~@MLJx&mog<4b@dK8Z_C;MZ4FLC1?@6V8Z+-l>o{@SD<|8dVQAsz@C(FJ!8Y$k#=Z2OXWf$ zapF^FD!jn)i!fv%*yu=md@qIy`R=p$>rhqgLIS=2y9N$f1Hot<*UO#sr>5qmxpxf8 z^n@~Zdj(eNt}?-FdKHRinM(y;4V}hkkZFaXiB_c_&FtCP6@l#Y_Ub(`dU0RHpd|FP zTzfQTiH9r94zM#qY5!iKqioyyM*`>?csIxizHC56W<~;ru{{Y? zJ)AqlG++9Uta<8oc^Ke!qFHfd1Dspv?&F#N_CH#Q-=LaC@ z___`&!lG;+bTlv|F!i@9%m;s~tV~f+mNouSHC3f^3$OWI>5r7w?BMfbI*zoTeGjjG zIY<{i$?98WjLrty3Z2!ZQ3D41Hga&BS+L-l7$6XyA+=mH7!7*6SqWnMccsRu z)QO}F%;9ubTiizfLIYTQrED&sBLOx&%K^^j>0F1k0bWitItWxC@yCOGjem&75TiIb z+E*^LZPu-Ta{_Bd1T4ni5MrRf^{>AdZb-z7i3wsbtOK=cx&QYv*t%PyISr~HdKw-} zlas>|1sqfCt6E}7(hgg8esFdlO9Tou`Z_4^A%}nwAhS~I;EOB9`35sv)#B?gVu#uo zUr?~rMvsj^HMBvD-MOVvQd!yBVackH8i@Tj=H4+#mTpnkZQHhcwr$&*ZQHhO+qP}a zHfP(mjoIey?^|o_y>^^)ckC1Q{J6g=DzY+jII`bRy}I2mdMIpC!^ zv`4G>Z(Ea_54P5{fi>V(w|d6Alyx`&5IT4|Ee(HRp>Xuq7y=$u*gep>mK2RC)y_V# zu22<;AKT4k)Tv0KoJ69-qqq5;tQ(BlN!k7L{dt=znWS0h#k^%cvP#)u=?oUGUlrSb zsOB~Slhf`h8luwUP0A}Z z)v;nsWlRu5XYdbKk9ZTraW!0K6SSb$^XN$wu3insQwsVnum}(FfW<)3BngsMG}vy` z_CbGbODNQo<*70o(f-i4k4zH!86^Iv3R=M8ttW#rdVvj`AkZRTep>|g=qC}Dv+8QsU6i(TDU zc^PyHg{OsCN1BG_a<~kdEebj0J>To#>q05w6)AGr0Iy^!ED`)#^Z#gY1CecSDV;;1uYw{*yMzF^6 z6fYO`h8{QeU=B`fZoNoZyl{@bLNa`J@>E1)m-ywFB|X_dB^zHHR<&z$`=^?N`ugoJ z>{EkL+XPg^F)~5g?OSf&CSk8d|4=~yN7Xld9(TjBSvNFlkZRM=|KV(vY3iuzSCnY; zzRUD%=7L_i&ikn?pzIMe(4_L}OQX*UP1 zVbGHUB1yB~NI%}q`WqMhZQW5b0bc1sX;F%xM!Xv+uz5{Totu*O-S)jbigT0 zOEbh4n#yTkp|1&pR8Nai2aRT%w0mY-Q>*Bn=tS$r+)6t4NHD%Jr;6-o(dH_J!L^aQ zDY)VZZa$aq9ew^n1G((UntG$LrCei5&>QuLF#aDp{E7M#*5(68$Rtr?mnO_N%4}+S2uaRa* z&S(~_)G4^wYbI`yRQ7Tq!L$HvUHz2yKlbLe%Smn{S(^bj;TR-%^OYrTlI5B6v!{2n z^c+!vI1szxuBw5wmtpz!=O;2nWE%9O+YLj|V z+--(7A%VE)nrt?wbH%*S=)z>32&)4nzC%f`g|x3b0_fiXWV-$j@a#-iGEq2Kky!7v z$-ChoIoEnn+Z_;%5)ns(tLJjzgqg@94kYUXI+5SNpUHkqBM?d_GNO<|XEu{!KQIBS zIiJZMiL-lHz4FgZS1~@Cxrh#FbOo8{e#U&H34ErA6^UImW-FPQ5lOOIzN=p7s9mBJ zgsZl|U~u{%<+Y?6D!n39jgjmIC()yNcrEqXGU9;Paa4{uwu(g_gDh|rnX8afP2+RA zBS~To_r9cnx2{cV!|r3?;R^VaHI2`M@2t zpW_=HvHgTk>-Nd|U*j~)|EF=9Z_&hGevSXsDl-2gPD3YPV`J;&NWk*==pnY{+bF+0+xRSc3A$J{(tKzVg2_NQ2(7?k(vH`9RD7dsn*m^#AQSD z&edf|8*In+G$oB@#`h;e5R#88ATaU=pAfRJuT$&{S^@mzJ#Om0HoN*|iKJ?LWoAm^ z{B$~BopRLq8Tr|%v%Ae%zNNm{s^H=8p^82}v$CZvx`KQiS z_qEQGu9Pl%w_7#X(ASZ(MpAZhW?{=!w`r+`+GWK(CyTGXNh8aE)s3s+k-m=DxO#>8 zjKyp@Y<4m0uMB;M{UCw)P7!SIY|+x!uScn`&d=Ik{s$Gym4fTr9*ZBFmd8V>Y4Mm3 z?ATM2dJz^n5xTnFc{UMb)!=TmMvT{Xo~wsbV_MBO^|{ z{4kQ6zR|0FUAHaD6f|K2&d&dSX^#1}HC{-hU5>QXeC!?qs-EyGnnB=a8mr9%$!>s#v1_)zVhT&er2T^Fh}GIFNj7V7JP@cGg!FM-hd&TNGs-y9y|)KM}Ymu4!q0492zOeI?zE ztcI7v+L?Z&&+N?Bk9=ZT88b!9Q)$Rw3UJq~3WP}i2;PfnO=V+OKL}WJ+LxCX^Nznc z8HL6S2FIlkHyiK^xBZ55vzm*$RK7Qu5&q;}Z_R~%p0kSHhXclZu0^!mn1>tKu2qG8 zTsmh(y32aCL+WO590K2s{l?Wz(zqFc8Hd{EM4kv;(u+ye-2z}q}? z??v;~sO%)61UM}`ra-4Jau}8y5^dn#-a{b&!618?Y#KZiY3zRavx>wr=n4%oHhr6s zCNFBE#En__MHDVIQOCVb7`KMoxVw+z0h19qkhBi?R-~fqGO+==*f9^nI*yM^AeLpL zjkP-e;Z0(SF2~IM%8k-u!}@Tw51;Ns8l}iBz3pTZ1c+#G9R&b$3s-4bV8B?bRUPdB zj)Bxg1GIL|;s@=t<%%O(2m|GcqC)3`Rq9PY*$hY&s7#YmUVN`b<7MYqDE74*7&!pJ zJ*3}fqCprD+iWjzooql9<*oaP&PipTY`_JE?lfZ2tVf!*Wfq!%4T56;fl$U0eu-dz zfA(Y(%vz}5cZCus8rZQN2sCL-z9AuqxDKFfI7*<29)_JIrX8~lMrz1{TBOy;mbmvD zSrnw$OK{uxF_+!_;(!hEcg^X8fo)*Ma-8)$$_^H#eE>L{7a(#7@7f-qqqBF*=S-2USr~ouPXaXj(0|PRU zA%N@bI{CQUwiF{Tz|kGyRAXR`=|E+ot2Q*HisO(*tCK55HCPXAul`%W14znhM)k`S zeV|gHwUK}<{35Qb(Nb?98S!Rmb0rP9(Y7F32E&OL{kMVXm3B5luN(5r{<}W9h-l?N z>|pB{qfV>S`+F#DL>fS9j4>cmK^N=%CHJ3rx#qoM>_Bng7r-ePqg=s8CJA5PLLNmb z=olNErfJXlJalk-lAF4p%X!>J^XKv8bCniDr7+!7=qNc%{>MN9X;`u#BmG3+Uu3B} z{q%r`5%8}BbAsW`Y9FtDx!gP62B;w=k@L5h4FnACev0}1&>s7_zFVSI^W%A52;v^R zzfsQpniDAs9!s3;&U$eY@S6*4HwnY`3#4ZWfoc?aglE=PA>0`IJp-Z;yDinL2t-v8 z_s8BTs-9gX!EY#!mZ<#~yjce}L`^9S!*^+P3OAnyv<}VIss|3F;LWiN+NGG*r%YQ2 zM@A-PLrN%as2`<(vqiBstj_yI{nuiTsOb51(MdFc$3h9!D?DGIQUdmU4(OCfuijy^ zF%`TW7KKC7O-Zhi%oCItaUCu4kK+NAGJb;WIQ0v51oJ7Shsuu|G~*ox^m?s~eGbc{ z>L)v8KnYo+E;{cz7r^?HjOed|hSghSIY%ke4tvZ_Iq<6B=JYCQzQv9sH5M-%7T$Om zkeby0X7YJScuhI2P$9}45Skeqr&3EKPxyN41%SaU7iTO0mgJpaR3S)dlD0-yq8JG& z7cnmVGliR+uf@gQ<5D(LxcJfxOz$CsO&rj>lhrD03t|I4rsw|75GFqx(P*RQb6 zUMyELuc0>JEnpn7*IHGD$QPFSwb+d&r1 zFgoicEK59#N}9+QsC0CzdCa;W)RBD9Qa(bAyzF0>9ZfGXe1tjw^~)x2z2QArtA+tP z5_YI@Q@orc=+y*uk{v~a_8jcO{>^y=Vl538=;5RlE8!;zS@i1;uZu#Fx?lDZCl88> z-c@!REGpcvSQ}L1wfYYL!r#m_@ztVH{xU|6a2xGRkhI_v)cP%GI+F3F^)8UX+KD+F z;8ysTM!!`Gf%c^i&7s6rs&LU(tm@QCa_yZ&O1v0#Pn^~Ky+Zgk<84H&vBtX6Pk7sH z!*ye&DHy`4$kT{}{f4jvrQ_EZLWIR7JVNUuBU&wDv@M~~Bu}lV)$GcLPWGNGNVNx) z`ZdH1;^es4<*{O@@^F_}kby#t4JAF1-GnyBdDQx~?RPm>DB5{N4#=WWNEJI0B|z@`%x)mL|qC}@lTw12l6{Mp%%p`PLTE9~UP{0G+x|7Jt(R6kgaL{82&IU+K1xXO9Ulzao= zd6xI=>B3}J4QCMpogs+Od%O6_h$=#X10Bc6m1+o!;~8s3$e#&y)Z_g zwFZ2X^yuN1SCWugV;>`WX+*XX>AndJz7$upOYc5;W8pj`2iXAdPmc4OIIlcAi z5Gf59R2vAuGT^md9XT_pV|$kidfELvuPX6*j>|(|o8o?IDuSH(TDu=~_%M;7M1n8= z=vjDBkAq_<9OVwrh$h`KwPK=x6hS6o7fcUe#FI3EzhG%`;L^M^9)0tP7kmdut)7E6 zqBr=H{804x>{ZifoA8R|xFBl>#(2p}we#ZRW^pkqW%t)6uIy;-D6Mi@{^-ShI7>y; z<{D1>&|U}A9@UfR-P5p=p74_eLIA#8+pgvq7nx>Pj!|p0fRrB#n?;2s)mGrg&(_${L--{IZDs+K!NrFm}KjJ=8LP?EE zWAt;lbDFC{q#@~zN9>tFvrj!#JC~r`5U98mB{csNK~SM&^1xkz`jINwJrn%D7(W-w;vs~&WksEF`b|C%FBH*_E0%BZi{KD^z& znfD5Z!>ElO$#teZGyPpdWVEhTu<;VsXf-_Ej&K$F{K@4My-EBX%ZvrrG$Hfd z5ignf26`81+@El|eXna=H6+2GJ4hA*%nWodiJ)Hmh|=#AO|a`8)&ngw?kgt4rI?um z^QF#!%Nj{|D$zhkqs2#OXdNnM=LzyVqAPES#~RkV+CDxHSaJbNk$9%3h|VNU&V~L( zmHUY|muDQD5R~C}I3|VrjB@69$)atq(YFg*iIhnDt) zQZtyLbM}QdNb5DNZxyX<_VyWg)L`UCvvi{a^oZC+DdbR*M)b$8?m>f^jqL7qwFdiN&9$SXDJ0r;%@mt7lp z50Z7k>$A^Awxr4--)W)6B0(^7b+rt~vhfC0*mQbp2rU)pOXP|WBYNpcv$O6lkS68v z3tIi`WK4`ne=%ED(q#7VJ1!RL*$(4b%-IP#det-tx2Tz~)4Q}>Lal{l4snRCA94Js z+X-{VqWVpr{%r};-?Q-#>caYu)mQ&f z3Cs2uzWLX@{CBv8g@uLVzu=akEcM2X;rQU~TPnQ>DP4JV^f$&#GU+${VSRT*;v<19 zaB!IsyMQLqq~XuEPg#}xp8!ysc@m*RGnY2Z9VruuWT})3PcOEAuKy(XD(W6-YaZcm z9egE!QTV#u3MKb^64qX9!`HS8ZFj>z{c3bI{+#mppnc1Ik6l_C!{163DgO#7#~*j8 zGhtnBaBat;iL|GzEU$HAYu4t7hH1sPl*wdjs6UIW$6V{e%q+;l*k558T7lQzg6T3p ziz(@E&am`Wesse0QIBQe!=S2}Jxq01hBr?CBE|osd$@h1&2d+bN%i^Zs&eFOH|Kr} zyKk0RUen?4`a$0!vv^nYc-`%;-|#U1?YX0=3nvT9qO+%L6Lr`8(sTriCY)!1rFvUloSCX?_jOW39*=kGD{=e9v-94zn}yU`XyH%*58aF|C#y%Cche02Ak0p#0wnJZ^jE9 zQPNFQVsn2tMgN8jgdlo^Z$m&7vkJ5gp*MRw7kK)dIGJZtVN&L)5BmsUljiShTE)-= z`hx-BroOD+;5MX_^~iY{-Fq2J3?}(XN*lZ3MpGRhB*Cnn0_z+!1akq}gc&CD&1rH| zEOOEdpQeMWu$x7+Q*rsM;LgyAN9-vWZKUd|@`YEd6#2kU7-8ZQ*NL+!s_EzrD;ZvK zKH`47yX<%U?|v5M%i6<5CE_a4eyE=4n)3PXQ{mEWMzj6U@{8YAC85~`Xvv2$c&y^9 z0u)YM@YDWcS5P_n9XCvcncJ<_y6{-E%v?Rr2OP{lizk1jzi%|!TUcLl5ZEsd2K{Mn zfOUlL(XKJS;{Q5&9+2}!_dS0;9F@v{^W13JQsHPjA8)9uq`n1k2-MD*5<2<_~`|1+-I1@jUt_vGd2?vT2v>g?lQGrj2W>%h_0 zb^TD)_4AYN-SY6-*CEu^?IrhxPUom+GNrF&(=Xa38!WT4PX~Xu_}94ZXDtizWIHZ6 z5THq0j-z@^>CyYpFVS>etf#s5)Y_{C)}AhdvlkwwuYhtT8K2WlF&l`fNAsa6mjDPqG(g(`% zS+l!3fFa5*(my`Hvh(~#WLXlm3*Y?O#6?jBu{^eGTj5tNSx7n_j_RG>=J#m9fnxz- z4D?W3+u0(1Apd;6+MfSdsxG}1XB!dRoOI=nl2*knF%fx&qS@UjSc(oVxd|zsHZ;t06@LDqAwi&BeAR121ybt3oJHhF}08};=`}< z6NVS+g}ir%6B7`6a32J0TSD*4DHY!M$5&E-=>fJlQ)(MOro~(o(_TREvyF7jNr0Cd zLMEBUbWM6q0Gw9HON1tEVAjN`X_QbVlBR^LK>j3SaH+$==qbQY@CLCm5ae(iUjxJM)(zk$g7{!U1nnfbC zG9nIYer;lZriP0bSB|VljSlM8N+%7k;K;G>`)pk;o=HM!-LpF#d_lVA-2iVl>WY#{ z=Yq?UD0F~a9IZyGU>f*&E-mN43dw}$g?%@icf~+%04K5IM?y}GhH(kyJTj-Vo_rUQ z9+}qcTt4$Vw&b4q@MCa7MF&jN!b;45Ci00_1GPZ(#nB9rd#+^F0i}n40qs`NIYzi#Qrj$zUDZFeFqk#4&ELZ?JIMD6s>)&Y+wYNJfXT zeyB2#GO~e6;_C25&tgGB`=w0`U$6(x)2%CBWEzl&IephmZ3JKJG9ij=e{xP)Dtfk% z)X5k74_)ZqkpoRCrhe>YMNZZy<-`WYAunoS9M01Y3JpK7sU=|9eowM`K?4T$a3;m! zb&nEQHjk!S@odl>gE}P>%wRpmWmCOBwh=;IHa~HAim59WrJEs|GR=QmUzxnp*#If= zrG)=(A(Wez12>K(Uon%qu0gaZAORgyTk~dG$+LKQ^*$QUaCRRW6SeuGB6jA}g0i1_ z=y8fz}#bP&l~>AgY)*~C z{^VBYbY_}{$GAr63uj^v24bU^P9E8J(~~|kL#^_?uYR+N#!*h9w&T7e*dMrdtziX0 z?DzlWV zR-dkfSVxtv%lnkX%#XIcT<0DCfg69Z=(s9jZCeew;ybQumFePqg$p@0UPw=4`&iB2 zKRXN{flhxL=u+je7X3(s9vUE*b_a*N?eG)M=N_Q5hCYm!Zq2jgwBV-2g!xD(dZSYQ z8YTP9h|=bVm3x2Zk27j2>=oCh*reP*)GLTAYrAN#tPAOsIfp&tsBeUy&xDwANV5nL zT_Qu?6oiL#*;M7ol>&X4hNke-kA~GaJV7+Q-3@z|7}iNJ=^Od3X$z z$z>A03?+uT+%Ho*?hToo3sN=40Ha@Iv|YW>O}|uCbQOnOG3P5}^z0gCAm9ZscP~Mj z8^+0>gh*+hn1qW!nioY~Ud#lPy{kD(ntIM^IZabw6BP8nOMny+gDL7l`#Lxmk|1#? zXcn87jFz%XCr4F>Dc(&yhlJs*v1~Y*p%JUZ+x9<-#WB{}O`@U6A|8E@kl>zDA*b;~ zwX6#G31*r-uY1I-DB6_@UF_1dN(kYU6V64>$@lbrg>3*o*Jdtk@G@*pr)8gnhC^=2 zUY1kT&*{doLYY#n=14!;??@iyGePX|TgY(8f7P#0IqB0L4HhiQqh`8oamBVvq~`j~ z31#Z4*dLLul96Z6O8tcK4Tn}qsjap@fTx0d`FU)jo0`Y$Yy(P^E za3$H|Ejn3udGcD3%iM|&%Vpa-X(iSev$fH%$jW#|d8eS7nayzIFnl1nTOx9wgQY%? zkW)n?Fq|WuvqU3kG)+i3k#R_WKR&@=VHc-h$>vnlDaGfQzi-6zv}lDm7*FZNgBs?= zM>T%}DbLw5G<2{ly&s{PHA&y81fzRFIGW(l;Mm?=cpZFjH;sRvL{vZQ}&|4gZjvF%AwoA#sKGc&!KXT=&~ZSGJTobgxIF_Sl- z4K*yDaclWyTQ1^FGaW~lPS#xx0iaEd({}sj@{*fYQaVM9=1b;+HiNieLr{%?yLIB- zEvBq%#h_GrzgCLTj>2@(+4_wQE?!}9MLI#qGu}u8MA|~TdLXgYBP4|pS}Y?*fDItC zA+Wsx>Ms_N=R1b-ft8*5gGp7#XT0wn!O$J$5Bwn9x{G>!+suVe_2vj|Km!X`xP0;E zD8g7=X>_QHr|}?J{eSP!56Sj|Vau2|l9~Q6(i!{o;)i%de$`SSh*2bGhtN z@rp}WVAp8f>)#>X$e!rnhx}oi)XI=+eWu|Gu;G6Hz@4C=LHI5`mH-~wWnZHyS71`D z;-t3@u1Ax5-+(^@l_a_-84vVKJj85;npSnwDSjn=#>j_BAa>k2*w1a1-)5v+@w7&{ z092nzatswTF_oBQg=vhtBQ2GoT`5gHJ2dHMxjVaXqnXoeZ^@4>zq#~l$&Uyc(%Eni z{I|#0R7p9(p03P6i%vkD4JOQYz+g5d71^O9N1LXC-A_qOkA)q*QSf$~=3acPwzPnL zt-H@S;0GTb#HN@lm*T6!EN+fayiCPQ*mmhlIh3UjC#sGNBg!G!vxPN-BEnc?fz?pb zZxgrKEi$37$mRrKelYVk0RysJ~XFt2}HFWd$UBD~~wnqH9an4okFm6UX-2mW9w2i3A^Cfi= zS3I6ouw$%WyyGX@*On`i8W2FZYE%Jtl9i)4>?Uc&JS~loCW3eQIQ)p@0wbOYK$dT{ zr~?UBEKV0k%+3A)cyS}v z7F+eZgCGRbnMYb$aE3*nhaV426w=7(jDP@d8L9<4#z5K;10y$Dz~Q&5q45f5sJf=C z%Jvp!8&?|06vDbcF7yRRyGI>-W@Uf>sL0G#MYpl=LwUV;zCd382;Fx=2|GNb8^`7m z+S+6+L=VohYMYHu=%{nsp5nhlDzimll{m^eSBCdhDSe$Hf<;%PPj41$OQ<8 zLf;(xL+zHFj$@RHMx&)(m@7fi^M3S6Te&%(ITII&mZ!AEH;k_p{+pQb0P}zp`?D$R zr##X|UEENgAziY8_IkiE7gdwD1rCfxzj=d@sKMZ-$Z9ENMaQrN~z1r1y@INdK&UlOS5{Torsg^GMfZF$0gXofO zE@8kAFNxrQRwKlN=5jNhGnz>Bf7qLGL3XwjMRysvxgZF-9!kqrYE|Ip;JNG9@5s45 zXZFd1irqziW!d!ed8*@89@X3AQoEjDlu~>}M{I&ai@Nbodkgv+&2IEsf7ic%o}K|F zE||lPvt+OD9OsnlT}@j9ynS8-ykME42U%uiGUcw*k5}u|?8A380zY%Gh83}E5*ck#zm-m5ydRijitG^RfZY=r3|2S(|s zjD4xGcs|?f*O$%u8ya=D*A+5!33aJ2JA!=NvZF~mdntk9LP`w@cjb?xCYA##=)tpM zHd8x}e7RQQ#RJp0zk^6<<;iO-*53Q&;+VK^hEOPxUs1Z&gEfrYD+)_pVDc zFF7%Qv)}E+yWM3X+35vu@AWd{IQ|QREv05_sE|`D_caoHmxImHW(#u89lz&X7q++u zGepQcZPO*5Pq`5_3`_lOX*SS1qD{1JsqLBIr>EIBS|`}|jY?j4<+L=tVw_gtkwa~n zQSi~Oms@BtG#W$53~o5*Md`$rf#lmE%vOqrZ$K>Po|^KNBRpfu8A|i7kI!KrfIp@j zOuJPDer{KuAhZ&n6lzfMQRnHz7-LZNZ#$H|e0R`wkM&};dNktoz?T)?@)=j+c$KQ* zl@`uE%ZjHt3HrnRnG08cb4AeLM<|tOH+?sN(3e5x6940>UYA9wrCCMs?h>4D$71H~ z_ronK?UIX=%Bm&HZo9x40%y=7GdBAL`6}xTjz*R`3|MMdJQDENEQYC`f(YmcD|$As z==Jkl#;bFi>i2CRxqfucxwth;B6Y{Hb0N+9OyOOM?cB$4F}i+VcB&Z4JC?iY*GKbk z*;~KXdzG{4Nyi_M1#`a(e*-@o<}rfk3 zpbe5RIP(EGpZss1PEo$a6LzyCn*e+>f*QkLe=&teuY`iVRW0LUE5Iq5eEWcWs0^ncsC#zhltH|-h6TJ zbj(#6;Y=90nPeagR8nd=>e!8O-OJ&RVQA)A`wmLhx)VfT}L0c>sCv(`5pUMzoJvVuWBh`M8OZr-Wl@ypV5eS zC<#YZ7Hi#{;})+!N}uyW6s@ezy1ZQ!yF#Dmp>gjw-}f4BX6M-?`0do~l+v@mWa4-C z39Ee&O@}Y=t-c!mmCCiMkA-;U@@v$5p^Yxv6EZgFLy`IB={dsK6 z#q;%e8kk?#-Tt@Eg2R}aK?&k$~>;c=9Pe2 zlhmT$5{Glc#dO3bum^`e#Z_i&(7bZB6ugfF@PUM$SpgL(puA2lFm~t@lswG{z*lTl zfRAGTe)qC7duehfDF%MueXP7+Tm>`tB^f0_{l*l4Z5wGoFsU9;GJMMOaX;IrMF0k( zE&V*6PUu*eu&AnrCzzqkJ~8Sh%i7uWPwSa|#scBk)=1CaT*r&k{5qX#N*Ea9TWl&B zSmIl9DiM*@%>b0t?jQ!DeZut|TeYx8y(!mQswYs`5&V3{wlD2K+SxOqQ$6CFF16Cd zC86xpp#WOhse>PFrtx)V9}QV1`s6|KbRz&LV+h8B1%1u)?0Qk_+tosRC;;x+UP-0$ ze=(=%FS9OUr~{&ekovlw+uln-(QBPiT&&e&t?QY8AMwsL6#F9qxGWV+eg}#79wkj6 zbi74qhC}emQn48kx~Qt|pf42r63K}|)YZJ#j1vUO0N1ZF#H>wR3&8*&=tmDoS=|9* z$oDZs%&y@e);lcFqxubE>$v*)qwLcvYhqJ+Pg1#`?e-&v9*RpOvYT@=E35;RA!Glj zHUFT7jP;?=`)jD<`>%5?wJ9J()Ns}1uMGU)yEC%Ne8N((vk9SiHqz=&uAa#dy@0gG zdSPiIYTs9^VWS1ui0R!(!01RSLB^yK*234h1h#IjPm{Unz#=( zm8@_8e2=2nZXasrbuOk3#l2r#dxp91BL0?rGTc#*RG)(2uTeB7Ocs;;SwSQhoP&8# zl4X&InHzW;Hf%b`55-o5V{-+zvl_ZU^7EkpYRl6Gyia|7W{Y-QES)9)=jjh^Tq%g+ z8K+Zq=B+3hlUkP@lrvt|tQi&37fUWuZuTVoLjab4f+v4Qph757Kj=dIRB{EDSKW^# zTc&fTPjVg4p3SiE@ML(XsQgjR!xb^>!n#nnzMb&d@91h{CSw&!_z}UNV8s@gGVm%8 zxEo>pTWwkQ{r06A<#%c9b6&@hW(}QLM*SJ-5ExFd%6+uTJrzk!B&7H!f%u8Bja1|* zOv#m(=G5V7NJtTtEHkD1pqeaA3NnJ_n^K^|IBpp9TB)BK%3zZWa&*w%ZwAx4(r(cg zDjXRm6m^`r0#KYA`X{wN5?SnPQ=B}zC&ePw5Pm(uOyHLCe(Wh#LYM6DUc zh~fGi;QLRCG7tH#xEf~k^^`i&9jAnQmAUfMNLqa=t1r$%f2M|Qb9RZkMFLD4Sf0x5 z1rNDgf@|wPt1g;xMAXo1xc>>i8c{e4Q)_d9Cw&k$alTn^ICxHxZv%gqiHGOyzJA_M9HnkHxbx2N}JO9|=ve9kIc)+OmJ zt;<2==;|t~yTLnz&F_?T;$`6kCNySxs|u$1-)X4Lde==TCPX@8G$vt6#@jS00dOCT zg1t2lP^1#YE`@SpsZT3xS0&a?L5Yi_s!TQRQ3p5us1aq54$vl6n3KFT`x_`QFpDHC zmZKA9H&&cm=3>%ZDW1cW@tug%^Hu}=u^OfrovFvY+`DOD0woWE-{?E`$r=THw)6^- zL?whcNEIs;^+OMS0M92&&gErK$IB}-KgcU574w3Isq6fXPp>yO46#U|m}*adU4g7Q z5LXSH{rRqOVBf|SC#e6B6VEUU_f)57^6moZ zAs<|_l24(cVMJ9@2-J!ip4!4PH7*i>+`GK_NAq3Dw9`v1qNt=_`XZGSCNX(hs~$OO zy(87esxtIdjlSbj32hV~heVd_iX^-F{vf-0S3w0Hq-);scZ2~p-&%L=5vnw#RZ6GbZrwC*=4-@xBGgt!#w4=q46!fxLoXp5 zz?#BcY6o}f-LNb3!^Qn-)cf%HC2``O9UBWBFuU0-G$3}pp;N3NjWDK8l_XZe_sazw zGILxEt4h$!C4^eMmXOpl_ZBYFl#Sq@2a1O$R)y?4OyKcimgd{H24*)yCV7ePi5_FE zXLabaZMib6NAD9UNk6?qp3kvDXR3yAcLor92WBDS z#@XQvPyl~`5I|0P?>LvC2Me)7k&#F&9Yg!%YCUL|DB42YN>_;>LQ<&SUtv9{F11L%bu}V)t(?I#Bmjliz%^jAf~jY&(I%(CxIv(>SJ0Tn5bj-^t`xI zO<+rP2hpRq+~gA4{<0qMGf(hB4RT4hG1wc39kSTRsc+DdY46CrFv0(=s4qS7Q-@bzI4+ z57-fjGV3ORI60uf_GXH+jXg`jJg-#4AJ5l1bu*lsoY}3>fm;Qp1~`owoArZ-jY~iF zkU0p69@E48P^p0IizPIZ^Yr?%(fdRp!vN6u#6cvmXX`l(4yb!2kvjt~-A=T!Dzp(H z&Q*nHqJsc&;|K%Vx?byCl!toGRMWji0bq3rs&BYNE5H*-To9OoJTQ5$*(Ld$8k&jh zDGB51`~2^&kC^;pki(oMwJQN5N{n^ymDa~(ofF13x*C7J7q~-H16siOx8Jb5iHMm+xpp^ z6htcepR%{;v&6G>bZOpRa5KL&6~|7gj31OtO@Alov7;sUB|#B!S<4X`0H!`!8bvT2 zkMguAV-5jBLPJoJCB`JI$m*%GZX6jk)bED!?b8Rn^O^5_sm2o9&%zN#cUU7xO9u(h z#zkAjqmH*on1n2iVFrpKS@@Y*MvMoNEq}i6DxM$t-roP1f69U6E8St7sqGw`;x(S8 zXv7(Pq7fz;M?7a9a+r9&xAn4xR7=<@Leqpo3s2D~GDjQ%O-Q_D^6i^)Gc_ZDE~afb z<58gMW{o=*)@S~)Gp@2v!N0M`H@b_W?Z&{D9>Yuz^--{r!3e>o z;)PZ}#yYg@g(OP?P0bQBa3)O7b3}{ye4bZW-|Hj}u4);!>9n(-Y7Q19uBhFAn9ry% zFYxFkyjK~LV%C&%$U-K4FyAMc;Lx=H`~uMu;hDL?{UaQTv#*W1dY%fUC7VpVbk>3k z9pwganCjU0Qppn?#!KulRm~y76)G!-6&Uo6lDNC6f0!+yLxjT-RS|~c} z*G!*wp6G+etdLjjIZsek<>BKVgMtlmtdWMFC3PiIj9p&aN(^h92As^AAuw2tXhKF5fCfnb2)XkpsGe5~!WTr2a~Nl*r@+j`qZJ($vXDqmm_bFfNUf}v(MwaFm0GAFSF(F@k|VJpYxc%0(85gwJ2#LX>988Noj77Gma zsL_0SOB7lLn`X=rw38{nU8_}U(}}=u4_lHHg%Eo(YRE+F4GsnDsKZj`LeH3=P0b#i z)18FF(2CwJl?hyB83d(0>Ev2f<~;0!5zAWtTb`?Nq2&rRlDR1Gh!tS&D^QUuB>qYZOvB#LTNjyyszLVHNA0;>9=Hl;W_rx|Cp zA-dNU!Lf0WjpNCT`)|>lv{`Qmw+Je_Di6&wYmhcYI{J!P?v(kiT?*tTx|SY0V{1Mx zH5n!rN+w!e>OYHAJcYY62m%`hktP@;7XvJAdm?F|F-MpY^MuoUD>RENLd%-;=I%@% z^6L+eC%zE;9DQ)98IWVckPlszG(R2oDQqA#cA?|fe*f#t?wbDUO8@G%V=?b zxKB_Tl6nTFmXY_iK7!GO!;S{has$SX&a3Y&nqN;57#?(4(|uP1eh3iFZ)&o|#;usW zMF>VB2BEPaZQT>?%5VqIp5zG7|4J?`5t*J!3kWqgvA7Szlp&RQln6y3;(S&J8O}?N zZlg}dIm&VN<@#CvAn&RC%AcAItJ!)s40=rQ;JA7`)1fj~6cLf2R|*?WndR|}&+#K_^>kgF#i*Gk8CMBq~j zMI!`sPJoDR9OiU8#U4hTp^briSVoYWn3@+dF}HT{>@gUvoe`Rj4AHInZPfzfw@6W8 zmYvnw!n0CrLI99$^!8i?Al?tR)z4_<)S*ki?f{2C1fSOe(q_vN zrO?FP-K}uc8-QC^Y-JQaraHzuFU5C$3f2aHObl-cQnLCqz@_jSoi5P6yCh%6H|Gu`N6=kL41;5Plxz-|WaYb93xPJiz410m9bs z0>nEGv&O7Q4V<&~4L0Gxy1iHeqU3(oSs6i2orV0o^7R#dj=&wuXnKJLQ&Fo!9zxB& zBUt_s^bwI#p|8Jd^b=Qelp%)%Tq(;IkXKBMS1xv+ScyHWLICb4z>PRGMo(|Vn}(v0 z+_G^}yKOAuhR;8DCi(B#6h9c<7;F;SojvX5bdaS;4xe@Oh0pO^Xm`wSi>D->)Srrt zcIy!I1$j3x#YJB*`ho>EgojskKk4EG*!lfOAe8MlhVx&j<-Y(z+5XJSRWNq6b#^c` zb|hf`_eAjDalyYMp})8ItIz*~kkF4Zlk9)w9RH2C{m&W1|BQID|CUev*AMxhA)d_4 zAB7nH&dTmgH?RM*5+h*SxGHmIp{s_(7gAZyim*8hJ_SC3L6{;PfxKsP-%Yl;;7s09 z1P;YzAyFj%koVXl>FkZ_{qs8&-6P+v@kXQZ+ne;;^UL|;>v(nf%k83@@q4%T1oqS2 z`qhSJJN0$*-Es4>?sfN)8ibE4ZMedp3BvlcS;n@Guo`HJT!{Uyp`-iFHN>?Qs&J^Eqo==FOS-K)p_+tYk^)u*=< zz89kRo8EcW_>~`C@=@AfPL!c!C$!%#nkNXnROc7oFk1H+(_1~A$anXO(dA6pYQ|wb z1#Q)D9wDEK^G0Q-gnd43Uzn@j3lyP0fMpPe)E!(YmQ#1940|(fem4A?3pn$6-h2J1 zbnvj3?c<)_`7SV4&ZQ{Lv!^^xet7n_e_r-dtV_gDlr~hCdbESP(*3@k-t6ShLE2eI%v>y4TKTuWxNa7ZH&*29VpegM z42w|}M>bSXVwkL~SRc{2b%n3TYo4kax9q5issZT9ib8%Dku;q>igKVfvA_XESm9L; z0*~G1d6*Z~l|(?(l|(ymx7n*=c>iG(4D_I>JznsC)XONld z)G_Kibc-=6I%(%LT89^P7vwTRw;WznpW*3uxE9Q8&67?sLj*QBPhw0$@>DMBgfKdL z3dy|abnrDqkX4clHlpg{bQj&3T4O)vnJinz)I#Sa-A^e3et@so>yzKMm)(?2)zM7^L%@eIh_an|f3n-;f6-Jt zvjo;h=NPW49=?f{>G0K$0N8z<4!=Bm@Zy^%0sgd{8oORtV+TSxH6elc*`F!apngrX z6)Lv1dt70btd>foE{HuPq13KXCZ(0x99DHSwjGMD1*f&E5}4$!_A}U)F{PNzutE?n zU-=NR_Z`TDe$`L1xa{VTNr4|0smo!c#Iax3^u#$8D*LWDNMotmkxGYh>C*DEoWFHV z_2dVPwh0y2;#iFO1cS<0!89@Y3gY<@kw@3x_&W6f$k~+YzYyxWHH^_Ru9o$tNe|+5bu8U^b=suo;bxfm-F$PWz_c+W@tJgbV815t@CAeTDw|cX-jOv@XHa^&wMfM` zb#_}&TN-)=9vLnGs-etixt6lx{Uc>ceH-)jEN}(9Ih7o~Pk&U_M*Q-oLfBJt&P=jw z$vi(9JLaJCg_ER7S{Vj7rs(a9LGQr&0p>mz4|`q@I^{Nnh&mP!&e%Dn(`OgG5w&(+ zgM&5pL5-ch3dzjifCuEU*;puO?n;HAA;h*zguCX!UIHc zcGFIGv%xOy&7KS{LeTa)Au?h)lx$)HuwpLnN27efxxKX>Qn0y92ss|lMnu;-MUSOMRzceIZ(=RR-8ZBPltv>=u0H^YQ$l(6=jAiC z+||A{|7_duPaK;T`KX|~F{S6(Em{{J-Y#TBB?vwycp8RZUP$2eiBYS7nU)F2tvhbL z0919MCGOFQ`PTWfR+}LkCp7AEC0MALRa^m0n{|bpamp;Ea!r|0=%z{^u)7PYKuN(M z$fRedhDpGUGYd*)p$aslUzm|!C;w-plM@#|?XQi;fX_@PC7a@>H~vc8mEucHaa5Oq zl_fb$X4F7XvX@f?Jjr^WVQ=+As_(3tOF0)6t&3(?s|Kz=j;H>vfqfA<&D&*>U>(A0 zD(%{l1m%qrhy$w)dXRYhkZK(dlf#G%RXd)L)M%D2a`mU8i(%>^ntc*^&`8HW-PO#= zJESJX$_Y0+pLyapT~{2Ya=Mj+tS5eSWjYm`!QySnVhlH{2 zM%B_~=y)cS!ME8{fIIIPHrbGW!xZt**7Fh;l|b|+TsR@YlxLl;O$QZ$Ey-H53@h!n zTXX%1y9T}m&O&S;U|W9IFelgx9u3SdmF@fG6sDqAS0WI2(DpG%w(P;Bn2;^z>-`ue z5k*U-R3%vD*uZ(eC$p5Nn)@eP*1V5Wy-Q7&`D+I-FrPDEe|#X}G0Z8jz8e+>(JYa5 zLNN_9wk8=<^Ix2J$2Q6DWkZx*58=3@KGR7}=JZu~Rrlg3b#TF&Bx5!1qQEtiC+o4# zYqZb?eWNIVkSBqvyCJHi?#JQ3tHbWt;yBnbsR$BLL2f8gKc*rBy9n=ve1#y|7Wx77 zD+*RG)}uz(Yk@^KMJ>}uBf-e!e{buOtW#cPd zZl{eJqKdpdVPWTszVf%6r7QPFeo}0uOD9{%rXm}a#YcxECD3JGMd1sDzP;WNbj+k7 znh@h8@OB2FSfG}Lqaf0sI^M4QJ^X-W%C&u|<>g>dTE_kFgk)gQR|Pdz`K&w8UFDsP67XCd3MB#52jOrUoDL*|y#yj=bq#9>8j_El znngcSbuWZPKZtg8zp{MvR}G)5=hT#NW*|811?*XDhPTFu_v0LMM{rfhRfR3Me%?ZReDlM8ohe3N$e|y#caUQw>SqP{ zbREPf3(NOB#c&zy(pLpQ6vKGUg#Ux2LdzO4=OTuzconcQ*wrb*NF+f@O>w|l0V+z7 zgs}0m*`4t!_T73Z7FM%e%hk~rQWn$ipL?OcE^nC&3z&_MAIG2u`3N`S=Xu8g5BUN5KH@w&;RTh1fsAqwXkWI$(!Xv)O27p;aELb2*DR0;})dky}l_I)@$7!u4F=TGc8RevG`>*19t^dq@n&+dN>SPs;}2TK0V4+UUXt^ zm%pDyjLhdEI?h(0A!uJ|8(d6q3tnpWBzY3OaUWU_<4ae-0~QjoXr>q{l z9Z5-7h10=cMNmHg?pbl2JqQGTDi;an&usBKY8`3jwXow=b9PL5+$=#no8eO-M6EGZ z-d!aYWr5KZ)-)&Wl<;?kNbOWdQH zN;$Bw3{)zypzAfg&8q1OH-b(Dt5WAh5BG!9HBlJrKnU|w8^TI+YAJ^D78oucbyBZ% z_WF7h*BV(MlNCB#gFrm+WD8-OpvkNy;~Ft*j-sv3-1GG6bRoVJtm=+SBM8C!S6ir5 z?)#mk0q_OcQODb8zq*}lQLXxGIW@+lqiHVI4OnD`tJw@MSwT;ckHjfRu-#e7vtoi< zz0pOqR+}M}CTM_C_&@O_=I|UjetT0e3#G6}Y;kdUy>Viyd`FK?Ibqa^Xff;(gp55} z9mbQdU3Ez385Bg)o(#j8^reZ5Rb2wtF6Upzn@Z?|_+gd9AvYdOh6*`Ha~{Bug5e{M zqj(*4(!8*>KXy!eVXLOCs+MqH3zU|TV_e@^-%PKJX={7Crp|?7{t#thCxS^$l1Rti%qG|CU>>syI;6KCQli z@5qTeyBjxb4T@J}b9|<4Y$wq?a`uy0SXNMjBW<7V=40c)#(n;>L}YnU!1&IVIj-Bf z?Muhktef<>Psc!iUFLuhtfJl))WAL&%llrEM?A{A8|LU{HFQ+0f>v_BA#dL3C2mr= z?SK8+!<#gV3#w)Fp5|kN`zzg%2IBE;yp-LM_3rjdp}1~+rCP}mW0o^%aHj_Dk>!)h z__NoBlr}?B!a5FXfoEBHRDaMlQxqcYRDy+hHH0Ymt1Xjc_Zm~C-ATHP!<(Sa9NEul zbZUFjmCx6Fl3E#9vxlMq!ZforFDtkS@7(JGKd9c*L;xshFZ<73cpj`T$K3l4$2)YH z+8Jh6>~`}`D~i!c{;o2G`5}xebSHILI@<`Dx+Z4_^RXpzX=TXgysjW!T8@?+r}TM{ z=@bXkjCYZt2_yG5RzLv{gHBRq3v8Z`?YZ4zi;GbyCgl_ymSZBi#kb!WfySJW=Cj0) z-_)gd)!2SMmfd=KH)U8>N@qX7{pi2cWM!}TI;>?Ss9Li1DGMCslC@g$>t@qZ6I?^m zqeFYO0Si9aXHfPu*BB z8&PCv_aKzL~5P%>CxT#+hWe*@&Iq9ESyH%`XbA)SV{~y z=ID)Cm@^uHK9xuK%$i4U1JRTYiW@M3Y}N!;M>9-`sal(dYz{((=)~qRH`TF?gCMOQ ztepM=Foc5TR{|DKeS-IIsIAa+%&X`mxx3Fv=afU}bh24m&dh*X=bTi-8DYMhmwL1+ zzYra`q_&d$sEN!)#cCIcKJJ1ftOPh4d6T{CSX2A5DQo8xOGDaFBo> zr0wWWaG@$F#^vTpgDlG5LE`Tl`Z{r1J*g$MsBeUBaL&*GmSjTjgS znEpsm{LhgsI&td{dw&`fw`L+>|5LzG+?pAR;~#p4|0W*rd)vQU@P}K~WDP8g4V?(+ z6rBy6-0X~ht2C-_`thb}ZscS}z{W&CCuVGJYUcF&rMQigv4fqhmA;cP!SCfkKg1)g zY#kKs^bL)n{(J(8()x~;1RQ^6R|=RrIm#J32-;fP+1eP}IDPnsPRiKE^rLSMMgqEj z1;PCtbvvE@2K4dj&v{hD-wBk{@A3Tv0uF;gulN7{q8J2(*AeK`znFA?&xZV8?494l zAwOox|3%*UeLnqfnmd1rV*KCao!_SW{}=E4+d3kk6Eb!&H#8P?(07BP`;RN`f8rHp z7KZBr!cCkU8M5IYk>oNq$G67$BPqS5>R)6OHRU6A3;@ea zT9dofv|fGzchw$TTmpkJ#-Ya433!iS;S3nB=K|%3wNHdc>~z2*v3{1X&V?)F#>5W=|plZF}KJVYhv%Ad$-<7<9=`A8Ua?aK$x z4S-;sG{ew`MpddML=kzOiU$X^Gme$NoI${V{S<)!1Z2=&8TTJ|u8*Dc|A5)Y`Vo2h zuQ&80eltaWgdlP(OAT?lp{4{2c%lS9o+T=Ggjya{9x){ZbN&j7Fx1>&X4es6cLZP+ z`3nVM{s6y_kem`d=s^uI8h7~ufrJo>M1y>h(-zxnm#=rmY$v_`Bddap*He7DS9_HvAkRQ6qr(-aEuB{5{w}jhV;XH-AZ01+wX|sq)VLZH0>SMLIEyIuk1kqx` zA!sS!CKpr0Y4Ju75nR&wX|oQ1!Ejmqw73xni3QedL0escvgT|XW&jRXJ&?d@p(*^d zcp=@Y1w3(z>kIAq>Lw=9pPzf5==>5;3s+7$iX*KN{CbHcb~=qS;(2jVG`1!2wNDTg zQbkd2?xT9^1>2J#tuGC;{nge;gr<2Es!(pk;kJxO4QrAPc)gFbSQAnDaft~&$h7`h z1RyyaETs1?XIE#1-{o_1bjX-tk*37z+A@GOZQhEsL-2vhn0G09YO~Y)>Wi^KN`ADr z^^b1>WtX-g|D>95(;5+?q^jgG>GHtsp)h|*1d?NuMkuR~ z91P`@e#Gdl31+8ba=rvnY+M8;9d{!%XUqtMfJ(k)>2i%+UsnKT1^!m&+x4}^eX-Iu zgihgPCvszPMR}H%T@QR$rfM&0#KBhb)4<(2(a8t1i%yg!s~1aU z;ECJoQ^ZvllUXhes5$g!6?+@aLr=NIK_W2svcu1AHM7SnoJa2$Nn>+|?qswQiQ3t~ z>!ZiVZC{l$75TZ}Fig^so}3+dH;06d%i2|fE(4-hD{=P()+1v5TL|D~9S!Aho9qzw zD}3nuV6tS@_*;G~=^;;OCd@7H)Uhb?fX!BQ#0%3O4HQ3%Oh0I9*1d()OkAgAKq2uwD4r>d6o1QU1@d>#4$U#kthu(XWE*WS zKgBx&Qnh}G)?Etm0^kVU@M9t&qA1}AHNTT!!y7RiWMCR?e>25MVDPu%z5w+P`c8li zuQi-AXY$d`g-Fi6_2c_b81e-TJM57Y!K@==C-T-=gBt*auD)ZA_3RW@cR5#BycvPT zv|k*oDq>JFgI+527zj;_(PjsWiQ1(`mYMV59D!ag614-wx4uTN6~JEQkn~ASRLz-3 z-5F;*vp+8;g$D@>0xb)(6u`eUI2RCrcW+o~O5wW6*B>iWDe23exmIKV-wN_wpsc&{ z^f-Qo1+mKR1-@NdR`Uy6f2hnTzSXenw)L2^#&=Mgv4F>_gDzi44x`i3t zm4iFH@3m4>L%>-NG(G|c|MTT{6vFL8W9H7B$nrcvyB?Ud)*mCd3yCjn_f4MT6i^d> z{EDXKopfRIBAxzl&imb#03Fb8CW`Vw_DEjQwCTqEZI$OYi>lR zuQ5M)4fa1VSFt|ArDB1&Dorg@Ho{*cI)@(d)%6DEJT~7fy39MxvSICYM@}Q!5UhP^ z`R3F5jW3P%WcFVytN(5=o{8n-Wb^l9L1+4E{JIF@(B`cw0J+-P3cu2Xxs5;U3ov{S zG@Pbz;SzU26Kh~8%Mkj*^YwA+jBx=bZlz&JxeD*fcB_-m>+K>>{MX0w7j2zOQ?v38 z2IaRm-gnKn>X)ZW%UOsqf?|ZWMC$i>#=f?@$@ei>9c=fA^ z^p~eS5mTz}M}~I~orXjX29ey8De_{i{lUkCY~}vzv969T8cw%(^ya`lSRYDRH?}1@ z7ca8x6FOVjv*sz?hD2;S-Y+^G4cFX!yPNxLK4b58{*_hl4)1SgZ=3k<*ZqQbZ;e*6 zY%YgwQ;EOgtxlh!ZI#}hn>{mm;JuXLIiJ{09A8gg`{D6*-|yejo8fIYyS*LXFJF(j z`0CiSbd$Xb+mkwB`}-W6sgo2dpVPQa#up6i8MIZHPp~Z;w{@g+xch0{E`gc!aNm21 zI-dJd!38HZv$RWA%9I3yq1DCrJk4IKrQInjb;WhGe${SFBI0(~jOv1%KXF#xR zsa*1Eve%35DX^%qXVxuQX)GGAZZ!nTpQ^Z+reCOyU8tdMXS&^Rr&Mei>u9wPE7qW9 zww{kSEw0aoup$HzuX_4fri4ll4OJylrgP#vUsaJoXiE|(xqU+0=_ThACktQ#cd$NE zxXoPk9X7-X+~69lmVKPy(|+mb4~T+45=m^kf4l2vr`K)}ybLd9G%z7{sI6(DZcmYA zsf`IkX&!=!no*4?13IWK^3rs`LANTavRbj*bm>+8PzcGd!OUqUxBH|*U)3{znTnAC z|Cagerw64GKUi>S$*FiJ2-@AAdvKwt^qq~v=&Jm%-2sE!6*yRHLswq>!Ft$=N*RuC z*aQO*4L~%E13lvRR6p)POLdmo)V<;=8eWTaW~0x%6!Zq3Q)ld3-bS_!pSwl3XSFC# z6GBXTBO;eF+Tq}@0cH8Qiow#*_^lmT(Ww1W(&}VRMpCEb`+JJZ3jZp1i~fn(gBut_ zkZusU)hL#{ zbs3mbu6#i{Ck9iT+IRvNbMgR`J4Br^D;2v30T$QsSa3tVEoPJ&mGJZB!00hy8>+C2C&fi-Zxz3uXPyxW`Etm6s&)-r%t4L2NLQ zzz9Fq%WbF1>g&tQW+RPT}LNf9*RhGy@$%Z=Urrn>)ogk0q7s*i(nP?qN zXnqK}MqXnNhw5tHk*5KyZY^{G?}s2C5)y066^8>7dmkikuR;)!PLXR$)Q30>&!nHY z$J>HLL7Ya;JXQMQ_Wtu;&nOUK;JwjC05Xnx7>CE@sn1|ogVjJOty2=AP$3X!V- zzR35?@@VtSE#vp>oDS8M-75Aa_ZCZ`Ki^KUF|wRQE>i$cI)`BNnoAGdfjF7g}6L5^dKy zq0Td{aN#NtNV<DlI)gsVv$og|HdgNf_ zr4evByI25!yZy|XS%j@k#n1J7bVWTP13m39t@Lz}XfEK;J`Z9$i0Cz6gG>Y9-F@U1 zWTcSPakB%LUHD%6%!6;n%>Kg)v~*p>4g?ramM;N}g^(~S9U&o; zT%U~i+@P+lII0hGKCP~&2iaTlkda24JFPsru1Zw(;2Wg@7Oi5?lT^kvcvq`;HT^pjnhV@y6eEMH?qI4Ul zXm0X0Cu~xRo4P|QnG}(Rc1{r|*}zC~NJxNXy;^nfg${r0Ff`Ppq~x}RV!N0*?^qLL z7D#23XTn7vxZ-zrY$ZX)a`8Sj)CNCw};``Gc)7&jZ-U<)X*P?i!tI*r3ApyJtE?b zkP6(3Ep(*vgo*S{b>j+wG!EPBmIldcr2@daLuI&`-^7g4T=&h08j^o{vE`dh?1ClB z4{56(l?J%qVX}#Z)COAi_i5|%FprnnHmeMaodNCCn!e`v&Jl;k>ybOdfD$_tmo1Nn z8vR8&#kQfPr<$RPD>5pL`XWnd-mgo2(P6<9RV2bTef?J;lddGFItG-p^(6=N zqVs9HAuInG!UYk3S#mK9u@5F&okC0~&v`n;re=QmK=UmS`Xfos=+-rRGNr8q^7E*Y zJ;6pLxGoK2fOZE*zDDaUaYK`aq0(g_v0uq5GV>RD2@RmW0RI|PN zOiQ-(A>CgID%p4kPZS)#(5oeKPW`&7CwR^idzy9JQCuX+Yx(IHGqEJFAw_*|yuqUV zqcaZ+&fYFU4Gp5YPH;~QU?-^7x~g|viEEKaL#pxJA?Qd}{V6T@D;IlQ&VA`j!*u6q z3B#Qq);2jNwuMx-kr7UO(R1~IaogeQQUsoPU~Q_|G#d+c?UgNST+eassl=wg)2wd? zT}^xu2e2rpzQ8YLkWWUA4rW7CZMoACp|Fi%)Co=djPR5?vbV4Ov^)4;yWwW`d|14fJ*G$Ha2i!6H@E z8t>AJE%B3Q1cqhM77Oi{w9hU%UQQn_)bbu%%bT|n94FK!$c8?sm86-7Gkr&19v{M1 z?V`Gdmwh1sB&DYMM3RtpCJzbZU=}7g%Q904f{^(s%#=Goh~6?AF{TC(>nN3m%@s_7 zy)ZXP#sr_Gkt$obZcEC7lx*`qz?Mwv2xi?oVb;$ z-;|=p@7dM@7>+P7-wx1JXD$tG@vVFT7ZSWU4C^nuY2}xul&KK=B10g<>Er+Fm0K(S zFhOx|Zi&@P*cQbK{C$8MCPA`l2q4b8l8|we-_mr(AhAODD@F572M2O+w|$0r{`59& zVK%CE^JUJx(k8{W`2wVE98@3YHLr!iu;)|djPhRvc?iz^XBC>{Evk*&vYoUQ_%pA!!aV3t(fcC+3Ogk=v*K?8wWDkDrnk+r`fZ!BydGU9(fPd8?m$FC1L2X$|& z`Vs|q310avp)1NLAR*I*Y9|erdB(i<4o({vn&gGVopxvM^Q@a$MS3t02UTEcG5gM~ zo4QTS!g^+VCwgb^z2L8KTOV=1J`lc6-T2Hd>b}VpocoADKfm{ToJ}u0+ihmPj?Hm- zJkdT{KB4D3U-UX=?LIBST4yh2#;P}xek~2LuyY#&beU2-sTWu$H(IOTAG(>%-rpah zpJQZb*ZYG%o$-3To@tLxoWI3+$7j5`dZeSdxx3q^XN6aY$nhLrfor z=FZoO%T75L@T|EtaXpi)r9N`m4vD_v9+qO3zF#_}zfpSKr{CyqVtNcw&ReH9DleKr zjeeudC|kW*_o*&rc8hnmHdn$SjvJ2mw|F6+SJ&q5f4m8+!}N>2k`%w!X}EHaae`k`7ORlAcWPZumWzbWwx+635ZbOe86 zjV!0IAQVOSqbPfrey$2J_A%A$_1L^j|7uE+3M!T^jjM57Xqbug6`6&QvcFmTaIDZu zoz(nuSH=$g|1R#UJF+Sf<;+IP#{%40|g zfw}0AA2xHh0O&gVb<8Qk%^qZFzv1z7TN*s;Z* z58%6tzDXGt4H=Z~6~oye19-c*7fgpKwJaFeUpTL6Oh$z_@eWj8N82P|B+b<6g$eVv zkb~@K+k`5bT`;o(2H0V=zoBuVA3#|TKcfr+&bIokEi+uUgSh5;xcR_gWv!f80YQEr z0?A%z35YXF>u8esXzhssY^2-aw*||+umz5H5I)wXQMhCbJCgX6@$5$|^adCq{sL5X zY+^jAMN13DLAw(LHXGN33bM3fUU7R2rQ~SsXOf-6Z{UF`ia4H6H z%vkP^ED-1DJ>YH*R$w!rG805MU1UP%d%woKr!2L5^6$FF3vYjgXua@3pSEoTyNJBE z5KCte^W+<`vrL4Cu(HP6^q9sM(_OH?_8A@`HEcVj#oQeQ3LW&R2vxmB@C#e5gyUjbM=7kGIk~n>6$qO_t zKh(OghkV??5TRyo|5;V_++wtg@zqOfxj|hX>nI@9GDd!0Gt`-UiB8EbRSX=xz*S=b zAL8@m=oD3sdm@DdKm#kIe8+8*4#_)#`rXr@UpENk8y{gJm?h<;{tB zGuZw=znC{0= zmnfT#;w*wPx@xY_Vd-qQyQ0;GkIgWm4i9z@R_viVyn#d7Qs%zNNksy1MdqNq%*Mc3 z#I-P(OwHs3T`rScu{tmHwqj*2;d%1E3o?qVA+HUHD5|)rv;j+FL{6}m&1=HnDty_x zk_2IKm@;FV0P09TjaXMpQob98;_sGYL#8h=nOPaR zg@k;Ll#0TgB;eNWwOtIw&Hj~A<=JwqEJHe2zHl>`pc!~ba(^u;-~9^@xx59Xy2cKg zF(aks4;W}N-IN!VBswggX|)&dQmPB zG=lLgXqDAMo&a=8pwq3qUn8hmBt`dx17Y9vZkkkT4SpVyQp;&-RZw6sC$U$Xc_Za2 zdEpknQ3fg~);Wf=$IAtn!c!a68NgO4R)d&)lx!+$QpUj{eQ?2DDYsW%FVv_tvm`}S zdfF_6cX&c$?ruy`2@w?rx}VbJkOCiYE=PK>lrU~7c?t5j{T^eBk|Z&9hE|Gb=b;Fv zf04+tK8G2zP9>ciNai>#83!>RBVImMuuQK_dTQ{=boMnaU%?e_%B3&cZ)Hm_7E*hP zpVb0H@`e~Ybma@f{Fh*kQql>36&`Rf-pvH=7|f%51T#@8<7J~t;j$0paUFS1Em6Ng zLlmD&ipr8zq9P<+11r9&fcN8eRiHJV`%xe=O1a0=cm{gW$hxAp;o=Ys509(d8WQ4{ zN1|R7LtvF!j4AT40m-VB&18+MvpRJREpfWZjo3EJc7r;iqDQ(2c3!@1n^nz&m%>kN zN3CPqHJtLM``b9u(G-p<3LVDb9bb+gV33OvXz@kbg2^o$Ka8_kRPeHP>c(?vig-zj z`70?52A8S@vR5Y<5Opc1!i==sEYOD5+j@nD$?ygvP{mu`93asq(naLXPY5{AKB0X5 z=G0T7U1SyLd3|#TBr5g-bc6XC!@))hmKXc>T@uGRuizR6PYmKJW4wSXHBgdmg7u-C_MR9 z7@oM|j#nTOUpCEjqdk?ZN?e}7*-!C0EN4n~z|awXs3M$OfxWw5%C|N%BKNXKr(2@4 zDn2L>E-UHhROLHXVjHeN`ur`_nT8hD2~KSJnv+Al6}1;i60p&s$8+NDdg4_s#Wz%s z)pD-NJ%_PHYeagUX(6tiFW590#4}ll152;M{3#CIA!rFfFd8n^uFJ*kJ%8kUfUXGx z=~%YCDtv~-WXY$s2;0iOXEp`KfWOv7p)6?3Rj1zB6qp_|w_##jH4YEsPNmPpvhkCr z6O@s1U^zWl5@sFl=kr#|laYLV5dYP7j?ia{%gn?#a1<&nG4vtJq)R=NIF{$7u&}QY zY}Wj@6HSM-soA<`)FW)|A>uT*K`W#O5LTYYN_XS;L0cONE_uO8SV^ZKT2Ll*@{4h2 zR;ZT_d6O~#>;4Q1e9@|Mv<>->)gDLSZ9X6SEqkl|8y9`4opUxs{6L>g7LsWd)!LpA z@(r}z*KZUISuRlH3+GEv=iNr@P*)QwN>1%I2UFVfKuHMvEw~Z1h8zfrH}iv**6>Mxy3ZStzYO*SxgkoK`8?9F~TcQ{16 ztv1>NxGr{D_Gcd0K%ay=(G*rg5;wJSh@vF|H!fc3CUg5S_HKU0;FfF_sHlnk#A zy0}As)vsoi8xM04`Vh?>^>b$a@y%NTSfP=Hx$`5*=~Hi%FLL=gF_5nQEN|G3pJg>< z$l7EYWC)&tcDk}wq#k)qc_@|F544N~rSmU^BDQspnGqNOs2(j!!~-t^GzOQxq&CZ8 zgLMIHmvColyO%Y(&xln+PC4KyYf%-U&S>Z2iPf%LMfq1XV>n#kn#{N{+Vo2U7K&2SS2G8~2tHq(&!3dU z&(buTS`5A$QX3^B2dYGQ4|>-_U*!sdIV|H>Bthj?QQ0mLW_?ej_dfZ)fAlPZ5r7-l zN?jP7M2dk%WXiZi-i6vH^Q#wu%mmF^R=I};1AX);xH_^NY~<4{%ORU^`{5k*w*q%18ti1e#Bs_D9@bt()! zKI-XInIfE2Tjeh6dt)7m8UM2x*m9wh4Ijjt!ec?9dx|gXmgB{)hY6dc9-8u?df7mq z-)fh&#tIJQ-NhkjJ+o`*&dXSsCdPGPLMljmRi;vajEoDa4bt((u9Spw9d<+4Hlj?=N^l(t?ANjH6HKx&)_D z%IF<4u%%gXD!tg(4r5wkKI5BAd2a@8I!_qrS#BNy_}Yv1d*N|)J9(`s$-<38^PPD))g}1=df5ccH_I(6F);G*C7>{>_^&MN$_DcN5EV|@{h#kvBLtqfy& z=#A@auHFi9ma2r=8CfIp=I`vo#+i(1zqKyWDvi z=byhxkHTmg{3!DuH$9V~Lanks(C^a7je(gS0N!gV39r8LL*oFQ2RybY-jY|etf`kFsb8tJL9@>dBGQu6(;=wb zl|~W?kVhH^D8exAXsn|H{db#o(Sp7ertundOq;2ZAJM-oNG}SnL^g`AdM5tGW1dossNUw!z za@D7j+7|jcl?eI@k+r8$0Bk)qRc059*M1gTt9}j6euq&q@#;}0N6at>(KMo&ug_=hJNrVuLf9-l3h&N}F_)W`?Og_29v=C1x)(G|*|B#KA ztB--X)r(7JS$1c?cOYbeL4a;8cxsW%+*w(-falp}bmZ*wBL~7*B1mb_|Ji6GJDKI=#PglAGBRN~bUOSPSeIKy8?KKR+ zar^6#!yX5JNBGM$1X!_L!a`1!e)a@65Z>w@B0avQemf0vI-avMKq%(toNIPp@ioeu z1E-UeV6o2YPcm39wF{ifH&0J_kGGqNbb~j2XcU1-Q%r!nQ7V`pU9Hx>W{2W%5Yq;y z0Y~pMLQOC$k7Er3pD>XUdvy| z`+ti9#6bV=b!>hI#Q)9#`lHETz5Z{&^BLF){*BYa$VkBQn>f$!^dP1W8qkNR_Mdlu z@qm7l^k(|N{ptS-L=e#Z#n9pA{*9Z%K=230=OZNWZ&8Z>nEoyI!QpWvpp(;g_>FVJ zK>v?Ghw~p497%H{M*>ZPKS(+sgZyn6jDM(&e{hvP?x2|d_>lRJx8Dn!DiE;#VO;xf zwttrs`pcvL_MHAx+(@jQ(GmkTy0l*B7vL zCD8os(Q~lU6RvPWo21roXxGH!uFf zdn(2bj^?&D1au6v%zyI$(_d+fngoCNj^N{=scR50f2byX4CiBD|EN;R{+F@;!P!?p z$B{$X#xYaOOx@;~nVFel#+Wf?hBz@ZGc&|?%*-(}Gcz+&{5zAGo!Q+#yZ?Nj?rN)~ zQq`00lj`Wcr>FIo*#BPiFOL!}z@H8EuSJ>uuJzA8{MVw441ZVqyQ%;EVcGwJmDXSV z{;$7UU4*P<+c7yVNi z{ ziyNdgb9A(I;G(B@adDwDv^KY*GqI-!eXNWfXbtooKu0TMQ+-g1-q6O{0W^9Te*zue z|5Xv|FUkIT0+6JPzvTMm$@c#tDF-8f5wz79Gl=wL^}E;r`i~zwh}+WQxC? zL6z;DjDKecfw1vAQ}EZHFtxD0mAQevIjzhe-l6or@jbZ*x{H# z(-#XU%>uFlXJuspFfp+KSV5yM8|Z&FkZQ7m)QttS4;(9q)n)|^!EB%zlmj&FvVoeK z1vJY2D$4?zx>#75;g~@Iwpl>)#DAIt{&=vz(DtWyDl;e?$p7kXp%XJ?y~KbldiMxN zH{}luskwRs0VensT$hyg@D|+2-Uz1X{nrGnpHFG}lMwxzbni@0gVeen&F@;Iw+s&T z+~7Pkh8YTyc6fB`ksYG8lD_pOa|G=84r*}RIH(w|>Wzh_Ih!ZREUETRw^ybmda|-d z+Hv(G@jfNzZZi^$jI0%UaW3fXK4hkm()OzAnC2jac^vG`{Uj}*o1LLkB1$}hn^Wt{ zJfaD}+b~-#M=zk{TW49n^gRZ>JwDCb1wSBCbQXw>PR8U#L=8eJD!crWG?vsZ8-&<0(o)EO10s^)9UmYot^$Vx^fi zyatBmieps#6YrlNUtiVhv&wfInm1yYLuuu|9c#OAl0SGlU9lW}$zk8|soVJPuZh2L z_E+Eijp4tc22DuvRwhuEtiJ2-6eBb1FW`Zm1Z2Ts%mmV!-|ue!RQO+K{u22& zTp0lzOrZJfKMXwBK%vn7g9SMV~p{IY#cbndU`LliZk*YV>^}bp+;3Fmf@9 ziN{8F17TsifyhB0*Z^DD6$nriY!@g*cpZ|eddHY@_>AwGjkY=FVb|%2Djl%BSFPGO zR>Nn>>m0CIs&Cv)NH<8INZRX6b=%!l&WhAj%D?HJEjD_*DW1U2naH^jZtarzd~IEX zJ9oCQ6Hh;p#h{SgdZit>ILjXyrN6W;Kz|)el$EEMi9?*QFJMw32R zP)VBOVi3_mssJ%DrT#B1FdPLwm(LOf)&BlO1Zt(~h2{4MobmR3?5kd4x_f(tea$vr z98c6Ue5V=!(qY+mSN3D0KjDBg@mfTyO5bh=mS0({=R}p5jq9tGPHm>nkQMg)h}=$F`9$~;T*u?mI@1FRUP6%x|O zA3hp>5Sxxi-m+x|w*{Mgsw*|HieL~(NpZ1x1;?B6|T$*&i8eP z`{B8Kb+!9-^O5l4)EMFdR@mS&-)E<(p`MA5&^^BJo zdBxwRJ={*H+4)L|zODyfwpA#McTW@$a4((BNa&9MR0|@s_s8_7e5(W@OzY%--VV+C z+zvVP5ZcN16S@=lb7mdJ8+iYQA7go}9AUG#KR?koH}Gi3-BzmxvpL5}mbcg|I;%eG zr$;R9vkS%CIlcV%y)k*~-TZ;pXX)6$2P}%_2dvT4^|5qAK z=Il50R7?&P?2(E%+i%Pd3lHo$a_o zA4WQ+3j)G7*Sp2+goWEV7$)ey+w7xx;JJ(FA?dD+lR3*fKBV-}3-+lX66A190PEOm zLO!9D8BlADtxZ)3X$zX3yRg>;4N+)z?*@ofn&&85<=Ni{1h`ic?wy}HV$kPtyNVc+ zd7+?nefT1pAw2*GRlS`FeGIHC8z7SSMi!arPA>JVzaSCN@w<^WNku> zBJ%$2Ql7p-;?KSO7c5z|W=LGVi{t(LjPBM!21rU%u|c9He#DvLCO_x}l9l!`KN|5R zqjzBEb`iryzkVe&!6{7aTOnWxtC1yzH<1tw-e(lh?kk4tKOALex7 zTzbQ1P?`0EPbL&+O|HFictY;G`P87;QHJqfOuhyJ#rBb*naY!>@C?lcmwOSZ=Z$0L>_3Stfc!y5QLhx^-o zOM@#<=tKP)qVVj%@!b9QSuAhEOI?w!*PtE3az`o_-(%NfJ^pO>K-cLH$%uR=Q$qXM zdyKS?py}%k=fMZZy@=@XfPeFz#w?VW{gNV$u(4P{^k)Zt$Z~fmiMI&VBcHqP7&|gD z_u`VK+G_RY=??9PY&hc0&!)u`3q6&cs*wC0<9xCn>6Qn#MvV-F`lwNE8Zlqp5>+xv zPSwtFbg{DfZtkSLBrI&Z(RJhSL938KgaeR8kK9iZbWGo|BwVhq1;-He_76gD zuSagWq0}J1^$$5cKqflo%h}3qe4l;OL2>9Om&iiWKq-NNC%Brb59d$;SGI0~V zM1s=LZgBaW5RCK)>zTLmHA66vWp;0H2y$fb6(M-wO_OvEFR#}TwB!mm1Ko7zJHdn^ z62QaZoAaAqzk^KeZU3LGycNN+A_!$*1Jnr8nAzl1p9DHcaem64fVoMaA0^V%q8@4x z;gPw$Fks4b^UI+NW0N|-mVJdUVz~Ti6g~7{52O-G_d^;`g_pXx?*o6qBW>$jK)P-0 z#IP-pY?DLQD@4ZLC)GqnP`Z7pz~{*la6>;nfp6VP*IzS|?>%v762lirGDTC81z}w}$O`y= zsbC+kLCPG_KxrXr9WZ@?ee{k1Pik-xPLbKF&svK+2tu>Y!%|#t;k6Xq5AbQBB%?ea z@*eRuibV?Tn+2`MSn=8gtV3dTwxqK2z0$VngsgU66d`ZXh zgb5!|78C0~x%q%S&|pT`(<6NR zvjb8J_yvK;^FCBes%R0|_}C-^))*=5qUdQM#7;F7PZjhrR33_HiTQv|#3yL~hEj;v zk7pfj60~I|*^a0rhIWJoj+8`tzDw)+aXlLmPwIiQib#Mz z$Z$@Z_k-ODVki-FFK1{NfpPgdMjh=(!z$WNu?XuyUgrSC@S+jzF7Nv$w&s0_x-ymg zr@N-<4@@2ryyCNy8FveEv>8Y3k0ozu>5`WQWgXb#F^yq|QzDVQAggF_cPWKka!oS1 zBXbAG<__8n%YBLbb?B*ZWGTrUaW@SeODG_Oc@-kxa$qSGlAK@ z!8KWT**eVWnNKo_3l$Z&OY_H=yecM37VYu(hm4<&A&!jto@=D7XeUXgqaGzSG0q%P zoVR@&ztrmZbi%KA*IWWF3YV&q|KWWSX^F9&Qv&07qDF0h&qSJ!DrIA7%p%Kcz~c3t zM*51G{l13k83WD^;0@zGS2&$J1!Cn-+ocxoK^#lN_}kFU0Oya>6%UY<)XGvv9a zUOU%jd9Q=8R!Sis-iN%a%*nFwQyuD&F14{!NdY5W{;eYV&icyHa@-QFD-)gBbc&;R zNY>;cLoUj?sgyZ$FdT}Cipl^J>*7$5ZMZ*Z&lN+U-1YbOjxBWsZy>xxKNE30E?PDq z_bd3W&uy1#z>{@hVwjSriyfH}&!ggF)TE>BvlRIDXco?-6m9K4nb4o*$2EymvucED zJdChUCJaVz>AitpyA!_<9Xh|7Nh=B z#MX-2Z1Xq!5Y?yZRXN?+x!YY2S)H8$f`z+d%^RTHH|@DNU-rbCveMy7&XwW!^~`$9 zYiVl}>eh!~u z#5^ObF&&mpY!0Be6@5!<7V*K=eR(8mCOBgClD7*+3ZudyCC~8-FP_c1?55^ zvwUuzf)7cNr4tl}qRPj!;Ts%{N5Br`+4@dQ?qN0mVr@np8&*%5N^`AAp5SA$tXbmA$$3!3aJd{i*JCB)~6@-+= zxAf6`7iWh7+%`z_9%P5&9hd?^(`)lSQ6^!jq6m57Nf3zaPl!Ko$n0^+x+t@Gebaym$)`Y3&9 z$XZD2hnmtt8|aLa#qww^#~CsZgAb$Iram3oRF$Ep;0c(ypYub)8GU1F%*5qLW2-}K zxCXKwde4H%`_)9xRE4H1YOchZf&rllKWNzq3jKW%9L7^jZ0t=0^5C>Q)&qX$^)-`? zu|hUnLammMZiU1GVW*v|p_rs=g!%nDVH!Hdm@6>^70lA;G=a^s+=3wnaD+k=RmB=DhZDKj=M`OsB?0$L<4W-)7W7 z@RVWg+*|pO8@ZGS_kUJPVg z&mw4+L=Zm2ACVo=&6v=zUVOUXV3+iugP-z(7>^s6i*NX&5(7t95E!2=d%I$rV}MCh zjbZu*99*&1!M*t_15^F{^V^FLACRiafvNJwh}jTcsjSWl>tWq{5$=PHUNH=s^3zNn zBiq4e@ZKV$g2kgb6m_o_X;)g!dnf5CUs~0&F!d6gCy1NpN(NmxVuVh6aKowmmV3%9 z0(Fj@XhuyRN>z2k#0#m=L<)WsVH!*fsMif^!Bm=U%tGRa^CzpTXW_-b<|#RAOXQ$} zm6iI;EXhJ~peQE=xEjqK(rA*sqcH491*TE+6r_mAhlmDKpx@^VW+WL{NmXD^U!n52 zSu%sa2P^vmaC)4LxK|x`P}KS`Qg6-NA8n!-a}98wOs<6k*9?I38kK2XMU_(7*~9Wv zurN=h(#sqmjky{X6RvEv>Xd7}Ac%>L3Fgg^=`^YQnSPQ#c`GE3B2t|ckyLAu%L<%` z>Al*uHE+u7l=xeB^W=VMK6C;b?}8(DgRQAl z^?I6Di|0`9&mR$LTt%tK#pXeTG#AfH#6*m07(Cly$&@pN^)k8B<|?WN3Tt!_7*(-B z?tu+wnf!Ng$B$Tk)Vmg4B<&ndhl{={Hxz4b*WEL@Gl34XnJevQ%e^hfZPj-XZ56;o zu9xewfs9id@5gO4Z@1#YBP}9t!|m|Cp3$kq`m=`t^U9|Ib_trdXOC~ywU`FQ2s0N( z0>a);^(UbiX@n!!)LCHO&mB2%f(5@^?P-o8BtcdNf7V|Zt!{2(rI#EwW-DKtPjd4f zX$pV%5Yylw%J$+ocTk3*za=zbcl+&hrHr6?=(<|XA;BivknH>p>|8DEFes9B8?Rbr zs>q0|c@SG_lpVs0@2TpeW(jXXc28_lvdcisZ-=E~LxIVN4B~n?}Nm=4tvaeg1Sj z50TZvVw4Fw|-bqhX7p1zOqg(mSeIRD=cB5JAwr&p>)y=_Yv~)^nHEvVRE}q3y zt@N8lm667iGcgj0`rAf={9IC^rJoHjqQ9}#i4dgVRA)?i#^nl3{ z_kfFT(#b$1su@ylMd|}z`wU|7XDt$kZ(N;%>w&|5p<+*fwAC48aC?c_T{xhY#Ev<0 zjo>Ufkx4qFH-KfTV>+_5}7U4^8ai!q2( zrimi}=EnvwdJar`?2jErnrF}tNyVegrrGGYrsS!)i+Sn#gZ7=b zP;2=;;WpClnHI&&dG>skfG$1d-KUQupZ9jc@r*oI;CI6NC5&aMD zN65y?==ZAl?i6h1P}|z7n2plY_o7O!u>(` zfa0MugO=KVo#S8tkw7dU4h_WiGJ)cvvx4$|rGNeY%4cR_|NRSEJ7)nAcE8TEfmlXX zMoze2yJ-DNvw-f#49ffU{Y4u6CWwBKObh@PCT381_Wwc>{gW*FlO$pRF-QOFGP_R9 z$S;xz>dYOEa7q}U8FvDK3<2@}?fp2>^a;4c_8_u?^jlh@=iBs^hWF!L_+mr(_t9Ey zgnUE=c1}BYJbk&P*4Tw{J4|{G=yOBnX(6&Zlh||33-zw22|0NWuFa+Pd@^0fDFwFQ zp9P1EN7(PqV|I1<4(e?Smn!i<-zQMcR1kUq=2|ATJgoB4C=>wWfzd+mBNb+AkD{G8Me?>Pm6xT z2eR}NWMADg!Q%`35iHpZp>MQAeqL3=YWbN&}%i57&Y{|9CX z4#X^hboIY8OPv2?mOvQ(C$j{C{eNPX{;(4Gr+op4Wc}~V5+f%kNZKDi!}(aNng_jf6`AF|RF&02LSW0>O^hijcO5GC)F{B0CI&l308mPvB=qG? zevNT_l@Q(nuoFyE3_MNJ5fHt5~-d!zLj-e^)ks;Yh-VvKki#wZ3HQV~nzA2|WL zLsC+xy$(cLMdc4ZdDJ2|zC;;!2(7LgkI|jEsS!HakBvEa$GJQ|Z5!l2PgSbHDz4Z& zPPJ!z_586+xtj9WkE>$8bv)LGk8;QH6k8dl)Da(aV|cI=#RXsaj?rdV7k02Qh!f`X zuqxspjUU#AU;_%B2>Fj-32_c&XTMLwxK5GG-l8qRuHYA3o2=b>$lhWtA+C@YOq*og zp+WpWT>*TtXOs(`P0ns2IS#CWK@tJp~(4xM@LkUkYZco2P`#Xvw4fR z_`2d{L82J#QPBWWQZ9q1OjOmA?FNBQ(1>rkG zroJNC&DhNzRA15bU%G=QfYu%T0%lXc+XlH^jK|Lv`Qpu{wbivw5I2eo;Pcl8f(v$* zey1Qy6g3iOVrTt*J>Pks`LKCE4rn`!O{;DO0}=yp1C-kc{~*YqhajK`M5~eyr5HL8 z4#hW!A?HnWBn;3Vg)`{QkH~YNPmmP~ekd?45co{?XE(eG;0t>C++#C-y@$B~Zi06| z1>GT^5&w*Eg$8xir|vamo8a|J#=}cwpa>l?G>V83$ukULwEsErGE6*nK^khdKtBo- z$}v9!aU_6G&@(Jaz|-&k%>~~kZ+A6zw6}m~kn1};mUF{!i*8~ zzV{fLV%?D_>>$uBlla6Moa;n3U{@mA0XN@vKLq7thj^e+BM&j^jtbBSh7oHbe+m*4 z0T&XOCZQA5_Pa;Pfl>@C5>p0Jp_~M%il8fgr4*;^7SP`b()2?Bib^2k6XRSV6r`ZY z!uW8gK`;kPWZB~sL;%|aJ;OOd?y)vAgVxr=&MmuzgP>7z4HJg+Ur@0+two{JD17W- z<#BOW^bQu6^?W?DPi)&EFV&*hS*KPaeeoe4X!{KTkv=?cFDu*=p4b6*UymViz;Pgh zeUHH&F#72QPazi&?UDLd04`sbVeO&&=>@EzA2|EVzU`c930Oll!fu-a_#q!)L7`^& zp&G%q#Q}4^+J!uQUab8p0B*tW5S$%1_A5RX2~Thm&kBvxD_Pqn_A5r5b`HD}yLF5X zjOv@J-L!_}>Wa+lB;UofSxwLd8qw^?HsQLFP!dVRkQ0H(EaVrc_Uo;O$1H=4-1uBEkH0+1f`W_(j zt0&wgQWOaw^NS|}p*Q%pQ`DTm&$pMRQEGy^U}voemzGh10)%fk-`L~19%$Njb6gp+ z+#&{Hm?iB583!>VOQT35hoXcc3kL~`yeIZCp%O$V2|@P%4b0mCVGwlu;x^x~`=;`# zo<#5r%Tj;>0s@w|NwS6qLJ5)SWoGv|u7((^A#q*Kk`}<`!y8P8hlLNVyFuzvx$&od zICMuM&yjo=)(*XBfVV?500p+L^X4-kG@vthXYghsGATUCKM17RtwG5_gd*$)P{e-y zqSU(pkT!_C*$}@+<{^gP5Eb@7w)TVQ1gb;$0)F%$_s0TYqYMFSUpx`*(SKa(0bU^< zV77&$kOWqt-H^6*qS}RB+rTf``qu<9ARoZ{fl;Oc8BhGo0E)&V9TFjHO~yXMT6i`mXNUkqvBSgX@MMA zm5`MsOp_u zwhiB|<@;?CAM=JBuBK1--}GnSKG5KpTq~d8s2=6uEzS0^9qSUsmfn?}X^p86YK&F< za5u4iX}Y07Uu<5*3Y+{9aWflMWZGKM=E3Wty0kdov|?#!xv1L5r!j(!tE?U7Dv$xb z5tMO6!rjQHA466$TV@bXon1=}m(Y`Nri;m)`%%*B;FPSg2Qt(^7}B@WAM(l&-gzu? zggOZ=wb?_?Dl3bh4R3IaYCp8c`L4$u-ra!N<*wTVT_#c%`lZHaRDJGrR9#$9tJKRy ztF$@XoHnRevw?}-j=3B1b+)mtF`|L=uyfcc`M7DAojKCT{wPg6?HKZ%Sf-s|?qYWedn7EKz4!!K*s0J-P{f91xHnV3F4$Rl^ zH<|ksH!-~KCXuK5E7e@q0oK{pWf4nIH7|l;9 z?<^HiI3SFYN+k4(9JKj3tC_#=XW*GScfYh=f7nk(OFRjRolk3g$whG3>7eXlyXm1# z=XGH4I>1ni8txr+HL-ccb{V2g4hK)a_;js_+Je$CnQK8RU9OB+7q`&aExyRXD2-dc#s zuf$8wuWA@iKOk+z=-Pv$y1!5BbJ`L#Mm@(JlRx!?Z!2DUTvA-(%*bV9 z(FzYyn^Cud`TM840jriDGXn|<^vTIVoQZ9repOh(!pXJfa{i&2mipCUeVdrSe0jF*E zOA>qV2gb(eXNb}VW_z^#^1y3Z13DB3YhZmecfZayp*{Tr*#kx+#w0&QeXL#-x1b06 zzKd{*?i4kR1De_C8-kJi6kbv}u~;`(Ua{Mlrw$K~7`Ni<7o#+Mz!U5x*d@R%=sD#X zs^t;p{-JVv5A6KW_rvv?cOUb1{WicYjYlwpw4Fp=u#`tO0~pv()L*?e>77WYa{H8d ziSL&2j6!_Q;P$meLYKTeN^Kx>;Ak8160>`AX`4hy`s1lyzh%@Fx!D@=S@0v8OPk}f zF3k;8+>_-cjyJ`b(8JvT#KV1_P1o5Ye4Klvr(~N?k{Sb!40*2M@HYIVyo4nV^)|k7 zob8TrRkCNn7g%PLg1BN6+$1p*@;tZ!DSPrpxXn$?bH3iLaAc%C0el@OE?nCE3+}AB z6|dzXkB-9WP<}AI@wGrvJ>FY_TRsTdR`_Rrs>kQ0Hg}qX;5EUYXTTrkMtM?-Yp>2B zcNzYLDWut2e37}TH6Hu*}6Fo^r3w2n%9$fIq_=& z&+Wdix~S6G?0P=$qN>H0AHOhl5Kp%`5kD=N1D3Wotc_y(*C$<|_`sa4sDrLQ{yBeMJ9#XrAi2J>5q83c zfP8tdE66&;xG$>!mNNMZ(b&rJbpD6`GlRW*plcpPA&uXD~5) ztOwN1C0LYG{VG7BF;nLlJp+%3bJT!7Trz3_`sq32=X*BX11A~YF5liUh$O3zFpJPA zpa_d{;8Vjj0;i<0eQ|=`MTR*a#O92AUKp?6TtN3;C+2gB!EL=79y?aSPSOj?tO+$q z@@ojFO05}YqU6A14QH~uj0$*{mb;k9--R7aHF5nifyw>D`bEe~=aa0Him|AhhIs>k zpC0@C>7J&3#eikM)*@aBm?%kxKNQu1$;Y)H3=Opv^JZ-}L4N8PnKD35389xaD@2YK z?QZ-j0AML42_}_c2Rcf_^+_{9$s-mIj9t~7XWVC-tTK-d9~=Z8QKvkB$$JX5WRUAh zzcmnohb_lCJ+GNhWcSz{&MG7$e=amjk&XHD|k)>OYm68P|BwLg+>O3T@iERGIPpZ ze?L+mqS3@hiE2MRCYEykQN&JJ678Y>{@Vsd^s$Z9El#b~I$yBF-mClF1lORz5T{X| zpO7-zhwSGW(eyCN8JYJm7G5zXl*Q2xh6*M zFkT6_y5TGWKpXfa z>0#BMhnsy;=n#IUrFMVn(Nb7Kt!L>OSl`^%xv+&_h6heE2@wcWOJw%kT@wMwVr?SC zcp_TKNQI!xcsFOsZKbk|^SlRe?C!D*VY~NmGCl{g(;<9$fV%&g4?Zp30?fD~_au1! z0^ZY{^{FsU4kN&%Z|AdrVWyKU__S8mxyXjEP3czzVeJ6P!--y8dHyXxvB5d*0P3~H zpaY=uA$4)x1hBj~y?ZWX8_NG$Aob4bjWWr14qXaZWg+(*xqIFbNa)jYUr- z$U+`;R0GIZ`KMF&s%cC~Ljer*>GV%Eh!1Ww+8zKc6w~bVoDlbk)8JTZdH(h|qIF<^ z-|6Q=d<)Bo_ViYsmAQ~rIWft#IP_h$kGg5D+)s}mVCOOJ`f`C2<h^x<+=Q5#ZovF4vhEDI<%` z)*{fA`&cvlsHex-@OZN9NHl0)JDeA4Ulid=9&PJ==E3&B6?ZccA1mrO-cO(Melxq2 zLE!abNOODujR!5}6*cGGAshs-(D;@wrP(cvb}h*a%tjvKeh1@ch2}t(BP2slXc|=1 zC6r~@ziEf*6rjwB2@28%n`8avb5`I&qA&bMeCrFE>{Cvgj}QIpZ%(wk;lBHM%cN}_ zNu=!@t&<8B1ee_Bhug8PN!;8h>qWZb%nUvBau^zSaBMMxiQ1~B<29C!c`BC5iQ~M7idx=J9h)0vd2F z&^ZR;2Jkw#qGsfd-oDle@0d@B9~ip#4#<2)LkO>#+*BI?a(}<6N9tUUyekpxQp>Xr zFn#~5EShPDTx-8*k2s%xbr&wbI$%>kB5+8-A6Xa+jwrLq@#d>6l$e}K_g=u|6?&mX zZH~KYw9tRHGHz3b^E*M7)w8-9|nw2HmRa6rQ@ha0xeU=;rn{Ox)+esy1Jn z2O}=0+ER6N)~m!~CySaK57qB#VXz`n)rHicaiRr&b6uCm+BkzrR_r9zf7xOB-j~h# z{Yc+EWygxB*!$#WZnypCB5)l@{=C>7iWXo(9xObm5#9*S*zEP&v6r*Bi z$Jm&RtjEd9Jnzd+wIkr`qy&MMZeKilvw8q#PfQLb+y~mbU3TV%eMTaWx5bkj$yA(Oa1~A*CVy?>4+9trJK-9%Ln+m$^3v#B`E=WMmnO*~#cGxg zEjSt`Zp45Yf*0j)PwsVj4@ZF57|c5aTFLv3*g#umSitLcWu0* zwN%*e1bgUDS7bObVJtfw)owJCscfTZ&1x{CZ~@0RIA}L$ViwHgJa!eRG<)-R-n5$P zEFJ3ON*~1}Q+j%osuR$)rf9ezSy{0agvuxutVUVPy;K}hxatt<{6BeaeUv?#oUPC( ziR(wFDpN_Sue7_#pbh_OZo1}fX6bn3*}iSD=Obm)p~dU?GvY*LB3^NI$00e~o+7i$ zRMSmOb7sMCZ`k`V+JpWWw8)8w1dk#@swc#Ibk zbvHGmfyS;KI7O4#mQQ)bjKR+5;U>MATl(E0L7R=M%3$x%TvYY@w_WH&y*j6vFdqK} z!$g{~q3@g?W2`qN1$$l&DgzzoqTC(j`LW`Sx#Lw<_N&v*uw2F|Dq!upk*d->>vOet z9$ti&nkmAJqgL}2_wM+Ni#+G$#Z1~7=HJpj{#e)R%8oJUnmvI=5|Tzj-Z5VepiMZ} z9i@Iu)IH#+HTUM0&KB-j`{FTxnUydZY#N5C&iq)0m>oIX*$diD^t}zyNd`!LZ zslYoM*=1|ift8>5<*d=gY(+*)@q)CCeDq6jpECF#zJh!_qA77Q7k8iRh26RtN3E9< z#d!z~2u;_P^l++%cAQ6ihoP`Hs*|Mz&m6ZoVYeKa{6b+`Z|zK`bb&D;j0zSK(sN6f!+gUb-u6=M88LA#GAt;PDk04) zm?|F*nWSTd>TvQX91R}vHn*BF6z)2N%e}p2El&2*Ei`Bp$yIW(X{g$|?BeGBaYes$ z_egevMH{+^9wV(x*uG{wIygcV@~L5aFu@$J5SkW~+(_<&n``D&92SrB^s$0v3t@?E z=Y4_77_aM9FH|afR05c4Inb|Kf|dd6TDG<+tG4hcNY!%A4(@9B+RntaJWJvRzk&jd z4+01|;rM!o2^M-!%N2xIIkx_hx^SXfgM(2u;)IbSjA=kTtWzt7fYO<2VJ`{K@ldgm zJ84KO-rTxm8!BFqEdEE|9FdlJrXI&bTaDmh-~zRb!3WD{hHdY+zF(2}SV?0SI807Q zP>yKjd%&*!VJoYN?lYca(~@upyX8I`)Wk~Q@s#16xjO9af@86`E{(Nq-B7a;akK+3 zzUG=xay`X}h70EAIu|+3k_p@PjGVo$Y~AUwRa>p_;$h;uds_8{T~?pA<~Z9`x0}!G zaJ$4!(^_1zW^mf?yff1nRSum3unystU26iS8)3|bfi?7 z(s9AIRlee8zis6rQ^MK3_gysI?en_%aw5}PZz=EkMvnK6#{vM>UBm)41Z~%`fRolz zAT{dw6ya-I6?vqchzXQsV2W2T5;)tV-uH&DKy2p2jl}zK z;}L7O44!fc=F#a$);r8_=A&D<)2+`~rd+ukt3-LRgaptXgg%EgHZnMn&Ft_FnF!>( z`-hO)R7x?@2snBAa*mP>ft<-omI{aVmZoBZT=1XTQp}kPX6~Elygfg3rKrcFHPw$6 zF$LuM%FckZTI)IOU5{GmE!9;rhweFw&`1qf`w#88XiYLt>4?@^>$!21S5!F^eeNvV zV<~KGp-cR+HFm4M{5g_(GG?nBW)D-g8k7SDFGlUA^$txW;pPZ72!V^Xh}5J+V`Fr50JLqn z*UI)&jH5aM^vBt?n>Ta4wVCQil*}04?bsZN{7h=!()CJYnWeRAjVHy=EF@R3?6sUU zZpm2DJrw8d?umdhq3n2yTD9pplY0bkEDqvvvBOnsz$Fd4mObDhe1P7?4jVJp+OPj-D_c_ z6r{2$KubFXdN6tVIeTk+GoO@`p^ItF0weJw1Wm(k$buJEz|F_blqkRGYA*TcHNAC( ziZZ2eU3zxb5lwCF1vRW1YP7!Xx-52YYnSv{Sd({biF+JQ$35Y5dd-GzI))$AQWgxN zFDnG12R;_ZG)$-};j_8n5@!r=?v9>5URUv$9<0 zSS)5+-E%}WWVi%$brDMRK=l0}$biNnvKpe1xzp{8OyF^L%^`#!SJjT>7a=Zm0$&V? z5E<}?t`)OaeD_4uG?Q&<56dq8$sYT9G_5J8e|Yg@KvQi=PBT*{iOb9gB_i@97X zXfN@T?2-)vdqRW}HTh5NS(m$Wrh)-XC2740e6;kTLlHholITo2z?0O`h;KG`vbY+X zS+ZD`WIe^TDOpcrr?0B7ad`n&shl{fecVN6E%w&t-@LiHe`?^AATFxhqV8wEER@ao z_xhKPB1U73e$j2h_(4&a&(oJpO~;)dsrm%eY;v!{`@RIJXgrLdnVhHubSiCbA#T>c zUH@2Qsd@0mQF(r%Bkc}7%pS6WZi#y);K?C$$QU&T-_!+GYPHDD4ilb;(9{KP!H*r6 zwTEasfggpG$yX-IX$Z>LZh?fU5gaq^`|`VyymhG?)p-nL*GRM<{tPSpzP(WJhPkr% zx6iLzrumyuiJil)N(faS5?e}ng!+V3<#OXZzHLoCg`AEd4|7>J4FDh^DG)ruum zf48vR`>5|O`Z~L$Hr(1kzgO~@vWdeA{G@mHO$_VFVkuyiN2{&Tv|zzx_8{CX`-_xe zy_qjFebUPH){!$!34HD7C%A-13y&`IHez*IM^a}yA4jw_&S$G{I(I4BVjv!ZJV`C= zql}@4Z0fi!ZH-phiBPTI_75N83K#bhc&OI(pBD9F)3Z>q5+BRgQ={=;-wF878QSV2HqvlNLUA&(sJfzeV*-Wp-g+nUmTy}?XZ-Jhh!Xqa}TxWyzJ$VEt<8H7z! z&Ypd5WYWB}4Qsl9@wjx2E0;ZyJX8NVtj@c)d=Om(x7s}rXOXT1Wx-3E|2)AJj#)*71rL{C zIMVs(c^fqG{qp`fdAG-F$;3ZTDqMyt0?9a7XA?nJ*uDSggBKw00RiV-T?wg@*3?w` zL8%j}sq80e0xFq9eAB!D4zkHhXBYWT!QB+&`Z*O{MpaIo@maUB@b+xg;Unu-TL|@P zQRFYgVw}U$@%nc5Io0TB?}*Yk)DdENN%cd%m^ zn|4~=U#L8JfI^gZ`GSk6$6C^sSJ+!VZc^04X|)*AD}x`=*7`9^I9fF};{+X=#QF5L z5i)|szlYSpMoYD8Rq7vzlBU-!S zHxy|5aJCTEz`Iup7ay+|GjaEKv0Rg}g|}2|niL&MI^=t*749yI9ay6ZRi;u#QlWh* z%nZ45OW=nFnfwUwe$xhD-yJllGqCq!il<;rbD&?+#AjFw-%!masHT|Qa9>Arrlz1; zDjmjR!p&)ghQi4Z0yhy^=!?#4FB!i3-punHIC6N80EY?}&)V?odqjIV#S}`G=@NU= zNiOn_`jU@sr6Kh^-0jmJAN^3mon3wCDgXv&uXmyc3NbaPqqfD$7C(Glpl&~^P}WZa z74yC~bgNMuGfL4yG2NWiL6b^x^wL40yYB=XOkr;QJZOx@MXJ{CbuZEZMWk40LLPTqKkA z4GjEgY#g)J6@jM;GssS7TzTX`mE<%=tpm>d28F@hHVpcKj*T|^2DC^brS~heCYywo!3Wi$jKAD{9w{FxJwOtADV7)$|l^O>iV8>>hy!T3~sTA@i+rLxlc~= zM-950e3KWOpPe)_*ea;OF>PGPBqR`+(j;Yt>cdfD(>@_Zlhdfhz?5Tw9Nr?%{Upfr z)9K+@F7a<93_K++7*B6muH_>xwt!y5&Xs&sGU{K4$?7weh_oC&e-_LiN!dxyV0EGM zbP-Kxs_%lKKzZ@`V0KnSdA_LJol-uU!rj`aq^2~dJGsNNdQrL8#R6++tL~Ute3@05 zhn+&qWqjGw zc)yS;w>G@oEcLLs{qb#rHd#E>r96RWp{D(5vdV=249>B%=d|~6Jlbv*R_c{}<;MHn z!QjzCk7(ScHAp-%d02Tq+N?r9q@dql4a41c9Aw+_i{o;fWY6C{Cm?JqV7b3fyB|+~ z5Q4Q+9%)^_HI{avrQ)%Rzwb@bNmX0c(OaKPZ!nmvU$MP`6vo(SOdPdn-uMO&eK1qC z9N_tXIC~4AIJ$OGHwo^+13?B05ZoCg!Civ8ySqam1HmDKyStOY2@-s8cZb2<9WLL$ z_rCi-`<`3p)~%ZE>FL$0d%9+=x2AeM@3VZ|HxD~{?wX<;r#XErv5ja~rF3cQ842CB zipot9DjI6#@|dO*7wWkA?KecZ<+VyQC_|Xkv$8Q<=W5-5b;DjQ+Qsn0(ss{n@&f3M ztW$?CidoLFKOu_YcxQ~%^ABw<515N(hPBOOoPi^vjZR-b)0eqebXkR}tg?EzP1oXM zq=cDRYc7+lHb?ldF!`{Rn=tF>TR?~EKdBc5>-2y0WOlA=sN?&_chYiKUHE&0C{&N%tY>5i@S`!_ZLTJY>OcuEfwb zxPjSqUitw)BfC2$s`BOKh?I6-W{HrrVU|8GAz@MqkGNHVnlQfo4IEA<$6^6EpG zY?QcykDpDF!HIi*zv)t|vw@K`S&MwUq_M>`%}k;9WLUI|S#iY_f(>N}x@|`%rYdHA zXe?UM!UjdI1y9!}`c8e?Yl5u)hEi;Z%7wf?7+~|2yakIfHJurXXmvUv79m~$2E%WB=O)f{ry8hMX z>Y}qh(PZ2b(d#<%RrqQk=@LHX%|Hg0j8QcBGIOq4`xKpAZmsE!dy5X3?JAK=gt;V2}gZI``DP&cN^ER~~2W8BZ^Gd z4+;m&)jHOHoO~Y;9j;>iR5%OKM1CFjsxy-J;%cBj{Xg}F1$oL!z+T=`U9!({Tv}Xr4(G?&v zRQzze;WsRxyjM7c%^$xxgEX0ZvN;vLw!cL~$MT8FCMdr<($bdnan7*I9Zz^$)q`FY zRwWi+v>hHJx~lVO)CmIo{bJ_y=6Te_wt*8Supk;{qR%erqAcN<2j{eCb<6a*nv8_#Fn^1LuzqMGTDHj zqK@2g_uZOL@hD(SzC?*YWk^Zf+g**dh&oWMQ_W0)HMT>)QVJ`aPa>x}keN1i#A#*; zHR~<+SX0w<{B+-f3xii+W)=FDx{^44)WVPM;X{Urvd}CTdBFW$ud4D+pe>5$-(LGB z#rGH5Uja?D{kE9AsFNKseL zr{40OiEQK;d|p2h!{fU(@v@f3MShCu_yM%a{>qe7n4`u(P+<_W+UPzVdmRPVlzYaK zS}F+m-yp{SWo-Ii3FH4S?7ifFvG@N$^8PoJjLP<^k@=s%{lC0yuMGbG3vmC+BD4I< zI`fZliTxF>=Xf&Zf8geS_HlB(*5hJD{g3Te!2T7ge>E`u>pEPo;wP@xb929*kK@&X_|L-m zD#zmf$IkRx#>x8%^uLnR|14bG|G@mOP(CluEA;&8MSGR#alM+MxLy+sI9^3syujD8 z*SfFQ`j79*0R-^AUYncq73}}V0QFjz`=8_h&R3}apJQK*Q2&d0>;IP5{qt-5C)m&R zYX12@GR}JO|7L#@H`LBQ{133-a~$c_{&bm*{OyO!ZR&)sI}F~Skhjak z%EH>LZXUidv;Jk}_QdKg+blO*AYUn6WHeOYbP(+BCwpBkIO|exbb98lHF?K+9mg;@ z)HIA0tUI%{eVo}`BAs=4xHwT@_CfLZc=lpElceh6kw0UykuOUv;XrxR)nNb5#!tcC zMDzrU^vbApnPcCeZ*(!8gu%G`+D-ass$fvJ!K$QBWkBYn?0l zd$AO6rLXTZ!$mss%1NFv0Cdx&5h-^1U4xE54DhLk)XBlA>{bZAv|@t_I~hnfBL+Ce z|42Eu#8Cgbg~v}hmd@~r^1Yp!AhzX9D%?4UE-xS*urK}=D13+)gNv*!#+*9tiPW5dhqNP<60AI~Gsb(a)C0G;iD7iuAdlyJ-#WEDeRK?aN zR&2%Aukeqsnk2z*Y*jZ??2jD^3zTN2w3?Qmwb6U6i4Z`PH#)5iLJEfY!@>)OSp|Ow zF?#of(BKhHdXgSaZ+^8uIAXnL{(19A`k{{*xo}*G@DK#pZ#?BmR&z%918^S22S9K^ zSM1aNCsS@y7MoA04YOwJ!HW$&%VISzyjoBH2}}Rxulm=X|GL}%@>g-N^Zb+1@SpvUjrX6B@PF)q)2%3; zx^?s1+CU+oNsis z1!FjWb)wqQzqJ?_J3W zZ50K{f1+=Sv3qw*(iWw}Z~w-UWZ z^#^Y~74>Vqrz4ZHa*h{qUp@lA$5y}gTv$(9@T}i`|J>Ur1J?xPeOffhFGn7|`ZV2+ zJ4IQ(&PC5GhiRHCQ+-3&t?YkfpPL@3OFjwTmEg50lx}HAH$0-Anyopg+~S;y2N}G1 zM!Xd`1+H!W?F;zzj+|myjOHaeUX(yIUb-GJ=MR8IXbPqqPmN7=F56A>62vJoBjhe( zA5 zfD=HMC=e0w7KjlyUjs}goQMh$1KSG|piR(76#+;=j5ww_udN`31u7uCfMA82uLf=c z)gn(YO2q-9K%B_zlHhqzH$n+vz5-YaG=!J04kiLkAuBUUB>)mYs>sUBQYnA}P&_ib z9@tno9G)I8UkIEGn1t^qq*es$3g?1g$gxaPVqiw$PEZg$3TiC9R4`x<1P_0Pwt?Ht z5Go1g6kY-~!aJdEyzgcXm49CbAP^n`CBw6!8ow7~2~~Js0U#Eh0u{q6!N(xPz*Epu z$|JKgLz4knDCZ@BEadaw0CJS`9KZ_!%mDPL0`^Bf_YnT_9_As_!w7`iXrRNOC2A-S zLX#5sBm7-3zW??8tHFacqA6o?9#6l6K$4R;x~VQ>3v3o?e%dX?v8UKR1Gv7+kh^0OdVd^ZE0?&4;zm5?5!yD zqwCc%U5JL`W)1HUjNS$~v^H?cD43%YWnR-w#1V=H-;Ge zN$bMmUFunXAZhDc|3h*Nb3|e}z1TOVf`K5JLkl3%EGG(rtlQoBR@c@^gRm*>6 z?+`<(E^KC98l$^rd36WZi8Ifw$%wZd@k1DZx*hB1`95#l+8OusF&g8$I`Vx;MUosF zdH0Sbc7-OQ`X!p__A23Zp+;Xv+kWjV4jL&=v?59~ug#C{RHt=$k+?g}^&26vc=M08 zMRm>O`@Ao(UH@sfP0#aB+hq=M;kAX`aXV^`p4gI(wk38EXFC6TyVYp^wK|WAIp|f8 zbe8LLM|kC^IpE-d@{((>KVXchN5ThmrPgy&wN;uBpKfN|%Y}0no^X55`gQL!{LrTK z0v0Ij;aI~I@txZ_gVugiPT56#*=aG z*5Gg;-r3>L$B(GI-JV91ys(STb6%Kps54Z0p(GIk6!T2cY8hf>VeFPgafZU~*m?6^ zkR4B5PHF7?=qA%@E8sn2>(v4{G3_y#F%>W|Gdo5&<~;Kg0)Gak1cnuHp2s7SmF#41 zW^ZM$(@zT&giC%VF~!6|!pW+x#8f6~z(njTw*h7S@JGFaKWE$cBC-?$_7{CdxTD>8 zd3(oS=@)SN0B#q4Mg>OQwhOIv)p=k)bG-7;i{P(XGe|F%^Y0(wVC@ty2wrGT4)6T2 zyx`9HI;-CLBYEMUqrw`tT>@FsWI-%%4LGq73|J)t+kXgPJ*NW+dqRW|0&rPZX6_6ak7t8@RNmcf2q*XkMXRhoszM zV4plc2rJDUksK5$5>4?e3{}$Q2ib&RCj~_c;ee4M3E@w8j!~ZH8d*HEocvG0XPs-U zU~=K_$W2JjJTRo*&NaQiC!%d30;>osRsuYpNVgt;9YU56pY7t^7zUaV%>2-tctq_% zzPQd*FhnR1_~d}@#JdZ$<`(?3ql#z-sfz0n;2E`^xn?G#aH?Fu=lQJ^Q-8uQ`(Z;A zshMSeWz}yz=V`h3Db~r~(Es7N^#SYXW%;>L)MRe9waDirM{t?Y_2l@=%h>U8$kt## z-yP(3==cKjXkY!v`Dmd@_HKuHZ;ZLbDT&iBi8@ZNUN1*4+{)tS`j|AN-XrcPqMm#% zbFQ*f-qzpck6gWM@OT(*NCOgk+K)58#o_vGyJel`2C{{TRj%P$&{^*pZ{Ym@g6>BexRlvaQ4Tm=2L`w}A zP9Y0LT0w6i{}v-e=}4K)TmGDFFw$_JAN=!+Rm2J9s@s>I{iiyOXrBwT)QU_4pYJDk zX_8x!KIajs(y2^L@r8|6%M;ryg>L-m>Z{P-`Jid8WP&hmo#ohRQrAIwe;3&#Tya!s zoEY0T;voW()E?DZUU*8pj8w6%f?6at=-9WYk zsbVkdRO^2)$O)jRpCo^VXQDX7_AH>JuC0 z-QU!xly;n*OXbj?wi+U11D6nXF%KvrJvER?xm|&y6JT8)x&I91`Z}TM=Sx zAZeWbF`@0eB!6QhQssMvr5Nm5=Drq!-xcw)&-g;98}rQ4*!Oa(LqhR^Qm}>=ChL^w z_1+l;W(<7`6$hhHJWxCUd?^)q1M;%U+_cGV*o+rG4E-kM0){Q!e4&+ zzPtNyjtvuqzD6U^BknmCbd`c!XeHzk<6Hx31vLPi2(SEnBs#~0*+H`a{y~p#&sV`O zpcVu#+;bo3NAN5~mGJlf3|rtN3Kn7gpq4jx7%(rW3)q69Jy-w^h;WAwO9C4RWd=Wz zoa4cyp`!p=imyK(;m_e=@UMSSOu&*9zl5Si$$|yoiGGp<3Lpbff$xCm(jpQ76e!$l za^KhBB_tqx6X7`(6pP|U=s5WCjWZ$a0em9dhSr4Zj0EEcFH$rJw_!BlJEOsLz-bgb z!fhx`*v@dUkKiiN$`D=wdcSmZ$g$HRBxuU^vhoFdR4n zKqzu8dM$h{axKIhkd8Hv0mOo!L2w~(5K;&R1RsI`A%dW=!vhJOF-@sV;Yh}qxlg_MKJgD!>Dg%U**g}o^R!3AI%uszgRiZCA+f(&^NdBcu1foT<3E3z%3 z4HyQ0lA_B0QGSQTGx@UDF#C}8J@94yMzUCkdoOuB?W$5cOfs`}mBREfxCBcmMjS>0 z2_*U3KGrfQ~f#8EjRb+`M#;KJ$jYZ=p*?wZ|ILLuEEi~T7M}M+$_U^>Gv06 zG#G;#0Xp+Me%VhWw{V*`>1sd3^8*>F2K!MbLW;%^zrApo!p$QOr^^OIKS5G{a&Inp zpSmGeh>bTt5UG!4GUcC_c8|F@bzr!SRt?o(?CtymwSVN#(iOS}x0;gAXWcIi z8(*&vkP-NNsnnHX78%r)V>Xfl`~pfb(nldSE+eo9C8eN)0VEA=F+qtD`5OE%uAxw&9u;_z~5=mVHox~ zHBjc577L7&!iq(EDrq7FB zQ2B^dOr|trU6p@K`MStB=u@TSFz;6t#ZoHmkb{xZBIsFr&jhiG;4-2g%J8?0<)B8L z_V@f;J*wYvn@Fin|J>$l7aaPmr7w5fPTii!6}HCdJ$z}3czk2$gq8DppG_Z~ZouTm zwyUz3F%PFF=vf1|(+~Z>v<7LQ$kMT0Fl6m>Vduz5$nDGC0$ep|)~E}wnz}P2J_OnY zSZLggv&GXaCZQeC5Pm{|=Uf41&IlW6i zpA{Pk^kGa!63R7~GUvNpRsditevW8_#)SDZFa&s+RF(2X`a5hmoSD6{x-Na!b~+8V zE1a&!z>hrT1`Y1R`)Uji>Wl_6i<7O5Wi=+_od_2@uY;H)c2@S*w#gj)`UX5U=0}mK z`=tZn8@ZjJ7E1+pYKC36c{}x*@$6YEF6)GMFD=>h6HDYWVh^~bmZrx`BE-??0AoWL zF@MUS;_aGAY7x%WH_RCc?9uTDUy|5IRC;MuWa`J{*lVf*Q+Oye3S1H*c@vOmvQwLn zRINGPR=qnMmEn*8q92YQfFklM7*RPvQ{>h%oLLP0mNY%qQzn06b& zbAf2iDRm_CTlm7TfmK$$p>nR~_jM>VMOKFL#!8ZkDkcDuV>74x9|;L#oYb}DO2&_|A_y#Ge?=T?vK6X3%fLMoK-PKRAx&hS!_pcl`7*cDGcHS@OHGWV=A>f zCa(-m=Q%-$e{}zdCL_a)nf^f?M%d?#>-@FVSwz>#W0C=>JE8yZ3EQ%seqt)?UeFN-E~^Lb%q$ht?M);8FXn7UrhAAg6PML1h%e_ed&DI6d;v2<8b+xsSms049cs z@r(ELX`U|m0(iW-5(CmKt-r*y;fQG#IG1Y7^(g1aH3OfUn5S@&X*XKG893xy*s<6Z zgfhjvd}_n|YAKY6=Jud#9rIyY!P3PwhYXl~IWZ$5R!l@51LSb(NE|x_*o^}@L<-+(G1z1bRpYb|hRf)9@Xx<;WpLt{D>CqAxz8H{79 zR7?xup7kR)g^%gM;X`a&AGuN;zpII)pf>2Z+k?WctGngtvB8)CH* zB3UIZ5RM8fv8Qn0#8e)B2$R)tXFBkLN=WSv^ax55`3yg~cuPW@Dt2<-Q#cVYOllHK z#|2piBu<3|L>FKQ;L*a~{3$iYW)$H4j7`voOQAp+n8*IB=C>=A(zUo#3qKog>4wHe zE>&AVxZx#OB^rj{6Cxm`6?q0Hb2cXiWbyL$A)@+u)4wl z+Qtqk8^W9AB8K+HT!wxj^9)Vs&Ld021kgnB2TZ8+n~KEA(<2-7Gpt}pO=tUPjT+$! z-yP!8Z;z2Dzdu2|WRv5R&*7?lIXYNoU0Ri`K#~?U=&6baQ@T-8NbWoK5vz2**W#x& ziX6&0yW(ui?6a|K;by0$D3G>1RQj;I{)~*y)~kvY&F?+_WasKR2+SD|3+oYFSNSp7 zY7}{g4>l7-@k7VW;48w|(=NWGYNl~AbPQNQ+6!jND=c!WCJfZW3#G0=5tJD#k`W3w zPYj9XF(no=5DhWC!vcVL$I^DAUK5_?rB3MZAT-b=Xk^f*fk9QtJwp5&On%A&R~V&L zC)fo6LGU=r_3AYF4d|AAh^|&b8~50k6(k$@L}5wlmyc$WqDX+afQ4N{z-@r9H`x7N zN{_l$TPAwkR%$om8{j)V4?&L5qqR>Cp0*c3GiAb?RXf=aPLkvFrE+Eg?v5o1D`?-V z{ti#(D~=iSNl073eCNJ=2;TadX*>6EWx*S zQAa8);Wh=N@}8+^zR#&4Kk}zOeUJEgkM!AB%-E~ETIl9ZlOuwRY$l~$0B$yEL?Emd zPt_ExU?a4!uIZ1)HIBkP!A;2`gqq#$*vJHumLJJ^Cn?!+iV`w&IicFPB|elW-u4+g zJXubx$V&aTx+2k=hBN4ZG3d?r5Zr@NO#5VX?oDTo^p12&?iKhnN7nP!UM{_WL7qXFU9e z4~2T^mm9KhC`_LU-QaAfjO2Jj56ryHjshKax`N?@L#Vn?%#l-LKJ-Yk9ct6BdDt+r zS0^@)-L{SW)lO_6Y8b2)Jz*Kc>(JDX_*395*?M|Ss3rduF@%b)qUtN6{9FiWS5B%? z^4ganveMnP*jG80s|4!rLNa6kd~5y0Hx|?llq(=71^K&6d+r{I`&yud@vf$vZP-~i zpZe$H@*3LTQl`e6VTB6>vd~Ox-R_J}`3jocyIBkLbcz|1s8_w?SMNAI=qOCQw}!jU z8z#zGF(xZWq6iJ4KrFJ6gV>ES3bQQedf_Xq5=z`kse zLVxx9S>tLkm%YylaU^e2ykOrb6yA;zRwLN((QGEzQtU1rp}Z*#mQLi38xrAF@ro(` zmJp{CKW$1>ZEzQV*}o_i?HsE*=1D@K`>B=xEce{6*I~SzqG8NajZ0S1tNjrTh82f- z_Z>&#R$|LNwt$QVf51MrYDpO4sLC!s^2vpw&nerv=HA&EH%di7tTRV5?tH$x-RZqM zktx=GGg)v5sX3hd+z#Ix^f>JnBp}Aw+gN#lZdr)b7kX+Sbp|Yk?ko<_55QIyH2nkhkAEpUn0`|7Z&)YDoA+#>U%brs zitaJg2H2od9^z1#1J))b zDU4`hJny(yLNDikS2hEbJ4NZ%Xc4fO=uFWWb>lF@3Gm1>6-dCKcC-bZ!3J*DJ6 zCWk2-zj+k+t-}>%d#c*6dUfitGJntFCAD64>d<(Wc5LyGe-xPshyKn%6?ZuT8&?(G zZQkeHHwd+49iKLyNuQEC#&ah(lV`>DF`#g@5gT%AAmq6_?mJB zi2ET>#>y5*sRBL2a6EoKjLnT5Lw4XIi%Eqb+6sn7btOA6mGZr8uv}?yPhWC%PVI;XH)qwX5rLpxZs$i+0jiQ{nL_i71K)}x-?U9B+JX&lXqZhd)ah3WHJ}f4sCzE^)6AC*bY4;WPZY6&XCv5g@~MPG@-e%+-4BwHp=_w29krET4_2ztQQuSNi^BYR zFY-yeoBq-bk4B5RJX^7+wrCMy2WrWvq=fdH$C8H%klne7g(Xvdl9VXQ(^-~(wcU|& zarN~0`ME1bkxuEG^Xpl&Fr+Z|+}~ack~t%Hb13E0?_`Op45n*GYv6He$)OiypE*xV zaF+KtCsZ3NQEH7_nk96n_2)&=8BH^1m=2;Kx}9mM2qn?Z3IowVzs5`JZc7$~8)uesHQySdP<&k65?3+p>6bthB02@6M)t zsF{X|mM%7a-K~?p2;^pXV%_Yr>6AoH?W~y*ktK6W*Uq+GtRmCDFnjtMa?muaVv8F=V$6jfZ%vz{q&BJP4D0+oWeF-N&b<7e@MV z^ItNapDOcwRoSC03FGc3uWY-gq1?gcMV*ms|d9ZGkXGQmhpQ(yGJ^M8KrF6(plC(AA_n_J0O0 zYWJPoz;=A{cSk-V$xa&A6seV44tylP&|tBV&9vPuzhr`10UI_`6s>)Tb0?y;4)_lW zn*y6kWt{^NB5sCQw3n2RSXEu^6AL!H@b@u;W zj;}6vg2*j#;^!g(bCbKgTF=_m;Lgb|U4u0S@mBKiL3QJ~3tYs>{o3`(_v^o?9+ujF zH!k^g_Z0l>o$M#K6b~04cExM*dX%CBH$3bff?L z7ux32Fbi#XKAj|YJ;$uQd^lNxob49aWz8R83jD|fr7}ExyLjjPwc;l9E6=oIKzSCc zSVcg&`XQeynE&(Qrgtj`3_ZvBSxK6Zhdfk%iJo}+_S>)gCMrVK+!PWYzs35z zO*{@2%gt%#f>zoAR94KKz5;rvUE%yM^b~&1+5p&lnfG0oX+tHLuJzoSSg4CVA0iz~ z4^@bUnty*RHio(J)hJZ-_BBe#>>JLidY>Xd@;N@LGDQc7_9f)I!0Sc_=<$4yUP(N5 zy|r67!^sd7lAQ6w&7zCQsnT@@@5vs>?V&+0d%)L;@ojT%3l`Z`dE4l*DLLX%nEV-E zhKu7pc+0vZX+x&u^nE8X*+t|S6jCpD-%ps2cS{CqTFbqS+9NR&m2;;fmA8*x>2ubd%puh5Rdnto~$9vUdVIS*?u z9nlDp67rZt0j8fC3lv9&xw2>iiY=WAKu7@uB-w1Z8yZ%&WLfb(pHrw|#Lhi@U`L=gx zetxuGzeG5XRJ3X%kwPpf_W8!TME8liisSuFiwnz=6XQull*)B7BF7=gSeFR=s#<16 z*BJ}+GYyAR8!DrrI?M_Cz6m4wTxwMUjfYDC^B#WvX{+Qaut!8WQ4LR=TijO07{j!_)*qG>zMBf9I+j0gdSjc)r z@;{A7GFFwGwB0zgT*Y+k0`>b#ekS;JJG%TK@Bo84uj zUo3|ccS=641aS&irG_O==h(-PND{-R9(@u1URP_u2zs=x9^)E5x4PZ(k@q)frZNRbiCYr;uAcA5TNBtYFDo0pJZ z%eh5W!NBmIUTQMhA|iZWS4&@8X^)UNjrQ;+Bwf44q(#=dw^F_cQQU+Bsu8Kj3N-&T z&3YZATg79gX1&{UcoQifxxDXDXlu{!y1B!2``*b#ZB5#^5Hscyp?^VlR!pN0E_`kDUiy-C5Io?yzVBzbpMBwHLY7j`kyfO5=3 zzSK#@G!BkG-KOl{4veyAx`Zl1erRLC9g!n0h^{~N_#uN22Qc$yO_;9}@vJ~zq#gF_ z3bXucQb{?4$mE#ctCN)v&8}0mdd$qG+K;=OcV!2&^{CZCzu}S2T!)G+?@$6Y!sYf@ zUGd}Tee&5COz7NfjQKRic2M};&OK9%T`d}yQke4uRwz6E-nZ<2LimA^vp28bTC2mP zXMc&5*Csy`FzIUEUH)<@Q6XGbyjEve;u7(#dH>jI{*%A{T1~;ga>}HyL@P(v@ZuXA zBK{Qd<3c+}-dSt60tsx<;#i7W6yGdwH%4@>=Hvwq3~})S)uRIae5NZ(qY{h~nUV!r zE1Zx0<;R?OS}tl|_-4n#()L12fn0i7jjIP#lIqH%q%uBk~KH+Qo8G z!iyMXo_17URP`*~ABNSQm!!G{+bB5s^%Bi8ICifPNt@sKTS(Zmb}zB5ksqbyeyc6({{lIE_7}NiZ8yE$Z}!A$utP{DUTk(Yh&p>&hQPu~d@l7)1IiQ{|1~m@m;v=p#q8)jhu?=a%bPr{Z85T8E1e z_GkyDRmGPkzwq=JsJBkKcYWmfzS&duanas)v-d#1v3}3;_}sy6`MyH!ZrqH=Vb%R$ zK;W)$@#{yey31q#Rj)x>ta9!1K>tU}i#!b$P2b_Ot3^d!LH{$i+d!?;;Pp*`pT9Gs z1ylKpB_tqRC8h7Q)QCj5gt%Mg-Bi^?`D6Mrh4GVLUq&1$1ztq1YDqtu1f>swuAgTt z<%%=Us{eFx_B^fY$)OvUVqnPoxgz&3b3VmTB)-)}E)$^;a;zKuO9k?{L4O-$C*il15K!%A!X7 zxxB;PuE<1PoI8P{CFQP~3YFTw?~MiNHRzSAW$>TE`J=2d#Z3H>_-E49Rs|+(PBO*?{3^?Pcsiw73OX# zGjlUxD0AA^hLq-)HjYydi|S;CexxgdXv|NVE7N{=7s^;o2+qkMez2^ZbZ@4>i@2Is zSTsb{&*sNzQJO!Og5PB={!E=L#5(oYG~H7 z1N#IHI&)6ru_9$GyPONH3P>}XdohubdoIqO35OV&(x&U8yc^Z$vXaM3m&<5|Ezcac#)i0({GJ*VIALvdS+?^l=3p+Ik|ftZr%+KGLJe78Yfs zeL8t59_kTScD`1{5y?202EjTP4m0ld?7hFcl`go1+~;aVDjH*TWp#cUuLjz3s!oO0 z%U&-m(qt8nj=(<&p<`1P{s!(q1yyfmtx``hk|QFmx#8tEQD$+2O}&tkv*E$SN4&i6 z^jK-u<|Th=@jYqCUArRTs9cH9!#~JuU=nX#+_#LU8y0CCt=UjW%C|04oW&4{_5u9- zlno5Xxvk*(KE>tu07zBAUAp3G%^3iu))`ppHG7jyLf7F;yO5xTSoN0NMz@~%cc1ut$K1BlocZ90C5wXjSa&fj5V6Yp zfA`zO>6s1eUqnW;wtEkJW++Q{&C9$>QEvmd9Q3vusp`0Nr2wrYu8a&y46fsEqv<3p z62J1V7IMpwM=N3y?z!EmY5U;2yYyC-%xUS=RLJm+8g@)fZYT!sK;B)Lx1OVw_in;g zZDB#>E+Cii9Xg5Dq9yo`Dhd_yKrYTLZa#YBhKDZR`X=WJF?MY0Ur=;w6ENN_W`+$B zC7d|-h|%*NDr z-&HIAE35j7LtMFs}6Z-IxKvuOD-_%znR{40hyBDHM5q#Bzd( zUzcLu$}Ki{MNq`OyQe_G#5W@;SsFq1%P>c&q(&Qo%LZ51l=tGN8ZK$Xy8z;0>w+pNk~+{%jE1vYy_9j#Nr%z@FO1CzW%x4`LB zDL%wol>J1w)qKBH%v-8&7dnpsL&=5RN_i@q5y*HR|u7$*%onfG(AVWI89UiI;uHT!i^Qg>I= zLQpgt^AUaL=db1VOG8CQeuCE_x-plBoax0=M0va&`CqIDIOSCdkw1v7RjiAVR76`3 zh!;NESniYqqh}dW=(qV;3I&O0e+-2fg~~CKl|)z}ar1T!_ogld41j)DDR?g$W~+uU zU7Ug8`B)Cxs{byTVe{ixldzH?#*E9lkP)5NYgy{2{~jBf8aG+?aBc^Ad#c!pS*2P` zw0DemPr;Rb-r}whToxbA(6QJ0;yFCgGBIsnP3CI;c2<2 zOQoXg-10@z&{tlF_s*HDPAai!-dx!S8xaG&R+bgde(lTUU>wT^tc6yDdj8-Yq7}1+ z40T;CgQfyyr-|`nbm1}ui^hOTJ=9|NJEPAv8@n9jb0@ zZDgBzX$yLdik1P4Y8@(~JHOd;d#XA>nk^@o*bx~12138{4^~Mw8n`Ul58U!nk*h7Qx=a& z1a{J%etIwv9%k0%GNb*GZd$*-NWyD+vajgbVdby*ls9@%zR1yRu_H>z!*zV?{_7(4 zW5jkvMJ@pql7qcoXyZ7$J9?uuCgX?X~&F zu3!X{=yg}Kh_Bw>_e)~}i@MEq?#;Diy#RMeB$I?f@4&8>^^(37uV7I8WL{B-vQ^0> zK10PzC-%>@Va>7Wcr}4SAlskcf?Nr{KwsIYnT!;2C_R=|<_yu5b;y+!DI-%oy&K`Y zt!sgYlId|_Jv7}G*H@uz(nRSX%G*J!FLGM@&uR+k{h{D~=7fqy59xsW{n0{Of(Bzh zkB+=TdL(_m@gw5a=dGQ5OvT3X*a=NVH-1!|-C~FF9GChaTLmk9SuMd9^?k`V^PWg; zcYs#aDm`Rk9v#w&mY;7E+?tgOrzciWH{WDrhNcOl4%Yq%s4xE}zDS`T9WCp%x})QSn}b!$wpwk95ci0)b&2N|LEA;B9!2Z%H73#rZ(>p2GMD|oUJPK zbq3|4gsY{uzXgFn(cFS+tO0l3+$Q1=dz^~a?cyY#)jFg*aJetzxD8Tib!B*rK4swC ziwSe`%!1^Jzl7*-)#{T-vmEhPXIrzboeov{RvFn?DBU%AI4rsj?!VJ%q*hhdO~oBz zHgGy?c}&bUty%2ro4uBIpuaBH(|?^hZ?dj*b2P`d>UrW~VRi-~J|o8PdSU}%#{=Iq z9~jO~B@PkB9Nn*|SX|JH#XVudnpI1>^SwYdzmjyh-yT}6Y5Z1&_RGK8*sr*mtI9*K z+WL5IfanS`qLG}nler9LYmJW1*IDyfMR_TVKY@^yup|{`07>LAa_EZ+hZdcbcY5Qj z^5a5d6lf)^*CU4-iT1eQ!ZvX_n1R==oPDT^kTk!GxqKl%;zrJrJf`D`YNGX1P6G;g zbO&>GAgTV;HLE1s7Un{VL-BZ~)>8zNHNU|@Qv$ym=5e`agm%&Fk&PJG?h%c=aO-}? z%xCAPpD_$NbI0(p#;3Wjl7LNxH0gRq>!6Z2o4-0q-j~v?IKruy@YBs$jBEK92rGmp zH(zP;9oL)D@{`~3lF1mj*>gySpXiQwGZE$b-r`Pf6Jo_HTlbZWOJWg&E}KXm!%CZ} zzUVMauFDpglt^=N6|qNrdF6MaG0#-LEyu+nogcmtFYcEnr^xdo%Frx*Xt7U6sN*nJ z{ZyByE2D_LXI0AS*IWBYj2uI&Ptq=|4X0;nGW+zlG@=Vlb`Mu`=;_^a#sUr?t3_y~ z2n%j&tlfc_qeH6NRp@v2W<4>suNl%uQl4Ai{MyhNvIkqYkPA=+vnMi@wK;t@oR5~4 z3q-R)Tk z$ep&~!d7hLoup*soSv@Lv^(NFNNtTU;R~EUW}WQAnX2q;su;*&DP`hXxi)G^i0c|6 zNZV&9c*H58J_c`hmH8&hYXOE%5ZYv~pq<|g`kjD;4-SQ@FMm^$+yDR-DzMe4SV;EQ zifZt;t+SluL^IW$xtwU-Cp3 z{rJkm;jpXJIKJ=g{7I?R+Ν!!uaHqti#8$ek8t`%!y5^=e|ZZ`gn&G)wSTU5!@N z->|W?min`hK9|Gec!aq9Y$cw(H4_}#6P>w!ewC5 z$>KQ^D*HZ#KE6)fa+vWP5`hgh_gc3h5&3d6BX5xe4J=0K#pe~iF)t!6EYNc){;oX4 z#5NDXK_3qg;?_={9v+el%;_Iu+@h_Sx;@|2GWW&!z|%)CE(jHO)5QI)&t_)V9WI_s zL=_Cp^da%rD)_&cyUXAjJ~L(U$=Tj-PfJ4R2^k*+ea*l%06XNW=UUeLkDCxub+9H z%fjsRl0NZ*L~1HzBP~HN^+lroJ}Wcv7@Kq7xLnRMHoZI$dM?EKTBj_9`DTiB&mfeK zNU~m{&D-hWT$Z&DwOQhb&Vn(2YL*L$M$x@e|0^grEhGM3cUSBo-*~D1rqZ(F+!|;@ zb82QgqT``sX;%xoFE(*#@{3_m4|6%hrkMT2#g*X}b83>t9C*-=#wa^p_z@1oG^(*a zs+qy&ZDH`{HCA|_xS?crtb~-E4xK8}%C~z%b64=_G-jgVv~E~Jl{AqW)Z1v@d8#s_ zwe$c`3@sGTSS!$={N7unPExo$!c#9DbL?vwT{r(ek9wA$Yn%DrB~@=qg(`7c^f8)3 za)Z>!H|>&T<}F-2lypa=+LU>S%_FBOjnCCE$6ozqbl4(?7ISAw$eh_-H|2Q@L0z{* zh*gM73TjwM@ZSr*It;VxbQ+g9uoZUPnO2q1ShX9ZDrz)3!v9e^6g~lA!Kldp3RLUm zw8!D4NTPT!D5OVL5ap>|azep@7{y_Bd3Ae9BCx6~U$);w)SG|vYjwnEw6XdEeKMua z@c?K+Cv+nk;NG`9W(sdqrZIpzv7**8)G`NmEMvjJ0dcUedUh{W+YV-h16-E9*SkZ0Yi- zJHes3!8RSL8=&?7bLaq#yYlLO!wsj31ez#iYE+*Gt~M9tR5pz=ygjvxA~r77j*{#; z8$?UonMRoNNLbJ5ey^b4ByWFMk8L{eiy8;`&3SfH zMcP%#>ZWAzW}lndi6+UWIK;~*?P@rtYeJ-MhsZn)6Y_ODXfzd-*hhxYBVQEx0n=6K zcCG-iwf@Q4QPZ(RLK3>Gle(&<#2DMVaWm0o(MMm^_%&p@+=;r2+yI@M<{r56Dh-(5 zec#cf@zO-rq*)6aeGnKje&snHUVx*rke)CRD5NF4=uD8?T$RYcA4(A9;HnQLU^bA^ zBCrhCSkF;mUr#bn#B%h06fil#39ShT%3-F;VM=p4nJx(LU{H6vj4Fw}h-LN2n2e7- zyO*v?K}ns(S+0*~_7ss0;sj>sD^SJNa?yb*7k@if=DI5z!fsyxYl5L^a2zYbCiSK@ zA*RKL`puuPj`EdjYjjMhZK`Z_mwe=3AkR*yhEA;pP4%U|b)yE?e9_le6AMZS`}ohc z>O)a4&v01V1ONXC#yEg76{VI-S+#NdQ=ARGL&w-{s&jb5 zcGE)jG4}c5sKr%th1=@|du2EHxFpZ1U5;_TCS+%>k#I9|w1nCN5Bm550i|sMzjk+t z+8OwV+a+nEP{vdA)G|-aCq~A#u&{pe{Yt&{Rcd)u5<^ONg@tz_JJ)o-=9z3Bge?i# zawWWuceVC9*^#mAXu8+d0M{<f$=!NG1tFevThH97W{XK8FT? zi{>*?Xk=oJht1QasxwY&=s7f7lUt@uoY$Fyyv!$uZ*SMa+T|ANQ^U=XkYrz_H}anu zH?ms88V_Q<45HBr#~}sl;bI!dV^U#*%z^+bGt&5u+sDIeUvA8&*1on<&(@;)gNly& zbqCqCBxN&<(w8WoZ;@v`cJObGiKevZCVsk-KQjIpx8)`y_xbaw;_Zf8xz_W<2Sbx# z=8euheiCDp;hLo?)KtsNd77g6A)M@f^%i+h-@C1JAU@-Kw&c!Y{yKs-UAStbr;f5V z&{nyF6#vm9)Yc>t=UL?#!J}aS9&cUjp(;_7+`EL3htiP#tg5BH>tMESU(3YAvBWo! zVwT@0hM)^tksN%O1?DxRqKqP0nb8)H9?ubHretjL@q_WGR0Z7(9Q{zjoH6H^4(OrCHtS{QO(piS5!w@rB0pa(S zsiy27_c+F6NF9DEkdk2{Ym^4RtESNQ+hG*mPU2E%TtvJZD2vI4`;($Q+92+3K}GX1 zC$2XCl$J`0YGZB~QIZG)C$3gdp;DQPfj02Cv25c!69=&;j__7S3kigV*fTzjtbGo# z8J#XC!coO)b=!p9vTS17qLv@0MsU+&aQoWDAd&?s)=?%bJ7nmWM@qXqcN!k?m^;Fh z@}nxc$12(7N32#g4&D7VVf1urY<&D?+w2u9F^zBaXe4CI zxxzm2x+DTM<|hTHQu$o&7=irEls^{vpL>(OG1L z9vwBSm_fLWMVzc%TSL#%^am^lQ(wIKyaM_FkeCWPDVK-}J0Uk!fkkjsI{8{jp_6!` zIMKpXtRZlA9AX5c7n1amWYnrIlsKv#83h2#HXcozM$ApvG;8+zR3#~@v}2=jx^ciI zR@yk6d-h;uRKrojR7;l-ecJM~lmFs@RC-&d-bY+kfZ7xfuXPk=$>fX7!eZ91N%t{5 zU$#3lC|?eL?tyagOA(W@d5rp*DuvX?hyGqzA8@|Z(Yc%c(3*m^07>VS^$6~2LV*v-L;`t{bO6Ca>M6GuDXI3mpQd72( z-_Ecq3=V@=$e(EuxM2*YX0nNn8SsRbo>S9s5xRkd7GobjKfIY_@{{eu9Q(1MBc^1e z1wRhQ5llqZMCNUERj}68-LhurkI60`gSkdhaYjR$zmzIYm43O`BP1Cj`aQ%?U(F$H zae8W2(6GA+MQITaBF2k9ui==W7B-xYiWY+h4;wwIjjGCbLGXFxGh@)?VgCA)oH{$8 z^k)J=OuJJm?wy3ZWP$MHyrj=b_xPn`r-fdHEL`LBmq``DHVY#2A__jIJNP^Zyvw1m zODz;c-y-td((I22+v;8dm12k4Ma~cF#I*ayUb9|aOT?g#>l+So`3Q{<} zf-65Z`ngxI>a$2AGo1`Px6vkf5pj06bXMX2DAxNG3xgb@J4dNRe$@*aUM*EAq-XFI ztsBNDC1Z6g`{*_fxoKCo7f(M#Ec|3eYAxF1L55jo!PbN+1GemTC08nUhN8PMmK1Js z#hr1{GxV!7#XjJ(eli5jt0;KEHTk7p1vX{&Pv92B+S6p-T!P%#q!cypOE{w{k2?3D zs^(v=f93E*Alm9srW}GS$MIhhE$aFX_1L|p_eSpB?fWDsm5{$cY;UwnO62)diFf$NYboL68vPID?*V< zk*e;=9VkQD>B5B}lzjFf4UbX8KL~F7;vVoo0qf5{6MZDrmrE3QO7Ah=f*H7j;O$)o!XDaMd;Ax>bj92i?5%F$#q8;I z@4B~k&MaywT1Va@;fJqFo}kI_SE68%U6>hrvdFHAZ*$T5n@fExwuOIk_IODM~g?Qy-tV3t@@93=>S)LTqqD9Z?0IJ(#lDw*$ExuDFb=%&u2sBc>- zb6WGx0*m6_O`k7!s4U@Yi`6UsF~LdMjO9{FXd5~g3YC+1aW(WYy6dzXRtdx4us+C} zP`q!$qx8GDe^UTn=7{S?IGRO}f^VY0^J;0Q^4NSFS>NF$x3q+@sk29QVVzX(D$qRB zDZO0h?bhu=k|CPmrC`KHX$(8VW8JaK`(qx`qK>-{@1H@iLh#r9uc47e+7m<^e#^I|0_H}T~x{iHb>l}fFWIO}74_Kop`#fv!aRh{=U$KQ5g3}ulnAclNT z9Ut-5L-P)VDsD@bQpH_(`>x+LQBP2rQ5Ufqk8kvSJXto0hYt+#5>6?_lEn^^DGriH zI9OzP4#I2I*)*+sewcg?z~^Ck(olt9+NdQnt(s3}GMx&hoRBOOQM=2}WxBdO>Bu8))_uSy-_=Gj{_{d}FV7 zL4PGdQ)rqMJ&25t9>>h8tdZtpCFq+WO^BdKd?H4JzCYc|%xu2l{lPV1;Lxz6P8yiF zJ_^T<Ff-BU>{bGPyl9r@oZQX;Z zD_Z_sM}=WQ-bf(K(fr7AnmpS0s_U|U-7B|VyAnhf4p(s2u~<>&VET#fBlqd_R!)Yp ztg@}Xlp?dB;b~naOF13=qGHst;)}>Nv4th!#7T`Na2dsRW=ET@j?HE6o3ZskuH)5S z;-|idE{h-ngpE6jx?@?%a(z9s-IFt%cLEvx}7Np4mrm`Cr5AuW|O*9{X#U z{Wa14nq>b9GXL<%KAf|E{IkCy<{WHrf332=hS`5uXn(D;f4OOY1Ia($yGl?RwzTozE~dHDtb~_3WL|rnt8DUFHqD>c;vk*K*e#7)R^+wq$)_GSwFyjq^Q9&7uUNJ+S~cF|4Sw{#4pZ&(;Il=WUa|5qM)r_hj)laVcnvm-&3Bxs-^b&|29y{c?+ktHtbNT~Ge=zQ!9R>R5z_l=cGjnHXr3O-(f)|6W4y@n#A9;RL@ zjg3>zey04a{<*`0)2|$2UdgY#*E33RggQlCa8|#1DWM!#T)H7bSe9K%1gZYHlpSlB zTF$#xK*f)mkn>Ap?SK(NQqvrTA;16TxCuE8 zsKqXYec8$EBLwdciwjd#lF#-ft*fmLS*PTy${=*?qDTAXWcL}UK?3VU*t-8sd;KW) zf0xm}8|?qV9s95C^#5^p>~ClE-`%nQ+CBY;JI2Jx@zKEk(;Z`D`Do_<19uGCO>1D8 zjpq<}CcN5~zdkQPGg4-NUe+vTS*A81-DoWNu_bXk*lzujhV~Og=nqJn{smjUz=n}x z@Uvdtl zBZpgI&i`;@zz&<;C`b3^G>pr#&WVna-|?=5?KXx}EhSSFl+gifcUD>xpo?bzpe8HL zj8=N*?B<83hMKOg`8*h;0U`;pHn}FTOf_)^4p>C@aPD8ja~4^RjX!cq@ig>PpBZ*Q zHAnFm7cc1O3~NhW2X(T+h$ru*Wdd^i8XVW=wm2Sv$bEQO-p|K)&t0{$2JVW!qfob_ zx1X=4_Os%szb5!5?JSBXzQUO&>q2#X`lB7D`>E^a<;~XSuPn%Ss8`ZQ*vs9mAu(?G zk*YWcJ)-Q0Qe~L+&pb%QBb=1t#3FmiA&P%cN}yH1xqsq-vCi`OS-R#3g$C?}M;~`6 zNSeuYiiN-jHVcIK18|Xdyom1MYh*(@0H-KBJVcY|22IFq0ZUZHOe7$04ofG zcx0TwBh(#SA~u*Boe*b0Il4h4a#^4nnNSrnP2dqqu4V{2fEF`XGQ=1_i*68#oB?ox zsZk3N2GqmX$c20cjAQ0XhqwdA(G8-I>jG2AgvyZV04(q`r2SGv*nwuqxjG?SL?$qd z+9A!z4S+cqM(L0efE0>BE%H1-309s;C=fY5fD$uTDnx-uA|QoQs0LXWfCeW|C?pjE z3)q8?r4Xt_mM3xu7{(wb7D__aCjtOI1rDPT3x+rmK>!{DFJZUQdr1N`VUm$$h;RW* zfz`13=)J^3X~-r-Qh;xP-(hkv0Tcl$FpL`nckz%W1z5R(ui67UVfKrCb`@KGv6 zHtBs%ah8u=Y#M;Gv_7!n=u7>rB+cjbrdi@9S90HW_y0oob*Jpt`B{oH_dx_;e& z$2w%+uRGCz*B>EG0d9&RoA6gb$W`!HX~`W*qU zA|a-Mj}6FEF!mxLy0BN0L_S3QAi%3uNEYmsB9RYqzd4Z)ZGUutn?#5rfQPCd6~IH^ zZwLUQ?Z^}1qZr7Ae4L=|w0yk$gZ$g-b9@g{TYBYqW&|$8hL*OV2!xnHLzJdqz~XF8j>E+EFWSEZ|{%12ydT( zya;C>iL45LMMs1PYoCa$3OB>hj}FkH?>7c$QTLMpv}pT<0a}#(p8>dNJ3o;R;cIk5 zyaA`^2GPieu=bV6ZGlT<{W3%@Fg4mC)&MJXgK*^Zz$Mat5u)b+4$%+FLnzdN>@0e0Ohc* zOuAcKB=DIdBVNi@U=#tk;HWWVPFKV_a_d2=J|S4fap#~hQWC7lUW5)zy7AKHsgD3D z$VhTHJDhCQr+|oM&VU#W8r|l6MQk!R925I2!5}M{I*tYh3vsBlt1lD4v^YPE022ob zDJTsT3o$4YzZ1@R`?Q`a>BFZTpoM!UwhV|vdY`JuE^WL{)v$XaFR)8$C=IqDscZ+fV2l8$UqXP8bMBbcDO|`XQ4FWa21r zgtNP*cyrXFC7`gK<;NsKqF|49vUj)^gQno7!09sCH`5Xt8LEn-m<=UX7f6Eo6VXz)Me z*eyoUKiHVZUu^7{Ri?_pBap&9HP~n9_=6c^#NQvtH$^%6EHia8yy@T(1+wMf9gBZW z12OYle<{+ne#CMeQT0#TM%d-*g0^FTvX;ZO5=ovwZB>ALyD_@KJt=zaliNG+0>EojH^@@bHJbSp)dMZ>6$|qowXlX z^Sr3YXvS6QB-Ey2Hij0h4VOfNIDu?-8dEnFyY)$%%h;LTtVPN^#tcP?Ko1UQM~xnH zPTwPXAJZ`ox_zXM0L=9f{$hWSflpibBXq-!!vCt?#(d@|==5YKg}O;;E_45kcqg4t zX&Fu!zf7)3D}WktGE$`ZCioUREb*djU;R2w>Qez!RG(G(IjoRb zOKP5n#Kvfzho`_;M4Z_X;|l;U`o>@dQRJnghF_#5BQL`#j?E%hVkt!Z~rH$}+HH~V++ zKM1ezj}$xn5P$qE35Z|8FI~56yVd*O(cK6ZHv}KGxA3;Cw;0SV{e5LLF<((HMYoW; zHA6g6Up==FwwwcWA-mw(A=x4DzRF&)ywnNK-rQ+n{nAQe zxw@!SVWI17r0i)sKYE{8dVY_ttbH~X?bN_frZL-jI~;dESsHaeAl6lEq3`(;8+Zm^ zy0UUeU~ZYE$y(%%xMQl?&^X04yRxA$KeyqPU*c_|Z0HGzpP8=-5I zF_S~>__0G0d{QEffdRr%x`gu|CEw8TmDp6uuAFjjwXGDXwRhc*+S~g4$Q!t^oVwuk zeJIAYm-Ue+vDaKDYTC)2I{0W2e5>-V*1U&t;-~8V=VJ9UJ8`s?*^)MoZIZ1ClnP>T zAx596xb`^7TYg23?uPX0W5woM4)?14&W;+ll|DM4lNL*+aKM=Ex@shYo!Ez+?KCnU z`bp|t<|q*N8-pBJVJ+$Q7$+DkHW;xWH25nj-(d(3i1{^jZoaw>ghgX z)e!H>y#K!N3^IMkWA@py%&JBVV=P2CO4IHpsa`Kl>OCT#>Z(3&R3x0!Ea^B4rEVuG z9Ys(&)iSNAddA=j_Wr%bu2vo{`@#b2U}PXFPS-V1^w{xQHtI~RlNYLmWY7oYB*A5t z(8um`*QzU_)H@`R)KQ}CpY4$tn*o>CY6G{cP2m3fFPho+&kv8fKH-p`r1K4*L%bL# znHV7GKhc9BLO}n#@q6p$(_^TH=0M`WTtYa7aDm|ddDg9>2Vae~^vUYe^H0a02;Clf zc-0tckmXP+;2qr(+0aK&Dqv%N^mPk&(nXZ91x1}}y_`H9u-M2I*C!P?EDNB#YC$`>U_WdSlda4CpUKc;LnN^o+B z0Ra>_7&I_OJ%|{jJ@6I*v|;dCKbV-$0e;BHpP2l<5aPjr`E*0Ofg^1}Y5hdC19Rzy zQUiyNfl2{K)%*12C;l|Jh5%$S`1~!(t1=i?3>ZK~JS0BIk7&zri+M|N3w6tIi@&?e z&lmjt6CcDMa4#4yuvffC96O9hnoGV*{7d>v#7nkI%&n>Jte^Z4zF->=8=riT+QHiq z+o9V3)jc7)!MdTifxF>9(p}j20N~Cq%GA$QM8FZXG=&JA6C(YMiCd zr=MKF{!Y#Kzxb}*yS4NXzr&k-*7#|X4VwbX0)ZgFD<`V*mh1|8KWkci+Whdt_8&x# z>aCm%L~Iw@3^;Y%XE#KKFYk7Be-hseL)B*B_WLHs3GR7Zle#CClVbkBBX^DQ97YoR z#Uq?a&frb-*AKgNKZ)$m2NGiM5E|`)V(a=I!2D0@?HLzI_T&Nw4MfUGd|wpSHiN1N zY7mhuPW!vB)AkSLRzzo~hl{>Bu=evP{OG$jp2oNrC$O-^@iBYcVBqQInH5QjDKNr1 z?$tEob^D`igr|-)1{8cA7O4#lWZPcRIAVpV5TJHqkcuu?k!p;YFv3~>;S#6)XbXRP z|JM&2?d2Y^d3B}dj6Nmu9O0|wzjI{|Uk;}6R6A{HcHraunbz`CYdAp<-w~xHMeCPF zTZEQOr9h;&<5Ad*(%YVd1NzC6=AOm1^z$@krIuhN(PG^1EhP3B+jyK2*DcIVvL-L8 zdvXk4=9b7c#H<|7&d8M2)YjNFA$$^kvY`?GJ)-OHb;b-+~|snXnU|A5`^6$ujC}irEOmx1;)&D3?6rv#2&P^YZ;^ zoT+!Mw%nv}jct?1eE3@W=_bV!*_ELM$@;~|A%N%S`{1qHKoy^u&#(pk4=AxXT(Tj# zc%*n#qnLqr*+qQ7=G8ursG>2MsHA%UkAzIGU?ySFH0TxPJv3zq<-v&ho<(w?kDr*I zyhxqe<4*LlA}c5O`STOm6Z#YD6D(k=x{F`*Nc|f3iOyY|N$@SGJ-kcs0}#s+!%mIb zf6pt9)EstreR$uEUXj(>i;9gFb&2*WXNhH<1xOJR2+-k?sOp;bY~mMAFjW%sFQLLo)4A)rYqWp63HEBmX|)^eL@psUZ%zV)`D| zhK~t~51ZLjdlxf;?LszRRc($8any^z;$cGR2Ty?Wmao z&I?s#LTM^pJodAjnbJDAA;#E*uv-Ayh801#^XVLp#x%@pvYh~*@@|eSjs3XaSjsZ<^~i$fCKgd!;zl4 zo0VX%dNSd9M~PPG4%A*?ILj?4EQeieEUey{2QVtKflG<>IVvgEVOIQtWV=$ZKnUlV zTctw$QyXO2R+c3I&(Dr{1NO#QgiFPBRwGOe^~rW;_tGEEsO8d1SAy>AZVl=Ru6D5? zB4tK>BQlCbf7WnBNwc1`nOn@lQA9}&B9(v;la~bbXJuW=zk*mLY--Q2#v&R_U(52; zyPYKXAF$@g0Gr!PrDoW>CEly4r$No#l4FGZU~HAe=(ZjPv@o!?9wl>K-z=sE;n8o+ zpYbXt$)CRjer9rlNp^|``wF(lFcpq5$;*0s!>796CWt*FRk0UMoXW!Np$o4qKfb#h_yQC z2^avhU5!l*Y|5GA)Ud(>j=eE3z8r;6wO6+xRy3jTn&#I~e60<_e({77MXWp}2pM{5 zVsWZUk8qhGFxQzUP@iT*PaNa=_2$QWt8<#KY@y8oDLi5{C?M3@ZcRw9-Ki%&M4|!! zBr}|fjV@W9XU=fOL|WoS2f&2Zsih9iilvbXLDuI#!5pbQcazuy5Npe*F?xDC{J-kk z^PudI&T>=UaL`DyBO4Q-4Y^WyKr6pWXeDF=fKfwudnGptCC<$T1*-UD-^8k)f;|uT zy(qrh$PGE$d#{nE8>b|wh<{~_Ca%yS7L|@uhx?K(#RHyePs*De4UMl)c2z7|;4db= zi#FRR1vTrc2p(AVzJ|5NLZT~ncBTP`F-V;Nl#o9K+q>pG->{$H5F|=Br}y`X;tvT zzdny4Pg~Z}mIAwt5?MSA)gvKWHt{D~BrTG)?eHADuD@XID>RB2?x~d1;8Czkd66p` zoH}Yg6%%Jp=rz;4{PT~2jJJC+D(e=pwC{UbBI41WB=B5rQeZ#4zKNhc3w;n`?d-oK zKUNp2;qldiS*IdlK%E4Ks7LaB5MmR0F!}UfpVj_Nh?TJYLx^$fqdi~JI;m5G^R1?R z--*iIl}a52`@N;W+=2P36O>*go|QXLj}Z41>p1fON;e@W7}yWsENX$y!ao(#TFjpm@sU(9g(i)ZVl*(^&~l*p_h3@!w@<;5`ByQg#Sa3EaOc#N{luV9pk7I z*V1I>?TzbZ(RAy6HdQn==@;~IK_7Ms7w%1y93-9|2_57$Za$b~#ET~Jx4AuBI4LJI zmMl9nWeVv)&CH?a+F^Dw07_oy(f0|sizbB*2n%j-XbAT=a;5r}WnX*vA4uk@U}N1UjNP6FnPpLlPX^ zf|oV%Vm3Np5VPC3$*zyKE*e>oab#7TH(*PvEL*2ERA-fb`q5{~*p z3Y6&E=^QqYrn6yjE{Q^jva>80(NaTd5SKi%Z1GeMtUGG9 zYaJuobio8xc#bt=4d)>0Z?%%GZ8*m4}Iw`{`udm`#I`q!P0#UdE^UFew}&b zw#Ex7-Q|nksb2rQM!Xcf{#j0pRD7M?HVm1TJPdgP+f6%L_F<)%Qu`8NIAgRB0882h zl1fHL^o_~XA3;ZiYmBjUKgHKB$bqOXXZ*ml#-u+`8RaNNaE>D9r) zi(&c-VI8ytSMe}caaM6MYorpVr0~B7aLZZnNX3}ML(ou=M#vcBeq4(a!6MUn?7@;E z>59$8LomgDlVdVr`o<9X*ja#1v-35 zS+^*)@TugUX&rxk^EMd^tq*>1Osb%;Y1}nmx|T&vr{R9-OQXvR&x>f(Zy+dxpyj?z zwdMVc^Hlpxb654{;c*jb@6#lL7yqS4D`y8+2mc$=BMVczwmTxX8{Bzq+Bmu6uym-T z0baEJYi9INIxQamd1=)mxC|sKCtb{@Vxt?_t}ZqQgSdkj155k_xafHc zr0u;Dm!rrW)3D$T4$CTfJ{t6{KMOdv>ik}VD%x823pcijThgD3HobC@)G35zZlx7i zf}hbe=_UvkALa**&vN+Cb}AyDvO;+kaXra{3=B{uxyUq^2DhZ*8#Ic@=HJD2)qJYkwv16p9q;i@TrSkd3YpMSA(i$ zEg67mhT7FErWW!+Dl-;n4KnGfoFrupRYbqhE9m<6C#!!u-G6DK=_|zZP|mnN=ASdq znlE|gYx^-HrLK}*;Wd;UuZ%sRSGdToFVXBCJD{(Og{P9PS=6v9<$gC7MDJVxVw%;a z*IAghN?~TYE;;dPK*dKRtCDZy2h@sgaGKOg)Dinrq2S>@ZKa?viV$5!jX>M;M~>Fa zcA4BS_W$`$2W;}cIbaTDQvF7(BS^xT5wBdiLQ*L4yoQ|}+UqhFmX>Gp^8*9g+HA57 z2(v0CyqXp?G^vyWt&d6EI#U1PfO+qZ;p+Z%z%>3kVAl?7HV9=kT4d$!F0M^DElzDQpdmE22oCHt^U;E5?x zX~gTKF}?odfPo-vlxI^4711&V+|0}vR#c~kp{e7!Q28capUk*YzxoSDYZNSRAw_9? zd%r7Az1sXvRCslP8@OyBJ8WzguT%1kj)@wb6c1jBq5#(DYbqr=!VzXqPZqx<5qj5v zm7(_)%bEw_=>Uy~=u25$4eNi0xK7QzM0C$kcVHW_V4 z)1{;09gDOX9UT>GxvXXhs47*w6RBA^YHo|cO&d>7f@4}auzoDTo99xlM~>l+IP~5Y zn;Sz&QqdTqtc_9-vR+^v_wz^4r$>FAg1n5G@;FJjI!j~vfi<`?YNPtWsUJtf_6qdE z4Eu)|cSW?L-;TTA3o$-3hd;}XvfX;?j3h`|!heyN0lxz%cs9Ds{hD$VOp-c<`;y-i zQE2FGZf%jqv>crOU6bxNL~&@Z`iywvby)3pjrzuRu_z&{Ii=Dv%=Nb(-ag-(zgQXY zWuv9x%ex{~T+9#OQ%<52Tbp52wZ zBD2eoGM?RqI2+kbh1{n;WiHJ^rts5@SAMawiGkIs^erLFlE1~4;m1!0QamI_bxyhN zu$F!|bNU;Zm|Y2p;vr_4$c=KR%^&39$ywA>@>!SRo1#NYd$c2&*O~1YdegGDrq0Ow zwe&xlVq|n)q8Jlp>T*Yf&Fo;MesrZoUF>5e{=(Smr{JP02+g?Q={`qO8g(ia zg9P*bEkABwUt02#TOHAB|nWP}WM4aGc@Zypkr^Xc`}tfvO|o8 z@vg3rTo#abNRW4Ozf|%5s!m~S|5lx>dt4ahiyI8X_oD)l5cN`H0to5G}dFp{~%x{LaPSp_*hYh{Gp61>neqZK}oY9Snp)T1Yws9^zpg<*`y1;~?K)jr^&Z0ACIIiq^20scBb6jL@yyV<& zd~~4NhA{KK;7j?wd#R`cz=yp(+iSL1Io*5>?D5I;rPYpI$W84++V+tBA-UnrQYEy0g9x{@?}{e zyqNljbrR%fxHvnf&h#{@eEno%{mns2W1Pc7bh30qKDfqWl&pzq^PamT5;(`2;ncdF z4?>`5KpFpsb#mbfNt7@debig9>9Hb)HbLcd!E0fXH6S)6fA!D~*^|-m_`MB8TCs3<-%=F!~e*^`q(6+wh5m_Hcd+S z6OkeVw3Eg5CZ^AQGI{NteD zlfx&Ak64wePFE3R1TE+X0En7OR|^Nr!@XYL5KWclpj0^hcVSfq_i`#mI#-d=WArlC zC|TWtXMNhX`Zm?g^sH$VP}yTUenJ7i;hn^Y3qv1+wx&?=rWY8YZ!&l(^PTzk?T;2h ze40pZ;B5J9GlFH+?5Tocx8x0!89PojvFcB@XRwOa?mV|1H1D$+uyiUQ*NJ3J{7oMQ z&W0N^dPahSI2ohZO!EvzX#(}GNIVO?vpcm-cIm8&xua}>V*W9>^B)LyEsp)&;>tR< z*8K2+)^gK|6bC-pMe4Q94 zN;Ab4p{kVgu!vF;YT>MWmvpxzo~Npxwdu_!mMt8!cu0r22EkhJq{QSUPHdtyX#>=14hE zRfW@3LR@{Kx59B1k(Rpt@fTv=2cK!!5RX4HoWem;WH325TWb#AIEz*OnRzLBdb0Kr z_c(w(3hsL4yCS#qmoPJhH~5r0h6sD`@s+P_Q4(|0;2<`K6OPJd78kD62{Y!J5i6=f z7lPV>ZCQf_5aWsi3l_^j4PVly3NjVya!hXBYaD;FRC6l8==LX(Tp0ju*# zlZvc$wv&At=SHVs{|kmK&I?f_Py7RJMhD;>Io5ihLdZQn(Moziv1ZWG5kW3~=!CT8 zn#fK{W?ZxXA3sb~*HJV*6S%=)Xp=&{#n{z1N*$HK(|gK{b%lqyJQzWzPG>$0`(6sh z6xgD?Ny_Jq%5M9#82X1nU<9He)nf0QK!kkbT&o+ch_g;#Pfx}n>15TRqepP1UeDyg zLWXq;sa_|p%TWQl3$KHn$b>u6g$i-6Le{(CNWs$3X|r9;4vPI8Gt)K}zyAPvOhx;L z6DVjD@39oYh)*#7v8C~+ucco;;+r>y^6_zt5--2n9AwUMk1CNR@1Sth8pz*AD|8xEj*x1o>2{JbhL{ zu)nrFpdlKI*oxS}3X{K}V($?hEon+n6s2mKm8tNOdzQrw@798kl?r%9O_lQgB;Io| z-5JNoBxjOwwD&_D({+W1pJ;!TSalW~xuhF&RYHTlSO_Al2WTd4V(gIoCitT4+-OgOss`;Js#RW<;B&a7` z>FCObo3B`U*K64_uFHs3X{^a? z&A0$PQKEvCcMGXdx~0+j;J&dp4ez01^N>DOk+-6#r9Z#VN)#uh#!T9MY9Bt&6|Yp6 zm1K$2_W8hECtf^{F*Rw9?SQ2+mCsUAQpWJ9UED81ENJqi?vd#=_KWC`mnV2xPdLjP z9L(`zQ9L{mypHS*xJ{r4exb8dd!xz+_<~0H8Se zTgAY)GiZbQ4FmsLqDl&S!GZj0iO34-yS|wufjnmw*1ew|Y#EF*`z_Fpzvi@@#;>*g zP?NBRWY1wYO)chWnSt1yTL5-)umBIR5Qg1irnx*mC zM~03kCJM?YOs1^cRw1hp;m@~m(Is+Z`sxWHHI(s#Ov7|Rl8c!yOQcML69eW7X%}aD zYkD?tCP)(3jH2P!KCpPUw+DrBzkY}_X9wp5XGYIN4t#s%VP)ox^og@U8j$|6x$4~x z22Hmul$BQ?ajqkHmWx zs=cXiummq={$+e*d72+{qtskza~+Mk9ozKhH7_^p(b{UFYc|N#xP_UZO3kwrq(!qW zxVTFTH`Jsv>YhnEfdDbaCU?d=GcD*k#t=rP8n=A>mSes zTxo1LqEdD`2c1WLPcbAaN=Ka2_TPj=7$)4yr&i-cZVaH~ObQ`c9XDs3(eZMI9#B%I zqM~G%nsK_kHA~iV8w$9OC*Q~WBt5G%fU2$6E9j04VU`&`PWqlbPwp2NdkwdHKz*Q{ z$QHis>NZn`H1C=2Q9KHU%w;(WoPjipV(`vZ2i^8Rz4MprtzXre;1_r!I=O?AYc>oQ zGUT-6HEUV`_R|aJFg>M+qRl@idEtwl;ft5y)ff=7p7z|lPb*WT*axCP8`)Zk4$j|i z%rHdQzF!O~&uwhm^-Lj_R?3eQDb3bVix)^R_|UEFcvo>-OQrz}eHk)Z992u9O+7Qm z9}B96nk_*-m^Z{q0!gJ?rrvF8STj3|)BgGHo4-lSRlH~v#U&TJ7K3Y#207R7jo#Q+ z-xBN~(C`m?juZxMi^eL~;8ZX*_U$TdDN~o53+OsaTmIAW!LW|B?Q~t;E780-TE9Fy z@AXW$ago(ji4Rn^wQ0Uv6BefLl1x9SOUJ{ApE-1%JH=Y7+l__CK56o8>a*WQ5Ux{E zoy8}CzG%}e<->eoPF7r{SXWt5uBIoBIfn(wj$I7HkmXleZ6$d#Fol~N0Uc^V6PdtZAG9U6Onl)SztU?HOoM& zno7~S6!KX!QZrCL1vL*x^QCN0vPQLVrj_Xil5;<&zQ|dmW5vc@BRCUdm8um|g(jnf zAcV!*Ds+69?HH}$Bi>W-AIN8QFHs|XGZydp)f-o|_$W1C2hN!LmCbtbdJJPfosJy( zJ`$bD{Ly0{?nCl{GL4`iWxr8M?yw`bzGHT_n@lAt6HH^RD|fNmGvtZ}tGh?^xzYD1 zQQ^j9vT0l@PMsZSbnGe#e9$|QngenOZF4_;>Q}cGWawemG;;9G`!{`l3z+S0Ft`reWLmI z*Ov0g*uUQ6;9gj*uPx0ASKPI2}R3DSQtSk z&9#`T8Qn16!UgaD67w)$?BPu80B|g;Lz1!QEX_+}*9XYjJqP^V~ak?#%qx%z9ZXBuBDHR(^YP&i>|nHgENjFzr|NoSa;GlmLQ8eFxs~-4WCJTx%<3 z?nwk>9X9p^kB5jz*owh-T$)5AXHT8|@97Mu6g-#XSB?tmX%k#!Mmiqs0Gs|30R)8G z){Beqk@>LF^lRP)NV<%$A4-+UZk@f){0ld&F_9eg6a@XNPspPVvJdu?HOtOcy^B*K zrEsx)sz!ALFj=dftg)`BEYp5t(%#%;$Ez_n>489}NFy$kC#-bzP==-0PHo%Ixh|jN ztyFX`d}RA1LkiG+LfKi&*$RfNuJe6SGN`vvqmaQlIk{#n2lh@2Mlb}uJ!m`*PJC*& z8LYFl>Z%Au8bxUKnAxhV3~D_z7O8aNY|}d01=|XI4`e^G`E5@x^V^MK3b+Ce62B=G zak{aLllJZyEGH_?O72N=N?~xF>KH*^EIuO2v4m)|fknIFAA_c4zBG{FKEGMDHtF2sY}6Z_@7UQ2Tqtxy4C|z zA}E(7Ons3>=}asA%FJfYF($LT!@q9oA@sj#q;r22_2Wpm%J99&aCZKFOY?IXo~BEj zHgctCDV0EAq}2eH(;uQs>In-g4DdY@i0xSyL35j_)y5(gkoM3$Do=SN>*rxil1I78 zxI4~TdYwLlXV;rm%|wd%WjZt&?zlp3!xZlW&Tr;H+yQ|3ddSZ2_QSV>1k)VkvNmC$ z%@m^Hvzdzwf}1-LvV5(cSDo3tvQ^U3U}GOfg*Ma6m&IrG@W*GKaF9yd_Lavu95o9aZr|6XpBphu_Ql5u*P9{rbRQu>I5M=~8ff#_u|lkLIyaEVcXD zz`IhpNX+ZYc`W&P4yWszAL;$QrF*^F1z9Mi{?8h&Zq_-NRYQfGl9qGD{-)&YZlNb>9cE7z6Ej4JO@AL1&EuHeb`1SUNZjhwJ1XIBBeZM6g5^uP28WrSpnMoKhZ?LpFaiQ#Mhit(le_NPTjYw(1jSP{Qg zT1E~bPHSg&9$f$UC%*x`msNb)BV4r$F5EsV!;PLK;hJi080HFGNrm|<=U}r7?k;G| z!5^e3uVv7dHVIV|=sg(an)j{l-QI2qpN6$4;2nug=Wq!)TOG$-$J;?P1>A8MHrKZL z{0gnpWjrZiH1s2BSl zQmWS6tQyB(`t?)ZzRp1LyfrDLRE?|ZZL}XcuU)l29$wnA40pd}RtD&22-&#nZVmgj z9;)VI-MzMGwM)p#uO@DOmHlDE%Gpw#>p%mHxTerzR8t@#@nTl zOE8p7A&$06GkX})9^g-lQVINV3J0sVLKl(*W;P4Xqct>(jxn}&^oFr=-fkhKr8yAy zqkVepSLronKfM1bhs|Kf7P$8gS!QIh%4aQnF0s?G{;)2;BaSjCakfUhmk z!Wa=}Q&oy3%iQ=TA!f^R2Bv6XTf}cqYK>EPjni!>d<2Yl5t8s%SFNaF6*IB0yc4jl zAc%Unj6=XQQ9+_g^V53MSe@HS<06J%{T;1%eMwBB&9HHhBmnTrYWIo#u{>&T8}8Ca)4<2? zDaf<(`}`z~|J8lwk_gN?2SNz=A8852dVZ!<%rb3uHx(t9z#&k~NN-;@W--_5YcFML z;&oOCI)e%+K`03imwIJ%PO&-S|*INF6r@h^?HZr@Q=oW1(z^_jnc!urdE^{=bn#FLy~So5R&)?iFNnx z=@l$5#8{Pi*|Pm`2RC7IpAGz)Q>J7lUBJ`t&@;{dI|aoA#@+QenFvWkEl$$td@g(I z%5;&v&cQT^vLeaB;%ig}<@||VHzED}w)@M0nw!T{W{FLe7L7&Z(!r$Aer55rfeysu99hM0QrO2_xgLI;o$BHdp-GCCk7Q^vCj4WLtJRLRBYoTQ2V=#k z(~|;C%|y^V$+_7v(%nz;H z+J)`b-C7&}Ali=GKtIK}#%E4G8YPQDRV8}%-~_knPnFQ30K<+iq(&>c`cOl%S-X9>(KFsnLj(6s3M2@~}FsC2@z4b@(wgHJVw zT{heIraYS6KDr5+BlA`72a(F?E6CPn6z$6?{@cho;oUXEeM@5MAh1I|Pa0wxnvP~Q zIKA|~jD_EIub5%gn7AV8@UwiG+r&7aK#;We_jR^##92V=_TA#FXGgQ9)40 zoQ^*?b@i7(F67U~p5th%2@Ub5dK!sDY`ZPvLFcL+nOlSUv|8$>LI8sqI3s$x1?{&| zQk76;*06)#Z}W9iTC6NxJSO#K?9o|7%Unw*XhM_1W-|4phfJ@NcV7mmq@b#0P)|oz zPX=+_HTpZzSk4aoZ$=GOj$Gqbjm&{&YArwPAWi@Cbh7fKq@`4Z-v~FgVPuLXa9!ZTqN_7JTa1mZj5j zqNgBJB4nDx@pPkMb}y5~!NLY6qJ@l0#C2@05nOrq~<`1aOIJLgMZ`gL*D zP*4pjf(Ad1Ktj)mfWF1#mwe|W9>H`-?<@r@4uudXYq~6`P3o}DjlMr72R7ZVB%f)N zCAcD&=pIi9xFcmBC}J5ExNh?4gr9g0CojOtf;*|`%VIe3jmYdh0j?+p4^!;hr>=Hh z+;n57f3$azw(#2vtL6$@?DE*F1{?@lKRQ(ZKBGeHBC(@#*lx4Hy@5-TRN}1>^oORx zkcxG(th)XBmNt88)zH4B$qO`*Sgw@0Uab6_K_D1D_HOy${KN8b`={ljPVgyrhZ_f0 zo8yxW>~V7v+1ob|o@nlkSahQb18cCd>fM`w+rt?OMvtP6Wc3iDqYJTkb)2MOwuO# z1!ZdDd)S5s;t^G~+_ABeiF(quiOPuV4*0+nWqW-Bx&dlAk z)e*Wv#ow~=;KDqiuYAd-@j$ssk&U5CgqIR~Xyzhz0F~hlXX?|$b`kz)*kLe%D(=Le zDG$(K1(-#R4^>W!%eOVo_SHC|LvKf&h8r1sbLLNDvy0EvcZplxMe(zm+kD?g<+d3^ z-ACc|NomR-Xex6r(NuI14UPK@-x(X7N9japL%SMp$u0$r!s@VJcPxcnRR=mXY79kY z_a}bgG9{^o$%N(EhLl@;^!7@v>Kau(Ud`9PQo>T6r%l;P&0-Zh_PDydeUIlC4E*dF zIy=JcKW_X^9wc1dT50ZME-6rYg{}D_65|cDjXe!l7F29Q;A`wvnhJy{Gx?WdGou6G z5b3(oFwRk9+?RX+ix{v=0Vy`tWuN8mt$zsh(U+t!7Y!eGs$Y*{`f9~q%GT#{nH>`1V7Fyx-yILVp-VP%sN_;!32=BB zwmW_!GM*17`tKA2E6@KZG5lZX6uE!WDGc&f7M89cy}-fV^9XlR(NjqzY!C5(7Zg{+#pPagN>MzjT3a^ z25kqyC){krtnBQ>oXj9Ng%gCBFu&s^@30AIAJ89t2Uj>j&*kLgg#UNYYsZsriMi9ZIEVBUf)Gn=CjPB(|AB z@@Ydy<2B&+n%BKxXhZd!i#5G5nq(+Xh?2>iu8q+=lr8W2_phHUT@GRN08batb$x~d zja=%opEM{R{6vH=$d%{{0J&!JR2Qbm@)sfgde`8`v*b7)XD*otm(;8vgYbB!wMO64%5JB|q8XV**C3j%(WqEP1|%t1q0 zOSnaY^D6wIX8u}fB^-DoqW)PJP%i<-AT4($nx}!HJzXYR`t;+bbTY_Y?ftO@C;dWz%K7!?r;EH-l1xHoy2|m&Y%%?K?N&Kc(gej`Q`pmL^eJyMZWm<#nmetrci89}8PE zP?0c+xO_3QcYWVR%=BL7?+brDg-OiVQQGXUHoyt0RVGzeGdqpoMdB1G>Q{hC5G%{0eL!c8qkw0!66~^ zBqVt&ywwXPGpRw{9dVUOyVAb z?>Q;U#tms7dL68)$ZK6!9w^g1@9_F{rtb~??NcntCrmpWE7NO7#C>}*prXUNyOAp5LXL#Azndj9+uZVHl2c>_)()cncJeW|B6uFbj-(!Ha*ym|>=v??Ct_0{z8wo;E4F#> z0r~-o=(brgEbRegC)wwLTtCRAj(y7B#ym`}xmZN|FzTK4w&Jb$9R&IbCg`Z--<1 z_jl`K`~FwBXxbA>Qk<6?(TLY6WMBBBa7Zg*1x}(cB&fkvLPQzdBrdu_1)jUY${ysl7+>4A zj9+6fsQp=dGIQXGHZ?;p)o!kAwt@%Jcik<$%Q2r!?8Mlte5b0LnjiR*2%ej$7Otuk z>^GU@*9YX1p6)fN;xDV@|6DWWtPJG{c_jEBu3Ei@?oZ$E=ag-CJ+7ua0CLbC0E*a` zzwb#dMR?=iNY{Faj)~BTQgP7Z{}5rt%j08pgxB0Tu5A&78*=;ncD!Ns&h^h}_BY8H zJok3pKzKUvz0dV5e#`ZI1By895DU)vi}Le0iS8)zdu@lJ-@tjLG+R43GBscaoMwbc zSm9I=t+V*JrV>IApS|jD9{?Grn&_HsOcxdz&9NKAR+qZO@Y5Da&Wu?6iC`Ow%<8z= zYqVEqYnAac7pd(naZ$w>M5eHTHad^M*GNIbwtJ|9=GG!93@R_+*$>4Un|#$1(~Jji zU5zNZLwY|6x$tJ6d@)-GE6f#2onIQX@eWp2SQ$=)Ica&@p@=Z?mgR*^#wMQd)q{1# zR8?Q1qTSu3ht*%u1S!nilB%leluVRlq)(1fDl7+tYjD+m|1E5xJTbbn<7X@h6=%c;oxB@M7?6) zFpscz@SmyHW<1ceg4JAU-L9e-H% z;I!bz=K3;Uk@H4pi=!VX)MMF&WVcPdSmM8+w}ymGDyE)u^TuX_zb@bNZv?qR5(s}e zAi2Tug66L1CZk(Nc)9Dt|9v2+bxI$z0^|F(fhj>$n~z=KAImxFZ+F(_idE6$(3h>$ z8~3N%z&;Nw6v|G0N9rwxEkB1=ZEAx}svu{ZVoHb@(>G#$=Nbtbn0;0`u6|dkSJPh5 zQPEJev@yH*`Mj)5U!$(RwX`CUzM8 zL@H_)!n}rtfK5?Y*gT1l+#PV0>os3;Y+P*cd3^!jNtc;@FVI|ez6b&}J?g>M@K^eN zJrw#jXnLy6Rcs$F(kSy5D8>da;Bn3QS@WTQr(qu%yS@|;QEcUoFmap{e7b|lfWNvd z)S07ZM=piGnktk<%Kb!4BZZR&@gRm*q@D%lpEPrNmTXn5 zoGoX9N1>QK(jWnzHq}=-^gQw#06?@PP6aGc+agxLNxQ;A$IiT7UM3~7C=Fw#7p?|( zIR}8l6#3*0G3~+;Ye_Bif@`Um;zBOmTfl~3oBN@tFy)7AV{ndK;F8MM{(|C=;r<@* zaS$4<_jT2tbfiyJko`jh`#f&M79;y+dw|b+yFny8+W0Qy04>_MR!|)?KXrilOOO!G z+X~-KLO-+~)PrN~mEjMdDcATEhM=i`iIWXdTFmiq)ay` zP{!!G5ubP=5;bwY(Tj@7uLuXo)IRIBLR=-_%rR+yqQF>1C8GHH!i*&k6jDSEgO%Px z_=x=LHxY{MD*2_zzGU@;LS?`V!-JQIZ-=N+bxLNU zQG&Bj&~9!w*l>Z7L(Xy50piM!X8IyJVV*++XB}Zjjy@^NVz4j~lP}afQ(>PpKkzB% z z-5y{vu;4rw3Ihhg`z@YUoK?iJoy-DYWt}rCOi`d7FuECy=qTX-&?F7g@am!I?83ta zi&lN$+|k7(4i|G}$Z?Qr$`ly{5Huxbcbm}nSLtp3B7t*`517rQBBJF{#dY|02~~gV za?%L7!cmFA+d3d~Mhc`7XLKau#+{$R@@k$|gU?<@R93M>hGPsa`^wLbNq~owbMw$I z_1u$ZeG%xCXZO2#lAt&+_r()_+;v+nQ2grLu#+|&tJS? zNCil$YBA>0Hw6LxKuf{2c?77{5f;eDaN-jWJ8}z`Vh>CHMLB+irA_=T6gjP82{ejX zMU$vGX@;Z_p5X@xH^v+Ai^+9Z4GdcdJ96e3}`3$I4w-5id=!Wv=h_+!NEL6Z4jI%5x1G0wdW~8 z1Y=s{%0>eJMwN6hIhQ|_RrFO!93Agu|rBuceBNTAPPU!{4! z<=m+&hzI^-ewB!ZL?6AnC6x7@8J45kZ7Ahh(}}`GLG>{vMKFy)q*Y!_5nocQog1R$ zI*Q=)W}l7Q=h&a6v?ni{!6+86JGYyD{{@}lL$!|&(9CTt$fXVV7 zBQr9leT-D9V5z5tEMLtCWc!)#f6K6NpnJzxEmeW0h8vVSG(2l=4X|s3KNh4j8&gyG zq9=0-pdRkAsGKNdWrI?hmx$F#+LA_B)4?-m2Y;5g(x+4=$!~4t)dom3fFO8z|!FY@$V`7Ix0Jk~Awf(Tv0pq6{;d+zDpsb>*{`>NDo2#A`6Qe_HZUP1^qq z|D^+%OE3R@Am*ZZr!1>qyOdt~i~d!xf`u;@bd9>g-KNl1yvwaQra~Pp^4++9lByG8 z0qbEJo-7A~T7$D^WwO@!`~eXz(xMOM@E>gz<@Nf?<;$=YbWRVpt=fF9M2&*hmJGH+ zlfG~^E|F>aXhw6aqN~8V`DQTGnQEQs9$1sGZcFMgwkJ`kA4JbReFSBM-p8*;TO4+Z zae0;rlA6;UU2ShATV~03zHVasfpeH%8YQ_D4Ke_h{k0^l^df z@lwq_to=rTtMMV2O2Jw9Tu~b`Djzt0Z?5|wxJ&9e0Gm?5cj-j3@?+Pq9`9rGBlBvH zy*)(g)Cd|=&*2!OF?(jc%6e2-Nm9nTw&P!KJ~Y->p7M*1uR_@dU)!xWjxGE=Z=>Iw z9dU0*<=$Rm=f>stY=73BKRa~RUV8)1vwYiLF+wopH2_k^w?1kIbpTVT#8JjN1d5^% z0YXlm^3ze|Iu;UnbpzBLozaCTGYXX;?{Dn2SZk7`i=+vJW{K>ps|yjP-v_O}BNjmV zK)*@j1}9(ds?h>uOokh<2(Xh9XSCgPqJLymZP$ND<2YHh3o!j!&~&g%?7*4Xn8qem zZ$&K-i;yukWXoN^mWFdKFRylv`DG3fmbUDau?6ildy=dpbCA2Lzl+#;&=HHfe&}Gb zhS)7s-d7WA@aLq~4P^QgSeXfKn9us4YfyLYNY4RaG?x@b$IuYP+L20B+A*}gUk#aeUalMr4i1Ihj>9uh9BdU8 zO&YE3yv*Xbq@IU$z2gk|X0k~(Q&d!4H5dkt5*4o7$$}?j=PTdl2P|@)9caEMCa0Vb z&x21DgXe$4-hHqQqBNOMlS+8Wt{ko2J3H9QD(PF#U_+%t`zhMX9J0sP8vl@rY01J> zSS}A$=7OVuD!7kKd6Sd-nF?KiFshcH|<=bKuVpT!J@Fc|m z*F|wN)QAZMWH+(!$s$k3nlPlc*2y?HT$NRrwrau{pjPs8V&}*w4~&a%z*UxWtwpL9 z>-3?T(KY6;XivRF=t9M_+Bd*I8`9E(ZToQ@b@0`9pJum4rm!%VItE%xq zlTz2UtDaWdbi`4F(&x+!MMuIKSOgvDqw$4$LUL&^T>lVmH)wYQ8!&O@#KOu#YGIh6 z;bSEEmJy)Q+6YnH+Q6rQ!b>W~!7f5lMw{pE#VIX>Kc5 zi!Q}T4-Wo-UdM;7OYvIJ_%p-8fo*WBk$MR8)19k%R&T(MJhU7(-Kr+> zY4y<1Umw34EEUntTCfcPHqUOy#{EKFSxN%S9I3e zUV7oM7MRKz8>4OfV-D8X24Jr2(*cL8N!q?{$A?;yD&c|ta#gFp@9zIQj*=y1 zt<%`W<_`qYF&DO?%ywmR%T1lHl5JTU7o!G&Mb+`f%u*ddR>(uZ;bA_tA3O?1_{)+d z4eb?=n!V~cyDURC=UlV;a!_>#UvvqqP2`ci0ok4KoTzIBtxkT#K(?*>~QpS0k>06&^hb)!&Jzj-i~v&IKSQatvtrG zrn%KNOUUAEd;40IdD+^@rozEdqDVW(a7CN{?F&h$U#&O0_RyGx*@Ff;lOf>?&Y25g zLms1{fiHO-cb(SnOv!Zj9&Oco$xvEbSM^Q!FQHQ!==ODU3w)R@YmLnw39GYe9AC(J zhIFnzd_Y8grsVNtioCd*%TXRAZ>RhNNp1T3eji=vhk*g#mAwDypE)@@TIZ@GSzZr! z`jy#iU0VB<76p0+BF|#FCeS=_+F&%q8NgD6^!Yh@BsD;CCE+?xdn-njuCKLk&Dw6` zwR?dA0M!}F!_MDr?C7z!cKPfZCc#tdHPTQ!kBr5<6$z32h`ft>{r-HpJvE)~d`Iv> zA1tA?fg~>VFBqoUh`zz}UMr^oy8d-Kmjx`9^iVc;DpH7{j|Vp7ed$7?_Be?>qeRN3 zGV?_m(^5Ona^t4vQrK}vh%j(Srh0nx(QsmFIuIVZghP`0A5Ei+`SrsX2PJnCAf5gw za(XSCTEzgyqqh&!`^Ba&Kn{_m=`ANu*3}dTEP=}5iHxya2e39cf zNj+K0Vd&;U{J9ux@rT76Mi1@kHx*dY07^}QyHE0P-qqG_#S`Z?=&+ESY7a=O#X}O` zgNd`#FFCINJ^;ADd=ct5@`R`T#kErB*Nclgkc~;Pv^t;;*^5x;* zqmFk|{@sj!_vPPh`FBJ9Zv!5*56Gf_-KtBLGNKc=`%Y^IzvhGuaVTu*Jp?C?Bs!dJ@hD0? zKnG0@?0y>LcfSwB7CYwD|KAFuYZa(T@e zT|h>warfhqX4ve^Ye=70X3BGe)4{=xgyywL?eq+DVC#!bgEii-r`t+~^it8Dr`Td> zjP{L6^#$r`ow9k*uM+#uMs5YI5@7lzf_VYZa|H0~njO~R;7985)YVI8r^=h8WwF$` z^I^H&dm=V47?V`&7fcxJrHSey91g@~LH6oHrMb)M#AUq_jk5EO6J-j}wY1N?cB~2N zA`L^r8o!>FznAx1&AT&c2k%x?`~W?!S|4dv!jfjQwKOz?vHg+zq|Gl>7d|+JF2A2M;wsmmXebbme zvo1;omgX@=)r&%5LZX?7fJ0iVMH|HS3^vnIy04m`HIduHF_vNCv?M_eIHBPWI7Ql= z_|P{;d zSF}0WfY*4ww?(Vdv!15_5qU$KE>xT6;IaL74#Niki-sCFl) z#P>uaGHekXG6_p`NI{E5gHA_7u8C&Clro})sGynh-ABq}B`x`fwm;R74%W-!lefPJ zs9%jQe|-jhD**HocVUly(n|4+omv=>iTm&G=lHq<&LG?=G&nD}@aAZ&`F3-Lg-DWt zR6_@0>43+qWTMM*CG**2XWe3lt2}d z)^}Aq5;ZzB0=`B%LXiXueu_lA4HY3Il}S7U^*Y27GhZUYoFqLYl}@|>6-jg!L757O zPhuS!0jo?V-td>`4uagxVU;Pwi%>B|zauD9ikF~Lh+-gsM0ZjW_)uz8Qo{&-l3r1H zbW+U-e3IHwSh#N#;y+PENLWK)VYje*sl;1Rtwamqw=hX1B1}p6MVmt%;kGbHWnjZm z-AQakwL+_5jj?*kLzH2IQN2i9MJ+=oVe_y=DMD0WLs4r{6H&=Y3S~$rL%7L+*rGm+ zKnqbHS|HWC((Vs?=|S>J2{a77k47azxcr9dkF_mEqKE);+s_d$vr*6Con#|~;4Y;| zUWtL{q4!KAepG+^?GB-yauHmio?;OTp`Hp6nxXfxs8z6+wWv&Rm-(n&Sldt}eiXoK z(Px#2{Sa;%AXCVF3#t(Mwl;|$Es#z0Sv&#|%1r_Uq4D2Pg)p|8QI+5>3sIF|FPl;0 z;Vz3&<6&7Cfh;71Slh*@QXx3#q>R8~RM0Zowg?F!>b4&VGQuSUNhcG~S9FyQC?LAZ z0Mr-tQHnT+za$_z!`Mb9vB%!#B(cZbUJ>ypU#t2nX1|$o5M& z66ANc-4NYGJfbYLSvG<$v{^J_B(zyRLN1h>805AizC-QNp^H>N0}@6wkk*b3U!xnL zFM5Ju5{|kOx=0DsAZdiH(T-3MwZ$+AMimp)BL;er%)`}aL~w|fW0@qQ28$xXPBDq+ zpmvCsV}QJN0nn@fe|hZ(SfI%PC_r92DJ_tcgf~=+`X2=bd{`%M%4Z;?RY)%*`PM2k%71=~>;0!7NVY>uruqAtjSJ8&2 zVym7vTPL2r%+oSq<^#Y_(KpkJr(&l*DCKx7Z#VOYlg@BShAK9IA`{Cc%2@|kk~AZ# zNRYYA!?4MoqlyRknyJIn0PGmE6k`MYY;Js)Ast;TrWkp%)N_x9RtSR zlCYGrJ@$+l`fL|U0B*Y{CO}pZGjo_H`Epp6C;37ribr8z4M<0~qt-pL>oWWsV~;&n zl@WlixYT}x3ZOTzpac*D5DnY{l5$e6on-gF_tPXNrKrmCn+e7wj}DWp{;J+aO z$?1ZdR_88W@lu^5hZq1Mr$@4hD;UB@0hAYPl$W>}zRdMKtFGM}tazWK8N5t`{hLn{ zSF|WEVKa12cWCUpyUpG#2Na4-SA&KwUV$@J+yWDI&xtcG{8!`vL&rxRK+Yxog!3a! zyieGS61TwEAtZq4I#XynkI0#K{E#O54>^F!bLV#^;qM!2fE0J^b>@KQfw7_#55X2Y zmd9M~)Mc{`uH|>tm>IE5!kwEBfF~Y;y_?`>1OvlI!Kz(B#k;F|Z|=3RLq^4o-#7Y- z8(Xea06tH%rfVJh->!5@Pn-Y;CtlzomceEQKL~Bl;9eV?vEOXan>fVdKjl?iaDLZSj~=P?2TS4msOqs9nQ;P&Z|s3 zZX~DHfEh2vW6zd`%=rsG-LdGZZT3MIWXGfZ*@2Rj8CgX-&jRoJEQbC17%nfGs@4p{ z;^-MP5Y+wUXH*p17^GI;dIhMw))G#HOUr&}dSK#HP zWts!+TnW{kN@G^`NYy?zxdjgYZY;`W&DIz$A-5k9Gi90J5wI^nqKjH77NZ4~dG!7@ z-HsFd_3%%p;oan2$KgGU?eCaP%5-MV@K?NSo>^c9X*mnqzrT-<6gkQ6?(BZ=rQxwZ z70JqOc7qxuXsU#4;pX9?aB_C6y$0tr=pH6xc%PRbGlm}!xIcR>O+fWt?i>>(+dRqq zDm^lL(>{Oaz1bD80d`J&W_RHb*c8C^(GTL8_u|t9 z?FHTpRHvr=j4$Y)KP%FM0eh%V7qmgZYckD=H{m_S1^%=W=^6Glcs&a#wE^dk#7LigWt{dryLz#veBU2mnd#F}gnScukLlZ1&dz)~jdUkT@`L zB(KJs)YEaqc8E?+Mi>!bD7cI_0+x%vy}PRyJi3f?&a1afHc$f2A@0EL!0$eI;9dE8 z1a`srV4HP9bj~;io+BTuvs>ctX=kdKkykVBokU2R-fwknis8+?y1<`*?~M;GUtnublw3W;*~1smrw z)?wpL)~ste?IZ1@>;>CtTAgmg4!l-3TZcKO8p0REH8qhXH3(9wD4 z(;?r9r)V<9GV-;vFY7O1>IXeX(_u>#gkwwa(edRYpm>O5tBuExOZn)U*|@H6&0ETu zsn$O@s=C^neW?eFr7D?M^Dpg{bujXyJqz(H;*nU7xU)N#GN8EZZy)G@Z=?8?Lb|V$ zSkwwNH2rhuWoUttjy~JaYbSz=t7>ZdwdkqoOsFk6E`qNq_giy0=+fS;LOYiRhI~6b zm$_M&Y=i#gBNr&KSS*04(_^M{UryFErZ~w1MWnPwf@n0W6gi+u`4Te!qBcf)+RaqC z*-cLltFgcSbi`y@y{2685%*B*ld2&m*;LU;t0cwY@mfKmUK90?+2xw=;Y>oF358=; zu|;m~zc4-4(>MWb9GvoQya*FbB9udFd=Th%eizz7 z7oP-Bbej;v(}VK{h6=-gp!N@Y5O&@CxtNw<>4B6+jFYhJA8v&Sm|=>cNQIF;BfZ=0 zY=OAKn4jU)KI{tPeun@4;a9h7E-W=9e1H!z3M|A-fF3c-Ahf73RstL(h-Lq94@Q)L zTnJVYfGrJ{_z#_38XP}>pc+i08~nfM?3lUbSwH}I0vH^z>1WYQcCbva&JThxf)IjG zf?%(3&k*-~7hIcF-G%}2f$;%C5JcdBKv3rtco*OisQM3>-4Ep%`-1PUDJ7b^b-OdV z@w$(@ZMs3^L4amJN?=L=cAy~y(}ynbY#2W{ewa*1Kd@)~d)y293)M~BO{(shZn({X z?)U&A@PWX;x}Jc6z<~g%K&b$yO`Hp6M+|Q87_h(l8!!}bln-|h;ekXSHek*m&Y;e~ z&Y;i0J3(E{J+dQ}Ba9=TBc3DOh25rZH_0Z}W=8i|w?cPpH&XX)H&?)MfK6Z(1Wce! zKouBS_guGncXBso_pWKRyH+dWk;>)=M>uB06BtJ5KVaU0(E$S8q22aI*wyHZV74%g zV7h?}-R4H<)gKo>AcA3kI1Y5{)-gh={-gzk2o51EGzoJ9P8WzNj8cuS1x*jt3NrcO zs&OK~qXQI;NdEqyuLCr4p)8@(16qX1CO^zVxS3uEttz|$HVp3kACX?eH;D39YD;2q zJG3W;G4F?y_S{7&?YZv|J{M+{Q>_d#zv_!1C*lpN?zl}WF^2MrpON1soG0NtkbM2o z?rcy3(%FHbrAWYHZpm4o$l#7e5`gLqtY3Z4#l&8CFz+TOHmzRK@4l!Rg~~p)UNNTZ zRD5DMeFyvVieV93QjYPEI{J($57LOHsP1C2;QXrK_SnZjU7;ab$4!pn+~keaHG{ zQ8T!~rJeI}ib>bdc9(=b zm50&jBpMgV9`a9n$_?`Pq@09;9g!>4uc=GU9~yVDKDuj<(Rbi-E=F@2dW{pf*qo); z&i|^0w!4$gUu!e&g4qAQm{v{JuwFDMQ^A&a0HZU~DIQY|bhE@=uvn3?6JK#W{d$T) z@e0sdHn9fi8Z#N=TGwTKysPk!6yO?Yc{F#%GvD;Mkg1TJ^T=yy4L)@F?T|Cz#vzE3vEM46w`XdzboTYNs3Jq6vx zIf!Pb4dounO3INxOMe!h64#K6t`2M`>TnIw3r>oRwP0d+h%k8IOB9cje-*32&ve=2 zm|KoKSA6BEy@?uWa#(3KyZ#xA7sja7Wq+DJR|fs0S$Uw{X=~-7>8iXB`q~%N^~zpD zBRkiaoo#VdhALi3Nw$E^UQFq5)KzV7&~tm{XAN`azI~ZmZ3fC<1HfFdx-8V6{jW$p z{RaN@vv{guK?({F?D!{Q;u}04J6MGBKTS-aU(Y!EO7k*VK=Nq%(^!P;$H?z~FMriG z)$q&iA~}f9Do1%7C@Lb*pM*IMUVB}%`ni&-5vJ80B1{~B_6j|*?By?ibjt+<9W4`B z9aKzABuOGYwi>O``uY*#&fyUweXhye+*76j=$MF(TcxtlqE|#3aQ+;$KER7<@Nngr z^@a$v$C5hI(r0ngm+w2es*2vq9$I)V_&Oj}iQAO;x?b(X%)QvuPWSUbEbpU4-{4>} zi!S#Myz=ENG>iHVjsv0xzMe4{CI5gnL8_lj9}C87 zU$Z8~mw_~FzX}EO;LeadBK|;u-xzdq5|X^Y0>k)PJr|W8JDkvH5IqKV4APzT3b_l| z&9n;TG0%~DYms`w)`92a4cUv1T|z=A0waEPCd2fFPar_g;jLR|*tbkF=+=_NRtC%M z7wIkPx6Tk2JjrPIZ(UW`v074NlT(;_vZFn0^}R+6|^n!)?X@Ugt}T!*Az%5tv#P%as)8=ut~|`J|#-k0ApIu2Tl_d%Vk! znQRDf^Qq}DR`KI$yXT4R;--D-XgtNdRfLcj+HMNeh>}ySlnx()GhUv#ns#=Py6u4V zs&|Dzh2rsb^saHu^-mKD4%7=9)upeQc>Gl=kc&u^)=zhLG^)DfF@d_1(`UB%c7qd1 zc`wrQ{igLv5>o~@_g@OvHZb)tPmoOzC6?PP_dzWCtKBK$^l$a~l}P2&Dn^|gi8F9^MB zJzD#=F~b;5bp@ zAo<$N^IX!%7Wdc0&VMQD6wOPxd`_0%i-9gG6oo&oagB8C1&Ica?)eA;bNfEnfSSz{$MS#qp*jVrpf= zWUNwvAFrvej>uWfzso0jV7TQ&MfB4hD(eHEV9O$<1Za`SsABOXPa|zv^OnX-U{iLG z;)Bo_A{b9Uv7yaQ2!8v5{1S+8S^f*BPjqIJsPMOg!`{(4SzWvkCh9;z3uP*(1bofKOVU@1 zpdVu)u%4u_7LJqD2pi|Z_|&b{7ht*@{xJf{W1zL~CSU*ffZ*X}9>)rPJfcLbT~R&4 zpt#x_NJ#&a4O{!mV>unop`$}#UG#wGN8qpO{7EdUnC9z1;zVe#mulXAX{tR|L;4$6 zd{T2vpH9~LD3Nmoa*zpty_&TmOZgrS-*iTH1;Dl7fkZ} zl*b5gOPKxtD0{~!&)t4sv&**CW!tXmvR(Bn+qUg4+qP}nc9*+s+f)DN+57B0`^=g- z^CBzBovf^6<&&)7zOJwI6yx0k`Zb3DQ~q+H+K+& zfTVne(|MCQ3XKt{pA~tu?ERN^PP4wxR z1s~4k!F(~%#$sPxzjZ0gbOQ|-Y^Gl+tPFT|R-G?6$G|vNSV>335NZZI^T>nwWTpyw z1qHqLP|pw@=5!kl+;_%(HRC~4#Y}U?=_-5%SrV?KEJ05H2-%72SdSo9WWjLaHhxd( z0f2gagpM&!pH@5#g}!+N6LqtgXR-I?zmWtVzm(8Y;eOG-np#oj=DhOd<+hqH@^1r(+ELeaS5e8qF-{ivpR@-8T)&@-YAm=-*) zB0{_nOJ$|e3;Y;AaVRR#JR!e0@b4Z4R@w1u3q$Pc7lK+eS-&nda2)%?MM(Hqr%qE@ zqOn2Y4Y$k1y(8&tiN=HMoh$h^U-&8^#&duW=?D>$>b_Z?l=Y zuc4bC)v{#GlsdgoX~52^acoREUd%4;t!MU?F);RXSo3oQ)2|-Z-G>ro@a%s_URuy= zhR=x5i>$bk;}ubO0L6TzwX88xFJcxf5H}_zhm)G7+0;CD%jTXcJLYBAQ?6ScBd<4( z&E@^^t~y?(TwC|#MXAwnd1mU@f8^5yz3s&HEAkGA+w;kdh89IjEacr0OTDYni)?H02j^XafkyW6F}v z)f79ghZKhbm@Qs*^`>@_RXoB;#|i;sWj{SXD`_l`>MPa3%&~(-tK`jDInf-MG(xeN zbQb>1XI8Ux04(JkITx(bnQJO0b3R0jKRabP?_Z*zA0`i2)510HHPp)hF(sbyB~!30 z^vxWVl7Ryjj^?Z`8H^=9FKN`7WsT9wB?&9e#c;fv>@RWirIMisX-gxDW0Tj<`(=z3 zi{PJTll{+uj3|2ub+q|6CBv|P$q$etv0{{e+oQ(c?ncWV7|ydOiiQ^kC~O)y4Mdbs z7WTXT$!mN#KwkXv0h=K#d&9kSx8jUSzkmjV5!NH+gK#P(ByCF;rx{wQ^)O)BT zVQz7vY{*+ntEFseW~Rh*IcQeFHcn!rtiR1ajPUib);yZ(S<`LvF)vW9P^4%AuWEDa zO9qQTfCnVPX|+^ZYl@YL6sS^1tMj@zD%v!=&S~RsKW5SY)VREtyGzHTd@NKBrR!km z*a^qK>^ctnXv*u4T?^Tv+p`Lys2MVA+N%k$&D&#%2cX2_{`|KRT%tB{0G^qXr#5bn zu?^FaBv_M$RA1rSocRgSM3Jh_a=^G6@^TOtY3~^7ss$ZYjvkl3z^a7q6^G;Cp%CM` z2+NEe1DnRJ%wp;VsjlCQ%_d(K28@-*r1{Bk_G`pAe#l%K~u!l=W%uz!e(2W z4dq$4Qj0S#?dE+T^-t{0x4_sigJs{?Pgw4IH>Jydk6@_z*Rz6obm04qEmme6dXd%@Vq|jEyZwv&+Ri~$zpK}owA68Oq4PvANP-8wZf9(kQt;)Q!B6d zQQ0!73{>$)BNB7xX+Lhx*g}~(Y*wnI;Zl`uGSnU^XUs0Hh|WpThNcz|$0jQ(DhCYo zQy89~Y%GketFc4RChu1vbQk;glP97D+0$UWSuh^dOs5Z+e?7P`?i)owbx|dYrzU8w z7~D3B1!wMoo9IghFq*{FaV#y)FR3)4)?N+r>xP<<8Gl%jHkYpklae+gbAb^_d^N+T z3M)Hgn+L?J3uM_hqc%eINRvZ4Pui3T2TT;tm%&>mc#U292~o=>Qov3(l9+nL3uLEK znu2*xW^7g<^!jDjje6D%{EUP zPQ<;!kV1Vbl#^mR#x<9{@7ow#2nSN}W0B%)MEFVAlu#0_Ryp6P!6m9EG+aw%n2Iv_ zE^^VDi2;QnhAT1Ox%*qjVuEIxhRuVwu`&gF+fszG22G^15u!6@R|@CYpOGHNc4QY?0$TYFFO zvK0FA(+SSx%p51HZpSX>p%D$`S>*KPCD&L<9rReangTPWeou&v_kE>~5MW7H_4o&| zLREx1MAvWvsERAIG@Wj!6C}wv>}Fc^FR(Mw`+9 zyyB`-ih8Hr=5P~?lu7m5aQ=0CvpRf}BA^rwTS(t~Ci3=iK5=*Y0cXWESsa7r?e$mP zM9$9Gtv==h~%*u)Ed2F<5>Me1Rf-(*pZMIpLa-91#(=FR8H_=@gK}1z4LQn7Fye5;^N(Pou^#5>F%NB4(!`9KHV(l2{clEAHAm-v=SxB5B zqt!6zx)xmHqp(BkmbON^_oGBBXFT4mmw-F>EGM7ZUGsvirA52&f%LFPS?v_0T@S@@ za=C#GH}-u^?_e=qGuVHp@BEXugl}Xf5LXNM1iHk*< z)&@utcs&x9XHoJ{@|nsq08p`#eGIZ1ubTp_%VJ$lr?890Gk5!^^*BxJqjpUTL1R|G z^tu;q)AllyIK=d4+oYmW1B;v_ljp1+j7W?mKEI(Zxq84C5wu{nihshZ3l0?LK5Thq&;hLjURD_*+?l1 zJ0RNAvzzN!oke2)NM%CS9G6K}Rt~8wL;!ko(qV1N7C-J0tLOt&jzN<@ESS<tVRX68LAms#_`eN_v{HBu(?RuYmQ)T)^=;gFcd3-35R)mkG@HtsXv|7n|JjYW&E+ z5gJrBOP(C_y%o7HCeuA^CBe6Eq}a-lHEo_=WZ|{dQj9rWJNDs_W*^kQ7eIIlBWKV& zX(ltcC;c-2t@<~Y6&J^$QChW=UznOxl6r1Vqn6WVFT=2z`}1kt(BxGQ-0Sb^R9!!P z1lKxx7yfz%V=G+h1RFFsRQKE$d|tlidaDb<`7-!Ok3 z7cuOj^|_dxwwwqXv$|7f`UcGDZ-_wG)<~U+1#f|8j``A6ds_9pEDR}!6w?rQRgp%C z)v4mtsXF)26J9N(;uNGhx1;-j*{vZaPT1nE-+$wuwr3bANb|D|X2jTA_zIE*yS%e9S#Um-eeUHPtbZvfL(>8dv>{SWDaLXqED6QWL9TnF0>qP}0>-Zg3HbPlev#G~hlZBiMvu#Fz zuPyNpf0c%dh124JcHY`c!sl;EKWW!UC3jVAXR()3TmMd|H=d8$(hlVQoC;rz27638 zZ;U%;WSU&ea_ANG#J&C{g+qu`Qdl0m32}O`0_>!AWc(U8;;5&IntPTaUv*-(s-&c` z#STs$`iy7S;grd0r6+w7+);LrtG=hR$@?z*fR~w4jvpE%UTof^r->PP1+nt;uzcyz zxx4M})T(FMw*Jg=Pg_XmIS9UXZBxGBi#1XnU5II{zCUF-50p+B$=cJef(0CjSzct> zTdi%xOn9>$qovxO#8k#paYd?#(-aSzctF;yn+>rR4g-3+O{ecdtTJ51WM{PvzNHue_EL~y;T9)$=C3$)@G426U-N>l+i=i zE9bGCvg4z%KCm^zi5I?x-rOPq^QPv(3ppp^b>4z3A_>or665&*arXn-n3zYU=uT^*8wofYAk{S9hQEBuJ7F&N+ zb4tZTGZv@Dc^R5bq*Q`iDHffYViH}6H$ug5f2sCk()M=%>REa+8lztWjR>}g@r32@ zw34i;ZPD(gy3E46qfV8T`eV5-kZ0j=h<{aBiEeQ>h_}20QzQrkJ6ny@n}tx}gArzr z{*8bqS;ms3mAm!mv6D+Sc7D=~Vkft7MNQ`2sl0K7?`nlmtMD#XBRHBqk(#fdHY^V; z-jYB{M2>z?{gT~0T?@B%AMtazx<42yx%hp8OU?uyg^R?y6I9!Y?1}>R_%vGqA`E4< ziy9qNG5QniObzDs+Gf+i)rz%_n!HCJuO=Jr=}ZH7@mmQ7y6Fp(REjPWy=%2x{hAdD zN`*)GA$q$iZN`@J@uk-4O*Q{YL5G#;S-C}xf#)~qR%rKmIo-*U(nY|lMsRk}dw!X= zlu@wIK(txpe>xt&zwhqe;3=fe>$vtvGrnRDf`U)4yH{g1eWG(wVaC;9AR1LEGd(k9 zzr0+8rm~Rc1o_s_t)eN;*cKHXMa)_>&mv|}?Dv8ipr`a(bhhmPGleg#bpg%^iBZ1C zB=_fZZ)S#n@reYe1gM-6pfYCUR+9-Q;iygoC}ASnM}~*#j$FK%C{jjhx+Km14|`IU zEd8nHv^J=f)pq`J=B5(aPqs|9?gl5S%f+>i#W_n}uqlxx&od+=gx}bcG}ydP?T1Ae zQ!peEX~ddqfJIXmkr^+U!BQ&5JBEtLHD+Hk>+G)AQ$CMzC(dbjF6CejZpc{AvZm-I zPz+FZFf=*~hE$-*^TB?2bdv>8eYO%c9-0FWSn`pw!Lh0^emR4p-bn%fw$&_#g8>g+ z&^t)qWHoP+)wM~h=i3uI0|lANvdMxNvIS|eP&c~NOLCwO=HdeYkk^Lz5+=Lsd>^g9W1`GCZg3Q0E6_4oyJJB~ zyxtaB02|(%CXTuga#ilx9A-qncFy+7q|)xjzV4;t>EpBuS`YQoom$d*k<;NxrwcXR z^z^$R;59b$A}=QcLo(_p(%dD~%4#5iF=VLEih69=!=oK$Gb3APaz^Gj_9&FxYV@ow zAJ?)(?)75nPgs3OP6P4BZx6|!RYbkW-PM>KTg>n}zki!Y!mR?`$I74*sLu~qk-E5J=Y z*3jVL#mcr+odkPG2@mvQ@NX%=&^j26&gbU`+i?svS07nVAZO6|9QsUiLl0>(H}lpy zFKpsWR5Wk)z-is&ws?F596CP$*-pKJ$()^i%;U51If$HPM#NZweM?^1@Q-V#wB2*7 z4u0vXoP>icdW4eMD0hOM$q+Y;Q8aBS;KD+T-L6p4_<`b}3I1{a%_rEL0jR(`s_kkwV;x5>hWvAxx)%w+cwp82{aUaTg_@EM<} z(?RB{qbcU|H5#7@kwqFo{At0Xw{%rjaak=Mx3&55T;y1VRn!+|QP)egJ(LNcVCbOF z1Z16Mx~>XwW7A<}9*kCH@ZHdQAz9eb=j_~e)!IO{1*|=e9x_oHNu;7q(m)*+7X?%g zqg!Zjhv^ZLEpnn*7{&ufn2I>J(u7=5s;N=DTsHZP2HjHWBv^S4~gwJ169FdW7d5%1?DE>IFe&&tpYb~aWdW=Lc z47t1NuLt?Cgo)2IJ{-VKeSfvSX5H01#RkS7?UR*_)zT_^;|_av6L>tx=p@HMqeD(m z#$Yesng9eXwvjz4b5D`=(>D%j@vGBz(snH#Erkx9zIGjs8jhVavl{}}%SP9j1q*1iQ>zhf9}svHDU

HXut^t`Np}ikJ7EsI zQ^9(oFV~+$6Rr!J^yq{{1vu9%@{@e!{usS*xoo`=jndb9#M^dan}riX*Mt!C-w1i2 zp1&mPvQZ=AxUC2pVzPT;BARq1&79;ZrpiS>SYUO$|eX_PQ<)( ziadNx({HuyIQ1uPQ^k9%nlPG14S4Eo+HW_9Hw&RJlTV~tz^Uqp?@*2d%CjGoQv^hO zyGZjTNLj=^oa?!gHp9u1&W~ylTtN2atgL=%3%`$%!6q9A+d|bFC)?iW?2}oWXj|%( zl5WGxATteC7cwtdGTJXpnsY7VpZokeYRgJr^T9JscFKmUGuA{e!l!eZ4o`hJh0YVF z->v(`+bgR}JB0>k;{a?gX{StTbpq+KVr#^1bIv?WI0LXVJc^n&Malx46~Cat3S)Jl zUkc^hQ6&@Vm5OkS5-Va&CKFAjV@(dF8g5A{@aY9_blGZ0aK|~UM1t^H)pkPFS&Sdo zdIbw;o2F>+c?l}&=xS~1FI%XpkUA>HH0Cpxc=p>lX*GVX&^=c$V_2kUq|6XFV&e?KLKTft=_`#Mv~f?bc# z?;O^!Oed62B$kKyQb}KCI&C)^73@N(`-tmHj>$Y36SLfuNrp`|aI+3nt8`NB@uRJ* z&b9D$0DMG}b&{Q2>($tZdJAuQ=u1dEv zQ*vd!i)BH5LL=Ck@(__&K41bZkZtwnjCV)bA{5ObA+onBg*^-BYGANNk zZ>wq%C-Rw8jL*3C(mTY$GVJwV?F4T)$&}jm%vj)Uj2-#K59g-v%H~}B7h^=8{F!63 zHygz_GuxN&T|qb$*>zV_1irJl0t<$2a>z$_pa)z*%khvz2Xz(+13qVP6_uX^mR}~N ziUBGI&)2QgSva6Eq(G=tQ05GAJE%8pCo$|MD|S#S%}=HPa95`sm*h6tzan(~cm?0| zb7XdcRWwi|>WWAFaOPNnU@Ppj&|I=$(=e1=zNdusO!>hHXkJa}x(Omf_9i3aUQ(%j z{jd&uNscm+<8nyi{AlIWit-r6>j~Bt5|{($9qSB5$)*ieHpOA#I5I|lucPdSI6lH= zQyb9vnsJmr>=ZTef{_O)2#&TG)Z2VOR9-CN8=R zjzfLfz$+WnY*~p?jp%{p!QJx9Y75#DCpIk-^YlGFuD%=_Y{bOG4u8Gt>W$Ix_#iqK^OQ82=aQ$nrh+52pA%K(nxa zqmJK}$8S`TfR&NuAN=v(c;ff;e@e>x`rbv;ePiWe8kvfBeIX}k4 zWI=TA*+%@o;(K~#Mg<%Z@7^;M-oG#)9C(=HZFvqp4)syq#u97HuQk)8S4Lv@IWprh z8WOzmBh-xruS#quX5RDgBI0*0UO2||Q9Ak-o%N+(hDYrsO&y&vLb9~Z8d6Y69_($a z`7T>t#vWOsa~xthuryhspyus2l(_j?AQ+8*cCCV*emHgOpVsVs@PzL~rKW1@j3Ed_ z8=jFi+0%}ua*C$k!G^MjP8C-a+qB^VO>0LNfoyz~}I>iNZ%4`4C zx0a-&o!_hAxP%7HGNWv(kjtsMLNSZmxR(FRvHDWJwt4)?1696a3g}xf`Jy9$HgTcM z?E|c$GUA(OS3~Atq*8jS5M2qaBC|hQo|{Caj>f{CuyoKlAzNXj!Xdf68mB@i*qu^& z8Lzs>T~EbwlrVNm=PvTSFtuph^zDW370h|ThkYPN(SY)n>(G0S_qgEQ=A0wa}=m? z<9As9g*N`*WsP z-`YVXrG#`fDQJVc(KoVIKx;pyH;7lK`z^b#ynC*mJnKcjJf|~PrzbNVO-QbA*7*e+ zjWX>D-ONUMZHRh+4}MsN&~1_vS+@lv23t>DR&mF=@csJD=V*B!PAd+PO+Kj0%f-YH z$?}3(>wt z*o1d6WpDk>GN}30%9C9UcFGhawRh6=>q6{LD3Ryh$%G##x?By&pTJrieN~>WpQ+qP zE_(hH{iHXI2eB=9`kFjdP^EKj8qB?bAX-Rb$N@+pH9bTaSb}@Qts%&ay|OC#39_Il zNDM-&U%v^0kd}!ng&+y<2`fd81&&3J1=UdGto=g(#7)q7D0v`xc>1LM&_QfLfS}~o z54?e1;`Van3^+*GyV)wgmWUS#X@p8ejzvoQxGIp!YwIP0po1JL8({NL zCz1$IiBSnriBR>7U(|ShAKWs~V-P|R;*d5V0;>_A^u-)7$%nM#x?xq#}2-|D!#n0 z*fUPQF4AWJk+0}83X>_~mY5sDP7K8@M9|l-XWqlEh->)%E5t3)xNV|$@HAV(ckCUR zAoks9=h;48!gr=iErdmS#8135ela(^G;$=LkZbIIIfZ?4@viX27$hBm!wE=oM4zB* zp&l1g z{eh6W0?$nSAdpYQ8yGDJ{kc6scD5UQpo zLU=Cx#~)Fo6*ROSZ+$(40lP(2@Jth_dC+~Lsw3UFkJHu@gCA%Ce!0T(xg;_1xJ>HbQ5V0H_xWj&36dFn&sZ2k;0@WiFgr-; z_DNp&6?6|&=!*%_z8CvcGpv85OYng;pF=S9EDn#LGhOi6%grqPB=!&&BNAMM@ zP}TpF@h^3(PKXomdmL zqxg2fJ!YX8AusR=WTCC#Yse$^)k>492mZ3o&Ik5i)h1O>{P~~Pe30)ozh0RNAqX}R zPWZ%i1Dxm!=>^-xH2-$t%ww=1c=Ff0lt0n+4#ZvtIYG|jr7K(=v8=fBSG?puxlE;W zwwPZ&Z9%_l5^VN@b*?xrZOJh&ZJi13<;me;A!y@pA+{fm`o}*0DB%6eIqUwn97GKM z{npP&!J-;o8>{_vG%1f-FeR9d-$DJD@{!pH#~IL68|lY_$@8@ zL;A)ig!E13ZRjJ@M%Rp{@o7};ccgPnRLs!uvvFNr%di^Luvzh84nNnSge^#7_0NTj zwZ|ZrU>E#Vw6!*4F*9x_JI#mX+2gpXJlds!yg1^4yu8!C*XDRNsBA08Cg~j;lXOo_ zm+PCEa}VJWNm^|$)}lw$)4JSW=lfOh%q_K19MbS}eXA#ba4X)9|3q_PYa&Wf?bmtW zeO9s+WHGLFximk_xEzZ1GZKA&7Xs}q%bjE#zO>%U213sah8pm4sjp$jJkLZvTyYsz z-ozM6%`o)Wd8K@?`b}vY9XA^i(Vqb8sA&|hpYdkUJe>_EzHN6_l>lEHR>z zHgwD=q@}RocHDP}==08a0?)hg7I=YMJcMk>nZFL8al6`tVEF*~kv^L#=aYvys@;j9 zxtup%qYVpz4#N|_{8A&-6HG*|&jX5Vz>A&j+g*cfQL)({h@FUO>sSY`!{(C3+a)RwZYxb!`61GBme3op- zCu8IH()yFnHfX&mW6bo&$x&J-a~YIF>;~|iJ5E~`Ne)I%vct)p>6pHF4zX)*914J33(9@%kQ^6Mlw1RyUz#^lJ2K%r};wL7@1%f6}Mur+^O7g)LB(Qr1;6e@oxd zGFX%@czaiTu1O7$Hr>)9=p^J}UPw(sQ;0?;L5jbuZNO@)jYJxhd-pNTTze@XK|^}nczCq$#q3UU;gbB}U^R8Eg{vZ7QDK8bEHryC^S z2~VaB>5FbCp6mkq7}6~y&(0B1mX}8&k7zeovtB$dX-oq7Xo8W2KOgv_fe$W8H0@|+ z&KIh?h7QMX6!bvuY?T1q)CIF!}p zb=#<0%Q&kTizw&|_{ahX7IJo+S0~8|bSe}oK#RV=k%#QJysp0vsR4W=XKrh>)PI?O z{a^r3W_UFus$H8-3=3=A_+gYqNa??y+(1H_n21h-m7pee3Vk~S=)vTk+r`+y+(ZdE z($suMVq_!cuSw2%p-Gzs*|`&ds#{`RBN|TisbgJsIXM=#^pz6eV=h}_dCL%E0edl0 zEC?2(T&c37BhJH zOkP%-MZi1L>X`k3q68}KW4{Xmob@!*iO{9fk0oxG2($nZWHL`kS4ueyOOgY159a~7 zclTnZ3ok2Sg!uc9n;fQj9IVH#Fcq|@fffIhJ73y&ZI#R$qiMk#AAYmurR}vGH(jpN z@F;|Euos4gTW-WXkXZWR*2>SmJcV!&Vw6vGOv2;%`(Q&w7#?vDDC1^XbPWIZU;MBJ zI4VMN9Dx08yoQ$y`So5uN#Lq=j{ygy{pMk-DaLvJL<%%&i{ScNVGZ)*!CCnE_IKW$ zy+W(csxgN-$HvIS1jq}q$vN1B_$4l+pIgXxkDej=-Zn@BKXs+U{a%Sauf>C=K zykXJ~pod+OofI)c@KAuM7$-eiA+u=pep_Gf*p>&vDoKZtWX% zh|iWVp8^HIu+#+g`^h)D7mYwfX!?AxYv2C;k&DB)B$(rN9Ar=@_h*{i1+K_E)M02j zE}0aMr$CWlAD+yD+m~OxJR*oG7lw)}i~0l;`c~Zyolq0aP(PC?VmeAOK7%~RygT0II&wmFCNo3A#F7T^@y%~3G@w2a=LeBIYjD_ra9Z4@Df}NPMyk+Fk zq|(VgCZ~84kR2VbLayymyf)n(b-(4g5_LV4Oy75#ojoGL_(@~R6sEG@;!qk38U)Jq zoky+0qpg_}6R>GN(+z%43K9NgG%^bp$(BgYn2g7X|64JYNBPsS&?AX& z5!ykT<%kkEI%qTv>4gC)=(E|~pQpJs#ad`WeL1hn+N9E!W%V%71>hiYmOH|_aZ!gjVn9pL& zJw3hplHOz4`?o&Cfo$jjXA#iko-i9*HUinHnWtcHavo+R{PUNnShgU;Qvwbykz9~{ z!0aNzIa=LK9?%*BGO(tojNF?%D4S=!AfkCpSsu7^K6tEI!o=(ccyNebRbN2jL<|TL zPRt;Yz?zvG&P5zWx`9zq4_onMKNp&MV_yDf(2%aAE8Xv57XJ*2(mdNj_DEcW*jY?B zR4yU`2wwbKp=J3VNR3d|c^FTutl*Gpp}&!SQ%4P=`-L|oOi*~}7_+CWjLwA0khZUt zv_a52w8FnAovxXjl>~pRu?;oO7F3d!OQZg{_yyp;fa$aim{yv*nzisK9@Y3d(0em4 zIVc7ljXnXn0QtLF+lkKcd1|CzDutFyqcOtb0QL=o9^*;(FTM|aQkRBFbwl5NEWXV> zi1Cc*7sQVau15Y5=?m~$TGi^B%uba*nbH06P&7|ZPz46gB)o}Dplx^Sapx*sZ%Kd< z8)u(CfN&WJHw#J#4}mj64lh=U>eQ^+Z15?E96*I0R2rB}ox?y|a06LHpj+(c_atm} zmbQNkyb8W*jR+17O*nQ%lZtF{)8c8Mpq3Cz8!_94NG_bvvn>$b44`<-bS-#GWJ}e+u>DeI}qS;b%GC!#`CWhT7{|X=-;pGY* z=2!qlv(h8d2e*9Ru|~&Exdb#$l1SGYbX$+`}Nkd+UnemzS#i&^IfE4 z+9mEtDNsjVasCjpclq_=PXe=k9{n^#OS0Z)8{nQkQ@E-#2yzkcI10H3KM0ChOYR~f zc_ip^5M@LR{)?&Tzx!l_wWE0*49(QP`>EOh$E$00mE7v$TN26^aty;<6@(}r*oMmi zG9VvHFks_KplbqM$TYkNw6w!&c9k5w4lgbmsFA?3nCKwU=e+wdY9 zUsoP$2Se0j_lIgBp)5lXS3Gb$@P1hs4qcS?ApDaAdOi`jL14Ve^8s3SHklkV@}1|S zJzf71Wo5YiP$d%`uDnXcmJ)x7deKXHv)EhtWvox&=T%5bBzwA~G<|B*p=Vw#u+8M7 zLyzA&DZGXT**5Y;%qAi%zs_F@yVBES%T%o6`d(O}7U4s5vrPREQkWU=@~FB8dg>j5mGxaTXFOs=1_y$QIzrogt}VD z`jdPOnO5Kc#6(G7Q9?}>6?Jt0V67LBh*AFu3sP7aehc1Q?oUlEV~Rx;9?ygkM49q7 zG=gET-5~i$WqUTwnpU}DSbKsRS$fT-@}M0ID5xPK7o)m`#wM+hr&MWcqQ#=kuv9wy zc?4ROi-Z@A8W@1#MAdZM+z$7ymC=8_vyB=Olm2on=ITItpt%B|>dsZD>r{M+9Kljs zK6Hc-shG2v$3g{!icqT2u2sH9uLe??hAYjQfo4e*xU}I?HHnrnPXPj{b}-D|rE;Ay z#>hfTyK@W>YFA?IVnetIIf@aRB^5hFYR1f%%6HEAL^jqyLN_N1;@j!TA;&d&7sQh$ zP`z6k&zrDjujjsWY704bIl+kl8mo1sO=7gF7{RCU)(|*52&aV&`pgs`d|Y6F*>Z$M zs#(hGz%3lNPf{rtA)_yCrJVG)s4a6vsx7qed91sg6FGWcBKG$*-jQznp4&Xj{v}GS z&09^|u9xyT759KK!@Zh`M>d_$WB=$1Vq^S_l&B52BMg1-nyjzbf~V}&{rxtNSXhe= zAuwM)g&OjF>~=bJuQYhZ&_6PdM;BUt4ePv!z$UzO#*c1-%FN2F$>~JEE4Y2>*iuul zN-Ww+Mz1#NWhcEd3k$hrdx*H7x{E@r9Ofx+xnc9NzZTLQ))m?=L|7GR(dU{2OC`6i z_PmPVJEnf+z-D$fE7ZYX%0&u-!5GnTPx90(^oJJ?-cl4anYM27MZ|wZ$e$Z&!dZNJ z7fogD&dyY^;HbEmhRg83MN5)Xpw=qCjMR4l7Keu9)y!xKusdXE zX3eB`FTkYjfedN%8npxjtmELj&#A5`X=XLUh6&M+&zs+gbgTLjz{XjFQA__0i$*jI zYb}qWCV`ct&Cg@IB2joQkU7>4s~ClV8JUbv8efMXv_CA+wThPS`Vw{vPmKBa#e+x` zy<%A)*4J}>1!VWB$#?v1OlAxd6Sz?V7~ZvM=Zo}xhGbnR9vtkOFw_h%*H1yagtWBs zgy=J-n(XEPYGsD+e+itX&KU!)ZGf8St~L3&tY&eX^)R|?dp-Xo+o+r=IVkc++aY+? z^MW_APQkyWRXg!P91g?u5PP3)toHHNpj2^EIkUa5R&pxAK7HFwR4SB1&M8BDwHzKX zldEqAZ~5ZX)*>fJGz0cXjs&5{&(uY5;#lT{nPuCuN;jsFWpWy_F`B3~%|e;8P{teT z8|vf9h(@$mJx?|ZZe%KlPaL^LDtbR9R8BMKwX@XQx@EocbsUynyXz17&;s#{^W!`l z47RKDRQlS0%SA0bUx+!e0wh(}wtC754UnE!7Yy7rk4_7JHvEbqE%bli(ckCw*^MMlF!&4DXh5x9nQ z9TaTEraJ21ognpvD>QYhzN($#tiqyB#SuIlmz7SG4%RFU_EzU|MF-d$wd3|i_y33} z=ZLbmxY96tiWbrI=yHH4nC%;q01XZAf(1W- zC;I@J{266>-t1&-z{Uxw?`Bbgd=niX!t(2GW3y6l_E=@@{I$FMH41L)d^o$iDQeX^ z$HTz&qq%zxRhH81!9wXKysx-9D~nSdj<;(QZWYc@7mH438(^Vu6XVxnr|C>-PU$~< zspq3)Y;P`ez3e8 zbyw{X(`dG%sj?zU(zvmbrV86CiYG?Z;yDXPSOWRDH2HBir*3yAv$9T`kuqIdY1i;y zCq?}Tn+5U_KORt0cpv(QER(5?tR8)1SIU46FUw21zz~pbg#qoFmFp|Y3%VGYuQ_j+ zZiiU|G z!sosd?A7(8bYoxBPhklzwUdo=QsUwV+SdjvIw>7ci6fO$I|{I7U529l!U%Ud+B=ew z)Q>Hv9vMCUnc4|74>5wx40HL@`6h6*k+MjQPs$3Z5l5=P!-AuigW710;J&?FmqrMe z6Wdn&SeoB&y1jL}6Vdd8xnfJ^<@c0_nj^iH^nnaVb>v};5p@pgq)Jxp`;EvC_2-Q= zq(_!B+*$Jq?vhNEhX7KL+F>kgVg?cBn!ZObL-0lr?#AK}QIKdD3W~F_E{fE6SFZGV z{ZbyZBpmnfp=fX%^Fc|?d@8AItl6KtE)E|c`dC`3Z<88w-+ffEe!d>#>CZaxn!S#M^A`HC z#O35vn2+VNmK1r4_^LR|SjdzY4O;%Y*I?7 zWw8V}UE3k%w)0ac=j%9kax(7_+$^JD=`8h<=eOql z{TfOPB1cUBBAl!uVn|!=Y9|-)J~}}T$>0Ip%IFdK*XNw#q;>!AE8JcYIvY1ReUd3l zGI~sU_g1N~Ogfm&NR^<1(&&p;cI1&T+|u zv|P(A?>>xvzyF^8S>4rh4fTNvNoX7+f}M+zlq6)l2p`6 zikdIuvlOuNfPz-Xw>~>N6`?k7n1Z@6n-mPe{kDW!I4VI}()_YA?-R1;_L>I970s=+ zt(~fm^CNhjd7}rk_B2ibIXO}feV1Biel<+@#Y#m*r+u}O+MBgT=*g1OTOY^IK94+x zh~vCVRL*xAyOv$n{XvsHH?h)LHR*QMEZ@I#UbVm-@1$KNrU`|)`LbIet> zy5oGSulpklYy0?8jjywPywiBSije;eUdwR*1)FDJy$ZfUr$jLY(hnYz|}1 z<*bJ;yj-WilN&m!veJ_~e98#WjTh{aT%OK`o@t}SAw+IK2BaJ&W)ACpQbyeN=OD>? zNRz0$lEz*R6h4z$pR-7^0QI~~eOk}kr+xX|yDD3?ya{{}<9AAWYrXoliX9w~0 z+1yGa4qeSo*IS?PIcC;F)p(GhsSD$h6g zPxRLg9{(@q-ZDCFU`^MJnYnGp%+O|Lj+r55W@ct~%#N9vnIUFoW@e_?jv0@$_ntd5 zXP@4Q(0 z%k&-BMA;xk;^^*j7dftT#PSf!wQeW^5z2FXpu27%PHbv!uOco1ActY==czL|h=l<1 zVqRKDvdwq}9E_t${Az`%T56A5ry3kcd0uA@olRI4G)4_ii}%r*z$0l|_~vxWvp|o< z_-tc`8!02v;dG-|Myy|hp$7Beuaj|LK&6k=Vt$IP$K?tWe)Alzjp>@!hUt9A0p^O& z);2WEj5U}v;dz?Q{=IEE{yk}YB{{y#@J~l$^z-Di6k=uiTB?x)dpE3KjWPvK9LSEc z4Rci1qTi4k`t50uXMFk80!;_|buUW4u|uuO=N5-q! zNT)5Av6Xotw75Wa*y7`!RksL^TO>!BCN-4I@?>o!_gXn(zw;%}I4aeq=NGxbuTOST zUP7pFaIvn)GEVuSo4#>>bQCI?cK=$OR-KjRQ z?RA4@s|6jYT~Hf$S#APcwZNhl_Nb{~MO}kL?jfjws7HKl%R7UH98GI~$4A^x1w?sR zF6>b}A{7MD0T>Wi=CRRQcpCO^%>6gzO_HTCy{x|XLM>__jO|myI=U~vxRFGYHT(5O zwOpB0_CKIwxhvX8Iwud@56YvAG9zQ3Vh=bk!_Qp8sEPlEB3}4la;t%fL$pkr@Jv< zr_4@14$+0iD=wZ0L;ifYI}g{#dW5u8?>o&e>Fc^sQ8l;rLr%Z=Sf#D{@8h!A!Eir@ znNq?Nt+?)=DHbnP7^M+vu|pR%MR8lISZQB2Vme!O8TYMFl%9$^+PC_MMBoZd;z`MV znM+etSFjp6wi*U%xvG0ET>P+ETMLEuf6D$=Sr~X_kXe9=s{)XRG%CS+5{^ z$vdTG<}iN9B1I)36`YQhY!nB}MN@j1(O^}`oWJpFo2uk6H80Qnl+k$4Bjflzm}B9> z2xJkPw|tRIqmWA5f`0$eRzEn~Ts9N&D-66+wW50FNmJx-EBaxTh?FFrX>Z(fMid_J ziivNlQtAHXLFP%`5V2X1aenjNd=xxrqo_TqW$1uk8CM|~fu-10n6B~_7yMQ%30 z9UJDEGH7{1*Th(fhNkX<@+IBx)n#P`pKAnOb?VcbMh&{M>oCOfu|q_a!lUo|2XtrF zR&55}VLdxDrQ=+Qfg!&5)k8}1M`PvChYPooGM*lA&KN&bz8#rOy=Jc@KZ;3EyI-$! z#yL>`2~_SOPxScZ;hxC#m8Qx;g;TK?!IT z*y}n)cJy|+2>kp?uz)t=#Y(bTp{S*N7k4jp;6PRe%MZ!IkTV`ZvO{#v@+B2dwcr38 z&YT6Hv&tK*peUR|5pD$dRxowfx2vdJuqtrYdk07LSdIL}UVi$*Ht?Pt<?;b z(&BZ!Xw}X~%RU2)Gd}yZ#_lmwmL!(83B&I-d@Wil%5!z4gOwQDYhOHtBDfPJD=CgE zmlw9oPXcU-(5%?UzsPl^K8cDJC!nd}mtHkKuiO~5v%SP8oHpFXNo#uF+NJ!W9Vyai z4E*hd+@K+C!>w8__Qqy;IY;w~8f?T+FQ!fBar+ zy8+vAHAGT;+3rwBJTjPK*Hl&|~uD9dfZsNZ(#RmUSdDV;OR8&lu=_!6TuXQ_n=KDIo{zj#y z3!6F7J#W|M#0C-xHv|JYVKw+{IMl`aMJ0W%$NcSTJzbjY)ipGprWiYIUJ%esZi8I0 zW#X|-0m?aYCOgM3D*$-W4xNgIjgy+}Fk)m+aR{J;4n4evjgF>#k_sEG%gcY}2^CPz zxQbNLcYspd;443kP3u^o$GL+|lo(T^zYD$6=FyhJzhyFcYr z9KQ^x+%a&ClMemm%3E5laiG0`+aSx>VXwb{s>#63y8*4l`Um@UrjK$I=KGb|E&K>! zVuGg(Jrdl`kI$sTp+cR~uSRJwlq{mA41Iger3u*iBosfB^wCl<(JkUhwvyBIF##HZ zB<8%Lj0E++D_K7k%m1n9{7)h4{{%^+K&@(SV`}udI?^f{n>t(R z|J8eb!pQ$q1^cPkX8o%n{qJxZwtw#WzrbleHKzZm*yi{YNwagX5o-T873$v#{<{j5 zkm+x+|1Z(0_Rm_IK0@RW*R0(^qtI>|ZDhqns<dhLPfBhqcsV9Ko=A4t7S$VLR4g!P}P7&(YJ@iJ|q(AR-?Q za)l(c80X5t)5ft|d%s!Ncisp8qx#P@S6|XBJKa}U=pt5*46}`L3DtVStB@=YF-P5d zGzH)2DPAIZV&Ya!QXIUh5w&sh@!itrz5 zWfn$;PsR1W#L7%;9RC9m{)DQxyw(Cb|Iy|{V@qOrnjoVW^%r32>+F zSW_OuKm-XLV|TG#HCSn){}P0d&h^5k;c|-jg~rS_qCtc0HR5W}#X*g2Q@~C8CFvr; zRI9YnsovG4alBtC$|sRF7LWO@kF#!}GM3gl$f?jP|BBG;d20X4j_yNmobr6C{Gz#W{>RIq49L}tYj(kS=37?(YZ?b&G+O~j4 zZ42>dVLI|TMA1%rl+l4?>@RUpAVpge&qizp1Es3fc&|QnOta{=m0W{1pXM;3nlW%5 zqaJFEcB`IH2zvFac8C|+WmCaSh(?TcE5Sqv9XKi)HFLpV5OELz5bL0~?*W5O(YG`w zx)NIy-VwJ5vr7`XB)rldp-w@!WV7A{Q*nIXxWro{8iJj`PQG@UB=TAH2*T+!Z2Ljb zt6fz6aD3%zK*dpbX%0~a#ca!gwO|32&Z5-tx zQyo#LOOPh}W=~lft}USm5K#mV2Ilzj{eV)-DTM`l9>IVXR(@+Ew}y|$UOLHB3HA{E z0y?40>7kxG=@LW40ySjE<^TBDC(E19k2Fl6siH@Zj_+m*$T-0JZe!!a8;8tnJrvL#K9 z(YW|fx#bgBWn<1(YH0^*El%#tA&71iaXR=Dmr6-FB33s~D&9m<@tmblq0)WXbeMy4 ztsMvaq1e=)f$JwMiOITEA2>XJ;z@uZ24+2ko_>}2i?&3P55?k|64^mSUk&o-^KdE2 z7D|glb{;6vIj68yzSmz*)G%B`l3Cyw%gB1qfTOqh>;XJPx%iOcPR;>HFzCBM2}HE<+@-Lyzgd4c8JK;4;bc*mQfP^vq%1E}aL0WQfXAuDTDyk9 zEnu8jDs-{<3og=&ZEV|xo@x?|WPULP-NaHSD)(2_(dJR8V;O_UbnPcVY- zg)Mf?5%t^JE9L;jQi?0AgLPE<9O#nJG4bBdr+>7Pe2#;-KFEGWxiyG%75Iwx9xYD| z5BC!6*vp9`vXM~=4^(QE!6w8?u)Z;QB6?E2VZOnUh#*RL`xU0jTS2Dc-M`PbjKJu) zfZD%L*)GcjqKnNVUSyi`)oQdB@~tI=H0X>WQqvCSGR627v@?{%Eup1d>;@!jplfIA z+ER&*Da^RGSKSApBCOIleFg1Y;-1Ab*kzxRyN6GY0Bz{cIjFt#A(j_iSJF#Mc0uaa zsOy#XD+B+))QyA&dz)RnJW&OT4asG3@Sk4HhB)bcgU*)kTC%frHt4S5V7v7V`4j^Z zBeE|;KRIV%PZZ3vS*W}zWkwtiXx#Zm41THE#Bm?!Jmq-lylZh9l{Yvqd&I5VAt!aG zt9A@k&t3XNY>=Z1(q$EH*ip#k(~@YC_?#ic+xe2x*kYY!f#N3UDA;K2=Tw zMcwOO(IdCnc0jy>Uv`jje|lbnBmI%^5g1QaQF{sG9Y7lOc2IlI5PhcIqHY?Cs8z)6 zMrjJ)JjS;Q`h5kuF3W3c8nMm71KC!ajF>@mfLt_G z=AD72&=#MYCg`bQNo1H5;&)x0F?&K1fF7uEZjVXV>a!CN@OswpM92Dj)$)+j(KjhR zla<|3RdtvcaTY&3rmCspN^nlll_(^g@BBrJ~a?r&jrW$ob z3}_{ulS;*@9=+8_-CU7&Dxuad9IAX~QT}j@63xaq!w#I^RLT$j?mcU@WzZB1Iwwxl zcaTT%U02pKs?1RB?&N**K80Ru&)$%jvs9zpM(U=8C^kWQ!pP#pr;^+M9hL=W{I_P7 zUQPkBScgve^@%e!ucWbCC;e<0I}4;Yt8DToE#ypXBTvMcVX{Jq8KP{$#;H^zdBSEM zG4r_FFU>AH5+RzC5Sy-{*`hM`PB2rfBt%Y*e%^M`;x_#^XZD_b%ud9F;D(B|4-szQ z^U1rgwy%uL@Nrc1nApUvmE=_CQG5K57bjkstO?D1Nf{D5WRyX2J{<`KATJN!RnK`^ zB!AH>uuRasDEo7Eqd+JRG!q+Bw5jt>J3izbDHvTbU|bP&C1E4&=9Kn4wZ*tT!&g zp~b#CC>1pn*2ugp88cVgViEv0G0tcEla*(`%bXThqsV60rm@TT zUPK z$PoLLTgUeG0^=0ICjA*J9*U@51#@*lAa;`3P=;#mLtis0%`EEH854C7%Zozg+&wrE z0*`6zjOP&WdS&?A7l?1Je-{th=gOn7VzW3he@x3J&tQ)FwsFju4ksqvHziHXOsaS` zSPnJai(4*jRJz)-5(o^Zq`Jd6e4&aeueGxtT9m0QSmP;QW7}B3IstiPztWft{`Xlt z%imz?-zV|^lVDBhKfJa7hY*e9pYhmtTV)&be;D-`ng4|p{lA20f8mAykExdV6UO-0 z82b-X?I%C_{LoJ)hvD$HU}Q0k#zW`*LTZt$Q;(m9z(Sc>so&I@b2n~0kM3|OSkAgMP&)eu(@E& zNqcoa%?W$ZD!t9dZ0W&hYSod~6elgFc`R-6M{Ty2y2+%q&$NSja=NG6NfEjCY`v{i za*{sJuOGVAVxA7|lYf3Y$?lzcsVG-T@$Plb|5Rl@IckY2S=bX;NPYCS|}r`1(9#XR5jzp=~dPOE4pH&mH&jX z7-7kxyE$o~1rdLMV~_3y(aFbuz15}sQGdBH#A{wX){9;{X5K8;Z18n%=q3{6`k8k@Q;WQHm`(Fq1 zzlIGXD+lZUAfR68fO66r*kI#x{C%&}NL^X5u^?GqN7Y1H-Xd;Ut~MakWGwZ$Bx%LA zMMc4-AQB^zB16N_!uXSt*J!M%C43=53?d~Lpv)z^>Xb0E2Q6ih_%JnbF~aJ7d7pZk zbd}{(kI6DUoE+bLNl)EsXshu&%5v_PMnp@LKG~XW&b-QA-3oNM&+g(T?VS-7YCx*q z>eP>b#tf{eMF_;Kz}z_@36gFz*lX~z#V!i31d7GDpX@le@bl zt|PWFk$v!AEw3E6O?zSj2tYodUl~qFu@96LVQ3)cVOag9GrRxzC1w1GqhuuEC&NFm zpZ$a}wfWZphnq-4iK&B#1qCprSqVV{qK`a2SP>pcF3wS6o zLno3Bs8nnaXH*S00j3q0CFBW)f4+ZBBBm4R05~g-#~Bm>m#p*h%Om3f6{A2dDsP6jKTrB=i${34?WDGXWYv z7R3@pN=12~xa71waIoNO;;s^qFLu`u$QQT!4fswrz+d?I1K^vyYpeLG9FA1rrW@WR zer*bz6u+hbZpQCw12kvR!{BE;iJKcb#Vms9U zwPHKXfNg=BL^x)ln_&1+;bS9UO5(Z#FeQFX4a`c~Z2)v7>|!duYK0dUJf;HVB(H-2 z{E52>0RGrrd!P@^fT1D})c}d&t9ba2LO1bns6sb^a1@}dqLfDss{2rm`; zbC(ZznYjByah+s90q8?G@KE@e1#p$JPX=ry?#co?Nd}q=ACmyC;`VKTW(oUpK(qL@ z46u`EU_#MLJ3PIhMIpRe!afkNBz3I}>?9s=R@9;%NG{|c9!M@|5e+8-RweCH0jm;r zVS#kXyG+3Uc^3l?AOf4DYGuMJ6|G_oorT zY0Tntq5{~UHL}O8gyWovSqMvXr!@q<13VxqQ5rP%&roue15{u&h)Oi&lXDINl3-2& z4d16x1tTDwp*2X&a&sU84&l-$O0?xQnWn={&CuuL;2VfoROKC+rlaMRm>7`eDN6*W zaqX>}hA}a})88z>q>-5wiF1CNc8cv#kν5L6B*3hSkUP!3fbg^)pK5do->mwex+ zM)^)dNnRo@pPK_J_>^~ClEb55Qk4^$gR9`ACNI7Z2Rn+9Kt`z~FCZ_xUf99lsz2n`RDWiWnP0p)HFZD8_9_-Hg2x3+;g(uJGqcA z`mKM?!$4zK=yWzjCdw^^{ROY!@9<$)@DAEzT0vic#5Y8{RN63KWZ!zoQL>yU;sWc z3$bDrAom3#6WK{?y4Fa87oRItS`!8vBLUedJI52^O@5j;AR6{rkO@I2+ebIyhF8!v z!qOGyxhjVn!dq;*8Nyp?8ZW>GGkAks@|W^7?d~c&g!i}UiGWTzrgc&wcG%~%9Gw2f zGZCOJ`YpQs1()Cw>~mcXNkAv5q7I4Bw}2`Pr^Fm;2<_P0`<)efIgh0PIy5Kq**5%K zDRAwKTNh#{j*|hsZ}gHLgbfTz#yn|+H&I08ZZ!YAknkx6eBld}=v5|-y0 ze$EYUE$8u~Fv_N|tP<<+nMgtK2xj%O=MFb3Ohek6o{8K$2S5ss`UqM=+`*ipH;7JK zTu<}vPO89Y0P#J7DO)wY{&wD7m*g;{Q$QgNdV}z^fgqlQ94=B5<%zzDcFJuHVjJPf zF8~Yw2@qrgO=1*d7z>C6(o9E`GFh%R0cD9J*l8B~N=12*S@pkq|=~y`{h_7wjxBM4*)Usrpmwr{+&7BfD^TL=4JvR-Grva{Y)X*dG72Ia#0P>W z>Z};$LFz1Nn?A=E@eOc0RgoSjr@;=9U1J0PKHo~@2J7w{aDxx!1K&SH(6{xMGDx8A z0#49$4$o(_g6=h4$Nl()0W?GS^{pF5i#ytK2ss%%#2?%)`zc_%1NPo0bev@Z!qJH$hywx zmcN|SY7q7>OJKSpoz*$*XVP#1OKBL8T~@2eJOGERT)yeiK za1`CB!@=Fl%+xmm;GFRzdKKR`J9OgoSwvF4><&vwlKK@** z;m_4%zwAV0|0KH$l@SGNR3yKPl__Bx7A}9w+^N~-%&$tvml^9!%_ZBD^+=rc@AbKk zdou``XO@s$OL%z4=hfBf0Vs_y!u*Z3wbpJOyn+8GP@wTEmcOBh^Luw(7KS`H`p__5v4?e$lD> zvUpS#VnsuS3;hn!-I`>!)IY&HW(w4m1Ay_?oi%H)R zP{JY%%ticZA&|8tFP9;Bv>uEPpj{{hewUtT8>)a zI51kJFWI%uE1eip2qWh?1dG!7I*by>TFe{USU_F6X)m^zae3dbU$kdmHIzy&K8vT> zVL4T$rs{=Z-?`(pRq8?D{5qPud@*lB&`fR5ZL?_uw+gs7T`wB6Rw_@wSjWme}&EGndnbE_L?x*AdTPmXeo))x)Va;p{o_yg?Wk-#US4_v#z^1j6Z zYm$i`f)0cZ5)lj&1QYa!Utl+g9={z(4bn1P2GTi*3s{>UUbl-LP7V4pC_Ly9$iL{P zHTY^!pTN^@jU1$7h{Z4E{`h+6HK=MJPGH*IpX}4=&zX7Bmk57EJ(L<`wJ+mPhaeXM zIMc8VUmX2Sa$wBBvHdu^tq2i6p_tt?dgKgXDTwo+tOBg^5Yk{&{;)Z?DX`KYqkf7x z;FORC0x0s(fGBH7m8CfXL<2GIlOfLTY%_!12^|nZ3HlQ}(osjEaw2-{eA7SnA>}aoyx1q1dwz2h~ zTd-STTToj-TQcCs`K0LsTLCTLEnhj{wZOHYaX}G5q5R&uA-ehW= zdhFl4C$=O;=g%Yb08=wDepk~(CTBZczp@!Z4O`!A$|KGIpl^qKKz z9}EmG{w{E}B@|)NEihOgZm;9Z+TEdxY`{a0p!Kxrl@$A-$83JIhojoFAv{A8E=$rIP=0Q(4Sc34N)kZ<6+ zsEt^;8JLPW8d@mlY1&Q!u!cRl~dV0?b!d(eu!$6LOR0efXnL6&nY45 z_WI#;!S@(Fb;y}SMa`)&3ig-bsxeHm&*+vmbS*dd3T+=#WFU9_o%ogG35Ih(skS^O z-CW*6?ndf{`bH@z>(JLXWSV)O^TzT9wNZ#yYO`lc;U@C_p zn0htJa0~xK%4+~U`S)i^h@pFH&1U$lX7{;4gtH}t3hnw<(}hv=4ed;+WSUF02D_eD z_Y3PvTF3NsY@EaK=%uBJG)_a0&(shL4Ry0|y8&i8Hl!5C4;*+dT%#h^!()VRKQj)6m*8GZ5YdjI(%>89N?)OKFryYADb@VoB!rx0b(3PH)O9f*9gI@+}FaeR+rim)|TX# zmog$Fy8hvq?H-dn#zytfQ87~jeUPq#LBQl^yDdb4QeVTVhZlx?R&geq=QF}qOb-dE zlIAcB>lHW5v-|k{#<1NgY+q0dM2XlQT*Z|0`XXcY2RC+lnjhMR&*4z616GPm&rdrGirSJI{Af-`%TKc?m{~q>n=~7WWo>$P#y1?Shf17qmR%Tq zsk#Pg6x*QChr-Ae7M?=*lNXO``#xsK5Ceq8G$D)xU@ru;wV{$$ZlWJ45T) z?EbQP^enGRm=WsQ=d}@A<-AdmL>w)=gY(Gongi-i$FpXtIM(lW9>h0=e5wd)!Cp=) z9F%rV!DLEK$AQX)V#La2YElvb87dtjCsC+(n&E&f{|8&+Cst$y0Rv*SSCoDp6;^x zVBT*MwV-&t#@~c`9B(L9BHrZ#XkeX17DZY~%)VWVXjeF-RJy-4(TCMsDC?}1s?^

vnC+c+6iK%X@gNS# zXE6ZE(e_D5{%hdwV69FWKhTFgC<<4+=*ecEd; z#-7#{=xj?y&%(sl*+A{ZWmm)<$=3y|Hj~Kkc@6VFt3Pe%zR~9$kt04l)V>gAUKx+y zHQc-A*N=h57O?6I!wi0h5uX|VQ}Z4o{bpuq_LJvB9~|{Z8`=ireXe%;GG4GyG`M+~ zwA^uCp0ss>x4inpPineG-G24p1w$LhK zIO+kNG>~v;mOnz(p|Y#Ps`eNl6ft2uX;`PMSji#_DUrLR)1?#$eeO0GU_IUNTbUBS zWM7D<*o)0b6iFNVIop*cZov6e_fOOp@S6-cMgAO!^}c#LFM1L?vFFsEu)OFyCcjBX zK`V_-RY)R=5vgU84O8RwbbvcYOlDy6aoq>h;D9{N5j!0vF;lME%>4|`OO*y-a--| zjGT+ARgQyYdO~q03DaH|<0(&=(tsERr^tQhTQruHO0Q7M`XYonHga{OWz5A?IdBDR z!GA11knP6uu>oj$kM>+qLP+JekS%u$a0sx)j~N*%e`{jG7~! z09cZCV$+fRlzibfOQXZR=d;@1Qa$w+GHGnkKG1n4NDT zi*@{O-%t`3=WqhaGQL&i%3mOB*&&G{$u#(?(}z&85eK^|KR_S{XltsM;6Q{04e}(( zJAt^cYZ~2B)_)}!N)sY*pLK# z?N0a)E$R$Q9N$FtFz@NwKK?|p0OBpuh}K<9f7KLu{XFI{l?>T0b!{mXKhFg@@tC^6 z{nFxL7K|7Y|FM&{J^GTZooADcFTYX;EG^tTiaZmuNqkeBC?Db&df7{w<8UvaQ;ROi zf=@3<#b`-4INm809VFnckP#(p6upCX{mNmWG?Kwy?5DVQ1Rir)mIL0(KkqnSkaoDv zlmz2(@BmesBF9kL6o?I}pHVcN1z zHGT?nj+)TZG|<)i=(f+S-+b~v^Yg5H`JI*C{$>uwx6nNG5Y4~awf>Rr#M(jZE#pDl z_wyRf%MXJ)x^4cbhP!x|(_+M{&Tl=Tg=g`OVeoLkt>)ymAI8=&KUeqz+PZrpq~^h< zyVmR5dX+*21vAqr2}SWqbjjo*iiShGjxTtzGH@qE^kcQG&tg{+#fjbFfFXp7Ir ze%d`YHX$@Rvdecp@@qZ7&3FIJ4KiZXv8GGqeW~|j5Y7z0P0On2k0Z%Udza=ohOewj zzfqw%He4+S&8T;*7)e)n35rzz?x@E3>AXwa^RtJlwY9psT+E#6S&)+o$7BLGb&+gt zEq-lgbTT67wH3g8&MZ#agjCFD}cXp)4c9`gDuJ zTCrl76Wy-IFl9Y&h4Z#&vala*WOA@l>QBzPc>8)TuMi^R==UDY$45=8H&@~j5j*+S zbJUF0qM=D3joiEm>-&NpI{_B2U)D1Fd*@)@glPKV#giI&DoUV84Ck@e)yvR%#)s4R z=+jindEH}kOpjHqSOV;=0zd7yt;pHk0?)8RA`Ri9SRg=GLMH_B{S^yREJnA!EU;6t2w8j6OKm0gLNIwXp-oF28=?PBIDBpDX2lYaSq=Ls(tHCsWK>kJFFYw(br=A-x{w zt<2PwOs2|AqyF|6>%{QshWNO1UPRqfztcax@6)k?iafaQRYbmaP%j6x|ISg=m=^_so2UhT*02)!{TDtGfolqyd+p z!P!iGbe}M;*XnK^f&neqF>fv-Q5jwT*38?u6g7+^wUlLv?&b2uHR^3eRqZ(6earJ@ zF&Zs#&Bt!QyAR5@re5V~@PY5?a#yeOFz$8x=6AdIpCYv6M(@)K?pMPG0M9QEWH}w_ zOXDftjM!`o3cXEPj=j?E*V0GlWkO$J`@twt*I~TgKI2IFZ|fc$k^~X6rg<#b3x#`} zaf{Jj(>1a@^jhju(V1@NOq(0HyR~ELXJI#>i2tri->sCgq)$MEm)tq zsxXugj9$DUpum}MAdC;up2a9vF2t9K)l5agLHD_0~ZQX&tO~N zd&MDDyZ2x@5De3!qNSUuKW$>^7Iu)!U)_+r7KtA#m~O;Os`u`c%=_b*uu{?^nWZ5Q z$@iA@nc$e!i|CieR})hksq4W$|GQ$rV762}L>WMNh;2!pq_Agy*|XbKV~;-TAJPH# zK@2|ZrB$2R(|KsDzo!KA8RjNAc3{DK7iA?47);gkr7_*A2R?vDqtiBpz6SP#re{yk zw|`}K>^Lql_}cS@R18pj+z^gwuV{gR#iQ>lI&Aor7c%j3>iR2u7Otb@i{6RT|Ih!w8SWlXHTT}WogiA%~TC@sdFo5qS%9APa_DvMQ3 zPi;ss`>U`6y_B!lPgB2Ia#1sr%wbZTYuU2Yd5HyzJx|}3-yZqg8Iu)?34$FWf7q>4 zRox5*Z?bmRx_;?>bFA|4-lEksjZT!LHuI7H%xtqz-KzK0JCWEl69apApN~F?$De<1 z*;kN=!BEa4U}D(PV91a$Q2}acHyH0I`Uk{Om&H>U7(Fz)XM>cfitlQWKr=<#4E{=E z>&H6i2lfjT(Fmpn1IrD$`U$zA{Yx65rT+==9=daD61$}EmMBfGEG$fP&&0GOO=V~T zgKKJJ6PATh`J%$5XhK+ykC8ivRx6H82<}JYSINm5|A)wUgw9&En7v4_NqxnL0~;YW z-9z#+DKRr2hiUTwTOQ6~DO#g}EZqGA3-z9>RId_!ks(Eqd_1KYH`X~t1eNi0N$1il zQz*jB)vcNbP2T!u+Uy->OL&aHN`sl`rnIb(^_zk8CL1j+M#DMPq`{=A?2|=vfU@ag z`WUunkt%K3IHhi#``IBG`fYon?j^k(+`;3YfE0lfM_A&Og$SxL%<&Wrg=VLr-sp&= z#O1j_oBFxmF8W%dkw(Tcsqw0fdM54z6=d8g)wTI|T|tZ4-w^9H_)cQ-172lSkcM)h zZBI++HX){aIrl&x*Q>4wAqkHj4JqsYU$kjy*v5fD*Pl?-lR7q^O0CCi61Kf9Bg{^fCEL?`j%J>)csZ;Ir|VeSnY3;g zkcS>+u)fz`B0SEg8in#6)gDW0@G-sXxBIhZ@~r3ihkc5eUDn z1d0ZRZBodYnWW@2Ho+5^FqChjoGxU?!&=?E#;Y^p*G<7p0@L%;qB!oIy2?r^zq}QO*g?LdTg2Ld$F*-IzBLY3p4if%5Hte>-mbQ*J@;B zi4ApiPA)Uh!MxccxtyG76|PciCLJcJ)kMZtNqwSk%(8s<)t9l3SxU7Fyp6`aT}ex_ znRTrc$jxcq4YLn(f+{+Q^bFQN_w{z8nWXAB@o22;$33inCZ5q7D&@^<`Jv;T>9Zc{ z$Df-yt+Ft#9A4BLV5gJH&_tiIRDgDPFiuF9Q&yL$oZ+SVN9I@$s&XA(o>G>sy>-Yy z%@xs=WG*amEf~~%Wqt0>Fg~MxsnWpi_#?j8ouT)Tx3XsPM2i6rk%WFX;XZL@I<>Z$ zw50XROoNa*&e*PCZLXe)Sp9N$5-vIGCUG8h~br7}`K{8kYyJHMo) z)IznO-Lvi*_^aAP-{!6ik^73!)#5e^RrJNz$t^HkHRACN(-K>=gGS>LS&G!YeeAFh3JDWxLiYOsc}+ z6t|be(I1_qM23g8E&&&rz1jmi?j~7Mnq?JqOOCs$C>B@OGh)mWm*P)mPd12rJ%)`b z&1}tqYMv7}0iGR+W4pPnZc09TJt3`Cr%um{SwHA3T||p9ZGz{f%^38j7rSBd4>aNP zeJLx#I54!*mgk&Cx@lBrGHz@g7Rps8zZqiKCUy)lJMDO&b^*TJV8r|m5=;WQR@p+}}y&K;>b3v^Ru8;H^jII%?t2VJiSiVwVODn0cKtoVsmflNXT z0Y_%zU}Q*L=-c&um%3OSaj>Euj*PXy?Cyklt!?z#MvLA0K03Y45HD)(RWx(AZuO6; zi|m%C0>>tEy^Ff{cpm%7f-U!4=HhKTjp}Q6EpIY^t8WMi$&jt%i}q8Go#5ks#~A%Z z_`x7Cq$`Go4Sj_N+-5|$fyfiX16|KE);w;BF<)WQgs$aEdu~$WpvEGHB|-04eNX~S zdU7pB)R`Wi>0YEX4}R&G8W`KJzKO%tSHHoK&T5(Gwe1|1A*(-)f0i2}*>%Uwf)$i1 zQ``|b5aY*>O*vzbp4Y5s=v5SGm~ndD{_vWzaj%Fa6hDz`Fk%qIC+94j(t4N{{kYH> z?{GK%NKV2`sD2ww3r-%q%ObSw8*IZyWL?Z3$b*?ZRdO_;Nj41w%<$c!bg)yf6^ZRDi6Y$ zwo3sub!03&rV|KN`?Q5e$_CZRnzzan^&2sdrs>gCiv5#q0~>9CNzGFV(N`$Fi7Maz zq})z-dphxSl0R~Oc!78AzsMA^S)qikY+I$#MACV2nK@^A*^=-3XURkAQjva{+frFO zI*;;c=iYlvvI9$}gLcE%d5!kasjJQAWB7doNo#$+r?zplYCW^Sb(cn7Tx2sh2ls2=98GcDwU~kqOvpuF}`9bRB_lb$ntkhZ5 zv?DWpZYk5z6(N3?vH-by*#W9$8;NywV=m^<1f@JvNG0=?eG(NPm%^A4DBCa{K7$^W z_(hDbhx^Ba9o3@0gz{OBZ#U0-1$2yu?-P2g=3CF@u(r+Lh?;kZe+0TuMiA3#t`a*s z&_XI(y1rOxXLIA~?gc+Of-rK4_GrM0Q>R%Wt3 z_qemTGc7=TDX=udwk_3B9no4mJHnpkI10hF;j*<6;We?f!Us8g!+RZkJ6G)RAu?LG zaGi071H*m+GzwLlR-#XWuzAz`FUHO}I?^>?+v(Wo*tTt}J5I;8ZQHhO8=Z7)+qTuQ zldtxiIWv3Cp7WjgX z1R5&x+Uu~B4YD&8tX4Iu$?X^S4~wN&vt^<+j&&y(A1xA z2>6Ja@a1Ftr;%`Er6OZX%Nki2`NVFWY-i2*beg#sb@kgT2T8zQ8_(%0I$3mDc%s62 zH4BXkirbjdb8Ljk7=yJhnssnSXs$ThbARz~-%M1y*XX_O&W_$*uGSqKHVs7oo}Zqt zziHRCJ}8ekLY;*B5i-Zg)?95ey3VxqD@j3P)KhZNu^pM}4x664%S%g3U;`KGkd9uX z*5|_mA?_#NU;dm`-clC5HoT)O}8@s3#}4;U@QDx9*4ITV0L)rjRjSwdTU5 z#Z9>$UbVlB9PjVk2V%8nB?NeQKP5t<$^=s^=|z9%y@HY`i3;|4H0NvEg@pZTMZo+Tn$VkD`_nu9(G0-$z)= z>?zc?lAj><(cCQQi z1+8>29K09n;=DuZ@KkeWUz#4Ud0tD=u$C4NDqhZn%&Fxg2N0o3J@)q}XVhwpN?AK2 z_N+2tF;=}+TCEQ-7Y|{ORTgLmr{QGupPVF~hz2zQ$q(vav}MD0qqQ1Bx5ljOF8A6u z$4r&zYeaK*fj1KxM;^=ity}WB6zIc8d>5pPUr7C-U+-Bc4X1 zf@<)l62e-vmiWSDqM}kVXMT0o-CMQWr_?=>g(V6|KIo2Ay?Y~9MQbFz;9P@l|Cycj zHOC-3`uwSTT`p{^G_QQKbV<~6r`|H-ZhBlh84;-LT7bTOtK2qnQQs#H@MEC?&Nj97B_qIO_(^( zAN1oTpT)05i%Z%uGO}js>F(3plOvEKZ_XRbMmbi-j%7Vb(NTjqH8bY;92(vP z-GpHa-#)pF-#x|O?l|2$N6Zx&!x+@xqU#`rZZbC$Aqt#oOH&*}`A#&B*A5lbG9;>S z4Y4IztHPSa_<5}DS#If)%)eEF;qJ-19)F+mXm<1L9FlTOY>*M2Z+O5QM?jyk)Smj1 z0)jd$OO)>^PLg92VyPpQLGGsF9kM>AFLe+J4SKuT+hOhOjD;iZ?A#hQu`NCRoW6WF z+n-ef^?tZd)GXdo3U5L5v7N9ecGbX$t#=v8LG1A%{M4z*X{U=jw;3!NO=q38p}eH| zV@{pPrq`_CWyMo_^1vbo{R3OPuq?{_u${_4pG{%T;%B3!Ui`_n;BY~|d)EK1ZG7U_21 zG+dpYoVb1QB7aeBp#)r68!W+`jWs*GT*$K=tac*6l361sY!93*CEfE-fS)G~OaD35 zjLM8!V#+FMVZc}(*}#&fi8#AFue%n*cml(i{HB&muy_g<<1^y9%QZKP;ZFMYGsW)# z$DlW~!!pz8^-EU}>IT4&L}@)V{vxElogXBF)ihfgBnHP)ULxvAO_zZQ7Yuys40kw* zJg)NNjf;vPgEqH*Olp2#uZ;oE_y>YUh1)V-REQJNRKU|$D(6Yr)seT0QW+f6nZgb@ z69@@&$>0m5LiP4_8eKfV$2}O$4Kza#7gp-YX8QEOn9A0Dq0a`VB(}37WiM+dZQd;o zYc4;P7cPI9ptrni3Tzw(Rb^oH`MpfQXt1#dALBRk*^0hq!o*yG{`5m=)~;`Ewx1xq zU86gxsM7R;YS^4GU@xWbcDEcdPgRS#Pz|bBM&h{*(Y-`dO+{csY@g|I(fx6RnxW*m z7M{Zp>Q&*>rm=9U`V`cr^m%KHYX4!Ap_GHK+pg2DcE7Ly7S*uVYM&_hdg}^8=e5)R zj7w?}vTUpbwpD39X|uj1x1^ONxW)OoBYDJSPep9tWFI4O3;)6bzdtbu6MhQaaZA@` zBRe+$!n_d#r!ds%mtqY8-}|eh_L7$JEE^>o_Yf}KU>tcURTd3=?~-HCSuy;#KBrA6 zY8g26;Rnt*Hl0ahCv<1Q?t}&FR5%zbyp(?9NMtisbHQ%vlrit8x45Wv>98jz&E9oS zBpbw-yJzf?CEuHzZ>=BCC&=7i)&A0uf&hq-m4 zhu~21xw6mo>d|F8Gd1^LwQTw++|-lpm_ZtaWkVl?&C31F1kK8U=t`HtQPjhzwKI(1 zj*QhdQ zXKU!qI`iH-ZO*e_h^|(7V6VWv&oPn-d0O1MVdrA9g~`t=1)+nJ@P!nb)cSTaiS+M%GG7et$IQdA#z3C0MYC|P-+Bii(2km= z=BIt)v4?Wjh^Zt*4_-ya`ZjMaysUlfZg1RX6I> z=3dkzXz6PD^kp45=5Svc?^s+6C5%5B{pDn4#)~S0LWVx`Eoa_hrN~uo(X_v1#>FRk zY)7hpxm^WyVDG_Pkn6?zHDE%^iEK7fpMBjVWmG}L%g@N+kPi2T+FO56B6}@uiQ;99 zXy#>?b3dM2BRa)I0udKr6Jp3AGv=p5th}7FQTC%f;j!V#J?z4UQUf+xPOq%SjUd}8 zZ)0F{hJz$!*``hyBjvs7w6$|xDn`&^-dx%EfWuNuOZ&ANEL_@BsUuV+-`3H1ri+5D zVNiprw|Ta&n?tlZ(-tm-@_K&+Iqf6E=yPzjztZDxAWz=v`rX zV9@RLD>~U6`KMu5YggSN{UA3jf3g(u~}NN(ZstYtm@{r5MF9X?RV_O^8E6) zz+ZnGao?X_U=@tyf8M>G7x6{)82?Do&=f;$BZL0H5ND=AJBSgp+@%6%u1GQ4!?&Op z?qHcI%hx{aZJqQ-vNaStLSLLVA9O2X!783Xi~=`f$q;KW^(Ld8o)$`y$q_V>Dq)s5 z9@jsG+#w}?E2(=jMmE54BP0s^ii3gg#W2(P5Bhkg-P;GKl0- z)Wkuheyd)hqaqct(xiWQi+kCa3^(8rkwn)2a)_zs)ZT5m=}_MJ!BRRin{Z~gTwhdBVIed|Fsj4%^fatW zFDKCs3u3xbV+T<`|8(B-y|BTX(=SaiBBAhsDa!d=r+h&r7MDiiXDR=W#8*WN@X60x zB&^qO6+OK(DQSC5rS#NKIX^M9jvWM31l_*p(NnpCQS`<9G+S7^$9r9ISB}PrDrlQr z{IyZQo-Ti~Jd82HfF*yT97((kgLOX^tIv=JhLUg6TmY6B$1Mtz3a!9Bb9#LW+T5Nh zn;|dpehl*{to%Z`Nwl{a;iQ09XU_Q*c?7jGEI#)V?v<>rCDrz zvQoMAw$C$RPIN#Jkt(7-+_38@Ae~88CK`G>f#7g#_DP<1vrKNP6W-(D9-94%)wb88irlF4ig+*}ZWlEK6BkTP>uu-lWMDt*d1;v!7<*E!w5 zQy^McIev{v(RUW}ih9atvGg7?hB;+`_AvL;u{M&&)GvWj-^473^$4ROgN^bKQLF+ucOlnvGS zj=;}m(a5`Sa;NR@bITrf@*mEcn6rvl*iqq(Q(>$}b$4jogF-Z_*ShBfFju>GnZZLM z2V}RiYG2Qhel9oBAfc6BSfcq7(>x3!Zbj(XRMdMbN~h_E;J)2UIiuy5NKw(Bz_Rrn zM{EM!I@}E}i^8*OlQB_YH6TNLhGMS?U-e3g{4#dwE}McqTArPq#T`Ag#nYaiKeIHO zjGed|vyI#=b*XK&npw8F#y@fc*&-X(mrZ4PWeVGSp5s{IG>#U2#ho(Al-bDEruTGi z(s*$CC24ZYS+l6VabjIECBmAL@!pDg(#m(+)H6C8e^+u(R(U%8rR>#~V1N1qhp=)_ zeb8Gxrc|d7PZ+aIFNZ7h%A}V6o{%;W>*nh{5Nr4WC~IXAjYybNfhq z&#s*?G7P0RNn%wk>seQ85Aoogziuhe`<4zOG+H6HlXA{2Rn4N&bp2-$>||ZjxJvtrmmk~X(1yZy3s!wc8wBqoo#xx ztVJ)rencs0k?KF%9I?Bnz}0tPeme0tzSl{@@-GVhA$wcU~-yikuJt!+ys1uTU!6! zkJ-*Hzqd`iY>cycH3<5rt*b0HMkEc)6HPoTE=CZy|B%Fw=>pb3+{x|khOki|9;w&RS(lqL zugnN4t>@U($p(GLw=3__<8E|tN3MyJx}X*v&nc*@)>hY_nIhN*&l)xn&CeFA7jSZE$XiX9~J(_mFX+fBV^ARg* z3fRyKyB&VBuhg@SMUptn_f&}V!zm3rNEMn7&O9DYuM^8=&5Z|bI+i?yo@6K-l;IRc zM%%s$iTMTt!%O>af~rgP{;m++)h(WS3DV#AZzVEi+I73v;e0Y~(W+*wak7kWSMSS5 zte*{^i`7*Q8%2}ef;eDHu{??U_zPa!F)L#35{oA~^w-Rafayuh*Oo0R-Nl{L$=8k= ze$18ETxwuPOyp!ID8w4r8hO+OHn}+vf0$J~urJ`YJalH!V`;h8_`b_|-U4q`4#q@p zW7{{ZOvS4TZ*3PhakIbs+(~Kf{B_Sfpt#}RZJGa1DlC-#yTXE2$i~v}uRRtljDOp) zPXDJK3zon8;{TT(3)VkZ4YC5n@N5ih1Z=FF&>ZY6fO|kc1v}sX^h&S-x+*vTvUgU% zj(_Gq`X@L6@^^sg{*QwhAckjRVFNt(Prn0n-TiTniH#jvi{MWJ?Z5p&|GI}B@B;ry z*F^l7b-*7Yc+a4e6QW*$uRov&mCA_fj)jZffodTF6(fy?{kyKRzNbrQWe(_hLd0A= zDe|gVt17fFW*D2;&%ngSAAnpsYoAtawf-TBM2YG{ zz(lX7ltIqjbl1JL>0iXqqHWbF)8tu3zv(mg&03y|O46uIxGiO{i;cKUHGge1pO5AY zt*i?*r-D2PmoQHAry-eSgAHuZ;5`beddk4Frr7>@*N^g=u;w;e>4bXS#!Vw5#X?FH z0pvwk=-mEa0l=k38^V5zue@hp(jz1)h*3)7whG6{&B-26l{i3YRD)}hJ4U|1Utu2il@eiRKWT%S@P^* z=~?>*bct?EN4QB@^*~6CyOwm=Jlb?f zaoOT@@uIE7!&8%BF(lskuKT;vFG=KOKN08@d`j!0-&F#YFnnT6Iola+@ZuFpo;1t( zaMcK7>Y02w=Z>0tpJ(H6KLvl**rCSZ;Xy8(I zGqC0M+^->7|APyi!Q|lgtSZ+9VgJp;h+Suf5E(qob`oV}Va{+7g?MB?0%QI=byXY- zjh4Ko=lw#kI67u|CqWrh{L2mky=yd>x6AwScHI)W#DWV^qaq%NptNi|A&kQMU*q%f4MGej#QDhMPw_Bk<$I}}| zho^Q+?~Xf4zKj1k@J_+20Hq=Oc{1?HWN=!5Cu-StNdf^soGMf$P%_AvZ&CMGT}C+| z<1fs9GG9rwwFA+zdaB=Gr2>{6r(2(dX5o6j=f$g@JLE=^+^!VD?=wImR80o+l&ZnC zgYI+11`y-~kO<5*mcO*dFyD(#5V(vaLm#~S9{P&-NYqU14frXL=8?cV`ruM*J?IH@SEe5~ zbgk}57HJLfC!w|Iy8jcDvKR9%8I3pb?ocQ;;u5iU;6b&pW<(44wQ&DJXjN!M?J2G5 zn?yfqsC@rH=!B{+@-9<6EhzZ^#u3YHz)E=_-0C^KRSu`)q2v5YW{FpVgUAS@9YF*xFTsAyhz&;*j{0H%2dW)3QRuOlBjF(t7ZPr$b3cvWsgs7z-g55?rXe z2(CU_J{lu3A(1)aLMUb^Rlj3Di--|N(bw!6VEJeY;Y1<{#DP#E5kevYzmgpk{P|t+ zA_RHgVR2U^w@^(Hcp~f_!Ir+o6S*`P!oVuaT$7-xIiR#sMv(v4(qN?xRQU;s(XC+r#i1ZoF*&A3Y+YS%9w`p;RqdOWHXwG}!3 zW1!G5IPYRYU3!zDLp!24P@2d6m+^a(xw@~AYzQ}DHBJSe#g=D*Tyd|lc9kk$Q2WPJ zSFUR7142^}>Gh4e2JGnxyaQbE?0~LucGYMeEh=9y`{$OQN)Tmt-?Je#%=3(1>$>+` z3x;YJx_U<+2=PSEMS1*}16(n#B`e+8m2rE@@q5ehMRm0qu7^~xV4&tWh5Kaus1pXCx<%>Q4uouCjza_*o*f1{vKSV3`K3!~% z-#U~%#P9_HKiCSmJ@#CWDM6tjxdE&>t+li11L@bc3 zLP6gIDEhb#&4W1bpU`9NVq*mOK%as3y=;&01-ub%(1tSzY<%0{Z?IYplwwr`9{hQL z>ml~_Vs-r2fvcaOz6Dx~NY=n)EN`nu400mWf!opPgEGR%M>wa3AtJGcn)kzc8Zr}M z#`V``9J$faa9ysCIoP)B4SOSIlP@RVB557pw=UPqh(P4yGD6G*r$(8IHWH*GNr#Gw zfaK%JhYSlD>hEPiLi9!t3ltJthO&rI5rN^)h1Z6%_wC8}dV<))?o$jeO+$P@1BBHn z1UkN+@Hd#Q_X@GH0-IpZ%)>bX@Bwc~`?#?`d)gobvO(O?_Lm5ze0kt*P=*r-WPQ&e z+;B*MZxCJI1Y;otoc+#0ThrWfG6b+|#5H|Yk=S~aL+QjbgN@aKRl`;NF+^y@Ux^c7k)iwx8FQz>Ln~m+VfP zq%Hi9taOm)EAv(zGQ|8hh(pBr@OKi#e~BkYR^qi7X=fC#%$AzE3 zVT)Je?Zgvi5fjgM&!-V%dG(zZ?`)S}^a-xmjxeyl-|D%WrrP`Itun6jj|*03^;Ktr zC$~8+$1m#Qz{5uLy>Utl_av=__+JPM3!}qtu-zTUzV+r+39rLL+U>?lEZI8GsrB$@ zijLsXNkkI7wwR`>An=Y$_qN5vw0>ulm;wUHgb!BT;ihfzd^PJa>Ll$cT1x?i@QMfk z>HOFx($TTqdFb2*-fG`|ySVl5=*-?Oi~U5=abalb;9fpBgPq*i#I$^zfSUZ`l~KdW z;o)IXJFtXexw(mQZkiv}8LZ2zbLfj2xV+Og+d1RiPd9gGQaQe@Y>YF?5#LiI#UDSZ zWm*v22s77Qd=1`W>-ycP&|12K)=9j4odC@BVzfUhY+Yhb3>lpvtQcJ?M2bm&)p!?H z1MVlLGscs1A5q^>aH(K(pMc9T{=%o&)Xy{YlaRZ1!KvML`T199Y*?-k8Oyt~C#tS$ zv8C$0pQojzx2UY4Tq@4OQO#Oy-^R9zi}Du})_&JBD_xoC<_D$%wt1lFNO$zmARawlUz8IXdPCg6v3IGfSmvZJT*e{lal7>xr06Jj ziL`I{B|K7iM=NBL8i zQbY6m65k!b)AV^|Bb7_spdF>fXAHlHnVVBBq1GtpzE#zp6gy%e>w52n)EfF0Xi1I` zs}rvir<0H}Y@!HvwN6hO6VD%yFkG^a5vf7SI_H?~A=LWG!0`<7tR^yaMGWn_C7Ul^ za3#Bm?1f(p@eY-4L1>)h7HyFqHgj!rMply*DaBVajaZ<#ILr&vgqycFQ=kc#$RakT znz`2BJDU|vVUxAa=(hG9p*9{i0m&XuO>!~rcEr8jPxG6%03C70u(3Vo@~#l1j$k#3 z#;}qhb!+-ttfp`^=~5hi+}Q}+{?NXdJ#s7NxhqU-(mI-?!L`QDkvnBl(Ynkf(PONK zpGz$F$kg!0{t@CQnChptJ^!&>!1b#@L)05eql+M4@)=6fPKQRgl#<;2noFVNcHG%EeJfXsf7mVu5Ygn`X56h-Z!9b@jRm0WK#lDuE{*& z@UcfDHp5*BH~osVmBHx4HX{+!OYreqaVaCz`>Z$M&%DndoFbck+K)3XvpPXIHNx3H z^;j-W`-PLxI%+x+hY*Ry?K@XcCZmG1X zyff+azCkl4mDwE%XgT;=4I%oP^x;Gz!r>qkB3CrFx!r@Z|zgpoFd9T$U>y?y$9 zgPR~nULiie=Y8fI&i*dY38YXj*rkM~twm4KP9h&torHqz9-HBQs5<068Y6!x{}{ah zLC(>Hk-fY<^<*Ih!-B?a0Ad0y6TXVK>>lnKS~6K={ONnBZl@Ao9LBIzp4Mx zRYSl(wC4<^7M*CAFq1o1sstqwq&eu2xW5Dg_dXe0!cTGwDJ=~~LkH`tzYQwtGYnN8 zoNybMS-B2Gl9i|sm^s#&q|l$at0-gcs2o@B?`hJp4U1cfoQcF$(*V({aT=&?VyX%K z^SfS}c=$0vd>RyK<~`-uStjA?RV4yzW}9bYXIC{rPPEy4L!g@E0@$;mRFz*YxKJLB z-T}r$S@93wv9cVt!8lOdHmgvVB?KBMC&!2Rr4=S-4^rGT(goBXI?Tsz057L%!o zh}2-?rUxhSBDqKOHBv*pZEQl%OekM>DGv!GS1@GLs5a?+jn0BzK9(QX4=D4ZBC^1q zx7AM0;78VDFJZ5qop`CsQ>PpUTAb&k0Ab{_WRO3hcE&So@eOSY%U%5P-6LydD z>b{m(nJ`ikc2wdLj?vhLmv}dtjMT>#Y&C1&@z)e_&>V`WfygfOZqb=dO%u3 z;M?XZLT6uSwC<(t)Co(t_&0Od#tF=d%|zVY<|IYE)emPD;mYLg{gJ2Q z%SYmT$8f};A^Bl-@pYL|>BhM-#W4q^?+#iDCT@K3GTRjtzLhr*yk=kJP?>U*VxS~n zdP~AOnw(o4IdHLB-r0drnb58m68MOMX97e;ktDfW*UC5ShbabPrkF|Ju>i?0yX)gr zis+vf`i46-1SlTocjf73LjckQT=4qY5Cl+!wy6#1C*!gJCgJIp7EUWb0JYZVYA!>gIE7vE^Q* ze5}QO_7F!7B3i5?wD@+h*`Mp*99NAuzf1tl9srfX8}|c-79WMctab|uFE*}+?)a1= zr95p*paG>=B+aCZ#9V_Wu6Ag511pQG@J2A`w~<~H0##s5J$hs>o_4rZxRI|1wlJ1y z+!3h4AhfR&L0MW8SZ7A=HO*O#Dr*)JlL`kyvDl*NiL%5u_>=Vs5Qb+1H#pP4a96!j z>YfS3%INn}rF!xu{|z@67ZUfMwaF7e*Rq10-DnVtjA2&nj+V3BFIJ+aoj(cqch=Oi z3h{8Ir{6DtO>00mQ1Z}-=8%az;3nIY3bh!&HxHkUpnaJA==1sBcq3s?`iW_l*c1;( zP{l-Qwv$83hE}2z2Nxbe`VOv!ZMLgTioIRamEKC8SFK#1jJ(YwsY|e<({8qdqX~X3 zrB8@+Z1_7xPr{YD#J7u*1rhmsU>Ar&4;_8laTuD+xOu#YV{D3-by3wF;G5Vj%DGXQ zln#=u3e`f6a!;b2rE;-_gHyD7m~{0Cz6;i0I2*XXI?ipL$W*Rvy2~;*^5PrgI14=x zW@a?Dhxw!U+A6B)@&sDZ^KtBEO?EmHH;KqbII<>`i4&=+_qnAfSVyS=A7L|Jzy8b) z9P{g!`22F}WAS!ix7VLgEb;l&b1gu~YLrg$ebGUpNQltzxnfJC7YR_) zP)JQlU2_-_agKw)DX%b5$8oUrRGd|lV{2!@T;hT{TDD~6L_$jP8@_E)>zt*r8On&$ z%wEmkKZTs4Vaz;eJ3YDbXn}I&1apPbTvv?Cc9*gB=Z;8MS!IbOF=RzGEUixmt?hWWh}u1ev|KwaUC{AuIXP*r}DgI6$;=rl5Z4 zV1y*Xby(w^*A(#quKL)cjRl-bBUEGynOSwXY5|IJ8^8RgD~mayq_iP0D-@nf;9;1v zyl^8++>&_%v!=hU${CHwu!KCB@whbXXaGr3aWUD9x|$vpo1dPZq;@8owur(z%b%6wzgEhS@0b3J_-U2C8`)GF330 z6xs4*XNOT1c?6yPMk;sQqDW7^Kf%aJtQO#pHrju2-#;*2vgNwIJjnKk&k=&q)pgZZ zeh@MB;V6>?UwaLa0HHir0|E4K(v-`5nJbcZMTlOig$c55;g>UAyR}J1KzaC;aKCIN z`E_hGSDb3R4sZ0OnsWud1I43UYK(e5IsKW~DW%iXOMI%zMoYb!MAbxr+BHqRhUqCi zg{`p)?(kKXx2sA|twE<`k!<*(1iCCtS*6(M5;te-gIVG-Cna^Kj5^HJ*&!2(QkzZ1G7L{C6NLC@c)LH_SJqzw-KUQgUX+w(NY*2CDtXEk!QI0B zN{eab3xzyVFuLJ)qA}-8(Cg>D-|j+>4GAmaw47XCQUzv zhntsvZo9^nEf3Qbk79o8>MJlVKlptvWaJLmK{G%lI&tBrNP{VOYBMC&uJlc+nK7P) z(U>Y{7K}i)X!$wPvb(j?%peVqLUVk59y#NT+CX@Ll~(KN=v?(xkW?^akvtl%vW;1( zS8$?hlCP5M7EQK0ubnJBJisatOZGmGQFw_6AA=P#+GI!OnaDU~I?huZhp7+ci5n;2 zo`FFy#-8U3Amr>#3cTnf>Za4LNzE9G%rgCL+u-2fsisa0W5xl|G z57Y~=UfiVbygnpaGguNft~s5_T>3z&iB#ei(RRGQlBwgLEgy(T!{D(b^~DrHlj)eD zRfkUl%X80>Oz>gHR{^puntt)-R4kTy9z;tDTdzql&R7+ z3C~hi#%ds}cIOkN`M4+(>CxeQ-F<~HsX9%|E{-dMHTSX`l5@~?HgnIly1p5(@_UI} zbN7PbDo;qVk5)NlNf+qzx34*7eO*hT(P1JNpjUIAGb2S4S60uPic2XT86RmpRPwm7 zfbQ_a>{-b2(s=QFLGh^Hq$)JpFEpEDwla449*jPx;M8{s0+)IFl8eu9xbQa556jNB0%!*JGkfXuv;U$*_eazH`27bW8( z#=`KC)zbTA*C|G8vD690$RqrmOLlKN@^rw-n%1LIs4cm(!FX!GiJ5NM>q`!bPa>4s z8Yiu_>@B8KJ6W~C=UYC~V0Y^qbzy2K3w91=WqqpGG(-b}+_mo(U%QR#!4lKiAAowlkzT4*F3CfQQdQd*hG&%TnO z5^F)VWiPRpt^mTkc&YACPU&HsYi#RWCvPxIF@FLF6H;9BB=7T~0@x`@DQQ(nd2!Eq zCss6DYLlsbX3f`NHd(H$qNXjaZSSu9i*Lffsf7vDy6=DvJq819Bn^N`;w4W zfxTL!)mhtXHEpRZ*ef{l3QUH6at*!ygktx(N##r;gHf$XPXP4&XdI!B zn^n5>=r(fOD=et1#%=h)S}AL3DNJr3mvJTxNx3zID}W3bJO;G+ohE(<@lYOw~|{S605ZZ8bHF>T8F{yps($y#|?gD8Tb&FJR&`*SAkryXX7SS8o0 zn4uUZdzZN+`H~v7WnEQ1s7q=XKe}Tfn+}WDJOD`N|C8q1{D}nX(!rT z5gymhJzk*jxT_`F3Ac$}j*F)r{y46vP0uWhhHOUZ3x7w``~<4dAr!Xj@kL#hx8+cR z7Ma`k5&qP(bk{Yu4jbc(ctH6>k@PmFn!ojG`$Ch2b2fX&%ese*j@w#&_tD#%sGpb* zm3Yj{4fU(BF{xTYVpv)kTF5}IY+ZW!;=BEOx;VX6Deg-1wA+jNQY0OJW|vjM(#_9X z`Z#lr0Q!8;ccNx&V2Ms4Q%Y;M_8^zW>Exd|ejOFb<~b+%4|M6XqHTPfKwZO33i@p6 zoB=EAIz2vG3yDYLH5&>rHlSt~e&J|+p62^U{N!9~MP|S}a?G1cDXMD36I(E^FE0eE zkM*F(@8d8%$TpQ`d7n?4LpEAUubQ;v6-B{aE*>ow?O(_@x@66PEYnbc*J35O$z_{? zAHJbgEKJHui!x-T^qs@g!!9Sejp|R()XRCM0ky7pCMxcZOfCu&QVwoeGgjA;P<7oS&sSH!=w7XerYmhaijVHu7vb0gJhv7zL zL%Yo06{lyJMUxE7f+aZsk9hiYr!WyaOs>+^sMR>AF|BI?w=Zd{DskIO#7UmhPE=CS z*Q>9+&q34&4NN#pBA}HjJtyd}I~BT9<2qeXx*Z^wpn!6?#cwxaM@UrS@vn7R`gSZu z)Y75EG1sD>lVMrQw@@I!qrP+N6&OTL84W^OAuH(%MpO_wvB~Jok|aaIbh{#XTQj#ZYc~;g+or0}^cLQ;oG|C~d*8TM`?L2IWhR$dAu8B>UQxVM zOspFiA=KOegpcOFq=#9^B{;^)MAPG@uYZt13*AODQ=y7`Gg%cIg(?-7dzg1QxGuO5 z@~3IZhBj!(iRe!Bsb#YedQVQ(Hf8`P;ri-sIQPInWUMSF8{{Yozx zhiibTJknl=9+-HeM|p#A=3R;0;wLMHbv9Vy$3P~>1dC(@vT#B^M>5ilAc>a_p2mua zH?#(QV0UgQ|88E1UMyysUdq%6Iom82I(>)i9JHqk#T6dXuI|Wl!o|?&k?zEujn6g3>w6T!1VPtmqzQdcLVa_fxiR*2s zFg6Ys7hxW9_+q~ng5?L+>JV((xrY~QLPKUU^mf76&4J!TGLh?C`fjd0RI#EA;#nO% zO(#$5uE7J|(6B;tv8vw(UHpZ^XAnH`1>cx|=gZ2&r;U`0v6(4FONd^S3OPy1D)NLI z7{kc`Tch0&^a3jC30E7lC~=CNX9bLQ00nX)nTpa!e~&9Y|K)04ei|M~jbd5TA&=|B z;qmKw$?x-teJ#(24MVb{4EHv9a$}^badEGZF+FI-E(<;yyXi9it(n znL%wYWn5z$E_E6)=hFc6NwKtpxu+SRN@S0X8S;)R)%hdV=*OPN!W6vx+s})MXzceK zZ}eU-_13rY>ilQvFA>Vgxk_g3`n5EGJ(?@L1yv1J!EL5H#h2~QjQo^>gSQe^{-X*j zSi@BISiB1tSr-d<<~beiGR-~d`gFrnh~uM*9_f6v8)Dx7(Ug@#t!w$tJhY=my#1?nNmsBelX=2`?eD1@Bv(i(fLSHlxDu4Mujq4!h zMP~^q1k+Vd`w>}MQAJJ<)|U1&V_AA3_{#ZQi_ClwAzQnhM+fztzY%zMJK)&=*&1{oMpm-Xa)0nazeH$7F$)eRXp1bsGr<|9h*n*@8YQfR#RKT)^!uleHvD-a#Pe{`_X~wiJ!_i0m~H%{0g5WC9!8Pag(*7O(PTY z{AI#vRQZ3w8UdoKKk2yu>a2f75dSO@`#apl z!~}rK{u6t0KLMhMN2mT++iu_m7NID5);`e)r3@cX->OhJdgEZwC!auOM4~>7@nKKx z%_{%nKJqX(1h=mLNP>Z8-yoV^|4M=>x9w)}o+4{oDurQih?jKB9SfM81kmtfWM!BO z2X8CGZmX%yc`WaQ?Mpkn5@s_-m#v`0G-OrJPGXG*CcP!KM6p9+=-2i6+i$2tYl0K3=IE8 z07BD$chs{qGZ3^ku`~i)?!R5hoB)s6p9nxk!0P;i00hX+0Ce9!2tX+#y+0J((0?qt z>fde3f3SxCqybp~K;u7Yz`tGm&)#GJefmE|Pk;4mGXfCUe`=nXng0XH6E!83w9&S% zsjjZE?zc&48eJfeK~MtHq-=#W@PnT~C$*9D{V0$*I|#9CV?fXX2hzTc5@Och!4mPm z6mr_%Bx0dE26GE^3Tf+GQz`PM#%OGcf|be?^5s73Bgj9G6GjS% zN+E*e4f=z*=K4#)0>i$*5{NPY={IC?zA^-N@MUiuQirfWs2a~0IME{RS#~Sc>70EQ z!!X!_0=H(`b_jT#JAb}mWP)LMSA8mxb_1n+IfM8rWhp>d+yL7uz(%Z?9O4({2QjP? z7{S00%48a#7=Y6Y9oVg^3qggbh@uGgH4>Hv)(0gO;muCh=xHLi+aAbJnQjlP81`@u zb{!VBm&|xjOh2E0D_}DI zp#$Uq;L)s%02G>$1^SPBfEMs?2Map@od$5GtbbtC|8*Xq=L2BUe}BvZm_ud&e$4`y z?!W2$0E$3%fJTrFp!Q>BV*0Pw0%X}AioZXUf&ZFme-^R*J=2)~fLH&|Op6~g@B0I* z{(z=k6Rp#4{SGoHrw*-lCkVi!h@%4X;-YqGZXS6HI&&i$IMOlImVUVXY~AYDV>^(< zdRI1{LtrG~j4s(9I5*_)*OyOYczRyDN#}P|kY{S=#W&%!)aOqxri`T2!Q`Agv81!^ zYe|sQ@{kdnMSMKmeYeg~X)ZB)i4EvqS*R^yT}ls)c+j6pOQIG-;(g-3$A? zQ#k?ACb2JCW!eS4)k-N8x!O)a!0uJ<0sc)D5>8RT3))S>e&*Jjc>+y~<>G$j3UCy1 z9rCCs)9ns1z!Q??(LQ;qV~`TcLB<=SaY}h=$ei_5rQS<`hn!RK3kU5^)qlI)46md+ z(o)MJt>|^Rx8bO#vP_Z{RZh9Jx9=#)ftjJ6E4hC~d7~uN7WDRc_B$RxkoV3xW|8?N zc!(^w+5P<2$z}w=^#5+O|39hwZzlS0;roY{PRz#IQAo(f6~JG!1A>>9iJc9=Ujqb@ zj0{X{|HD*I3y9pmtLpy`02`3B|A^oJj$9TtfD`kd05;Q~BbV_n0QTSXn$UmV7w}gH zB_jbN2OHpx;=ciGMg|tZ8_54T(F-0Bu9^c)pX(k!AGM2Uf2}I1-D_7>n6qlc7d5$P zk&fAGv9Ex`Hp>$Lnl$}L?m!{GD)TD_JJ| z{)9k^K zhQ|SFzc86M7Jr|R6L7x9+UNj!u{H$M@E93QGM5HPIJi5&#NO?T6oL6Wg=*c9HZGh< z61Ff_Q#`ahxm96)+ELByqzWPB%`Twx(rZ^S^wi|T_PCAZrmtA%zJO<{g{7UU0u7o z_g>XiUHe;WDPZOkCZUp_$)pA#s4&yXVC4%0cf#U_ zTE6;X$r@lCgCGphd8p#affD#5$VBXe=mX?s4r01LW$h!>7b&Wwbi?WhDPqyZbtCF9 zDdO3J>mUo!3h@fzOnoS;VHory)p;fGBxohzBm@W4!+FBB!!yD=q2z6q+XTO4qZ49; zhj${Sp};F(UN|P5V4R@aVc4NRWBjh4VhERKs)8&eE<~PWlA`PPABLBLkAR1Pf6~<@ zwL&xPF;tusACn%Fm?W2g;IyCwXR<;uzrl+@vxdS^2yg47s^mm&DYyBGxl-_95NBG+ z)D_OfnuxQRXCw4S%R|ZgLX$8w!xKVtha!q+Ip0g1$A&kei6xRtCQ-`HhD*jsnV?6* zPcaQ35Ad@?-B8Grk>^VBg*g*$8^eDn@;!H_PQAc?$nwF8Jqr$OqQA$2@wlEi2Y#yZ zCxB(bMaf@Dl>(!{2H~3~tF;(`5nzRI4V!DE@CVf=mH|O{C#tUWy4rBqcj9epgcpXS zz*sPr<~#njOu0YSb`-o5`74A{&-b}gx&X9oZq1%pFyeq0Mo$>np~;_MyI1vzIoye| zEBteBB;?S%C%KLrqAMDF7w&)}%StZv9ZWp1gq|Awoe6*MkN#u_6eV%5Q+vv47?$n zN_!u@pkFBIMu~UOn*M`!_8Jg?1h0g9aQ0cFizGPX4dlUlkrPXOR^^a{BDb1mwVGwM znq=`(t%pl(MiV%S;mb^_6pr5^*yGE$qatRL}>uop1o1P^d90X1|>oxVu=>ps?kfx4anLu zOVi2Y)9-)Ed^y8ETnMNRpOY4s6s9yGJvJZ>jR6Ut1utYZCZ-_DGai)yHVYsPcW+XZ zbT;?I3&rXW$?$|G;+c&#>G#a8r^E`yxFJBlg%^Nk&bCoir$s&uhSVCUBNfYH145{h zk6~EAt2d<;P)Et*hKQ37Fzx+}z_f;#5r0G8>01*^bcN_KMS^MJ{}y~ug^P-2NkWIys?LqiF;!Wpou@gZlRI;lMS4b2cdzv;cF$lVFtV? z{NV;#DY}ridz%EiHs?mVHs=p~jUjXA4t#pQbl_3Edz>rRvb}_Qc0Tx=^IW>ER&Ugb zPc*KYU2>x5M>?xFE(ul;+=-N~90sU2ZoWW=W1%O8JO5(4K()~caT)Fm7ha6+sN-12(gIknX_&{rW%aiRf~5r@Pk+oJ%hN8csVHeW%SFz@|UuG2o3jO)A28ZUpBueH;M`o zZg>H?6s7%SMx}R)Q&u03I*XYIEHzUbS&7L!{8k|%B#ZSW*EYZx;C%DW!A_n_WTz-t z$I4aA4PT&wx7$J)c&uJ&d;537cH!@SaO7`~?Yq&%h$Zc6)LQ-)0pjY|aGj91iQgg4 zkIQ0hy}wzzc65!~e%bkW^B?`t@`&jC?hzqaxjINPx;m&(xjIk{1_MAz2MW8$O~yn43|6n%dz4IdokDY|`6T{-WX^NCCSD`@0a7fMB2tK<{} zdQW_t@r=={JH&3n$mu_5bkTkWwpc>lt|YDz>Z8X^4qM-?KAPlgOdM4kF|IvZGrBQv z}!{FpbAPlYxu+NeqdMHg;>$nf&bldMt-Cc=^zTrG;k6JE` z%6Z>qk3kQv6X%&MAB41(RyuJ{EUml$4NtJ8JXZR4b^9(G>Id$>Ewj<_j~{^%kDr<2 z`;tm`92>@FN~QE?_BjCVK7w)p6NbIV{xvSSQN+m`)OT_hZzNjz*}y22Xmq$xe`~Eh ziqNq$!PC81X?Z+TmC=ZxKdb86$kh$y;M=SNiX@sBw$oPS}kcj!Y&SdfD?v{x=AM94q_!4;dF!C(6qf6>ivmkbB0*B>mLK{>Vp= zO{e*w@72NAKv4=#8I2!wl=ms;7G&!x3CZ^3N_%uZ`LFRnfR5x@<7dMT%r!M8tuZZY zDjD;{T`#s3s=OB_$^&*X1}8IS9tczQ-v$Nzh$(tIIZIQ7Rv+&97b=`G)+n5* z99U{GKFwzjg-yMjhgLHUC`lTE2I7|Y0@0_#+3yU!K?he^GI+vbw8u1107dN-Er7i5 zm@9mD$#*8I(=k|%uaV<491=XK%odC*u>R-d>;EbI+3f4Bxch_B{8!rWbqe z)NR!zq~%Q_Din31X-(4f7im#d*lkS_r1?TJ`d1iJX}&ke9*A8JqUnj2qZ6EM?n<40=7nv#khl-wn` zLEQ`JrRb&ZHJ4C?X-s=fcn#}a7i{;?1l{`qCwmo=Kyc_H~n3l?A zwgNkvyw$+Om$ey>oeex5j!D>>zEWJn-}VoJ6<)Ue=}SK-r<@6U6cdwc#gKyz_chPh zueGlE9zzjabA`n70V>Jk{7=xbH^&HdeC*b4E^mML2wbp*RE*GHK8P%0RsY@W5wYR2 z;mC~eiuvN+vZgqN;60;0vG_!EL7N{Mm_4HU;Ear(?!9a^2P$tUCl>GyV+?UpTnk@! z0AvH17TDDHbjyhE*O587zVWZ_VttoKx(qXSH-_HfZ3e3u`|HQEV(q3B(AkKCUnrt#7wVgb z@vLD3s;^oUS`u4PTlNmwvFx-sH-(BOW~i_jxW6u-$64R_(PW-c$K#te8rak57R}Dt z?HU$%*l2XMvd*pU+`kkTC33}C4qJj;+I2IW42V}19l=U_-E4uoB_Tj!WLuuAoXAD# zopp2z!bAPh(b_m7$t&U>>U_5+RuZu-S)uPvwh2+*Ho8l(?TDFeTqauqyO&rtLZWXn zHg}L9Rdp&P{0&;JWRV?WB^N6?9NJkP8w#PHn<{IrgC$}-q3C3%aRp~oME?*du_KFI zJd?`0lH}_nZ6|aYELmR2(WY9itHZ`GsSQZ3>Jxfig^u*Dh@urBlP==i`uh_G4d_u5 z;%}J2;eFHu(L)iq(eRRT90s(pi2Z>!=%i*urG>1Rta}eb%>GynD2Q}`*^X*aN-J>( z`}H|u+OWZK!>a-9F(kWN+>!z&UqPWvAJ)t2=t(tEm7mBhaQYS<7AJk9tKE z`VSCRXR28aG9hWY72))0tgMjRK{c_~qr_4i3J(V{bh*#M7SD-Rp1@PBQ z($7(eb-3|ZKBO7?-!`lQ{w{N;abPO{v?zAKt+dUdYR&Nb`N`q&w(QyY9vy)$z|NfGaQ#QF_FskJPG?jD-i1+KR za3LMpCjQP_Q{Iyg7GlvA+GmK#nFG|!cq_`4NLa0dzm2OWaQ88sJpR&_WL+QX#w_=8 znQQt%=A^()O2&CPfZri5#-05el#(j8LN<-}!E+BnNPAC^$6m=7BQGOSbh$cbbz)$w zvW0~HUdeZK@%aW#h4lF$85sRJM0D(;?w1m=vCK>c44fh%p>cGzDCq+8F)$!bAk2mr z1Dg?ZYvBM~0<96QiGVpv|4FJYuE^QLl;GP;{DsEFq@2E~U^FC>VE$Z=+PM z2Jc~o>&PV9!>6&nhe~0+1tYltBiLb)lq#LDNP?n@3`XIK=l#%$;#n_Ic z84IB;8=&iKux@6bV6!4ktNMenZ@!11lf{h`Q|Q}T5IH2zSVyON_Rz2(nPtt9SC_L1 zIPNGMO~L$aV{j&cp>9gJl~LV=#b5}-i4aLPgkmN;ps@9xg{vCGKaOgTkBf*+l$?zZ zp7{YSGgRP8i-i!t#8R;MduIZY4!wt~h9wwsoAEm&{q45YaYxCQd57rALaBZjO&U%J z!K8WdHOS4=f~)!4)27TGxrWeQWPeeICf#)6l-*UaQS>UuOk)(n9)@&+33cf5*bMdv zef|Jf6fi1_sq4MkJGqBTg-Rf)ijJtjd-MxHQ4^Cy)EL7UYhp$tw{{`+$`up88Y;lkHavDbfM(-xd4f<@W4;>3w(jDU{;(2=wDGsA= zmXBl|fSBH~>#Cc=gO&ge)U^}C!|}oKgS8t)kX+y0ef2hU|KebRJPc<#;Gr6PnU5~Y zCBZwR`qRng>(m-72xq16+^zMREl#GOInB$Pg{JuWeYqZu3K`XzlYW7JBES@UKKB;!w!#}fZ!hLS21YhOD&0Lz*!`~#4Fptn> zXaY(BHgYBa(*V0>UTo`gtt5En1Wv}jUtd1vCBOL0iNVb>_RW5#6ZY^SAu)P>&+HAe zg83Cp61gHqRYSV77rM{hJYAw)(CoN%OLd1yQl~0*FZV7>*+7g+79 zD$Tv&MOJXi^9mMU70Qc80pe{4CPTrvmpuh zI$8E1Sz>VOSLHFeG0rK78?1XZ$7+DWHOX;vgI&9}NU^v4N>P`JM`efdTh&4IV$ECL z#pH9{`>)6slwS4&LYbpYPSDwIAR@0k@w__Y1~N&sF;=WlveRTM{RyGg6xT7is}+{! zk-1|y4f_;LKfn|!oug)^n)~9|{8@jG2_3w+=2Y$XQmq4FY>K#<9q6{|d;zl6@bEA- zWjE|RRVV1vhj5b#L*f9O$Hf-M|8c?&lNz1a=OFm0)~Btlt(lgQ!DKo)iKr_g2}hx8 z)Dm88IFO#H5SsgXx|$hT-4^@N^G>HCxtK=PiJry z62vPiXu=7%e(G|aVbUYsw8ce|bo5ylSp)M!ndV5C^xp{!_YV0)S zpGyV2N9ka7&1|-Z{&cYe7jb^JQ37O{GH?!csgoj<<>*H@Md>MYW~Qwvt=WM{sjeY% ztie~@Gw~QAj6^DEm$RqGOU=5Hss7+lb(= z8b^N)+UtsLS|eq{cW|<7dR(P_*Kyft?ec0KBX1jXN@YVA$`4`Bwj0%^TS@ctv1YGz zD0A!KGrbjTHZ{pI);)2Xi5r6^7?=b9q6U5cCx-NXF9i{ew3(wD0`4C_jWx(wCK#tm?sgNu4edNG>Ew zPzg08({pDG-~}GtDt|0ftLuM+JqdNYokK)I2`IZGTIClOb7T%*8Op<;hM<1!Y)_Mu z-k&3@V~E>424|I=`JJ_sN;!He!`@Iu7q8M;{-UOdGH4ygljoJqPi|21RUsF3(7a@m zr&ey4W=S9TZZQexb<*UEGW9kybxhjqJtbewD0n_d_fRf4S*?-%x0(%7Zu5-mf%L%v z6WaKh@_st~Z25IcyNppNb!wM3RIgv3uiF2Pz6g!OibYpw+!wkti_X4rE{tP(Gudxs zLC-~hmU*{h_#NF^=o~8(>?Eer#f>sWRE}0~wk9Gio$PhkRmk|DIJHnw$wz|4=#xDh z8A(_URluz_p%IAhGxFrvsL`qj*CvE-ctpU^E+l7FGi(_QH``K0RDJ%hWyq2FY&FoF z%hxhS4|A%e4F&T6E<(_NL7N-TZ#&Oas@(O#+>%Z;rx| z&p*!*QItm7V*Tz)q5sSGd%aR?Go;h>rMyJ(;hR0Ex2AjaYc$5(@I-f)bR_M$dL^GI zQ&zlU%s-=j19U&ufb)NxHyd%hF4{~NPU;e*!bITh>-T zDt|XD4|#F#Jx>^{{y1n~J8{kUEPg*hs#cQfHn>j=bvlVO(i`tqoERTRdfD^VCuE;f zmYrdF(P`0{kk$HNI=g-2%;7^()*j|(wvG^Mz?<$CH%W^sBO-@nYn?){{rFo&`Q~Z6 z(rY#+u^?(5k*B;VYCavj4@5rE7kkAg-M zFs-q!MTP8z?bB3QoN!9$hJsl7wZdcmu8R469cnRUzt{`K(u*hK*JS&CS;1yT{xLn; zsHX#h@7ylF$3f>J>=)}*>q%ScO z@$&NJliA6mmdzpR733V>{$w>xXW!((k!bH+%kUzXQtw2U^$b4MH^wTKF>|Oe3ScRm z&Mz3w#{lfR`o7Dmzrc3#^A}{LQDLmq>|M7{8CFh`TLu)7ReaMTs+(|-`nKj29p3RH zO^=t8A#Uav9BTj52Wwr%6^+U7*}NU`VW(r)Z3quJBl*WR)FJd#AoDkvm1E5w2Q z(WClxePr=|2WRc!f&qV3z4h&0EA7sb&G!=O@|)Pnm>XW=Cas$SgC%BBu7yWv3a_0| z?(hJfa)W-qy!VP*dU`u)v6{xUuj8)+l77xZjKqzKLGzMJ3dQTFf%3gHyL5;2gL+vl& zr<-l&orVHk2FvSOC7KM>h}9ArqIDGjUk9!kz544pKVDSgqlrg#C+poZ%k&Y@nj_-P zS*=N2-l_4r8C zx}`B@7{OX6R3Pz-I9}s-&#?7|-u)eWmERIPS&c~4FC4TwMYp2{=(yQEsjK{}(03}U z=b28{Iol+6WYGd=p~=*XKS#RmvmofB3F)A@!^E| z;;Jh#A}MhLvS7&)4zc)E<-A5Qmmk!An`Wu_AiG=|+A6mv&FvA4I5xTrGtp|4Te#Zm z&yxP0xhYRzt!&23Qm;-8ddaM}GSRUQY&N9a2AEL)u)oumbPS;Tb_33oM}fmn(DoRz zEl0X^Y{A+0w&ciaQaAhTuW$}jYh!@>t#g`S7xm9hHQ+Hlgz>q-oufjUnq31baksA^ zgYi!`wr3QmM5Jpcc7v%xohmikgojI9^iQ`U$+3AGlAru+M#jRz!oywJuZ3R=tfh{0 z<0~N;= zd-_N(3R{^1&DKPa5EmsN^{0>v zu)A;qx^2E|YihFOYJOO`r8(+$oc;}a`#JHalAyxSLDi1qv?u|mlF&_a1i87;;k@Rg zrW(ce=zwLJts2O3b+Ua#h#g=kerYMZ64*IW^!I86pe#f zLWo`6z*V}Gw*#WT?p}z7qIYCKsnB#eDthLt3f+b=nE4JPls}=zq;ztWH8b?Kj_vPx z^O+f^a%kDQ6;peWx_wjAulD%^yLBRi`Kc*PPb}Wt=@X=i3P^nE^442nJJ>qwwA(2W zj?DXfxLLgex=ktPc-NHpRbQFQw`40bWKkT(Lug&M%MWQ|(YjT8x74oKQ#HIC z&EHO+WOVru4+H{wyy}PNHiLrLK2X(-|KmRQVa?O7^Klyg|&vgpO6?Yh*5zIQ}$!${zKf2;F=efNs}b)66pgncGmLaG zgIgw`T&h$@*7@w)2T&gWFI?h<l%MqUu^Zj&HO~7?b2cO z4-`LTt(~=*Y~Dw${uiQyN6}eUw9cB0mxtiF+Kl>hXzzmUPBSRC5@}f}hVgooRm_5g z)Cu=AG=NuX@qP8j~edVHBV4~X@qyvR;&8PBNH4!l2s3)pssK`J>j_ad8*Htk2d+EqDqes7C{?Cb9TsohD%w6{@ z=$5rDITQK?25hU&(G-kt?eoi=z1e?Y_>TqO?jxsrn5Zu6CoR^yF*`>OdB(M_SF3p+ zX3msByFR^-&dOdMk(xDW7V z_WPNe65hfTt99&Nr9dz~%rJ@98y>>@=?0F*-(}x3p7CHj7VmN^1&t`XEBxu6p$Sd9 zyz3<@Ouh24ygWw@x-@6Q3`YO!^}Qy|_8fY}9XL*=p>jU!tSNER}vQOStbN z)m;nh7e=BzWHl;*`rMn_iKt8bT=$94*sG|Dcx@k)hNAnt9`>0pYO^1-QrF^UY zx-b1{6w>~`1?JP=dGb#ed!(p5@0}JL&E6e^XB>BIcI%gN1hluo;XU8p)TMtUk=Vp% zycqbjFg2qHJ_P7!b^PM{t4`L*Ik29quAzYZZ zEph-Q&b)jr$kB9x>M*DCmjbz}huy(j!JTg6CRJ+npc%=VgLN`IhmBsYcWW5u z1~B3!cP}0FAxRNaxAmdJsD1pn(I-rs+6`rpPSNPcq;(oQyY2Z%NDY&+!~Qqa?`qS+ zkZ?cpF1zjqO`D~s<*@~D@U)5c^-0bY_VxGqe@Np7aIt&Ds52h&RitpZOrGf-$Mt>1 z^LaH>+~YJB*&b)hiOn|^2@kMmb^{@3B+wTh6X3p^!;hO!BhXNo+sgRJi05UwS@pMb zj3;>?$tFYpMR%G>0TPG^M2)S%93veKh7PZE1^2tM_|!3pexKO;^RFjK>o`uGrOoOv z*|U8i&(z~e+wx}WR6UH5k(qg|Vg&*^=Zys~moAeB0V|_ikyH>!iLLmn$>e;(QbgMv zgm$E{4r_cJ%)REKpIhHS zP|sETn*Sp*`pJ3z&xq0g4H#NN{J&u6|B-_JB#r-rivRB^Xzu@(Fa5uupgI5hFzNpY z`sMy4PQU&4kmr96@L$;We>pEcG3WnJrt@3UjNPa6V&qa}n7B1cimJ3bTD65~Z&sA+ z911@Vx=@Y%AgT58$gy>H&?__Rk~a`l^ll~q4D;xh=-CIEipH`_*b2mu&J8fhgFbX< z*RHn4OU0-4US0}SAS;8HXNPzfAJe}^jiSYq>8k8*J!5-e8{9tSYMQPqy-h%hgbcMs zL8aAyFq^B?L-&^a-d)_z`jT8OI(nFoPKSZ|o8pPHXMCJ2k zLMU>dt7uXMl0$G>lFUtRI;t&GfB#|`j5 zt}gq3F2sLL+W%#$`CkLU|F>2BpV%<|Bg>na^OHhn=ivGe8^$LH{J*qe{J#V-lmAbH zm=U>nK4tK~%K?85|NpRF{O6hfdfWd~BA*;EH!sKMsQ*ndpU3|jVEaOjkFLhj>iyEj z7fkq&;9!%XaA{Q{bZhbIuQXD`V$n2w7&K~X82tpLi4OXLOUjF@e_Gs^zZ(2e_RM#% zKh*Q{owil6w;%m$9_RnCiuQe>$7%EO`{i>@rPG+x=EF^uX>Id8c4|v|MX7eCR1RA- z#e%|Xf<%y|wfM7kEznanH-q)-QL#q?Qif_SYJD3nS5-wZpI;(+Wa?e>J7Mgw)2!N^ ztZG$!@O`cETvzrEa7El=u;C>C`pk8xjQV{+_yv!Q!jtKawW9PHPchlWT*E=7eMid6 zIFE>E0!LH5;){djCs!M%Dy$iyWf6NWF_fq-b3&j;%H#i7z5SVQ^quq}RhHxUSf)q+ zBbLkQ5_$g3_je`ptNmZP@NH`W8NuC)8np1}<(tzA4Zne2+=gF`#*vB6gW()^Fn9dP z)MqC*!q4?%>Z0hRcL7J8vk$(vBu8t}o1r}j!iWJ-&(OCnN9MCK5i;TBWU&|p#Q4)~ zgkQaaTgA$C~Wwl#p_)co>(NtpAQ#5#*EtGwN(j8Z$wZJV-0^ zje31$iAu~lgggtt-^-6HnhjYqR-`%Yz=OIhP+4fg_kD`q;`XTL~{`bNO}R06XWS?kNJ)yYf19K+7ZA@Du`i0QQ)> zrGQ$2J*IAjRHl?ZYXll zmb+#Sgn2F-e4;>Wzzwq-nw(AW7hTc$QnCP~DXu9TDFlGh&!DEi za%IVi)L9bhiX8klj0426vNSLbsTfKCdgRqu3>;_&4e}>|51?I>CuFr<&b9oXcM6j1 zh#IIKU|#OSBZoU~lcENos%XRj3|9Ow1xU(8s#<3O!YaPO$_d28?fIvO1EAz!RhMi5 z74z0Xn6%?Q^B#yXVXG^0&&hz)Tk87cTZH?p$YFU(Ipq7S#ByFaNa|g=9lDh`Kn5Uk zq6+XQEuOMI>8pBH79bRmJD~`WPN_3dN4O^?RAh(|CZ*M^4AxqG_Gh< zHjtWM%JQS|2rnfl^;Pj&gROpjqv91`ktys|?9T&WGdZ`U!HNDkau0fZN%J0OyqE5Y zdK?e%0eFJbdJ>fSsd392D?-Ju>>58ILj4q;LYC_P^_pTFPIEsXc7w`?ci9iO>{_|* zL2+yi;G}k~lu`_EO6pS9GNR&_7}t?AqVUPuqyBwOIgXU(pTEbSVl9_X;gfAABK0Q~ z5G9vi&@d`TTD(^b_?|>e$uB!6$Bm|X%Qh|vc#*q@!E$9gHeoa6DGB>Z<&(7cCFMo# zg36Y*oi{VMv&R+f&XsrEh@mrXPdP68!swC7S;jX2wD9l~}XaNFK?BqKRzL}aE|M5CM& z?#_(%Smr!M?m1;y_BjavQ|?HT4S<^> z``flG8zT*wmOU9?ZlK(XZUMQlB;+f#nrwKdV8;XtKglcGvHaFw8*4R5Zz11y{5aHHuG%hyQ1XNomSf^WiyfDmAc;u98w04a8Xt%U_OX%paD_^f%l(TYu*Ov7m%`)BBs_BPsnYGf5qGX_*cD=Q{U%j>K zB0xp$1u!#IC86?#hV@zhMc|pR$`#`8vl(EZY!9`*-C-0+>p(G3wt~8bT>mHFEMQ*z zkDUC*Ex=N5Zlq)~75Pt0E%on0Ceo?os52RdessLRqVuVO<{?_n{ zeOJd9OxJ67=q#K3X7I9!;;dB@#@Yd38YS0to+!O4OFT2sinelpM8Bp7h9NN1Ftjm z@%CYT*DPL}5C{p0YVdrG3uf%hBTX?=%Q$c zq!++&h2fa++dxnDsn}O-cM*fmz!ZrqR+y^ra7uF}n22m2CIZMXZ??Vp57ff;sHD1747a~HA z00`Y6|1uQDH;XhBif;n*ha6E?48Rr!kB+L?2R|T22cI>YQ2nJ`?2E)a-5C8ZalA*A zS48EIk6`1z-u{^_S}@h)7k{)KDBAwkEh1+~f0Q1`4@l!s);`gG(Z0?8!!4&RPG@3b zsGp%KeWP1cV2VeGF0>7(%TTYrwJl~a4IknLL~Yno9|ridXt4{~2$D4vukU7yAI#(p zD}<5{sS-N4g#hOBMixRO{SwtDK8t`F9MvyrBDxG0S^#CUB@TvYBU^`C?f<_%AfbYN z=UY6^jLT4tUpo6iCU|WK>+p^cOJS#d%FfJfu!bl#kUF7^efwJ+bx?+gEMLAjv$w$m z;nw=J)i?{4Rv=pmfRK2hJargAh-wpIUAVf`hKE5T5GKrr??2`)RQOu59So1v z9eyOT5U_Lmt$>s3q-ts*+BbqPaK_!Bv-e5zBImD;mw}2`_(t!M~BLG zG7$~azha9j$Efd%54U+P565sSm%`SN)J2+_(JN+&nT!k(WH+@KcV-mYR`oXM3Pb9` z`mqf#V2|j7Vq8boj*sp|jz4r6F*JXe^oQhMxd&>GVk}l%g&i>}!L9mL81};g^+rwi zK%L{PJ375eYn@_?u;pkfx5DKTLG1}3uECHtar5~Or3-uF@=qDOpA|UhKcW>}a#^u{ z#EISrPSdwb7*f<=>umeCNgFbH#-6$utphyYDE#vBd)3ZxTeotPnQNpDaQ~fSFU80V zyX{b11$(OsRn=N@FJ@?mFO@1AA4^yD`%d}X=uwp|7IIC0udEFjzx!>uUTt3>MTAWp@^_;2=bKU%AD>kWT>(`7XxXtxqf z?!4-?n5l7T*`#+I!SQBnan&mAM9E)g?hqC1eNp@;?7MQlgX%(?IBY~g!f1IR;aJ;7 zv~=HH^ld$=ck^u}QJxI_;Z#N$i-eNyKIV-t1uYJ$NMq(h#S(32<7$-W#rGL8|9HQE z4?x;aaNWiiF9_0j+?_HX6aJGLAYChUrLkjs6>p@FArj$s>a$*GgvlDGGi1M`_f_Wh z94XoePi8o0=i4ykL*ygo8q1aM(IKV0VxQ;-+P2LZ<_-Aa;|gb0W++bhU$1-Z$@?&y z+&umMBZLoG;#{B$eNUF|^Ggj*XEgki;!w=nKT)CsF*wfvbp4>`mJ6qUIBP9DwKn=2 zZNTG{$l*BLMb`4l>WXYpr;FSb9Ff{zT|jBu@mt%^Hd7UrY_9q`a#2>VP(kZgnB9@Y z@o7R~JBx#@_}dWMinqMO6|7yesz11HU)#pz12N?O@8tJa6}v=4q>G9miI=EIuB3bBB>7Kt_g&nRMdr&cX8EG>hAdstiFc+8s~7 zLW1^(`eLnfS3-&+%JlOR`&1yqyz(Cji$xfBFUP}6^@A`QRF$u$IBa8ocK0o_NldX) zOC|27D7ThN6f~#%(tAcT7^t>!eiKouPNR-$2W(I&thVhb-pJExxAf_$uG|>u{VZ?R z;^&xivAFa4jhhnd8f7J0S@pZ-$4M;;-wnHDRVm$r-Gx7XYp*psl0c+IQBN;ssxIA+ z!ud)|0itF;YnEyr%p*XviD{OOlf()nGm8pV`hswE(-dUWFugi@5}Y)u>is^`9VzzU zr#CO&dHEg%k1AXxQBq-SP+X1?-rN3!%dfN=_Rup6PWLx;i^k>NG{L4eWt`@S{p1osWLW2iDpAtS`@yjMh;}zK zgj@W1l(TTlf7gOUm9=W5X3R|BX?*x-$N4QvD#57OIb1k5^BUK5Gy+^|J759(yw9p( z3a=O)QsVZ-=PTyV$dOu|yW)Rt8EHSU)O>K$Z7ECJ)+a+=59Ao#k4LpgwT1J`N393s zg6LRw%+|fW%8{#n?gmv{YqogMbs&H`hkhw}J>}}BPi9e$W+iW!VkXn?r~9<|BDoy8 z<38u1Ru;2uU7k5sBD%Nz3mFNWcxG>7ft)VN4sM(hM1|Ao#b{bxoTwj)H7jis!uwW1 z**aKZsJXhW&B9O#CT&98ZYy6W(!BcSW?55PEIQEzM^bH zl{u1a$2IY8T6q%nRaK3H)mc9kZmlspYme}6b3?*O`2^k!T`!a{&r7Z4$&AKr5rD;A z;=!=8J~gVD-n*V>u~L-{;jfU>T3t9wE{S;AC&b?|qNMCFrdJI?XH)4<#91?i{+Uxm zdF|OL1zRRwJ7q-W?mN=)_7ibG1^xNns;{rLHAwRQ{oCJ2({Z5nr*Atr3`VTQy%-2% z;qu@(QA*RK6jrmZyq|P|N4v1RUewS$9~_=0DUwgdO(Y%g^A$^w=uYU`m@OwfBvh8| z4j_W82K{<6bp5pv;rbOdN((DB*Sx8Y>x7d_>4NSrUbF{lst(ImTM6zQ^TiW|ZL)T=nHdv>7Nxe{b|}!fH;kiIk5ETgv9_q|6ea9QoqdaQD7moeCnhhIgpsmDK2+sDhD49E;W zSA&Q-e`?%nc6Im9Q<*I5%a!Dd!F|rYUqv#|2{Yak5>sa6QBlp45{NVnDK)BKyn6_5 z!>Bi*E3umK=pQn5tw*uR)03-NaQIblKLH>TEumtzGwXdGeL=&ZXQ_u8JsBuAiz~-V z2_2-t!*BPBu?p1!#bdAx41Y(Orf1|KeX{7C%;sb(JIXu|5l2fj@Gnx<>*;I+&-m_| zv4tLT@l&2y@zP)3!$FQx>S|YrvIAYqfFsm48m@=3reB#+M!V4ZyBk6OjZvUDl2LpR ze(2;Ry9pM7+V#|u&qa{T;}ORs9$tPvw+;R8dq3+GdV>&gDkE`Y z4tVG#=N(BzBk*mp_{uUZ1!P9T)lAB;BHvXFk~Yu_Z0rukaPe0v<($&UXqC@Wu~Hf7 z<~7;4zprf>=XPV6La}~&bIB&x$^(vFz1T1-l7VU~oo|aB|*o7_KtbU{xxToPviO5;0HBKD|VmQtbxDj{_aE z>}5q@Y3%I$qZ)C4D(*#IM2%(UrYL>6ShR`6Js&Nl7IF!YGjX8|@C%6(bD}1C$tehw zMdswBaFFf0pO{c!iaOCd?GRz2_4pm#%;o~dE*<~%ft^$~GS>Qm{dWYaqk}dl-7+>L zMZzz4V=TNRWQSo?_rc#QauMu#N05|!6$ID2^V5Mk14$kB4l?8$46V;I8lXWcI-EbA zO&b{}GLrU!;X7$6S@{RKxv0GR#-OP%n_wYHlZhjUhz7)GONyBbZO)4ac`_s*k8CQ&}r4+qr)zoq<;$9>Vv#d4qPqu77itfWutfTRFGIEzT2hasCLG(^JaU zJMBdglsk`VpjOI@`G&n-{JIl~ey%&BydBv+;FI?ob-FmOrB^3zHfI-4?Dr7{w#>FH4{jMYXLK+Sv-mw~i%4O#vV2jgHtMrE?wFlaz*tSI{tsV<1X}H_ZTM3IRy67{pZd0e{I72AJucX0GZeE?=^?i zmH(fsIV7}mSon{g!_{5M(*MOm^N&T8e;>{NlW32~-=aPL1s2cxZ>^XAl<)cX;=})9 zwE>nc{=Map?GOGA43YqmcbLC{@P82aKNn_TgW(@2{tp=c2Zv_`irp-X9DjlEe^B^8 z7dB=FU_OYGkOkO9_Xm#u1I_<+TR=Ge4?@qv!SNqIV*{4f{ZrfFKlRN1`^v`530w^S z`?kYz*%JmN(FZpedIO)G0Sj0~G-#jbmMvdO9sx_a67ji^HK%Fd`)6%$QVcVDCj7xn z-u>PKd(@!i_)3dgtz;SgzUV!Uj9ARtxHqIQ5tE*+L;BIp*X-2L*n_htj!^^DmuVIm z1L-HxQF~c4$L|CK>DniaztBkG?QJXg@Ee{+?^$Fr9ilmKwCc*CXKL3S+22kO3`f@7 zYoX_Yo;-yXFG3$~NCQ!)tDA6#qXZ+B4#~dT(~B5cuk!HL2lQPQDwosawZ4C|s5i&y zUvXdmx4uKm;(zNq>|Xhv-y-aD3;>oL9;+-;X1SC!QfAT2bE8cG`wl_iOSsV<70Qnl zs+=uUKw)T|OME|v-6VUU6#EW zRRq^@^E438Mn_*<08Q6z9re{OaqL8=Je?P9{Yjn8uu0VpcJ{RCfTh>-WP^^lzsz~| zFmbYWVQL7@9ExTn;^WRKOUA(bQ5e|DPF)vspNeZ(Ln)+OL{HbNu+yDIcEpDtZ_nn{ zGZ|B&lnTW}hqIwj<&ATUyayk`tLdVHJijl!Tw(FF=x$=}RXSZG~`J&c9dXS+r zr7(QTAUGk2w;dm86-9A9ox?%+XcP~``N6t91n+$>cY}y#b}Ki5`Dc!k!n>PFEz}1Yj2ira zd_nXc{0O?^N-6^q@yHwK9puU$n*tScA*^Wqb5m5&5ybZI>U{Pebsk88gI|5?`-92T zlX!owa96ZDU;5;b#gP60^siv{SoTmSo+wvfqWHqN z0z8pRQNhIcLZ?DJp-W*)e!+y!Vu~;Veg=IN;*v!E_<}s)u29veSG(epe8z4_SDzAF z39d-`{#fA;gy#c0{KBUKR$^8{YXMEDr5&L5+!&qk_B1;fedEEYRcjGIY#!&2Dj(H^ zVE^ns#jQ5=ZXpY7>@4!uJkQ=eiVN}pjLu`s_OQ4ZpC znEKD8sNaHPLSrIhf=*&q`BOD?eapeMNJPREIiQR<(~;&vb;PDbnn=vZ9`om-kQ&vrY`Qwt9Kv4mF|FG4>!BAY0SVG~% z9fF<_9089oSD1ajcC3#w`|+pg8Ll1s%!1{RGYMsh`9xo#8GRq2u84L(`=I+?f*&ru ze}pITMpC{32dWQ_Ip`h#sx`P74sb!d5t39W^t%z+@#~g#pH?tC$pKfeCy8MNWLu;w z{1vt88%`gM`f_D;jZv^3k?z2VcgViC&m-p!S)W2*STJVQ+Ku|1V{oRyZl(y2-@}VV zAF%s`+ZQ}z0EaiA{2f}=88~5Aq&v`kf_)%;yXtq|Wn7^u{DCSLf6W;C%AX4vSZTzv~TbI3|Kb8e^@oygVb_MmJ>kV!Yd4Jf>w zmEdB$5$o=>MZyYEII-9k!m|=_MfR-`@fn^j^q4&SuKk!i@~#8%8SSnI#xswk8>TUb z;wsphjJbJEz6Cap4TVVu9`I|_=w8AgWiw7FgsXxLRKGZFAe-U$RHL;7Y#^GU_e7)13E6+Xe%f>IXBzxY zxabQ+=OK(!e1Yh^$OJLM`L`{movdHN;af~c1LDM~KTDBIi6Pi5A(1f&Rf!>x4oN12 z%77L29FPhjMZv!{Oq7uJgPDY>a=;YADFJB2FvM9~l;dJR;20UgA3s~j961FFi%fDJ z3LOw4Pl$qa9UPdfNj?Vt4s8s!M-q)F$oGj8hnNZZ!8t!) zvxuYZF;+eDMT-GnAx=S>{WLOhMDT0{w8Pc$8M_pN>4a!S>S+aOMQH)IBpAfcNbP@V z^Z0!{ecFAv!t6P)_G~+}!cfy8Ln2@b^PIs}!k=OShJ=j?U!e$k!WtyRT#*$0!MaH} z!1}*P__ub8?-CjjUica6fjqGeF-Gh8w833VMeF^1#oZ&5zx9qDZ(F?b;`{xG56?yS zZ3(T#>9Amm3?2u7<6;9<%%*H*zR^|6MhZ%|Qsvl-gJX=zUWTYs=jbI~!)L);sJ&Q4 zUgvz65^V{uqPN6=c8tr#cl(5t$uh@TXKsEs6(KZ82=Km`+Q=pm@^pHwisn#ORp_+% z{Y*p$J;TW){GE1%HE(92(gq8ze1#J$77hd60X-9O#sz}v7rXc>ga;(&P`w!gZ*Imu z9X`wI$(^5@Uk~9A!CnFL{RtoWldi5VGSF2>1Yk?;mnNH^tKe#B3|UiinVWXHzZ(w~ z9HMb3+@pKfT>aG$aJL4wPIrxLq_GMQeLqith|nU^!GB$CW~n1>qO5a0%#r_LXHZ1H zgrkXc3Jna%qNZS`p{BGt$`)}ip>yF}XQH3N1vonga`~QRFLSR7m3M1oYanf+SRstB zE#q3ku=!)Vu=%fG{|?vpDvG4H??Uy@>ozl4DX5FHKvA(h9#OV2Ip!{=P?CQa$^8_A_zOLL+Grc17R2U3Pa0irInH)1;z6 zbGBr=a#mgtm9_|z<>>v{@_VVfPs(ORf$z#MjgM*v?O|w1@ke#Wimd_k_{%v7s%-a9 znV%Y#rDP)A-=Twv?P|o1?(&$Ya1){?Z4fBx#^GmadN&a6zt&Ack5<6NO{F#Kv{JP< zc(CsmxCF+ftRCvS-T>M8`U1|hm1*>Cms9cbBO3%;!$n_0-Kg4c9D-#>2xEGzb(ZtT zT_vA9ea7^_8B2q3oop1*#)ML@$Dvz6En4bF8#fQHYiEP&ti-`G5{0R|dmxt=@XwI$C< zxq%yy_SdM_JWuFP;ndq>Ud)`r-g10|nX#1y8zaRb1yf@Z`|rJ@)fW$a_Z3_{4~DI+yg)&T&x7LifJo z47i9Q!v-}`Jfbsj>6J__0{(^whhkc4C{&2E#Nh~3MHf}T4W#~eG&g(Y)R*h)z zB>J#iy~2fPkzfdVi1Rb60dLZwOwq2+b%%N{W6=wqLmGKBJ*8L&`L11mnM`I-c3_y^B0XdG82QI&=EKXjR=Jk>}^OUa>5T0YnigPw|b^CU5#g zKES&$AGu!eCdDwtmK+}muyuG6$q@xW(EE^Fy&3rw>nZUL=pZia^4*M{mdGAnq&0~T z_lYp@`D4#l&#Dy~X}~1NQziJwNoB#5bm3AE=0o{bEN zxd%R&beWwWehYdNoaNE`V$>Vs(z^4Z4#)|>7)rWn zSV-90Fi>#!9?Cp4;VqE*=@u$bp+h?)EB83Y8!x&Yd!!ra*{bi{u(0e^RTUx5n~+pYjyo&6;pi3n#ydfoKDzx zyJU+xZCj%`)l^yG%6GIVwI-DW8ryl5;iCLR3(e-+MMkQ0r-v~=b zXE*9I(IPu*TZfX{3Zv0tY!)J`+_NAM=$))7YAp(p6*k}pgbe4)&EJ>4v+i3AA}4Wc#b3TBo? z;v{%**2oh5bkY?N!CWtHA^s5bvpBIjz~;@)&e=TU(@!iUX$;fk&@2G=78%#f&SjRd zaqRe`GA(WHVjp0$8A!EH^~$?DH)lau5>pm5^jI2v86xL0t~NIjC()Q7e?O(ENGY@Q zN}5hae})ZWI8kd5{F-ir0IL>80=YHoclqmhRU*u`2cidfT?HI2A9_>Mx;#vtA0 z4y`OT=dq&|#BUad3F$h>2o1m6S=U=8Ed4`c3Gyt`+zb2xc2sm zmN6_54oB*JQ;_WA7z4A9zZK&QpB=ohN22KF5DY&Fic&!qNE36L~JxQ$wNmh;6`2 z8l+nO-JLPvt5fiDr3WJdBp zy*Eh_vBoU_gIQycUpnperVozSPlU;{SMF5*hc>8F3|iAnEa}oO8VO=XB)qbx@IHu6 zL?u-2X#uJXJG;ojpv}eNVDu3wai;j#usf^V@!PKz86K&6U#Vhv2xWe~tKPT0u7Snc z1sR6y80{aHK+IRQXuL^{JB{0)0d!){-MrG@)gXM{fM=MYe?Xk>xD}PA)kSOM-4ISs zwPsN%{f71U_6^lxPYw`GBK!QgE@-9|EZ2XQltRrT)MWAUEO5Z`iB+4T7~kuq+-&Q_ z+|cb@A?0OZh=$~O+6->LnPgD(`ntH=1c^*yba|azVcsSY1UKJe4{G%E=5U7`Hbr&S;Bi)to(Af9J^A9=y37NMJ0c9!9qDr zImS*+G=++n-^8+3v@pgp?(038o3CK$nB{Mr_VM$2$^?u`-u}_!>qym~qO`k(q;gVm z!Ksf!TBmC)U?<_XR}T**PEG|BT<;yxBNc6y5rZ&nd78Cy`L|68!aLazQIk0N8i156 zV#}1F()sr}rzi@UVn)=cRcblu^mMG)z~K6p7OrVUT~kVypN0m|dgcUFSq*DXybHPD z0XP*L4*r@^V;9|{ZJrz|0dCCA@KH77uaFNTqljQF?WW8tW0S3Wnj5?KPm+>U*dxRb zmvqB6^<&zJdg>VkiD|s1nO~>#Fd%(JB$!y+WeXmZ(N*VO;A;wh8#(D4xF<@C(A;8E zf0@TtK}jYXC23yLSG;N)vGRoQW|WjTc??3Sp93Yirk?vo8UU8Dmk}UgnD514;K}$E z*y+e_cpBa1yj8u!Lv!*?H=ZsWDzsMM`~7rRb&Tb`hyfP<@TeT$qiy2k=*2y`h5Zr+ zSz>%waD1{MNqmHkk|K7vB5pAXE4@-m=^?_rjraaRLxr`iHJt`piHz!qYlvd$6gUp% zVq+Ps$zg_ zzr{u&F7y;mN9@SeK~E{#w7OjI0+Un4ag9IKI|XAkb9a#~HRE(Cs2g$Bh+4?Yo3F-+ z+>we|m1FzP^8tjuR>gqrOuFkfC zzI6+vit9GG6T&@S2EY6LwBaRp4c=GQzzI8jilkKq6rzD&mU;QpQepO2zRWQQRGBn; zw(86j=guWLet%-$Qzw3dXE1eJN7T_#N5?x7@To(uj{t0Y^R!|Fd-EnZY34Y(Y)8p- z!&^YXmve^zRjP!ZpI9_mYLrf=nuSmPZOq%>?(L~B z2&s~lYttfEXqGBoLv#AFB$nNWXwfgY7MY8JMQoH0gQBBQ29oEExnNnk>$Jn*_ zGqvR!0kw!-0`c?cf;h`->|;wg$+@eZ+_^o}|UsRdaaehG?v2q1S#`e=QP^+Pl;7PL zyCgfg=jIDo+(uS837NsaRJWg(y;uJ*_K|2o{*LUT9*5gFx6p9bXWiK5;mCY>Uw*MM z!*m~0YocVkX<|)xI40v2zBbN}yShH>{!pCm;)R#Ne{xR$@U{8Jc-_F=!x-;jcl|s( z=H_4VNT8TLh5Hq{$t>!le+Ls<#&~dsvZH zc91#l2h3;3qIuuAA(oZko~RusFn#fqs2Cnk&?>>uuBmFEkz!r=oq_H9q{0h)8=v}% zCH8IU9_C{#;i^JS)FLt~BawFelp$<{ zQOshIG|q1j9~x`Q`ea+f8_pE<(e8eZOWgM(U2_-45t8hR(f8YI7A?m6J*eJ*9`j9& z*mGg!aY5n*dtEy>M`by+1l_)CvuOTEX{H)B(&vJ; z1(8vV@sZq3J%^VW;@V#8Nkp!iQ);!q(O8xJ(TWMgJsJ3Nn~UWc)H%)B*gA|TUe?|U zS$ne7Hj!cwX+7{fz_2j6XiQkA6EY$T|8$id37@mq^k zd95XQfhS7Cn4+Q~CAn+MH;MyMo!nuI`oanfYtZ1&r9RA9qrck zJ^yH6)Hkt3(HeR7?C-C(hPsIi=(hr4u7)m-t@;`y5t%WktuC)PqL+j=G&0N*Z^QX* zAf@)EpklT4z{>B3rtbHTF+lrBRxFj$@gbrzZD%q2%jib2S;CU3GNub8o@Tpt#o|O! z(G^>Tc~X4|XFF*r7Y$W^dQSZdZRD-8TnZzz(^K0b>MX2|2>|+)LLYaT!y5p|qmjT! zmb3}iP&uOJ?7Hh|VCeE9NDG$GP&|zlzu94i!e}4&9axOluFTY+lg+-SwDzT%L(w`^ z>6JvhM`m>Ck*>bjEZeyi-hRCzV<-c)Kl{eCRUqKRlqK8T4Y%SaLPVwMy1tgC!F)Wk z?Ur^hR7W*m?51n0Te6~~wHiIm@98|Sv=~@+6wuJt6I-{_vGcl;M*2LRLP2lK@K|7c zU+g3qB3!H_!7J(6KrgU=*doO=pj)1GD=abZ;8|`jV;_&FQAC$l70uGcQ>%KF60c%Ntn7()`E+>$>}9@=IGmnPSP|}`%+o- zwS>E0Wl^^NHj{^el!1a{vRtnGD49X)U`cJ$sk=e%#{4h-_F@?AU=6dorGmYls@DC$ zz?;-IgiN92wEh82X4h!U{KIa9hBT{)Bgq79@1I7UIz#&q;Q7-kmDCRuQgs?v-4J}a z3i9fyp~AfAg65T3)-e;tsVZwqUE-w}59l06=pUx&MI@e{G8yIIrlWm7cfEGD1+|Ux zU&AE7nWixJ7L>G_Y{Y(D{}KRet3K7%p-6_%h;~;T`yTuH1w_fv)H;T@v#ReX60!Wf zV3{H1c{w^&Q}71?fmyCdJ^WKGCg!j7S%oaeU#1M@tUe3(KAZ5-#3Q*2_gE1Xr(hJ|smrQ9si+hA?a&aBv7vzub`3{%d78dA9Qr=-`oui(W}W#q8iq*=UUj;E zn$BQ-A=)6l6kom>em zfhFKE+rKAs%e-;K+#4UNx4%_pXl*k~Sv6-ILDgZa?Jb+t{2DlN7iFvNXzu7WJ{9>i z;kb}5cQzEDVe7Y)HD=TseUFiDlj>eiU^N!d67T zVJ0?4Gld&ld1pakxIIlPCB;C2ZL;0c1_`0c>a>$z27h&AbNnMzxx0Dev!px?pp;H- z;+IewL?!67uJ$ z3$N#e1XlV5yIAa!7mvoE)&U&5fj5snh^}hzq&};G!o*2>Q2uWX>NAfagIGxgXsQr) zP{SR`>0=mbKFK>EWP7HQOhz%27mENQMj-05K+ld7_FQocH^x*P5zxJ8T48}GtZa^v}=w9BFJp&q;0S@t@ zr`46%D^@-ZV%DXsrB1hHX*{x)w;Z##;361$bT{gUk(oJKdA0f=+r+c>xVXfo=SWt{ z(p44mJ(C9X?#fk1IMWfGhL}-fm)gI%CF0(${Yltr3NdH#C?hJO_}6z?RKEvO7X)(A ztY3kQRt61np3Z!iOksDF)Yu&hbx7*P$xc5pI5Q$X4M0vSg5in?=`qsC&%*|&prGu# z6QIXGyIWC?*9(#KtC-1MXSkl~S#P=Euudn=mclq!e726J>S}F_fvkpaJ=xYa>CULD z`%K0#qq=YQt@`t0Hjd5ut-=b5g^grXD~7sC9h9blrjm-6tcKBq^s2NKE$)8euS`B? znjq%S9K`xcMjtW2xq-+;sJHOGdV+?hnRj zKvwf>(Nns0V)4_|aM|-`GLGy_HR5HoRwY}HVc@=e9Up%`zZ;)`{_YT%RG(eg4J?flP+ z3zJk-QxHM2JrQ0HM%y{;6$d}ExA><{k}X-T=u4HZXWO5sEREco>20@N z(4Dmg*WkaNL$gj#TWl)Mevt$*x$Pda{<;1W%;~CJDURrB&iMBj@I8N83X4oyN}jal z$47)xT&LP6clwN*8a3AHeJ@W90zGR9(u9*-%yQ^Ty405U>ac}CwS6d10OQ7)<2 z@uzf^{d6*Ccf-rA1Q}MGTucN$dy(0?h-s;B5T=mKT9Brn9GT4E1qj$9*GY+{28X%v z)k2s$c9<oOvRi7e1T@ZxBn8@}NHQEYR6MHdn5?dK^1`tjtLs_VrbpaLwo+?%HO| z$FxSDxypWFD#TpUM^8~*(~8&oWt~Iv4MArk%MlFE=w=62et7jNxrWEc(o}JDKZbRG z)a>wNDe~~{C<6SOx&~8jGRMP=eUImo;?(5{no&{Y2<4(8tz8sL7+mI5 zj?4<fW8ebRDgB={2YV-m}XB(#_?fh>#TY7aVvrTVDVJ* zjT`2GZ7+E~7OWnCjsze(H~bOnVkzY@s%+c+O2bvF8DM4P>wma^3>Hw?#yP38HTP1Y zxvEv_$zpwQtl^#BZ#gn7dzZA=z|y*qVIT*~p|rN#lV-WSmaK6s94BiAR8H0<9OCBl z>OEp{H73y18m8cPXPMrSUCNEwlL6j8+1$tUr<9FR5^Qp!U*_$R=dkmUo-6E;cy*`wzn#jLoBB+vbT0=BTlf_j`PO$bU z4lcGhvw0z?9ZmM^1vY+h->+?oBsj6Kil^CgP~!S+iMJYeGubt3>t;n)s^8tswufNj zlf`_%@~on$Wz^F2X8J9HxpC8qIxN-Je!TpR!XX!7V$Dph>;!J717U--F9U>p$-s}q z(L^&rrg1!@F}t748E*kPMA!B7E@8lB1$C0swM&hz)e@Q=nK4nGp6{{g{&6i(mwVfK z0ps^~y5;b8KJm3RhSw#c^idQvL7G<*j0CQcJLsKJr;V}^GW;l*MB^wJP2wUZ9A0W6 z%Uq(4C6qh;(R!`rjwOi7x3cF(eF&jXic2^GyjmOYcMj4draT-EH#{D@czco&b_+;a zOkX0#PI|TMIVWvpfuFuzJ4oVj4SPLE)D??pEQ_d?JYF~Xu8iK)hRxQ^oUOXn^A2X} zSY?+qhQXPBZTqxHc{EpDn1Bu5M#q4&HU5|$!d4#s%Oc*Wa;gl>m5O$HC3axK#E zN#<2|N`~u5Z2dGBCLnRiz)`D~eZ8WtH?>T~S9WRzFM=(<`@T85uhpbsRfMIDM4-cf{Vg4}kf4=_1 zzyBfR|4{OOc=*4L0Xr1`x*jlm{nz(ER-TFZ->(1X_gMafu>af+FqjRb<6-_OO#Rm# z`djk$Z((ZSxdQ)f>Qv{S==dtbL+Al{#n1mL$2U+p*<*;Qkyw!Kr>^hPIpq%P8C~2n zr8L0ujR5nD6bFQZbjGtij}sC6i34lJUux2J-tKrtEHGC#lvPZn-$jSr!qprfwqE?! zPL`x@QCjU-TnJLVu$T1$x0Pg3M2%`&*mN}$JuCwc4@k-7^5fDeE(T8gOFF+?EDFL= zFg){AHB(W@(mylI*Ub4j zp<+gv^=+OLrl^QcUI4R13T;aDdw_5KC;%wO7pqyz3lx?>q9vut?#m057vO`lSd&u9 zr;;~PMkh+sHNytfDdejKD05REsStfHxh;vd^doDh&XZDcSDC6~YELZIb6#wHZ&z-2 ze#37(bozzmHhdd2LvphFUC?IJ>Nlhg;T8CpXYI|u4lCnd1NFBj>+jS0zbS+KUkvGA zLFxa&Iy~E7J){2^mHz9<-~R0Xh)T0FbNpS0=VS-|Q~b9xJMZ}qIDFj~|Gw^uK)gb@}Qwb*%=gS$LRik@!z+q(pUpfcT;L6k<@2&%|z20)&0TQh+dMDq*5w zSbZGYcIJoEk|px(x6OyQ&Wm!FbK8Tlt4n>waM}77fK0$tg zn$J{uEdAt)TEztxFUF#Z59L(ZNo?MMV?{ z83ycD988)qXpEFZVv;yfb0U%qykjb9_EYH0OzH*w)2Q3P3SzJpSxBbmMNQ_+5WNjS zR5~^H8)}4%3J7}XA$5?$NUPijwq?tM@-o%eJ=6n)V)NteGIveufq|-qC8*h;*?8IT2H-soKqDT*|G>Wx-qJ$Sbp-?)85_ypzYx^_ z4r&x7LsopAXpVS}kXGckNYMaSDH3&c4UE5oKT}yPS~l1yItdyP8ZjE-o{@>0I#2k% z10y{o5sm@0WgwETIw7pjphI%e7Xe^D4pJM`mykLYh7~6;IpT6yMGGh!Fw6r^WL(NR zk|m_FBr`#V+$n!55?_!2AQkV6A?TMS+tixK}kdk{$wv3myMWk~Tj(Tos@j&jzyza7EpQ_g_SvV4dpTBz`5|)`l(CBYCBO`2ob_ z(eQ;H!F#?z@rxy>G2X!xcn4lG!RP^8k+%z>_yr#sE#ING`Q;yl{0Ru#eljH3{X8_v zkmEQ8$q;( zOeI9122Z^y$Ps>N?Qcuui8{&~4Bp`bB*M?dnh>{7p!9^AFt_pjTT$-?v2JysT*yy_ zqMt2$I=*a0`g>t*(Lldo02A$=(A&=bt4Ih$xWY}W1_VDpH|nRe8>Q>@aoGZzkV`v2 zV6~$dB2)AP5>8O=q2?UEsyf4~I?Mu?WbNVy-(;(4_as0IV(vuJMi}bY0 zg#ptD7SmuJIIuszo(^`L3N3}5MHpW3LbW1`A~_SC3I~&>4xnhLApG6=BFIFe8|NHuFgZb8A2TqyC+ zN7p9b>-qdbJ{wB?mC{PoTr%mGkgidW^ty;p4=y+o$^n*uS5F%P zP?p!}kzO?Y3V`oX^gs6JgmY7YcElGj>CuLl_mR(Fm_1K45Xy%lgJ#aJ$I7NOD2T@- zM$^~3M!v3+GB{PF10Xn40Vmy=*dIxF2(VQxKyC?9CFOnUkGOh6Y@B7vL0!0wx64}9sGMdI_hWb{`e`}rt_#OHqr;{O91((40!n_z%wb2B2< z>xbVZpMNJH3F1kQunp4fN8oKH;VW_va42D~H-%gwcLqUzKyF)4dBD!t0$f3RPLRA| zx7m@rt(T5p6|If7$Gg+jH`F<4eYZ?Tr_rL&gl|ONRd? zn15~yZ->Ns(S`lG?xsDL z#z8w)L2Ui(pn3$M8Z8^1Y^Jr3S~YG|HZfUUo@{2;c3YA6*aezWV4o{?N<1^oN<7s> z2Z%Gdft7v44ulR*+n~s2Afg^!j#;~1`H%<%kK-WSIaAsg&7=-T+fu}sVszo!PLDl9 zsHd1i824P+Y!2PqZ^+ButM6Vf%|Fh~5H8G89+*X5z9gQqpFLb0I=v9*#x` zI9Vy!t+D6nE$4^U7@Oc=|?OKDQ(c#ReYCZ^y61O5o2|HUae^~~>Thpy)tvS0~ z7)mS|kJ;``B@t5bi}5LWA97Q{AxTBB4Yw-N#MJoVsza)Z9#IDV#;W2KGql|yZmS|^ ze7Bt;t~OsXL>*mOb{y=4e;!Z5-!cl@1;nN<5c9Z(fsOXT+gC;bF*;g%yetF%?WKGj)6%Ae?|~H zYRVfZqlbD2IUlHvKTtf+^db&|i!`;FnoDrW`5m!iI@W2vT(((yQIjlb%=eRAR5(W^ zD_?`uXJIX|NiJzUuiXe#gn}4j7U$qE?bBc`7wumnsuAq}IPsx>ocIK+BP1fmZNiA^ z%Yycohrrw(CUnM5llRo*T7Dz<MFYUYa`jx?T= z<{c3P5m6-1QFL7NN)=9KYhv83e3gBRL;>6yV)Of?+y zP6vM(xb*d*8~Mp~hh zIg?t1W2#b52|b3fURwj##1Uf6hHQrjpLqH@0Ow?zgqy^~Pkc|vPy0EFAESL^{nzQj zgS@h6eUd|`#mh&@wgO4FI6vHLh!!VY?>?pu*PLkDP10VH~| zUxKfOuDZnibQEfzZZb)z+L)3%9DMd}_AHa4O1IqL*D7?xIzEYKhM9yZ?e4idfQ}u? z?1hn{XGVREpLrbLV}ojp)-qT?6nq_JcyNiXjO8Xf5_I5xij8jx^2EEg)ytE*Ik>wZ zc8T-ovgv?GdGNX8aSf!KZwulP>40Rr1HEQZUu8z}h{O$eblj7<#&8RI^?8kX4S{Ax zA9J`yyq3FWs_Fz+FHE~g%vjxS{vLS+>$55a#pJl&19#=B8NVYc^Cn^U5z*0F}TilmV&LrCk?(NOXrblu5!5 zMt_S6%pnuIfmj^|DLz8GL7(oTUsJo5Z^p96VmL|H5N1HfWyYu(6J66Z`@}d-#vU%I z>=BE9#J<5Sam92B!2wQFN*~Vf)@wbC7bhN{xEpL&TTEOp+hlOq%k(hAM4#Q&9-Lgt zHJ6vCHyRAxzDYSM8TrX~mQ^&ET6|YA5pgpR^wxEzOzJm#)@G|6E?Tslqs|A=?Wzav z)nAssc{9$@j{sgn(Vtkx5r69I`()|e`W1bzj{IG?4?*}Xrr=YG*2EN=yi(GvvGlv9 zVru50?e^PF*mxU(ZmvfTQfGB?)Kk9&Rfl5eC_oW_7$WdV@=;5BHRX+X_QDofi++i1 zV`eigb5PoxRmO9+ikv@6+Pn^F9w0q-;3CJcJc>otW7(;OG7RvxE;E0DyZEVz?p)!TSe^HzHn@bIg$0Um{^KqfKB| zYs-W*)p|^P-+S=2rn9%2%FKjhrt$L2p@n+#j)A>HM6k}~VBncx?}hS_n!!X5Fb#$R z1sd_>p)i6!vIrom(`Tko(P5v~b0Tbo8w5WkfN3>6h~^VhS|eM_5FZgpCZfPXS^MSGF^vBhIv4== zJM3zD8!Me`gY=*ce7qZyT%H=-h+Bv|AFdZ8K`?=T#JveC{VUR=)^<1h0w7RASwD8d z+^C#?#8q4pUQ@ynD8#!Hc7vy?3K$4buGICQe%ejs`^b^P$Nl6aq&$8n0g)a(`2fB8 zG*^+$b|xR$Y0~5-2#Kiz16}MlyfU#am*@~f3fhvDGu!MNNyHx&&_qz9LJYebFYJV& z;~nGllKaX)u-hHze@>Z>J5tZmiPz5K#TjeLZ9(Q0rkJD`;6@DXbSt6+?OGoiT5e#W zdsHWRw6Ew+*Sr&c+Mvw#h&RK_*Wu=CCulj60WBIjlv)uLqO*-fj}Z9u>CDV~!$0)* zXRkMzDtE1J$Ln&?w#_|YjZab<9u96MlK<8E*SFQgo))abRko;`_G!%|?O|lxOKrf5 zArYRmm>!98f9wEsMstN3K)>Qd2b0&*H

aB#d0$Rq50=T*g>X_qHe#NieoXSu#Mm zUk&IFs_{FG7Lj8u7`b?IF=~(VzIO5oAUf#Kh+b zL6c!jjEd6J=TrqFLk@TZ^+|{nO{Jfu1#;-A&G&pI;XZ zB`vNGwJa9RD2L$CDqwT^DVjrC&B-G5ZZoIotx3j3nvu*~v50!{iIY;hl#!5tKZy@E z7Z0ofA?b;!GZlxWZZ=@ePI6BZNQA=0PU4=@IDM8Ty!8qRF3<51u14jWMzX@=MnY*2 zk4E;NND2%p$iAXrM#i{D*0fO_L=dPrrvMZ z7(ySecG+BS)05FDv(zU`ZHE1;+700QMNvj#s*+e^F{?BZhzB*>dbSi!kag*kL!K=sKH zAkv}o#GBvHDH3$p2rGpmU(4O${X+-F-7h>~=S;xb%sLvDXWPEo9`bFBwG<}fEU_K; zkA?KNzI4pB?1JF|InG-FG399H0uqP~5a?ukx3R^T-nglol||!&=u?osbn(E(7RHW# zTr^|JWXomLv)qePrjUO0r*bIxR~B(cBuHf9(+H-d8d6^;^wCct7H7nEgu#+8;!xkh zwe)H!LF#Ub3Dsn{8sA0WO+-JP+&>JwyxP;4c;tTfgPSMK_8sw~xrB21co=lQwStm{ z(b>tvX^ZJEDVU4dn9m5+%<3vc-b4OzxSJEskkzuq?!he+*;seb?4f@jVM1V2SjAKvPcX|HM)}s^1b8X z*@&pN8x#|_dNPR1^^DO=J%&Kb_gmmf4HK0pE=E<7;P6>a%h(Ey7~X6Ts1yTHgb&k| zs2wgH7cXYeQB+WrHc&Ivj?)bWWQL7eURrbt-+dFw6j+44Mb!5o(pqM&t*+U=mD*b| zSF}guG0;G!m_8?EWLhLrewMX_Ti%3_7gl9rNALbAa~@|BO;j1>B>hOIIdq;<;qOKs z;IWSzAUrYuP31PmgD%c}kWRDz6ye@NX~G1Z^OUwRJahL5Jy{67#8nsNj^$KRT zi%Oef7@UeJ$-w1mMh#RJcH0lTF>{LCc)KZT|V5PA3NRiLE)DCG^bGI`Ex4GFL|W)rhyes*d{iIb52FaU4W%>4+Z*Wmu)@1!E~=X^Dkn0>iWo(h(b5 zQtX2!(izfcuG(v`OR{CF_Q%8yJp*#Jj|0KY+qD&C^t*cV#TqGMSMdXQ{h0zKgTT3Qf!+x za`iV-Th_9-L~Lj6)sHx9AFy1K1`7W?+9t@;CPB&7ih{pdC^#6F$t9dET)v#_ip6}Av6}M1c~Vw|$;il9Z2Zn^yM9cx>|pY-!m=*@n5^6L8WJCu zcd*GTn2}6dfVX5qZ1TJt4!kiiX#3M+z0K94iE_}Gf%$`;wnks23S*O9KnD%u!=`Jg zmR8--pP5|D9(nhrFCh1v{T?@iwv|5ytAzC#VdC01FF{3qnP_Yv|d9c^)K*GI<}Nq?qJ&oxcF`R8|E$4J-J4a`sSXj4-2np(@| zzzOoZgIW#IkAqbc0kY1fl$0D}nJEK|7BD$l5?DdGaYtt|6CBFb86KBjgT@v^->p!T zm1m{bvRaCJji1QwZgb%t!>`8f$TJU@Hnis zyzDJw*Rl6>Ls0P@lAAqmRv9fvJ(I{GC5?exiVP zPyi#i~c zaV}85x2kJh`LG-oZ7W_N;Ep{$R>M`5E;EvvV35(BGIQm8?k8R_7Y?qyH_y^!I>rrR z9~qQs0+JwXa~Rt(tp+70=$vV*bpiG4+iL!apQS8Yr6jcxuMo3W?qJ| z{3((vM^e(kc|e`1TWKC7J?e=L|Q;O4uK|nRjSS!&9u<1FaJm{voJfbiD)gAe^Z$2K0 zRxT5e{%+SDbwEsz%&9L5PTy)3sG5Hvuh1?0W`#0LOw7f6wlWv1R}nwNgJ({g;E}f$ zuMHTVToW#w>NXH9S^%DN%}Gk8ev;r73KS!)icdL{CrHOuu}JWqI|(1cx2FAXC^(F zlsGp(f9GVDzfiEiSY%6+KSp|F(mk#7Ed86-OZmCNedxI8~`(>e1DD%&K(@+P(|$^ z)NNk6<>rj%)@lnn*y5nOnv#MaPF_|XFrmq=rKs3qulNeK;pwUOT1a~G{1t69%jQrp zpFeLh*N;y(&$VklnxdtA5~MRnxN( z5zG-iFwXkR>pOp$s0>H@e1Q#3+)xE|;IYek1*s+sqMdwMlX7G*i3i6kjXLn5XA$I6g{hD z6K#C;B8N+>bMoFOd^(n(f!^;ycfx&JH6x_vRT5J?l(I&+;;`_eM1pY1z!LW!sfg-I zKDh#?vU<7{WFl)_Er0sFkS4|zcN(@jYRW|QlFeIM|AEo_`mk#Z_f!*2&;P1_xcx);`#=(&A)BEAg`UYo>0 zq5I`}Jk<2gyPZFh>SP)jDzP*8#8K2`KoOf|83Qd=^bv|sxsKU0tV;siHNfhUw5`HAClOPb?`=j}J4-KRqk%husQgWycX#cRUVf=+~zBS{NCrzizm|9CzoWrF;*49#v$$F@NIu?xgsVgM~Qx$3N zW|d+?CAPALtpR5vgF7a$%-U9QtcvKg<^`?#PdT+O&zGpOw3{2G(u~N_&eG94V?igV z^+gWVl;w37$NR526+cTqypV%-t=Jc;EGxOSvnc z`p{4l+bpotpH{=(q0gD};GszwK#d@WX!@C!xrA};dw2YXXS|{|yR}P{V!tuIHrHu+ zrH*n+|B@DWZ&~WRY75Tqj__KJoVxQDe=Ad$0yXxu1D)eaD{Y3|N?3y3!W9uJZ>$_<1H?j`OQT&~@$c0#1>dsMtjX?qY0EU&6y9*zted$B9XJP8vlQ;DN>I ze4EEMN_5*%x^jzV5R`eiqauCvq*Hm#0$+_^KFu+wGihKA84+7k(f*QZ%JSvqO)pkD z|87Isa6_|a;%s)#4}P>;uP=(M9Vddyl>fz{P-|C`SGl7Xn?8dTm|=?DKGF`^&bRgJ zsqNI-bZb2GuB#w&WY@4FogPfIQQsPlR({4i0JHbfCUb3Ql*$A*wzPz4<6+eg2eN8o zJ8=6XJst;BM12f6nnP`uFVcOAce6`u&58z9<*R>TewprnWB%+YD6=44qjBDIzg=0n z+?6mV3eIy=RbBfKQRBIC@wmO0Mu(JZBzWe!>eN>_+4U(BjGMm$iRnZ>3Xc= zlhQY1dQ>V@6fVWc^0D~0Wsw`K}?cd3DuOLrN&V`{>Btw9Sx>ZWe7V_EbY zdOAyz%IWz93moFk*q%Kx7E7%<4WtuVY$Jar-ru?)z_C%WW z6dQTqtW!hRRBR?a?NY3^khIeu$&9~+;0^r~#m?&jG1D+ObU%?MKpsJ^&Ye=5#kuMw zaG?2V=^Eml6H)L8(cp|26TDY+?`9B9&=fS>VtZPuYY3YvNkAQc7q{mt5 z;w-;X*L|&|O_~F>1lqx8I_ed7slgT9(RzH8--s!>GJUl>jvZYRw~B6RM?Rn&8v*4A zF8H!#p3r)cqh=%@2)fTmdiw1a*{*0b*FramRLvqSvahFaxhYgdY%(s7@DZMRB339? zAYpN0zkgvh54UlhNs*kyd+dolns8G;}jXAEKygjH>_>CpJrF zh`2V=Vo{RcRxHOy8#a>{frle*32T$<=^u=8I$BZ-pH7j=#qv0dHwY7HyCpJDk%OfR zf==KIhO@K}%e8d&4Bk7S9{tpcCN=Mpg7FwXapXT#UbflW_!YSpn zWPFL~SSV1zuSZlr8b;I!+OX4?KdK1I-T=v#D32Jww~gbzWcNm|RX4pxdLr6Vb-X8W zaJE$nWb>6ZYtIFvg1&5VY$36DOR{?<(N&D4LN?R3t3t|*Is0e5aac!VYQf2Sodk`) zaaNA`Fh53;WfnC-AHR5#)1Y z1Z8WMds5fPa2F75Scnz3_sbgwM~3xo>v8P1$q;z21&7)xgkmn$q-sRwTT8XGtf#kS z7OHsb+YH(|FO4*g%F^!?KC&&;Ig}cBDA26VBOZG5S3*5cZI-e3B{(zdx5gx5@65ghbpI6$QAQTew8R<5I*xbLi1jL<>+xKao+3O{?v+bNK z5B?x{0IpQjH@~9l4OW^~n&Kw(B_-~2(X5!!QdIgAU zWyB_wYzF6r%$Ls+YywMX%M^-^uxj8wDg%n|q$A_XXg|8}@PDHU8gKKdn$>%5- z)j~;*&IGU^KWgD*M+NCLEF3b%I#nFW`O+{~877S<)5n3&gHsnMoo{_d zemVC`QOUqZPkZW;JmjuF**^#av%Xhc>Uq)e1KbFndQeUoKT6ZT3}k=V245d;vAFeb zMGqxdg;%zZ-ZG>~S90<>is7}({l*rj;h!l`))X|IiT&1DvY;_@crlFpa*XWD1w#ze zz7Pxh$ialhjndnM7HK6}o>_x_?!< ze>J;*HM$(U9RC>mtIPeX-2KlK=l{A}|3-1L@%~@9Lv^O)EPGhcVK#rt=a{s@CuVS1 zbmB@&cY@!(HNjOE)L_ikM(+jMZE#zriUI7dzOswqn;blqxNr@hGRn5*(0HE6X1iw{R)WK%~i=Q&Cekk5NvuYApB}t;;c<@y3%Yrb*Fw+;}P48!FQcSe>60Csx6n} z3>B(WQrZrr6CHn98LlGK@nvMZF5RVZUR2FxKtzY|+(-Q^Vt6hJEx>Z|e!+^i$qJhA z`hZao8A^>V3L0-?4Dm}{`VJp9qlo{xlT2{uq2q-t^TkHV0|7!@dLwRsz_BLMR``&5 z!cpos>=s@0`^?1uCJg__`~2@T;=dyFuPFR88uA7fny z?LS8TeV6|Oz~o?I;rUlBH^<)s`2WekyqD(grXtbUsj#+^u|BOmFVFYY)nP{S@RR@n zA%AH3E4=n}s-KA12hpxxkwvVKogl?k*DnUMQ&YvO9K{jY*}0KO$2`s9^mLKArl0#z zy9*rz8k_zUbbgHyEfey%~x2TPWlsKZt!=g)M)XTMG zJe~*!bNAMCa-NV+i80ljDpA&m*Cp57)ege?cJ&-6+4729LB*L{uZHWwngDG)K7?7n z%2oXUylgcU2!?1R!Vg;;b<%y^Cq3_;+V<&o*Y7Rc1R*nY`)gSl&ydXR9W{aL&oTKiD~`CL3NUbjhxmV)P`&?OZ68(pHm zLV5s$cp@1!nM`!wAek|#l2{>0T#WqXckSEFknvr05ZhdiT4bXNE3uX$bb$)ibR?-N zI%T0a%CG?z#+QspA!E(J_78hn@0%U?R?l;bby@>|F<4#k@n^>3dgv=Z=v>}Tju4bwR_F$7xpc@?wNoh_-6zK%uEsi`Nc1bGTuUx zZt>xs@NEcD=q?zL0l^4p7(^7O6sIJQ2;y%6km1>~i{}b7pU)t=Ujv@u{R2E-5q=*! zplvD4p4)co1PEiEQ>=snp9Z)yePFO z!joi=Y9MGpXuxQIV!)XbRUK9xJ1N7HHYt91KLFSv87C_zVW3X`%Hv-hUL9}GXMkY9 zYJiagu8yAkdPu@RGDzL z%^~(NCuUOQ67v|rIY3JcB`5WpM6&cHIvs*Cd>jIHfI~NhSjvW4&<#DMEJZwe7=lEA zm>2|UR&1R_A%*;(rwGZ0a7C*z8KBv_KC@tUBf$R1%+3>PfJVXV zfw%k-MuG_qN$v-ULlKTC2``M{L-C3FMdUH_GQ&apzJiVX9tAH7ql3yz;xX1f{_>q6 z3^3?E2$+D+!i+>0BK4Aecy1Gxbbwy`643L8yUKei-VOJbtTek${por@CGS2{xDfV= zX^XIX4=9zxYOGv6E+=8w8$?NU4eHq{O~^A=xb_J*3<$bIvWbjQ7lr;N%m2~_zK?l)V{YWy=wt&FH>X1 zuT#W=grFi}57=!~-&^b6vo~|JZM5Cm2w-FEh|R78{oHG&fF0?X>2-UkJvnFdcl)2h z9#r@4gq*(;?NPQY@uyXH-6`F5MVnWN1(8;4NGC?%lQ3al6m2wILxoETYnF(e@wW|q zX9apC-ijrA1K-{&$B~N9y{=yfThb4fA}ha)HAFJY>JH>w9z{}rBl@xwT)SW&))U1R zK$d6y#r?ycPyF*YSjBUR7PvhH8rQtl!0RvZ{EFuyErfe$G%Md4b5{%Xj+^oJsNx9} zZADs$_W0th6e~qr@b~EA>78W=)w6+-wJ>{Z@g;m))LT61kf>W;OSr0IxIaA%szU+uLab>)5DJ-m|>2SsGtwO;;b)Gh~eeLv&4K8qoKmWKtzD? zLALkX`*;nH0Zrc}#_~}XI*&LGQ-2E@N>pJIqaHe9V^EoJKLz{(H_S48K$Df@73Kgv z^P6b6jpib|J>nW?IE}`)r@sCBHQ%riO;qlw=u*Tr{BT8b*hU_-hOmUk&y8X30Y1cW zt#15oOEKcVhYaXHjv0&LsQ?-=iUB4?ESO&dpaY{^KfQD4#VE2c5hLEgQSXV;TxH zZ90AV<|FnSV~=MTtr@oC%Wu>@?RdLykvU!wny-j^GVxK0Z;{s+!v^taib5jp#C4t@ z_F&=<6f?!$arP!?Cb9)0uCa!F;;9uOY0!-NiN)N}O{j-aaz*frv? z-Zx!IcZ59&str?a{x^_AUi6hg|}rwzf^ng?5^U|>0OBj*dy@T z=;!G-=8xANOQY+Nx)48IZVOFkK^NQW$&Y+8cDhwX>H;e(XD4{4_hX0W=j*dS8$9ir zJd_`>*ScL85Hf8uYR(xh5H~#OaZfRR=!-5VwP$5wkfb-!RzSd2zT(f?6~Yzl>3L4w?b$` zzpRSVEYa?MlVKw~{ix%}+-}_BT8_Z_nseXH8^vFDLzcO0qU2^Sj1txBhX`heXY5m4 zBvlDAVW?oJn8J2WZ(gXOLiZH3L0m@44tJj(26O5a*(BvShO5NteDfK|vQ7!T$CK=d zJb=jRm+D}hM>(@Lnx?A$nkn|EdU8{0Q(7P1KFmJzsA!#KTZ#?$8Rt)9OtWO1i*}KG*XYi_< zrkSWC{qis!i|OGS*-T?^vI(gfSqV=5wnq1bb1YT-DNwsn#85RZeQ|mp&}1W1ZfO_$ z?7p<4I4r6Q>tx|Np|{lJut)bG&8_=wzv}ZysgM`FzFVIIv924!WZ$cT?kd##j1EX^ zsVN)nS;UOvX8pOk6Z`yHq4n_>=S|J)itg!#%fX)qZdl-;m+DL`TA)8OEU<{)25F!E zm#dX66zmN5; zWX-r-J(Rd$IgJi1CVxhIULb^ex2ioS5Ne^@*A*e?<;oF8N+i)_=He3GzS_Z<$Cn;dMw9Uz^_9bccDh=hUO0+7juw<#MQdL zkN}QACe~OIYj-^R`h?LAhOcgDoZisk$DNi(UL=7a0iUWK4X1S>(jelljfBC=!;YNZ z^Rth+19@J!FxJIP&H`n%9)y=+x@-xWt$ zeLD3aKN{Q~Oi!rk_Nd5?bzjQPuo2GG*_#?unf6D~r|Qk(_FI+zD*fFuH{r}zkOhx3 zlzZ78Zo-8#aq4DERZFq2Kg1CD3IuTL?)2h^7O<%o>x56U*|t|e2}||`d2Ds0Fho^! zm8I=f0~rqL$kaxuYT4?I^K|{5D9T5aHDK5cNEw26juip`_CQ6qQsfM$`&Xo}C*6=B zo30Cg)x4&tQw(Cmic^^IT!bIVQ+3I3jU@*?DaV!orXJ&#FOhIZQ5-y2#Y7WD2mK0`wV<~e%dyJe)ZOTMy z!(-B#357J0DzR}jfpznZ_5HMUsAd(wCXXW#n=f)MI0S5mWd+B5Pp1sH(*)J#ow4bp zcgQv2w6e7Dcnxtu(3AMTZA_+AS6ZYpdCMvq`!my5D;Kl1j$}~F5;>*y#!c8F@tB-Z zP0k3K8T7vg5}sd5Oy`czEF0H+BtQvifPw;ys5Pb2&JCuVpsld@f%h0n3e{X>c&ZDR zcDVIxmrY{Qp*B9C>f*nB`r`egfZZ6uQL_U=cc_Smh$_W7G67;Bh`jeVCG|}W5dX4M zOl9{?(Ofl1 zAznpdN)pOtyHsa>x{!m^s^XI>qxcu~;)HZ<@Oux5bIAd8QhzDr8eo_cBE<)I3F+O`tR^fran=s0KewoRM;U@l8Smy#7Lx2(}QC5kE z2=aJ710f3Fi8g)fqj&KB>G?Y7e%#~xt@)nn`0{KT9v6TG|>?<5G6ee2EWZ?LgfA9amm8I-R8O^69L7K*TdH;+6 z&dY$yjQv&m&JtF2zuvRhE=Z}efemoeKV*J|BE-y8Zr)w)9A5@GYdjtUfa4-8i_3{# zokFXb;o93A@w_&*;}H`O4P_Xw$1P6TExP9y$GbZph;5xa*a=#fLCoRKAxtQ>sGgI7 z9wJeE1t@xvi^WKe{s=0|4|!w{O(SQvJ~NFbUZ3TQBw(vJ5N71POJ^P<99H1S@*z8_ zr&QR^&dxlnP;`fuT?O)HC7A~(jNmINl>$b! z&vt04kXea`Y`Ax|OmO_Y+{^?H)#6@O%d9kB*I_Q8L5K^R7!;n|`j29GmVQ%RrLaOc zUV7pF2bEDbwx%%pjqi>(Ng?w+HT?3#h{_;&ftQk>5R6Jk8b+rwC)-r(13tBukE1=T z=ecE^=Mn`B#Hd~dKfD1<*5<^I1)`ZJ%2Ydt-X~n8`(OY2Vx#xWV6^h{@V{0LZkz7H0#32|B^#Ko57gkO)jhr+qLRdwy@ix|b3;kF0sW=8@=t}mhiY(KR2J({b*4^tw zFHXlcL&6xXibE;3R>X|`Lemloa@~sQpis*Ss-OAN*A*7B?uvFY3R1F7M=_xYgE7>z zg*$pBa>ALVrN2Q@mtQqk;%BR!CH=GKE$qgm!sN#kl2?s62K~{;W+e>@W1;zy!4LlL``2!Mv+l`{?>> ztBf?QN!mkRReHl7FXmhA$ z(#X(g?y_5^T#Qqu24kTEj`-AYKeF7Mie-gP5$x2yGd8jLEb8!{x)^O9twBkiMT z*PLd$-e0!YX`Wxc)dENCMKyIh){NdBP^p-Itzq}YWhJTsKWRZrB(HaG=YEpCck5Oa z*qXw(4UG(=WuQr+sf=_`7#y#cUv-dvO;x_3s#Z%(_GEmVbSEk2bXlT56@Mv@_U;oTMh*bBPb%!A{0K>YkaZHjmJtk zYCEjwCRaj=lM$qRgsVnw?^5V9zT%__(iY>D^Sd1gP}PSd=*c=G<$N5HhbpAt?ELgL zC^<(yiu5~K)&D!^f!UIqs+!;2Z^2g6YSsRzX0+B|`YXOsM@2u2#hYJeQlWXFTo_S$ zqDmT0@ww8p8q#7&Hu&iwT1IKJZkFRm+DQuKx}FE!;rqwixEWgEwHh;F?J!75{Qxci z4rf9kp7R!d!YAgX(VC$voQa@}GA55&->{)XEThJ+pg0Fsb8g_7VA<53l;h#q$4BBT zuB|6u2;Ui*p17UVZ{^7MwQG=n)>zdK?+(f1PLNHGToNoGE43)io3{xB__U2;FpJ1$ zT|8vRjxBIYCix;m7|VL42$2~z*Zx!^g<%kqQdc(oNYU_0lMA&D7?cC>J><$XC{4d`>Ouc=O;fOSzRHG(7OXK#gOGhmG0-# zT3fJZ!sxl@UL=4XJa1D_HGK*7%d0cPr4g& zv#0T?$23(NOb3>)Y0EBn^UO|S+l{tYVchRpK#=^IajIN)meR)7`BY@QO#K)}TuX)( z*eAqG)utDL&Z^!k`}`9cNqjAo09Wr%Z!TVW9*ioTOF8Mi8l6PwIH!YYo6~R_+mW$P zkM%XG=|S3mNEI>{c*nN)=#!Y&en_uwJ|lg(2b>S^oI}3)Rz+Y!@coXzVbbD#W}%98 zK1DF^gR0|klBavtqFgPWKJMX|Z;sdS^zeEl64p7&88Glcs{$& zSvP&cCd-#_T=tn(DR0WMywc&p+S^)kyLUC_lOUJ!j)WVftD&J}d56V0rK98J79c6| zfH===IL$TDn5Hw5Ee4DvG);p0?y*SP!SM>C7;v1cs-;f=>SqJy`x(vPk? zkN4nRGo11A{A!Y*3N&>tO~XfA@}l~uVd`fsdZqp#+RA~9py%OoGxr&)1TI;6=AKcT zUQng_!zRz~FJ4}-o}>NdLBTbm6XBi6bnx(mXdbtTeE2jY5d)%h3d8RAghullpEj%D zIE8Q;I2s3jvqKG#bo}sa{lGPa8$|W_yq|>fyQs!yFog_>n-iQ6QFPYnZj_^pAEzgB z=4n3ys00NxV{V*)Vd6#FqIuqBFv8-if6@IX@rs#4z#a1?Cd|s%3p*miV~P^j-m4?5 zDu8;osP+0|H@Wi2^feAnl!PvE){(t@$Q<|jESsyi>lJKNu?j9&N-Frg#`z=V?G`&JLY2p=LiXeM?y5(-cW7C4YPywHd$wEzaV83(Xc{9#^G zNG1`c^Pz7THalQ3;LZel*r))NKHmmd%i5b;MNq1xDru$a%Q`G0TPBcj73}w({GN)| zis5vyXUN%hvur~uEKHGzkS8V*gg77~cmXy8Iice==~AD2)XHiEKIU5sFuvCGpVo-8 z5ugnb#&S>bn6g}>$=0mDd?g&OdoQ;PBMvgd#k5ct=n}`k{%tJp9?w2riohOF zvS79+xs4IeWprkJ&ybNavB{gQwo~_p$EW(`fRn@A317~MuAk2ImJd|)$dNAw=sPAY zoJk=eB4$wKSKhh1YV@m~Ho8yVCPV=}4Z?cIS;BJADq#8GRyPAzy4<|jv>$iyj2!)h zb9#Jd0A^VX(`Lt^F%}j_3>6{w?$*Wz6j|1?vhk8UzAd(JYqfn;Fng#(EWH+e&_G`#GGfM+S_M}>cCdDeDD=B? zV@p1`Rud&)y(?#{c;Y~Q@6^_^RWb(h6R(=;d{eLABWd5B@_-~+uf3`mV zCn(|Hs(=4a3aa-x-T#0RINvo>|4>MAvm$b`agwmVtESlBwNq?t?;X9o@36xA*x&O% z`g+;lJAD7%hvQv2_1>z@!TqkF`nUC*|G3TluCICr8`yXexme#H$MwF<^Zq<+?EeL3 z`1=C?^K3H-JNNs``k!W(-<4Fh{w(Mc4_<*uXJp-*BA5uIswHGKhvEgVAF6}lOK^<` zfBd@0_?jxMlip__(8#>=s3EA{p{MdfB&j`<+q&K+a^r@Os3LQ){^e^a&@L%$h?}27 z87r?v_aHE6*fozXOseD&itz?h?e227KauG7incwLhp!r%-hfueY?8%O;rEwZCzZru z#o#mD)T0JGslMsfl26C4wYHOYP1}wcQd^RTQkCkpd3o-Z41xVwv~=}M;F*%}!8YFl zjy9M2H5-f6c$hrr#6-oI!f)BmKKh)K6^D_W{*V=}+Vh_fvxA)BV6=)-ozY+x>5K$L zAaJP5QLsb`mc_o$Ybzqb6ra1-_(K+-%6|Kh!0-C)!yZ3DfSElLu`zn&cTD*vn^ zznT&MI6zn2x!~HyE{A;k_e-ct^`9#LO`5s>`!xT*Kob9Ji2o}eL88t07lUDBf0sP5 zvb}fWva+yo=^!%yQ@kc>Yi4co9vNm)M!YpoJFJ)q3 zX72RfJpH~>*~!F4?e8Nr{yB=s@lH4}i@KQoBlz#BWhG&jGjRLo66-%IdH>Qr@A)%f zBVm2d?O&=#Na*i=|IO(?NB(nS-;WV?7Pf!!5v*)%?+Uj6F~W16t{T9BwYyc%riWoj zq*Ep&@T5|}A?6QkIjpbnp$Q_Gn5tuCx)r7jEr#@sMgxtXns{tOfr;3)(PgL2RG`ou z%!NgZL@*F@1q9W>?&^Z>68rGF|x!7ppDLfSiK^9~2^Q4U% zU~P>MUlim;GGf+=(U+oH24`WctsrK(l=G?G`&ZUsqzJxQk9oEA*~z zF$^A~u_v20jplSU^ib>5h@zx-kxT8}THE#mwH?{%+T_oUti21j&>(J`qo^XJv*Pof zi{Jt-h?LK2emWKbX-*ggpRhs$cjJ%{Y7#>F9FXPIv2osHJ$nwN9s2+jU&+4+Uv8~$ zC|zC8`ImLPnmUO*#}q<~o_*e-yk#DKA~Xffc3$C3Fi3)>4UeG)cFhU7yKLHBgSRVW^gB3EQ?}@T{KxXN;H)U zu~-u%GlaAQjwNOY(H_h;Ix%^J2yrz^GvYV0iyo;qY)-^p`b_R}Ijq!n@@-KjRC^E; z01BAi)91r<52{H53j$B~x2>66Ks9k-LZJ15Apt(}40Z;V z?-`;1%33t~B!mIpz*~o@9tm!M4zPUJ5C)L({y(cB9zdq$a5FapObKMzCmWR@0Dzk{ z1|{eLNX_P3hC+aw=Hw9xc7Pm^!(pnk?-SE;OYu%_A{d{kv?X~=A_PpwMAwqsCjkRs zZ%OWw;02ff;~f;cC0GFxKr9E=3@{{9At+`-f(Xz8+_lHpHKYS90cE$yz~B#n6ri#F z)&W@t5-~uRNdTA+iW!zb1lTggwn%N0#UKFy2tb||dwYX}?*708BqV?-lPnOog~dMS zKx`l|5eWrg$)p0LY58VP3L}+c@b!=^0F?DQjX92y2`T#($ z@jl_^M}9yS=!zDQWq-vAC~A2O0i(4%`hg!>c>4N0fiDr@Uk+CQrnk|)tY)_)uxs-p zIl#{G3I|~4a0Lsfa=gL^_-<~iGU;w@n=t8aZ$ALr2m3CX-M)hlTHGSRW-X75fL~kN z3qXOMz8RoEUtb(hpsQ~O_!0&lXm*PSzb|(8^#BEW`}~0doqeys^i9J6@D6ZwppTU) zsD)=(A{-QN!Sv0|>EMy(M+`u4b8|dcrWtp4 z+mMNAds~c&X>;3)X?$m!1OV5}lLUrf8s9P$20S+}j`R^Rxj2Hj0By~SLw%@BjgB=D z;0mDimLWSJt$A^<50+`(5o2qcfoUF8lL+PnmhT&4173l*ps5iFG{73r2~-pNuD@|| zs7VK#02%gj{lP9wiS{+gU>1N4kYU@9^xxy<*kZn)8w!?W!f#IQkq`tp17{r+9pldv zzx3W1S|kvirWjesPeS1EaVK&?<-A`9PrYfRLc~04m^0@IhP$xy@h9>TXu9+%S&8uD zo$1$S6xbN$RD?HH502H$T4F8snv>_DFpPLeVn~|xDIG^U66Q68&$DQanX57s;AlQ+ z7Dp*E=MhP+g}35X7}x(uI5E!I3r}R#8ZP!%SmBtC2q_21!m9$1-j%J5Cl} zJLwwUVRDNi^PC#kVR)+`smJz2mbkc&hanV2$prc8ANV$Y$S#>xTd$yTXe3#L=iNIk zWPA$&_R5-~mAqhmA{e<=$9Y0RdQAy@>pj$wyr`}hX7fms=;%9?leA;;$S`q_2z={2 zoJ+PsNWGRGZNR-{%S+POy}z1$Wq3=G zM~y2ueyGlHV8n1slNT3GWMF~D?hzs(G5I2&&y(O4V;?5T^l{5 zQd^2BPb9$AnV9w&KID@O#?u)=1onujvp*r^m1!&|lqV9ixBe*589!u`6gG4UnJQp7 zpk&|}JT#O9u(n1|!LXWfFZ=k6E`G)-1vw^rlm0zlPt} zY(3Z9OuN7xZVcs`` zmm<2$6S*Y8xQxcL_>KXS)iA7ZoK`ZUqHw1#$vY(Gx}z~jsUx)XkJjzP!QEdDk~Ft%5Z^ysz$R_5YZ^aFLu-2UIU|&H z1TmW4R1-m3f7f_d-`LF92&TN;FHj;CF9jD54^Km0aHPa2MoSW3(o&KxQF+LLP9wip z%9w(MEC=Km6>K=VdVI8Hig#3ZKbj|k;x-9CX?i}c} z==Fv63aLj!_aWwiX@`3mt6#oRpTVEd^Am>hgv9I+(hfI z6R5&R5~%Xi4wf<81){ngWYB6PLYr<=`JY=B~%be0YN&XQ9@EmRzL(v>5%S5 zL_n$c>-)U#^FJ=X|9PLUdpKw3%)K*rX71eidiFE-gKDj5~8vqw1kpwa!qI>bDBU8QL(TcK%2^3~SfL8gdZ;6TzBNxX2# zVAz4|={FASMep{r_OtjMqU{rc-;eel^`9N@NL25~K4QyIZ$Pw2w5)gU9ZW4|Et;$N zMeNgxu)gX1p+LRJq*DKkdWLDH!R?jwyfEXG@Tfa&ksGaI^=$QQvpK|-$b-N`s+#L| zz2GFIimOQp3~gG?5@MfX-%#$-VxC>P^9JwPu{+pg3-JsQfnb`tHCN^Q$e)SX(`{<& zAf4k)$D1#|+b>jpx3}6!E$&rU9DJ!BIEdoNT3of$=;)0TB!2L+?%6BWtEK9C&r?-X ze;s2N|HXuHPmQVbgNL1i0xl$jQp1ey{4V$iW+(hXzBi;3dEYrdB`#?u2p(as6)&ho znwDg*ku=WV57{yxdocQFSZJ!RC)*Z0lgT++%SphHG@#Zbs0QJY&f$%qsPW$FuUIz^ z@p-hQJE>5y(-N3ysdm7vdS|-+X@Fa;n+j!_GaW5euiH<~Q|zDi#g=}7nbxyBcNVeO z2`uDTALDX5Y1Ct8H(sbSrldn* z(e(C_Dp~L-m@^XQrlaD$txF?)HN=)^GRvrGKFXZr{sCFnl#djb_2uQ%hRuz$mH%CH&;DXAsQqoQD;;}0YiTGi^Y6-lC@=5xq-)LTjkZ+OI zkFZLse%v2-!yjQGYkyjFzE0X3@lc>)iNmm?>}pWyQbv{hQpUgQ>QIG|{TBOf&F4=) z4$Rl&7BD=8K^U3XJ9x*KL19uT_XSr=+A7LPOjo>mOw+J_6t^Wu6{ZoXVrWgMFUrJ{ zxQgBg_XzuutjG|y54Jf<-4b_*KoBnlQzMKdm&piA@J72VLlwReek~SJD2=5wh%}W* z6kAi4V+f-Ub1O_dm!<@>ENn^^zXXdv%vcr|M45{D65CFePaBI0TS=A;#KenHg!xOB z`32DmhMXn;3*y_D)u9+K2y8KeS(y$nEl}76n5D9W3pWzOI9bU(F$qE`Ju&=HH;gce zEN|QnB?n;y%Hla<66fB~3#HKRWB#myG_EwJ^o={%ESM})2hXL6J1@fed#8i-_dQbZv?>)nNA~CFUic?%q9#1?^2~P%3 zfdlUangs_`KS~o7iy}t-L}`U>hjyUqP%zXON-OkDs6ZGCwjstV>{pmFSR|OQuwG$2 zL486gp~6wPs9yyh$Dy9gqyLwig;4gElvU)D7;o{|QN}27OQEV8M#OKieuqit(r#cj zg$Y}7Rbg%5q+s`k7RurckqBbaU|Z!98{r7z&|nCm9$E?y-4w-)l?D3DmEdiKn&d_t zUA)p7x!R4N_&$FbdbK*JvQh79ZKKQrzrRX&KAZGgS-z_x^Bhmx7SmXzJ`wZWOqL`; zpoe3Hcvyi%o{1ZgG}9xZ`chIoo2@dqa`ej1a>sQw(E3FjCG|T>$YuZO=DV3N@NzNQIpuqN2-(T^$>imfcjU>j8!Oey-<3v>Nv(X&83Y^otr^lNRum%qf+^BnUP*XoQNwxFI5r@qCEHMD%qtCQxc zQ(6OZgP9s6-BHkJr0M|2dj5nkCv8IXSDP!O&v(TNIWK}ns*7_DFS=h^zlTnAg?U~j z33SIVk{TxDym-@7cMzSExE(?k6w4UG)R^!MCnt|9_;G56tuL%GLQ*xG^K-Y zYp=y*it*DKyJXi*&8m+UwZ9e$c^ch@uNGnM5W0^v={idD(`EPyH#=_iJEXWW6?6mFjr^>lZMa!CH5S>tch8zeR$SYC_WgdZ>A{}z75LF7rl8;f=Su-68v|Ty@Y9kW6q-_h1Xw~#(!+cZom1{<&fdf^iVPYD{p;edj!8#)`GK* zr;<>)WIo~KJ`ZC2w83?*_I}6jZsYCo z3ggzYwn~T9sDahq6u;VMGc-c3=0lK>xo>MlT@lEizICv%8U_928h-l$UJ(HyzJbBs z{xpj2zJuZ*3MSykOeGUeFy~}lHmi{AyX%$vhsxOII!dVdp%)q*m+p!_T2UKOf#mvE z7m_+6LKCqC`>QwE*2`E{ZobRRd!G6Dlc^lPmv@VAu*cDqN!tTOqv>gqMjlu*>vdb9WND;Z3%m+F$uD zH5J-ls>{(Vy=PhCzs9`ChrwufGPWejmM7v1>$ z1SXRCK8#G?-sF7lqX<6pT*z+@0AiiG=O4pAa)_Jvy!JVzeH7uW8KopcHreivUmG=M z5DIoFd__Ey8RJQfz;9rRFQk5opM=xB5{tz;MD0S0Z&U3bc2xUbHdUPN$HAU|4P*9j zCkZsT?2qAxB<#hihgD?H!Cp3>;a$`@vbm~FPv_^EL~1|ymg=i8a+uK8OcZOR(LXfJ z+<)Q`C4N5EHytUuL&;^{`d#6K^~aS#VRL?8g?xwR-aX30YfDge})*^>2I9*<|PxGmKwYYtx+=J!O+%`YI z_>451rgmf?uRi6hAs``#x$;XZ(@A3eez;K}okldpJ#SM9(xIec$4AKja`$}%RU~-3kprwfdovMq>A{Qs;=P1z>9;h*%aT&XdPvDA4T(xJWBPoP(cIXHP{yBLbmDW` zCA1%IJbT$o%1Xwx5$T7ssW~$-%ySqhq%*vbL#~f&l=TIpRVVm!Zof=coSALx7DS|= z;8RV4(ym}vEUSA2b$Gq18!GAKcf#llaK+~$M>Hs9$~rGUI5IW3?^l#;+s!PAY*oja zg4?Y+v}0>|^5?qcg9_oN`VUaNwcouq+Wl{Qo1qw6evXxNn@$8{o3%7SnkZPLvt#6K z{IIi$O1J!#aNosI-l}P70wc^G?q}m`v-&gg`>XHmB^pU;`HoESHAXPEMohoYFF}yt zXIHM`pT29k$K_N6k6uNd;oRWgymfA+=wl2*sQlWpsOPtR z(ozIiYWoVBDd^>!809hAo_rmfC#^`sALnRf&iL3TDSJtrYqQbPHoz2%f+h$$ZG^g5^z|9Kc@#Jkw6FuxdNg5q!Ro%WyQ>V|dh%UD34zmQ z$ki1ddLRFZwtylYjeoOvi}_?aVfn6f4nscq4zLY~e>HFFR$-ic-p3MD%iWXPS}MRs z_^ONCX>Ag%_|#8omBjf_oZ~sV@|1A5}FI{t_UkhfK-PIU-fvE zJ`>cZN)X;O9p;m|6O~80ym9q#0W=0&DWA0^{C#4jYK5bGNviYNf&TCv;QGm@fo6&* zT0P%eM~AdMme>QS{2!$gWA>9{PdzlT=gt^aC&(GpP!BiQ4Kg2aQNRXXZ-nrfycl^J zLZ+9%*?w90o%}G8jC_uEFuANSDT+nFflo%4Nk=BvX{@D8b3!_Adt~OP)-975uC8KD zhcw?c@4l1tO&Q9>cjd#;Vwg$V50GgpYe_Dz*YRdpI)68iHDt3fO02ytA6qG7p>g)K z5gBNJoo+RA+Zsf6E%)^3UoL+tQ%J14uh`90q07>aKy&m6oaJ2K3CDSFS?6YHWoQ9K31oA^SEaa zH>a0WnpP3^(FvF7@t8yMBIvnuox-ZtAZ2t77FT%qh`^_%*P$}AoL}xMaTO-(E*^>M z$lsy4%Qsxb+Il*xTWY7rwRd7DB&=7&mBFN(tb1FncGbYvghr_MZMTNLhI4YkXi4!) zgJOir*6=+;)4N#&rSRCUl=Ow$b!95^+UXyDH4h)T#j+pn>L)s{9hTkPG|5udE79X{ zdaicY;Ws^P#x70xoclX&$5HqjEA`#OuSA)AwQ*F%Nnys z7FQwGHutM(kzZ6Zu*X~@%RRL&)C?+D^>>D+fGh0N?BzH*sk#c@itdlvCRxWHs4TuS zCU8%Z*JY?}?|bJ^t6VPcf_hAw4k<7ewBz7ChYI_2Q9XH35@Q z;wtowZZVT%DSUzJ`Zf{HT~@f3zq&|4ZX51x*dwgTH2R8} zx1J`M>i0t4)@#YH`whDB24?lA^;#Y*XOqcUyA+UpNneHScdujHS{CN=THC(q3R^r_ zZ)gxYvgISO4M;gZA6=~bJmB(szyx`~yLPkIY&tq+{Y8*t^RvX7jl22!mW}$5|NiSG zZjuaRH&HMtpLIETeZPm}F}E!vK0Xh2I}s)unKoA*6WGRu#!>atbadWSV*pWlmPm7a zI4nr~#xHHz3RxC5Og1@rCk`QLMsR(ZBkntV=NJ8<{GPXz$`gJmxQMOd3&8p~`F8a; zV$#0~lv;J_)8{LfcG}(M>J&Y|4W|kG!0Q+z{)sVTrpQWpc=8)b#!MNVX>nb_q+1Wo zPouD|E$-2~pc_A{3<*lPNPDsq?R#ocoGlY{xA+Qap6H~Ss!J8WY*OEhH1d~}cxvgF zoSaUjZoiUDSA^ROd`N79r>_a*q&l zxBV^1UQk3anmIZ*H$J6BghE6eFH=%3#T(n&pfB-|)1N%&BGsGg{V=Dql5hG-H4i7g zQrKJB(6e-l)oxXdW8_g(*1)$f^=YPce)n_}2lK-Ar-HhYZsg@UswIaU!D8jg^~%Ttv{F>~=z3{9-lnxS*+q0v zy-mFbI$n>_+dOY{F?SxDG@I|kJ(%=4Lecj+>q1Mu7u(|Zyu|Klr+P&OB1Edm z-+BE)aa{>&FJ(Mbp|%3nd+I96&j;oMzt}WREvXfHS&T3ZNFL)J;){zLeC$+Eb9ZBB zr*maZS~`KaOHtZcRa{|}uX^Dp7njefCqek3ZMgAmA!ftW#A;p2htCb3n9y$z;n(wR z@=0eHu(?t{txLR7bYy#rOOrk;0ViBHe}dQgFcY`<{Fq#cI=0xG=I4ji<>EsA&4~iC znJbai@u2>(?5%TWwMt)VI?yJS@q)I}=#MDD+F2!zb{Pfk#AG|}$6?x}T+k8*c7fAT zos|?iT;AULbTGTKJjt7F0$p1^3Wsb#3e^N{y_blft;hwEw0o+w!z0wCEGw}7z!8v^ z+~KAfcTj;o^P+(GufAh{PbG%{X@>QY#dHDjS+@K+E~>`t$f4iEtAv#7oJ_sMTYVZA ztcer0sXy(Xj%TE5@q9RqEY`=9uxlvPP+-+I>r07TVi%kU|K!7;X*4WAUCWT^Ouy{I zNp(krFS$&RZ_hT~X^pzvyS{$Sz`fafckb!qU#m4u3`95SpBUu%8H!lwk3P~dT^LuW zdo-3Ehg*XfP#3+W$N$92N&k`kMcI@$0%kW(E5z$p{QE8}h0|Ntxmso{n{sac_`N^_ ze{-;ouh6+S-|ub#DTSz>k;9mD`3)8_>&YkcdB-<$=p$O6OD40+Wm|uRF2p;1&P=oZ zER%~18rxFndYELX9ymxjOvfNe$MIOq)gw__FgL`p1O}&CiNP;p13E|-TM%Zah{y-? zWKc6dBOOtL+a7SX(pphZIuU>7I4;84?7%NyxmB*H;qqKbo0!{_DoLceU(*#^$xTX1 zbJg~YFGO6A-g+`Z?J!E+S69h9DEMUT;!_QRWe>l8oQB6)|8>9PKpFnvWI&wAsIkt6 z_xz69+oQumXsiU-3KHPHK0wM5id-jG5=D=D!D}FuIc3<6O`O@k_Q5 z8MHFbuidEHf2e)@P;2bA+`e$}rA5V)u`fa(JLJy;udT~f(gm$x{2mARVDX1IpQ@I! zo)~#ANw4+z$fg$qdv7LQIW$sppB6$=CZB%H7jsT8&Wsi!{dwOofI7!}*#-X7S*$LO z_I3f+Gmht)+$J>JVnQ)#kHsPCP}6F+HQTGK?1gH`Ow=90kUozzJB`Bav2iNAS<(Sy z%iEJ-uDeAiX78$3Eme09IJpDdre|D^#|-LTaU-K?29Ns*#~iqMcMq=saA;dMnAOdg?6{n?m-#h|;ME+rFgnjNIv+CzM1&1KeDoIX@1lLP{r%?`P@{s#W^toqM`Vn( zCHxa_N$aBznZ-A#UI}z25ia6}=V}+Mw9z@LpXc`0_Hd@xvJ`aheWL^ZpDpXj&exH7 zLdZmsH&&5@k8BhBdTBRFW1Q?|MuKb--}fi@VB>>^ibOu8GdUbzot&Z!yns6iCuCUX zlZc)t@0K)=y}zdEv!8^Uh-W5?(rdh#AEn=N=|hzKBqZPZM}O;f z@NjZav(NE>aj(FLl1|?tY~Lhv{kC73rW!nd)^&)7Yg*tz{LY-;(zmARav8S{d^Q=Q zQ&+N@aH3u=a}aR%jwC~;$BTO#D@j}vE{=gx)}G?DSy4k@1PV?#YJXR6O|aW(&e>He zc}AZ~R|0Z_gtUgkp4?YB`;zm5)nj)U+nE2h6hXzQaClpNvb8bljIni?kMHAZ#+?RX z%3j$*$Ir^#y-&-DX~NZYnkL<)CvqUI-j=~ml{0JU=7(1OMd1NT4znKuE*7&HqbpIS zFJz=fl5}d%zco&IOFsVO%*3$0p9$xgA8UJ?%Qj!U#egHy@W}LYioU5gtmSLgEO-!Z^ll$q)k6e zn~sYW+9Vg(TKRm6;nzuenIZKF+05-rZ*hd{<$unwX}@X@$@(Vy$mV^SYN~TFC4Cdw zd1;HILU)ELy&Ns^S>%C!cXCnj-Tdr011YA4z<};8r}Vg|FBFH1xUCvW#It8!>g0$T zW^aL}riLnixf=GQcm!lih{O0^*>}A;QS@snF5qxJ9JNn2v`G#eE=m+4zaucihAhm0 z!9}t@h&~U99pOJ2XHR{(QTJxdk49?!u&Xd=?RVmapK4gNV|K%9c)pZmAVIuNN{@t^ znex^2H!+v7PqRMHd@fHB@^2t4JnYh5cy;67`9q>Z^6#nV-grWXs?J)eGAHTnz_ALr z-SfRluN`~IK2biiFa6X3qmjx8E|HoxOK^9t_{URF+<}&Ca)(-q@>E1+CP~+;s8e;e z!Mh4-q9gC{dvQmkkl*741$hXu*E&RA1!-=;Ae|jk_mFL#%=pYHT zE-pUAJ=krNUhiDa+T`EsH*zUTA`d8n&IpdiZ*uKT9%>}+e6HG}3&}p%f4|)EY}P5T zX$yK)P=n1SIV0w4GgYs% zY!e)8C5rUyi0-<|*C&6tz_}?e%Yif6uBX;b6D~Ua2}EV&=T+50joZ6jlNm>%n&0bX z^5M=9a)aURlk`!!2N)!Q$BVgszTe_yy1AEm;xl?$G&k}j6cC46_X~F%5GdJU(TioKf8Wy05*VG$r zz?eHOA?cTV1bK@{?qgRN4g6eIhI0?-1E24WW5i4+Dj1KCKeg%Ov*d$(GRi6EoM_4Z zsE1Iu1E+MiwzE`#@0jo9NEK;|$k2*=ZS6~iE=>gogC^T*HsI@v# z-NdI|)+aqyB%C{dDD7wEk2gt7iT9gJ%L!cbf*Pw%J_{6$4v^R#^x#~sdp5ak?KJ){ z@eaE2>UQI2pum);wH7Wc>}(AMLf(&VXu z#`W3e*1c~Z2!s4IKTi6dVl{b)yq&?_wqR-4yFZ1P1y!oB6!dDp5LWH8JT##yI6Epm zCI{`8Gam>0{9uEj{Hhh5GfqVE*GElu*%W6o= zX*7&+oCssbuZxjpG}z~TaPw3#(uDav9?9WP=0E0lM(TXjeu#}uX%fd8j~0vsRT?1+ zKe!L*1txB*zAL-3tCWWK2?_?iIMZ` zRKf@37YX-(pDcu5=zJ5PNGnLX?~)IN!YlXs%l`I3#=Bf|Y-P3du>!D;G|_VZh>%3Y zml~_J9lF(0<$KCya%=>;TJq`oZ^oP%1H3g<@*ghBKv|dtOZy=j^jUXYygIncmy18G zTP7)gWDm+>YilfPEc}(Z7L<`(v&@art6)lE7WnwQyFZfrMbkm~R{a-;&6E)uBgW6`NhCiGm+?Axn0RVL_sb*oPpqCA z2^myU<1Kr|PEmU(u81cS6rY+!IY05LJ9^}xyU+Xnq}oI7Q13ekKH{qWye*)tbDhwT zF;&J*ZMGICOTN%>`-y&ZZ_)Uj2M*yhPfZn!r-)7j`y5jfcJ(w83&u-pH@RYe-Bp+x z;L8hNRLT?ls7D(n)0oIe$1E|RHEYq(e=m`aH+@Ns)Ihj`ch9{KJef)J1o_cgv$}*b zkz(i4iO=}c-ImR}0@E866Nt;_?=9{l(&U7TT9KKWZ!f={9rQitMw;I#iy5_`Ern78>j?=nscr0w{|V{4|tEAgzKJUxE<{T zu*@%gP>IiST{}@3_}h+W1g3L#dUiHqG?=J;5US9FNG;>12fnHm9YAR3=QO;1+v7?aJri*AXRT|?Jy=K7uN8wWCmvPI8}F#$-Nnbf z`6(G`JPR$SBWJA96u5@pl#jCH;?&7%U*wgla@XF*CI50R|J-6I2yC;_x6pZIH@1XbMvXBq!XEvEb zv!#f1W4p3f)qY6)jFM?786Yew47 zZ&ixm80{^Z>REaASq5B+@X*puPJ5?tTXD?+Rhq;vC}=68LxxjDr~trvy$KOWgu>g(-} znH0QJ5lxAyt@U|kz=uC<$nVmG;OZ!&m#}}wPfU`eT~W1JusWcaL~)OVUgbxp;Z7h| zSGwlq<)a-bwc>}j_U{T$53@xluB?xERI*b1`0-s*xZZeSUcYQ#?-o<(0B4S79)$$8 za!@*DWeee|gK~{>9(+2sOiHV@Sr`Dsa1!{d)#>!zVOPLVaYJr^e^c#P;HY2;#?N$ON!9G zuHq)7(Fl|AOpV>{6{gUhOwvEWAH)EN!2bdQw7ooReQoT#Sb5#7Y_#sO8rXSxJ9)UX zg2BRYRx@6CUniiQCAxym)XB%fRRWfIt>9vilNK>*Qme7f+0u<;#wU1VfkAI7z(@Y4*=E!LXRs52rPzf z7l03FZ2Om75CSX)yJq`;kP8D4Iq0^B0H#MD3lW7}ivx%lNf$6$Q+S#s`r8bm#r^{Cm#;`d#y- zC>Q}p_XiM>*XIKQ@cP=I|4Gh)fM9T-WAop-h$7$!^!Y@Al!&eikYQoheFQ?F$L_yo z|4Rl045)`L_aFI0#jfcBgMwh_wnu>B*K!E}?YtJJFeq3Q-S$A<5dBYdhQLLU=wo5P z9dOrZQ0TQ-1E8hXau^^NbZx8{;1V={z<@ACk0BUv1fcIN7?8)&{RTr`&#`d8>F6@x zFwnIe1_w-q?sFiE{{a^MdHx-{z;iVYw~ zK+t9U6Q3vyb}fd0ctN7?eIPYm^DhE&y^cUY{!}0TlJxI-1A+jf+v-mWyB4RAKe$h{ zu|WNDZ7dXVJ^w+W*Yl7l=-PQM27&<~&c9`d0ksdh&SD_MwKzaRkk@iH5->CRd`Ku5 zy*>Z~m{%lP`~fux5`Ap|9|GOKz?qCh&vgI|hVEZ5fL8s}9RJVrzwrl#!vBD{(P_Yf zuh9SxqtRf0FuLe8V1J;+9~kyWX*51K(EJ{KJ~#x7e#QeW_krDjJ{Ar|k2RpM1`h9Q zd~hgQYyic^pRW6VuU8B>_^;8RqGITFK?1mU^mPEfM53<)3FPN%e86<*>p+T%0)YCz zbwR?w=rth(1P7y^$v~nLL(f+LAMmd5_j~{%`C3i{&JQFAZEXM_u+!1U0{k0qhbQC~{qR$8H4hY)*fB>BUfF=Te*#)49qMtnws2B*n1_7K4Y(liL zqA)S^`VZiPLC|dg6B7eE-2YpykCzpI2KOSAlmy`9PJwoRUZhw>bUi$L0B}0s^FP-< zsJYvF0CZqg|NTu7xaC381}0_)g2EACYf)=3$j-(ds0jX4z91W<7!(e*mL~kaS^m{7 a!P^ITQT*?>I0#G(i4-H`;!@I5Cj2ipENd?S diff --git a/refs/notion-of-privacy.md b/refs/notion-of-privacy.md deleted file mode 100644 index 8e90c136..00000000 --- a/refs/notion-of-privacy.md +++ /dev/null @@ -1,159 +0,0 @@ -# Notions of Privacy - -> The purpose of this document is to list definitions of privacy and related notions, sourced from literature, and provide fundamental understanding about the key concepts of interest for blindnet. -> -> We are interested in privacy from a perspective of builders of computer systems, who have to account for the human, its psychology and relationships with other humans and with the machines. -> -> In this document, we are not interested in the general perspectives related to politics, democracy and justice other than those views and findings that directly impact the building of a software system made for humans. - -## Definition - -Among the many definitions proposed in scientific literature, we use the following one: - -> « **Privacy is the selective control of access to the self** » &msdash; _Irwin Altman[^1]_ - -This definition captures the essential features of the concept, in particular: - -- Privacy is about the **self**. - -The _self_ is a very important element of human experience playing _"an integral part in human motivation, cognition, affect, and social identity"_[^2]. - -The self is not the same as identity. -While the _self is the totality of the individual_[^3], the _identity is an individual's sense of self defined by (a) a set of physical, psychological, and interpersonal characteristics that is not wholly shared with any other person and (b) a range of affiliations (e.g., ethnicity) and social roles_[^4]. - -Some scientists challenge the ability of an individual to know the _self_. -Under this view the self might only be intelligible through its manifestations or consequences. -It is generally accepted that the self is developed over time. -Also, undoubtedly, in part _"the self emerges through interaction with others"_[^5]. - -Due to the relational provenance of the knowledge of the self, privacy is one of the key features of the relationship of oneself with the surrounding world (other humans and artefacts) through which the knowledge of the self is formed. -Privacy is a "factor of connection to oneself and to others"[^6]. - -- Privacy is about **control of access**. - -As relationships play a key role in shaping the view on the self, it is of crucial importance for the individual to control the access to self, and thus maintain control over the change of the self. -That is the function of Privacy. - -- Privacy is **selective**. - -It is not an absolute binary "come in" vs. "go away". -It is a nuanced choice to control access to parts of the _self_. - -## Genesis and Function - -Privacy seems to trace its origins in biological processes. -"Withdrawal from others is ubiquitous across the animal kingdom" [^7]. -Researchers make an analogy with cell membrane[^1] that selectively allows material inputs and outputs, similarly as privacy selectively regulates external stimulation to one's self or the flow of information to others[^7]. - -Biology research suggests that, in social species, privacy might have emerged as the cost-benefit balance between the advantages offered by the life in a group and the interests of the individual's competition over scarce resources. -The practice of withholding information or actively sending deceiving signals might have had origins in a survival mechanism i.e. sending away the individuals competing for the same resources. -_"By increasing another individual's misinformation about the environment, an animal may increase its own fitness"_[^7]. - -In such primitive groups, privacy emerges as a strategy to establish **information asymmetry**[^8] and compensate for the power disbalance among individuals. -It is thus possible that the need for privacy in modern society remains still linked to the power differential. -Without privacy and the information asymmetry it creates, an individual is made vulnerable and its ability to ensure fitness for survival is diminished. - -Compelling animals to remain in contact contrary to their own privacy inclinations, in laboratory settings, has resulted in physiological changes, reproductive failure and adrenal dysfunction[^7]. - -Beyond the privacy of an individual, privacy also has a group-preserving function in the relationship between one group to another[^15]. - -## Privacy and Other Topics - -### Privacy and Information Asymmetry - -Information asymmetry[^8] is clearly a key concept for privacy as identified by biological studies of privacy in animal societies. - -In the context of a power differential, where an individual interacts with a more powerful entity, the need for management of information asymmetry is twofold: - -- reduce the information given by the less powerfull -- increase the transparency about what the more powerful does with the information obtained.[^9] - -Indeed, in order to selectively control the access to self, the individual has to know what the other party will do if given access to a part of the self. -This two-way understanding of the information asymmetry that privacy seeks to create is the ground on which the legislation around _data minimization_, _transparency of treatment_ and _consent_ is formed. - -### Privacy vs Loneliness/Isolation - -Humans are social species, hardwired for connection. - -> « **Connection is the energy that exists between people when they feel seen, heard and valued; when they can give and receive without judgement; and when they derive sustenance and strength from the relationship.** » — _Brené Brown_ - -It is crucial to development; without it, social animals experience distress and face severe developmental consequences[^10]. - -Privacy is not a tool to reduce connection and favor isolation (which leads to loneliness - correlated with negative effects on health[^11]). -On the contrary, privacy is a necessary element of connection making connection compatible with survival in the natural context of power differential and scarce resources. - -### Privacy and Trust - -> « **Trust is choosing to make something important to you vulnerable to the actions of someone else.** » — _Charles Feldman_[^20] - -Privacy is strongly linked with trust. -Because privacy is about the access to _self_, and self is clearly of great importance, an individual is expected to choose a particular level of privacy in relation to the level of trust. - -### Privacy and Identity - -As we derive the knowledge of self from our relationships with others, the freedom to engage and disengage from those relationships and selectively allow access to self is crucial to our ability to keep our identity safe. - -At the psychological level: - -- privacy supports social interaction, -- social interaction provides feedback on our competence to deal with the world, -- our competence to deal with the world affects our self-definition[^1][^16]. - -Inability to obtain privacy has important psychological consequences ranging from embarrassment and stigma to de-individuation and dehumanization[^16]. - -### Privacy Paradox - -The privacy paradox is a phenomenon in which online users state that they are concerned about their privacy but behave as if they were not.[^12] -Anecdotal and empirical evidence indicates that individuals are willing to trade their personal information for relatively small rewards[^14]. - -However, as we have seen, privacy regulates the conflict of the need for connection with the need for competition, survival and overcoming the power diferential.Habits, and other needs, indeniably play a role in the persons choice of privacy related behavior and may yeald behavior inconsistent with the persons beliefs and interests (as outlined by the _privacy paradox_)[^18]. - -The existence of the privacy paradox is not indicative of a false concern for privacy, but rather of the context not favoring behavior aligned with this concern, as is common with attitude-behavior gap[^13]. -Researchers consider privacy-oblivious behavior to be a result of technological limitations as much as a consequence of users' deficiencies[^19]. - -### Privacy Fatigue - -Privacy fatigue reflects a sense of weariness toward privacy issues, in which individuals believe that there is no effective means of managing their personal information on the internet[^21]. - -This fatigue, brought on by casual data breaches and the complexity of online privacy control, can reduce users' attention to privacy issues. -Yet, being consistently exposed to a mismatch between what one hopes for and what the environment affords leads to increased psychological strain[^21]. - -Privacy fatigue is closely related to the concept of _learned helplessness_[^23]. -Learned helplessness is the behavior exhibited by a subject after enduring repeated aversive stimuli beyond their control. -The subject affected by this phenomenon discontinues attempts to escape or avoid the aversive stimulus, even when such alternatives are unambiguously presented. -Learned helplessness is linked to a degraded self-efficacy - the individual's belief in their innate ability to achieve goals. -Researchers suggest that clinical depression and related mental illnesses may result from a real or perceived absence of control over the outcome of a situation[^24]. - -Indeed, privacy is related to identity, and to our perception of our own competence to deal with the world[^1][^16]. -Repetetive exposure to technological limitations[^19], as well as the privacy paradox attitude-behavior gap[^12] might situate the explanation of privacy fatigue in the scope of learned helplessness. - -## Privacy in Software Systems - -Software Systems, and especially the ones operating over the internet, put an individual in a situation of _need_ to control the access to self, naturally enabled by the context of use of such systems. -The user has to balance the need for connection (ranging from simple information gathering, over social interactions to economic transactions) with the need for protection of the self from unwanted connection, harm and abuse. - -Having control (having the system respond predictably to user's actions) is one of the key features a user can expect from a properly designed human-computer interaction[^17]. - -[^1]: Altman I (1975) The environment and social behavior. Wadsworth, Belmont -[^2]: Sedikides, C. & Spencer, S.J. (Eds.) (2007). The Self. New York: Psychology Press -[^3]: [Self in APA Dictionary](https://dictionary.apa.org/self) -[^4]: [Identity in APA Dictionary](https://dictionary.apa.org/identity) -[^5]: Colin Fraser, "Social Psychology" in Richard Gregory, The Oxford Companion to the Mind (Oxford 1987) p. 721-2 -[^6]: Darhl M.Pedersen, [PSYCHOLOGICAL FUNCTIONS OF PRIVACY](https://www.sciencedirect.com/science/article/abs/pii/S0272494497900499) -[^7]: Peter H. Klopfer & Daniel I Rubenstein [The Concept Privacy and Its Biological Basis](https://www.researchgate.net/profile/Daniel-Rubenstein/publication/227655770_The_Concept_Privacy_and_Its_Biological_Basis/links/5ba4eb2045851574f7dbcb99/The-Concept-Privacy-and-Its-Biological-Basis.pdf) -[^8]: [Information Asymmetry](https://en.wikipedia.org/wiki/Information_asymmetry) -[^9]: [Mininal Information Asymmetry](https://privacypatterns.org/patterns/Minimal-Information-Asymmetry) -[^10]: Jaak, Panksepp (2004). Affective Neuroscience : the Foundations of Human and Animal Emotions. Oxford University Press. -[^11]: [Loneliness](https://en.wikipedia.org/wiki/Loneliness) -[^12]: Bedrick, B., Lerner, B., Whitehead, B. "The privacy paradox: Introduction", "News Media and the Law", Washington, DC, Volume 22, Issue 2, Spring 1998, pp. P1–P3. -[^13]: [Attitude-behavior gap](https://en.wikipedia.org/wiki/Value-action_gap) -[^14]: Spyros Kokolakis [Privacy attitudes and privacy behaviour: A review of current research on the privacy paradox phenomenon](https://www.researchgate.net/profile/Spyros-Kokolakis/publication/280244291_Privacy_attitudes_and_privacy_behaviour_A_review_of_current_research_on_the_privacy_paradox_phenomenon/links/5a1bdb5a4585155c26ae08e2/Privacy-attitudes-and-privacy-behaviour-A-review-of-current-research-on-the-privacy-paradox-phenomenon.pdf) -[^15]: Barry Schwartz, [The_Social_Psychology_of_Privacy](https://www.researchgate.net/profile/Barry-Schwartz-2/publication/17491080_The_Social_Psychology_of_Privacy/links/583315c408aef19cb81c8c80/The-Social-Psychology-of-Privacy.pdf) -[^16]: Stephen T. Margulis, [Privacy as a Social Issue and Behavioral Concept](http://www.sfu.ca/~palys/Margulis-2003-PrivacyAsASocialIssue&BehavioralConcept.pdf) -[^17]: Shneiderman, [Eight Golden Rules of Interface Design](http://www.cs.umd.edu/~ben/goldenrules.html) -[^18]: Alessandro Acquisti, [Privacy in Electronic Commerce and the Economics of Immediate Gratification](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.580.5737&rep=rep1&type=pdf) -[^19]: Jochen Peter and Patti M. Valkenburg, [Adolescents' Online Privacy: Toward a Developmental Perspective](https://www.researchgate.net/profile/Patti-Valkenburg/publication/279190144_Adolescents'_Online_Privacy_Toward_a_Developmental_Perspective/links/567028d208ae2b1f87acd4ce/Adolescents-Online-Privacy-Toward-a-Developmental-Perspective.pdf) -[^20]: Charles Feltman, The Thin Book of Trust: An Essential Primer for Building Trust at Work -[^21]: Hanbyul Choia, Jonghwa Parka, Yoonhyuk Jung, [The role of privacy fatigue in online privacy behavior](https://iranarze.ir/wp-content/uploads/2018/04/E6393-IranArze.pdf) -[^23]: [Learned Helplessness](https://en.wikipedia.org/wiki/Learned_helplessness) -[^24]: Seligman ME (1975). Helplessness: On Depression, Development, and Death. San Francisco: W. H. Freeman diff --git a/refs/notion-of-privacy/notion-of-privacy.md b/refs/notion-of-privacy/notion-of-privacy.md index 6ba1d2fd..15bb382f 100644 --- a/refs/notion-of-privacy/notion-of-privacy.md +++ b/refs/notion-of-privacy/notion-of-privacy.md @@ -10,7 +10,7 @@ Among the many definitions proposed in scientific literature, we use the following one: -> « **Privacy is the selective control of access to the self** » &msdash; _Irwin Altman[^1]_ +> « **Privacy is the selective control of access to the self** » — _Irwin Altman[^1]_ This definition captures the essential features of the concept, in particular: @@ -65,8 +65,8 @@ Humans are social species, hardwired for connection. > « **Connection is the energy that exists between people when they feel seen, heard and valued; when they can give and receive without judgement; and when they derive sustenance and strength from the relationship.** » — _Brené Brown_ -Connection is crucial to development; without it, social animals experience distress and face severe developmental consequences[^10]. -Yet, connection can also expose the individual to existential vulnerabilities. +Connection is crucial to development; without it, social animals experience distress and face severe developmental consequences[^10]. +Yet, connection can also expose the individual to existential vulnerabilities. The risk associated with connection has to be managed. Without privacy, the need for connection conflicts with the goal of protecting vital interests. @@ -74,11 +74,11 @@ Connection is **not** possible without privacy. connectedness -Privacy is not the opposite of connectedness. +Privacy is not the opposite of connectedness. Connectedness exists on the continuum between fusion and isolation. -Fusion is the state of total absence of boundaries and separateness. -Isolation is the psychological equivalent of death. +Fusion is the state of total absence of boundaries and separateness. +Isolation is the psychological equivalent of death. It leads to loneliness - correlated with negative effects on health[^11]. Humans need connectedness to avoid isolation. Privacy regulates connectedness to avoid fusion (where there is not enough separateness for anything to need connecting). @@ -141,7 +141,7 @@ Repetetive exposure to technological limitations[^19], as well as the privacy pa The privacy paradox is a phenomenon in which online users state that they are concerned about their privacy but behave as if they were not.[^12] Anecdotal and empirical evidence indicates that individuals are willing to trade their personal information for relatively small rewards[^14]. -However, as we have seen, privacy regulates the conflict of the need for connection with the need for competition, survival and overcoming the power diferential.Habits, and other needs, indeniably play a role in the persons choice of privacy related behavior and may yeald behavior inconsistent with the persons beliefs and interests (as outlined by the _privacy paradox_)[^18]. +However, as we have seen, privacy regulates the conflict of the need for connection with the need for competition, survival and overcoming the power diferential. Habits, and other needs, indeniably play a role in the persons choice of privacy related behavior and may yield behavior inconsistent with the persons beliefs and interests (as outlined by the _privacy paradox_)[^18]. The existence of the privacy paradox is not indicative of a false concern for privacy, but rather of the context not favoring behavior aligned with this concern, as is common with attitude-behavior gap[^13]. Researchers consider privacy-oblivious behavior to be a result of technological limitations as much as a consequence of users' deficiencies[^19]. @@ -176,9 +176,9 @@ In essence, the available knowledge teaches us the following: - **Privacy is the selective control of access to the self** - **Properly designed computer systems put the user in control** - **Privacy enables sustainable connection and trust (choosing to make something important to you vulnerable to the actions of someone else)** -- **Connectedness is dysfunctional without privacy** +- **Connectedness is dysfunctional without privacy** -Therefore, we believe that a properly designed Internet System is designed for Privacy-enabled Connectedness. +Therefore, we believe that a properly designed Internet System is designed for Privacy-enabled Connectedness. The Privacy-enabled Connectedness is achieved through the following design principles: diff --git a/refs/schemas/priv/json-schema/priv.schema.json b/refs/schemas/priv/json-schema/priv.schema.json index 47c990d3..1ebb27fe 100644 --- a/refs/schemas/priv/json-schema/priv.schema.json +++ b/refs/schemas/priv/json-schema/priv.schema.json @@ -2,7 +2,7 @@ "$id": "https://blindnet.io/schemas/priv.schema.json", "$schema": "https://json-schema.org/draft/2019-09/schema", "title": "Privacy Request Interchange Vocabulary", - "description": "Terms of the Privacy Request Interchange Vocabulary", + "description": "A JSON Schema for the Privacy Request Interchange Vocabulary", "properties": { "request-id": { From 6998e56c06a06ad3e0ca2a4f1fa4965ab18ec7b1 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 9 Jun 2022 17:19:32 +0200 Subject: [PATCH 140/204] typo --- refs/schemas/priv/examples.md | 38 +++++++++++++++++------------------ 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 54cbb007..ca20a21e 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -38,8 +38,8 @@ In the following examples we show how, requests introduced by different regulati *...the controller shall, ..., provide the data subject with all of the following information:* -| Law | Demande (as introduced by regulation) | Representation | -| -------- | ----------------------------------------------------- | ------------ | +| Law | Demand (as introduced by regulation) | Representation | +| -------- | ----------------------------------------------------- | ------------ | | `GDPR.13.1.a`, `GDPR.14.1.a` | the identity and the contact details of the controller and, where applicable, of the controller’s representative | action:`TRANSPARENCY.ORGANISATION` | | `GDPR.13.1.b`, `GDPR.14.1.b` | the contact details of the data protection officer, where applicable; | action:`TRANSPARENCY.DPO` | | `GDPR.13.1.c`, `GDPR.14.1.c` | the purposes of the processing for which the personal data are intended | action:`TRANSPARENCY.PURPOSE` | @@ -62,15 +62,15 @@ In the following examples we show how, requests introduced by different regulati *The data subject shall have the right to obtain from the controller confirmation as to whether or not personal data concerning him or her are being processed* -| LAW | Demande (as introduced by regulation) | Representation | +| LAW | Demand (as introduced by regulation) | Representation | | -------- | ----------------------------------------------------- | ------------ | | `GDPR.15.1` | confirmation as to whether or not personal data concerning him or her are being processed | action:`TRANSPARENCY.KNOW` | *and, where that is the case, access to the personal data and the following information:* -| LAW | Demande (as introduced by regulation) | Representation | +| LAW | Demand (as introduced by regulation) | Representation | | -------- | ----------------------------------------------------- | ------------ | -| `GDPR.15.1.a` | the purposes of the processing | action:`TRANSPARENCY.PURPOSE` | +| `GDPR.15.1.a` | the purposes of the processing | action:`TRANSPARENCY.PURPOSE` | | `GDPR.15.1.b` | the categories of personal data concerned | action:`TRANSPARENCY.DATA-CATEGORIES` | | `GDPR.15.1.c` | the recipients or categories of recipient to whom the personal data have been or will be disclosed, in particular recipients in third countries or international organisations; | action:`TRANSPARENCY.WHO` | | `GDPR.15.1.d` | where possible, the envisaged period for which the personal data will be stored, or, if not possible, the criteria used to determine that period; | action:`TRANSPARENCY.RETENTION` | @@ -85,27 +85,27 @@ In the following examples we show how, requests introduced by different regulati > To make a request to know if the System has data on them (`GDPR.15.1`) and know about the purposes of processing of that data, the Data Subject MUST make a request with two demands, one `TRANSPARENCY.KNOW` and one `TRANSPARENCY.PURPOSE` #### Article 15.2 and 15.3 -| LAW | Demande (as introduced by regulation) | Representation | +| LAW | Demand (as introduced by regulation) | Representation | | -------- | ----------------------------------------------------- | ------------ | -| `GDPR.15.2` | Where personal data are transferred to a third country or to an international organisation, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer | action:`TRANSPARENCY.POLICY` | +| `GDPR.15.2` | Where personal data are transferred to a third country or to an international organisation, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer | action:`TRANSPARENCY.POLICY` | | `GDPR.15.3` | The controller shall provide a copy of the personal data undergoing processing | action:`ACCESS` | #### Article 16-22 -| LAW | Demande (as introduced by regulation) | Representation | +| LAW | Demand (as introduced by regulation) | Representation | | -------- | ----------------------------------------------------- | ------------ | | `GDPR.16` | The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. 2Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement. | action:`MODIFY` | | `GDPR.17` | The data subject shall have the right to obtain from the controller the erasure of personal data concerning him | action:`DELETE` | | `GDPR.18` | The data subject shall have the right to obtain from the controller restriction of processing | action:`RESTRICT` | | `GDPR.20` | The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided | action:`PORTABILITY` | | `GDPR.21` | The data subject shall have the right to object, on grounds relating to his or her particular situation, at any time to processing of personal data concerning him or her which is based on point (e) or (f) of Article 6(1), including profiling based on those provisions. *(note: 21.2 is not yet supported by the schema)*| action:`RESTRICT` | -| `GDPR.22` | The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her | action:`RESTRICT`, processing-category:`AUTOMATED-DECISION-MAKING` | +| `GDPR.22` | The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her | action:`RESTRICT`, processing-category:`AUTOMATED-DECISION-MAKING` | ### GDPR REQUEST TEMPLATES FROM CNIL -| LAW | Demande | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | `Other properties` | +| LAW | Demand | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | `Other properties` | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | | `GDPR.15` | [Acces](https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces) | `ACCESS` | `null` | `null` | `null` | `null` | | | `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | `ACCESS` | `IMAGE` | `null` | `SECURITY` | ~~video surveillance data from 01 Feb 2021 to 03 Feb 2021~~ | `from-to` | @@ -115,14 +115,14 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | `ACCESS` | `null` | `null` | `null` | `null` | `null` | | `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | `ACCESS` | `null` | `null` | `null` | `null` | `null` | | `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | `ACCESS` | `null` | `null` | `null` | `null` | `from-to` | -| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| `ACCESS`,`PORTABILITY`| `null` | `null` | `null` | `null` | `null` | +| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-Demand-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| `ACCESS`,`PORTABILITY`| `null` | `null` | `null` | `null` | `null` | | `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| `MODIFY` | `**TBD**` | `null` | `null` | `null` | `Selector.to-modify`,`data.rectified` | | `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | `MODIFY` | `**TBD**` | `null` | `null` | `null` | `Selector.to-modify`,`data.rectified` | | `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | `DELETE` | `null` | `null` | `null` | `Reason of deletion` | `Data.identifier'=Information to delete* (can be one or several data capture, or limited to a field , Data cat., Process cat. , Purpose, URL, ...) | | `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `Data.identifier'=data cat.+purpose | | `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `OTHER` | `null` | `null` | `null` | `null` | `null` | | `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | `DELETE` | `**TBD**` | `null` | `null` | `Reason of deletion` | `Data.identifier`=URL | -| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/demander-le-retrait-de-votre-image-en-ligne) | `DELETE` | `IMAGE` | `null` | `null` | `Reason of deletion` | `Data.identifier`=data cat.+URL| +| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/Demandr-le-retrait-de-votre-image-en-ligne) | `DELETE` | `IMAGE` | `null` | `null` | `Reason of deletion` | `Data.identifier`=data cat.+URL| | `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | `RESTRICT`, `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `target`= `ORGANISATION`, `PARTNERS`(propagation) | | `GDPR.21.1`,`GDPR.17.1.c`,,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | `RESTRICT`,`DELETE` | `null` | `null` | `null` | `Reason of deletion` | `Data.identifier`=all,`target`= `ORGANISATION`+`PARTNERS`(propagation) | | `GDPR.21`, GDPR.18.1 | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | `RESTRICT` | `**choice?**` | `**choice?**` | `**choice?**` | `null` | `null` | @@ -137,7 +137,7 @@ In the following examples we show how, requests introduced by different regulati *Change my address* -| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Other properties | +| LAW | Demand (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Other properties | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | | `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | `MODIFY` | `CONTACT.ADDRESS` | `null` | `null` | `null` | `null` | | `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `null` | @@ -158,7 +158,7 @@ In the following examples we show how, requests introduced by different regulati >we need to add a schema field for providing new data, and date of validity of new data (not necessairly the date of trnasmission) ### CCPA REQUESTS -| LAW | Demande (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Other properties | +| LAW | Demand (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Other properties | | -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | | `CCPA.1798.100.1` | A consumer shall have the right to request that a business that collects a consumer’s personal information disclose to that consumer the categories and specific pieces of personal information the business has collected | `TRANSPARENCY.KNOWN`,`TRANSPARENCY.DATA-CATEGORIES` | `null` | `null` | `null` | `null` | `null` | | `CCPA.1798.100.4` | A business that receives a verifiable consumer request from a consumer to access personal information shall promptly take steps to disclose and deliver, free of charge to the consumer, the personal information required by this section. | `ACCESS` | `null` | `null` | `null` | `null` | `null` | @@ -213,7 +213,7 @@ In the following examples we show how, requests introduced by different regulati ###### Account Contact Data | Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment | -| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | +| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | | **account** | **Contact** | Contact data related to a system account | `CONTACT` | `null` | `null` | `null` | | **account.contact** | **email** | Account's email address | `CONTACT.EMAIL` | `null` | `null` | `null` | | **account.contact** | **phone_number** | Account's phone number | `CONTACT.PHONE` | `null` | `null` | `null` | @@ -225,7 +225,7 @@ In the following examples we show how, requests introduced by different regulati ###### Account Payment Data | Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | -| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | +| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | | **account** | **payment** | Payment data related to system account | `FINANCIAL` | `null` | `null` | Broader definition ? | | **account.payment** | **financial_account_number** | Payment data related to system account | `FINANCIAL.BANK-ACCOUNT` | `null` | `null` | `null` | @@ -233,7 +233,7 @@ In the following examples we show how, requests introduced by different regulati > Data unique to, and under control of the system | Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | -| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | +| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | | **system** | **authentication** | Data used to manage access to the system | `**TBD**` | `null` | `null` | Add AUTHENTICATION ? (as a meta cat of biometric ?) | | **system** | **operations** | Data used for system operations | `**Any/all**` | `**Any/all**` | `null` | Ok ? | @@ -246,7 +246,7 @@ In the following examples we show how, requests introduced by different regulati > Data derived from user provided data or as a result of user actions in the system | Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | -| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | +| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | | **user.derived** | **identifiable** | Derived data that is linked to, or identifies a user | `**TBD**` | `null` | `null` | TBD, isn't it all the data for us ? | | **user.derived.identifable** | **biometric_health** | Encoded characteristic collected about a user | `BIOMETRIC`,`HEALTH` | `null` | `null` | Ok ? | | **user.derived.identifable** | **browsing_history** | Content browsing history of a user | `BEHAVIOR` | `null` | `null` | Ok ? | @@ -279,7 +279,7 @@ In the following examples we show how, requests introduced by different regulati > Data provided or created directly by a user of the system | Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | -| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | +| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | | **user.provided** | **identifiable** | Data provided or created directly by a user that is linked to or identifies a user | `**TBD**` | `null` | `null` | TBD, isn't it all the data for us ? | | **user.provided.identifiable** | **identifiable** | Encoded characteristics provided by a user | `**TBD**` | `null` | `null` | `null` | | **user.provided.identifiable** | **children** | Data relating to children | `OTHER`,`RELATIONSHIP` | `null` | `null` | Ok ? Need a more detailed cat ? | From 7f0d87475efbde949b601432e19c4d460e8c9637 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 9 Jun 2022 17:20:53 +0200 Subject: [PATCH 141/204] typo --- refs/schemas/priv/RFC-PRIV.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 7d54cde7..081b3741 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -130,7 +130,7 @@ The key element that defines the nature of the Demand is the `action`. A Demand Actions are hierarchical. Their relationships are denoted with a dot "." separating two actions, the more general one being written on the left. `TRANSPARENCY` includes `TRANSPARENCY.WHERE`. -When `TRANSPARENCY` is demanded, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` were demanded. +When `TRANSPARENCY` is Demandd, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` were Demandd. Certain Demands MAY include data, such as a `MODIFY` Demand where new data MAY be provided by the Data Subject. @@ -293,7 +293,7 @@ Regardless of the [scenario (Responding to the Data Subject directly or to the S | `in-response-to` | 1 | `request-id` of the Privacy Request to which response is made or `demand-id` of the particular Demand to which response is made, in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Privacy Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `by` | 1 | **TBD ID of the System having generated the response** | -| `requested-action` | 0-1 | Optional information about the action that was demanded, and to which the response is made. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | +| `requested-action` | 0-1 | Optional information about the action that was Demandd, and to which the response is made. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | | `data-subject` | 0-* | Optional indication of the [Data Subject Identities](#decentralized-identity-of-data-subjects) to which the response refers to | | `status` | 1 | One of {`GRANTED`, `DENIED`, `PARTIALLY-GRANTED`, `UNDER-REVIEW`} | | `motive` | 0-* | Optionally one of {`IDENTITY-UNCONFIRMED`, `LANGUAGE-UNSUPPORTED`, `LEGAL-BASES`, `LEGAL-OBLIGATIONS`, `NO-SUCH-DATA`, `REQUEST-UNSUPPORTED`, `USER-UNKNOWN`} | From 13512921a2fabf776e8de3de708b8bd6cf40afff Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 9 Jun 2022 19:32:27 +0200 Subject: [PATCH 142/204] changes Filip requested + improving terms for clarity --- refs/notion-of-privacy/notion-of-privacy.md | 10 +- refs/schemas/priv/RFC-PRIV.md | 38 +++---- .../priv/dictionary/actions/en.actions.json | 8 +- .../en.other.json => boolean/en.boolean.json} | 0 .../data-categories/en.data-categories.json | 9 +- .../priv/dictionary/events/en.events.json | 5 + .../legal-bases/en.legal-bases.json | 4 +- .../priv/dictionary/motives/en.motives.json | 4 +- .../en.processing-categories.json | 10 +- .../priv/dictionary/purposes/en.purposes.json | 4 +- .../dictionary/retentions/en.retentions.json | 4 + .../priv/dictionary/statuses/en.statuses.json | 3 +- refs/schemas/priv/expected-behavior.md | 29 +++--- .../priv/json-schema/priv-terms.schema.json | 98 +++++++++++-------- 14 files changed, 128 insertions(+), 98 deletions(-) rename refs/schemas/priv/dictionary/{other/en.other.json => boolean/en.boolean.json} (100%) create mode 100644 refs/schemas/priv/dictionary/events/en.events.json create mode 100644 refs/schemas/priv/dictionary/retentions/en.retentions.json diff --git a/refs/notion-of-privacy/notion-of-privacy.md b/refs/notion-of-privacy/notion-of-privacy.md index 15bb382f..4219f2f7 100644 --- a/refs/notion-of-privacy/notion-of-privacy.md +++ b/refs/notion-of-privacy/notion-of-privacy.md @@ -12,9 +12,9 @@ Among the many definitions proposed in scientific literature, we use the followi > « **Privacy is the selective control of access to the self** » — _Irwin Altman[^1]_ -This definition captures the essential features of the concept, in particular: +This definition captures the essential features of the concept, in particular the following. -- Privacy is about the **self**. +### Privacy is about the **self**. The _self_ is a very important element of human experience playing _"an integral part in human motivation, cognition, affect, and social identity"_[^2]. @@ -29,11 +29,11 @@ Also, undoubtedly, in part _"the self emerges through interaction with others"_[ Due to the relational provenance of the knowledge of the self, privacy is one of the key features of the relationship of oneself with the surrounding world (other humans and artefacts) through which the knowledge of the self is formed. Privacy is a "factor of connection to oneself and to others"[^6]. -- Privacy is about **control of access**. +### Privacy is about **control of access**. As relationships play a key role in shaping the view on the self, it is of crucial importance for the individual to control the access to self, and thus maintain control over their own view of the self. -- Privacy is **selective**. +### Privacy is **selective**. It is not an absolute binary "come in" vs. "go away". It is a nuanced choice to control access to parts of the _self_. @@ -151,7 +151,7 @@ Researchers consider privacy-oblivious behavior to be a result of technological ### Internet Systems are Tools For Connection -The rise of Internet Systems and of the Web[^29] is inspired by the concept of Memex, proposed by Vannevar Bush in 1945 in his article *As We May Think*[^25]. Memex is imagined as a tehorethical machine that humans can use to augment their cognitive powers. Memex can store information and provide access to it at later times. Also Memex is collaborative, as it can facilitate access to information provided by others - a *collective memory-extension tool*. +The rise of Internet Systems and of the Web[^29] is inspired by the concept of Memex, proposed by Vannevar Bush in 1945 in his article *As We May Think*[^25]. Memex is imagined as a theoretical machine that humans can use to augment their cognitive powers. Memex can store information and provide access to it at later times. Also Memex is collaborative, as it can facilitate access to information provided by others - a *collective memory-extension tool*. Memex was the inspiration for: - NLS[^26], a system that used the early internet infrastructure to demonstrate the pioneering use of videoconferencing, collaborative document editing, hypermedia, document version control and many other concepts prevalent in modern Internet Systems. Developed in 1968, by Doug Engelbart, it was the first system to implement practical use of hypertext links[^27] for connecting information diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 081b3741..07a18f10 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -33,7 +33,7 @@ Different Systems, and different components of a single System, including differ >**TO BE Updated** once Lexicon and High Level Conceptualization are synchronised -- We use the term Privacy Request interchangeably with the (deprecated) terms Privacy Request and Data Privacy Request as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) +- We use the term Privacy Request interchangeably with the (deprecated) terms Rights Request and Data Rights Request as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) - We use the terms Individual, Person, You, and Data Subject as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) - We use the term System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) - We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) @@ -47,9 +47,9 @@ This document defines the version `1.0` of the Privacy Request Interchange Vocab ### Design Inspiration -- **Smart data structures and dumb code works a lot better than the other way around.** lesson No 9 from Raymond, Eric Steven. "The Cathedral and the Bazaar". We want PRIF to embody a smart way of thinking about privacy, solving common challenges through the data structure itself. +- **Smart data structures and dumb code works a lot better than the other way around.** lesson No 9 from Raymond, Eric Steven. ["The Cathedral and the Bazaar"](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar). We want PRIF to embody a smart way of thinking about privacy, solving common challenges through the data structure itself. -- **Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.** lesson No 12 from Raymond, Eric Steven. "The Cathedral and the Bazaar". We indeed now have novel understanding of the [problem of Privacy in Software Systems](https://github.com/blindnet-io/product-management/blob/main/refs/notion-of-privacy/notion-of-privacy.md). +- **Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.** lesson No 12 from Raymond, Eric Steven. ["The Cathedral and the Bazaar"](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar). We indeed now have novel understanding of the [problem of Privacy in Software Systems](https://github.com/blindnet-io/product-management/blob/main/refs/notion-of-privacy/notion-of-privacy.md). ### Design Goals @@ -58,7 +58,7 @@ With this design we seek: - Minimal exposure of Data Subject and their data during the processing of a Privacy Request, - Making processing of Privacy Requests as automatic as possible, - Compatibility with the use of different protocols and tools for user identity management, authentication, and encryption, -- Allowing developers to be fully comply with [supported legislation](#supported-legislation) related to Privacy Requests quickly and easily +- Allowing developers to fully comply with [supported legislation](#supported-legislation) related to Privacy Requests quickly and easily - Exhaustivity with regards to situations we need to support in response to [supported legislation](#supported-legislation) yet Extensibility in case new situations arise in the future. - Highly normative minimal specification, using as much as possible the [Plain Language](https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf) while at the same time making clear references to the (often misfortunate) language of the [supported legislations](#supported-legislation) - Limit, as much as possible, the possibility of representing the same meaning in more than one way @@ -119,7 +119,7 @@ A Demand is a concrete action that the user requests. | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `demand-id` | 1 | Unique ID for referring to this demand in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `action` | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | +| `action` | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER-DEMAND`} | | `message` | 0-1 | Optional string comment, motivation or explanation of Demand | | `lang` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | | `data` | 0-* | Optionally concrete data (Format **TBD**) | @@ -130,7 +130,7 @@ The key element that defines the nature of the Demand is the `action`. A Demand Actions are hierarchical. Their relationships are denoted with a dot "." separating two actions, the more general one being written on the left. `TRANSPARENCY` includes `TRANSPARENCY.WHERE`. -When `TRANSPARENCY` is Demandd, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` were Demandd. +When `TRANSPARENCY` is demanded, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` were demanded. Certain Demands MAY include data, such as a `MODIFY` Demand where new data MAY be provided by the Data Subject. @@ -164,7 +164,7 @@ Privacy Scope = (Data Categories) x (Categories of Processing) x (Purposes of Pr | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-categories` | 0-* | `AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.RELATIONSHIPS`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, UID.USER-ACCOUNT , UID.SOCIAL-MEDIA , `OTHER` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | +| `data-categories` | 0-* | `AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, UID.USER-ACCOUNT , UID.SOCIAL-MEDIA , `OTHER-DATA` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | When several values are given, Systems MUST interpret the `data-category` dimension as a union of all the categories indicated. @@ -180,7 +180,7 @@ In the absence of indication of any `data-category` dimension, Systems MUST inte | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `processing-categories` | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `USING`, `OTHER`} | +| `processing-categories` | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `USING`, `OTHER-PROCESSING`} | When several values are given, Systems MUST interpret the `processing-categories` dimension as a union of all the processing categories indicated. @@ -192,7 +192,7 @@ In the absence of indication of any `processing-categories` dimension, Systems M | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `purposes` | 0-* | `ADVERTISING`, `COMPLIANCE`, `EMPLOYMENT`, `JUSTICE`, `MARKETING`, `MEDICAL`, `PERSONALISATION`, `PUBLIC-INTERESTS`, `RESEARCH`, `SALE`, `SECURITY`, `SERVICES`, `SERVICES.ADDITIONAL-SERVICES`, `SERVICES.BASIC-SERVICE`, `SOCIAL-PROTECTION`, `TRACKING`, `VITAL-INTERESTS`, `OTHER` | +| `purposes` | 0-* | `ADVERTISING`, `COMPLIANCE`, `EMPLOYMENT`, `JUSTICE`, `MARKETING`, `MEDICAL`, `PERSONALISATION`, `PUBLIC-INTERESTS`, `RESEARCH`, `SALE`, `SECURITY`, `SERVICES`, `SERVICES.ADDITIONAL-SERVICES`, `SERVICES.BASIC-SERVICE`, `SOCIAL-PROTECTION`, `TRACKING`, `VITAL-INTERESTS`, `OTHER-PURPOSE` | When several values are given, Systems MUST interpret the `purposes` restriction as a union of all the purposes indicated. @@ -291,13 +291,13 @@ Regardless of the [scenario (Responding to the Data Subject directly or to the S | --------------- | ------ | -------------------- | | `response-id` | 1 | Unique ID for referring to this request in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `in-response-to` | 1 | `request-id` of the Privacy Request to which response is made or `demand-id` of the particular Demand to which response is made, in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `date` | 1 | Date and Time when Privacy Request was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `date` | 1 | Date and Time when Privacy Request Response was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `by` | 1 | **TBD ID of the System having generated the response** | -| `requested-action` | 0-1 | Optional information about the action that was Demandd, and to which the response is made. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER`} | +| `requested-action` | 0-1 | Optional information about the action that was demanded, and to which the response is made. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER-DEMAND`} | | `data-subject` | 0-* | Optional indication of the [Data Subject Identities](#decentralized-identity-of-data-subjects) to which the response refers to | | `status` | 1 | One of {`GRANTED`, `DENIED`, `PARTIALLY-GRANTED`, `UNDER-REVIEW`} | -| `motive` | 0-* | Optionally one of {`IDENTITY-UNCONFIRMED`, `LANGUAGE-UNSUPPORTED`, `LEGAL-BASES`, `LEGAL-OBLIGATIONS`, `NO-SUCH-DATA`, `REQUEST-UNSUPPORTED`, `USER-UNKNOWN`} | -| `answers` | 0-* | Any of the terms the meaning of which is defined by the present format and its dictionaries or an object representing a Legal Base, a [Retention Policy](#retention-policy) | +| `motive` | 0-* | Optionally one of {`IDENTITY-UNCONFIRMED`, `LANGUAGE-UNSUPPORTED`, `VALID-REASONS`, `IMPOSSIBLE`, `NO-SUCH-DATA`, `REQUEST-UNSUPPORTED`, `USER-UNKNOWN`} | +| `answers` | 0-* | Any of the terms the meaning of which is defined by the present vocabulary | | `message` | 0-1 | Optional string comment, motivation or explanation of Demand | | `lang` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | | `includes` | 0-* | Optionally an array of one or more [Privacy Request Response](#privacy-request-response)s | @@ -313,6 +313,8 @@ Privacy Request Responses can be nested. One can imagine a Privacy Request Respo When a Demand is being denied, the Privacy Request Response MUST provide a `motive`. +>To illustrate the `answers` value, we can imagine a `TRANSPARENCY.DATA-CATEGORIES` Demand, to which a response may include `answers`: `CONTACT`, `IMAGE`. Or a `TRANSPARENCY.KNOWN` Demand to which the answer may include `answers`: `YES`. + ### Consent A Consent is given by one Data Subject which can be identified by one or more [Data Subject Identities](#decentralized-identity-of-data-subjects). @@ -353,13 +355,13 @@ A Data Capture concerns one and only one Data Subject who MAY be identified by m | `retention` | 1-* | one or more [Retention Policies](#retention-policy) | | `provenance` | 1-* | one or more [Provenance](#provenance) | | `data` | 0-* | Optionally concrete data (Format **TBD**) | -| `legal-base` | 0-* | Optionally an array of values among `CONTRACT`, `CONSENT`, `LEGITIMATE-INTEREST`, `NECESSARY`, `OTHER` | +| `legal-base` | 0-* | Optionally an array of values among `CONTRACT`, `CONSENT`, `LEGITIMATE-INTEREST`, `NECESSARY`, `OTHER-LEGAL-BASE` | `selector`s MUST include the data category of the data. For example selectors 'CONTACT.ADDRESS.SHIPPING' and 'CONTACT.ADDRESS.BILLING' indicate that the data being captured by a particular fragment belong to the `CONTACT.ADDRESS` data category. While the Data Categories are global, the selectors are defined by the Systems. A `selector` uniquely identifies a particular data field that the Systems works with. When several Systems exchange data among them, they SHOULD align on using the same `selectors` in the same way, in order to be able to correctly interoperate. -Processing MAY be legitimate according to several legal bases for processing. For example, a Data Subject can give explicit `CONSENT` when creating and account with a particular online service, and at the time, the System providing some service to the Data Subject might need to process their data in order to deliver a service or honour a `CONTRACT` (e.g. deliver the purchased goods to the Data Subjects address and issue an invoice). +Processing MAY be legitimate according to several legal bases for processing. For example, a Data Subject can give explicit `CONSENT` when creating an account with a particular online service, and at the time, the System providing some service to the Data Subject might need to process their data in order to deliver a service or honour a `CONTRACT` (e.g. deliver the purchased goods to the Data Subjects address and issue an invoice). Certain processing is made legitimate (`LEGITIMATE-INTEREST`) or mandatory (`NECESSARY`) by law, e.g. [Article 6 og GDPR](https://gdpr-info.eu/art-6-gdpr/). @@ -380,7 +382,7 @@ The same Data Capture Fragment might be data collected from the `USER` for one S | `data-category` | 1-* | Any of the any Data Category terms or concrete Data Capture Fragment `selector`s within those categories | | `policy-type` | 1 | one of {NO-LONGER-THAN, "NO-LESS-THAN"} | | `duration` | 1 | Duration in JSON Schema [duration](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| `after` | 1 | Event to which the retention duration is relative to. One of {`DATA-COLLECTION`,`RELATIONSHIP-END`} +| `after` | 1 | Event to which the retention duration is relative to. One of {`CAPTURE-DATE`,`RELATIONSHIP-END`, `SERVICE-END`} When several `data-category` values are given, they are interpreted as a union. @@ -388,8 +390,6 @@ When several `data-category` values are given, they are interpreted as a union. A separate document gives a list of [examples](examples.md) on how to represent real-life Privacy Requests, as defined in [supported legislation](#supported-legislation), or as modelled in existing systems with which we seek interoperability. -## Detailed Design - ### JSON format We provide a [JSON Schema document](./priv.schema.json) for machine-readable interpretation of Privacy Requests compliant with [v4 (or ideally lower) of IETF specification](https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#:~:text=JSON%20Schema%20is%20a%20JSON,interaction%20control%20of%20JSON%20data.) @@ -564,7 +564,7 @@ In order to automatically respond to data-specific demands, Systems should store >**Note** > -> To automatically calculate legality of keeping a particular data, Systems MUST track events such as Data Capture, End of Contract, Account Deletion +> To automatically calculate legality of keeping a particular data, Systems MUST track events such as Data Capture, End of Contract / Account Deletion ### Exposing Privacy Request API diff --git a/refs/schemas/priv/dictionary/actions/en.actions.json b/refs/schemas/priv/dictionary/actions/en.actions.json index 398a6d3d..522e661b 100644 --- a/refs/schemas/priv/dictionary/actions/en.actions.json +++ b/refs/schemas/priv/dictionary/actions/en.actions.json @@ -2,9 +2,9 @@ "ACCESS": "To access the data the System has on me", "DELETE": "To have my data deleted", "MODIFY": "To modify the existing or complement the incomplete data the System has on me", - "OBJECT": "To contact the user to offer products, services, or other promotions", - "PORTABILITY": "To take my day and ahve it transfered somewhere else", - "RESTRICT": "To restrict processing of my data", + "OBJECT": "To object to processing of my data", + "PORTABILITY": "To take my data and have it transfered somewhere else", + "RESTRICT": "To restrict processing of my data to a particular scope", "REVOKE-CONSENT": "To revoke prviousely given consent for data processing", "TRANSPARENCY": "To demand information related to data processing practices and know if the system has data on me", "TRANSPARENCY.DATA-CATEGORIES": "To know the categories of the data the system has on me", @@ -19,5 +19,5 @@ "TRANSPARENCY.RETENTION": "To know for how long is the data concerning me kept", "TRANSPARENCY.WHERE": "To know where is the data about me stored", "TRANSPARENCY.WHO": "To know who can access the data that the System has on me", - "OTHER": "To do or know something else (specify within the message)", + "OTHER-DEMAND": "To do or know something else (specify within the message)", } diff --git a/refs/schemas/priv/dictionary/other/en.other.json b/refs/schemas/priv/dictionary/boolean/en.boolean.json similarity index 100% rename from refs/schemas/priv/dictionary/other/en.other.json rename to refs/schemas/priv/dictionary/boolean/en.boolean.json diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index d88323f3..db8b80e3 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -7,11 +7,10 @@ "BEHAVIOR.ACTIVITY": "Activities perfomed online or off-line", "BEHAVIOR.CONNECTION": "Times of connection", "BEHAVIOR.PREFERENCE": "Data about the person's preferences", - "BEHAVIOR.RELATIONSHIPS": "Social activity and interaction data", "BEHAVIOR.TELEMETRY": "Measurement data from system sensors and monitoring", "BIOMETRIC": "Biometric data", - "CONTACT": "Data allowing to contact the person", - "CONTACT.EMAIL": "E-mail address", + "CONTACT": "Data allowing to contact the person", + "CONTACT.EMAIL": "E-mail address", "CONTACT.ADDRESS": "Postal address", "CONTACT.PHONE": "Phone number", "DEMOGRAPHIC": "All information allowing to class the person in a demographic category", @@ -28,11 +27,11 @@ "HEALTH": "Data about the health", "IMAGE": "Any graphic representation (e.g., image, video) of the person", "LOCATION": "Geographic location", - "NAME": "First names, last names, nicknames, and other names", + "NAME": "First names, last names, nicknames, and other names", "PROFILING": "Any data establishing a degree of similarity of the person with others (e.g., clusters, user-profiles)", "RELATIONSHIPS": "Data about relationships of the person with others", "UID": "Any data allowing to uniquely identify a person", "UID.USER-ACCOUNT": "Data about a person's account or profile on the first-party website/app and its contents", "UID.SOCIAL-MEDIA": "Data about a person's account or profile from a social media website/app or other third party service", - "OTHER": "Other data" + "OTHER-DATA": "Other data" } diff --git a/refs/schemas/priv/dictionary/events/en.events.json b/refs/schemas/priv/dictionary/events/en.events.json new file mode 100644 index 00000000..5f3879ad --- /dev/null +++ b/refs/schemas/priv/dictionary/events/en.events.json @@ -0,0 +1,5 @@ +{ + "CAPTURE-DATE": "A date when the data has been catured", + "RELATIONSHIP-END": "A date when the relationship with the Data Subject ended", + "SERVICE-END": "A date when the particular service ended", +} diff --git a/refs/schemas/priv/dictionary/legal-bases/en.legal-bases.json b/refs/schemas/priv/dictionary/legal-bases/en.legal-bases.json index 6729343c..eaf5673b 100644 --- a/refs/schemas/priv/dictionary/legal-bases/en.legal-bases.json +++ b/refs/schemas/priv/dictionary/legal-bases/en.legal-bases.json @@ -1,7 +1,7 @@ { "CONSENT": "The Data Subject gave Consent for processing", - "CONTRACT": "Processing is necessary for providing services to the Data Subject or withing a for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract", + "CONTRACT": "Processing is necessary for providing services to the Data Subject or for the fulfilment of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract", "LEGITIMATE-INTEREST": "Processing is necessary for the purposes of the legitimate interests", "NECESSARY": "Processing is necessary for security reasons, legal reasons or protection of rights", - "OTHER": "Other legal base", + "OTHER-LEGAL-BASE": "Other legal base", } diff --git a/refs/schemas/priv/dictionary/motives/en.motives.json b/refs/schemas/priv/dictionary/motives/en.motives.json index e5c35944..d7272327 100644 --- a/refs/schemas/priv/dictionary/motives/en.motives.json +++ b/refs/schemas/priv/dictionary/motives/en.motives.json @@ -1,8 +1,8 @@ { "IDENTITY-UNCONFIRMED": "Can't confirm the Data Subject Indentity", "LANGUAGE-UNSUPPORTED": "The language of the request is not understood by the Organization", - "LEGAL-GROUNDS": "The System has legal grounds to repsond in the way it responds", - "LEGAL-OBLIGATIONS": "The System has legal obligation to repsond in the way it responds", + "VALID-REASONS": "The System has valid reasons or legal grounds to repsond in the way it responds", + "IMPOSSIBLE": "It is impossible for the System to respond any other way due to legal obligations", "REQUEST-UNSUPPORTED": "The System does not recongize the particular type of request that is made", "USER-UNKNOWN":"The System does not recongize the Data Subject havign made the request", } diff --git a/refs/schemas/priv/dictionary/processing-categories/en.processing-categories.json b/refs/schemas/priv/dictionary/processing-categories/en.processing-categories.json index f710c64b..ddba2662 100644 --- a/refs/schemas/priv/dictionary/processing-categories/en.processing-categories.json +++ b/refs/schemas/priv/dictionary/processing-categories/en.processing-categories.json @@ -1,13 +1,13 @@ { - "ANONYMIZATION": "Processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information", + "ANONYMIZATION": "Processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information", "AUTOMATED-INFERENCE": "Automatically infering data about the person, including for profiling and clustering", - "AUTOMATED-DECISION-MAKING": "Automated decision-making", - "COLLECTION": "Collecting data about the person from the person or from another source, including ", + "AUTOMATED-DECISION-MAKING": "Automated decision-making", + "COLLECTION": "Collecting data about the person from the person or from another source, including another person or a System", "GENERATING": "Producing novel data related to the person, such as making photo, voice or video recordings, or reconding user actions such as making a log.", "MATCHING": "Matching the data about the same person across multiple data sources", "PUBLISHING": "Making data publicly available", - "STORING": "Storing data for further use, including adaptations and formating of the data", + "STORING": "Storing data for further use, including adaptations and formating of the data", "SHARING": "Sharing data in controled manner with clearly identified parties", "USING": "Consulting and using data", - "OTHER": "Other data" + "OTHER-PROCESSING": "Other processing categories" } diff --git a/refs/schemas/priv/dictionary/purposes/en.purposes.json b/refs/schemas/priv/dictionary/purposes/en.purposes.json index c792400a..6e9ff816 100644 --- a/refs/schemas/priv/dictionary/purposes/en.purposes.json +++ b/refs/schemas/priv/dictionary/purposes/en.purposes.json @@ -2,7 +2,7 @@ "ADVERTISING": "To show ads that are either targeted to the specific user or not targeted", "COMPLIANCE": "Processing is performed to comply with a legal obligation", "EMPLOYMENT": " For personnel training, recruitment, payroll, management, etc", - "JUSTICE": "processing is necessary for the establishment, exercise or defence of legal claims or whenever courts are acting in their judicial capacity", + "JUSTICE": "Processing is necessary for the establishment, exercise or defence of legal claims or whenever courts are acting in their judicial capacity", "MARKETING": "To contact the user to offer products, services, or other promotions", "MEDICAL": "Processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services", "PERSONALISATION": "For providing user with a personalized experience", @@ -16,5 +16,5 @@ "SOCIAL-PROTECTION": "Processing is necessary for the purposes of employment and social security and social protection", "TRACKING": "Tracking information about user behavior and activity online", "VITAL-INTERESTS": "Processing is necessary in order to protect the vital interests of the data subject or of another natural person", - "OTHER": "Other specific purpose", + "OTHER-PURPOSE": "Other specific purpose", } diff --git a/refs/schemas/priv/dictionary/retentions/en.retentions.json b/refs/schemas/priv/dictionary/retentions/en.retentions.json new file mode 100644 index 00000000..58284bf6 --- /dev/null +++ b/refs/schemas/priv/dictionary/retentions/en.retentions.json @@ -0,0 +1,4 @@ +{ + "NO-LONGER-THAN": "No longer than the given period of time after specified event", + "NO-LESS-THAN": "At least the given period of time after specified event", +} diff --git a/refs/schemas/priv/dictionary/statuses/en.statuses.json b/refs/schemas/priv/dictionary/statuses/en.statuses.json index cfaa9518..e65b7c2e 100644 --- a/refs/schemas/priv/dictionary/statuses/en.statuses.json +++ b/refs/schemas/priv/dictionary/statuses/en.statuses.json @@ -2,5 +2,6 @@ "GRANTED": "Granted", "DENIED": "Denied", "PARTIALLY-GRANTED": "Partially granted", - "UNDER-REVIEW": "Under review" + "UNDER-REVIEW": "Under review", + "OTHER-RESPONSE" } diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 911ceded..b955cc1b 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -58,7 +58,7 @@ A [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/mast - *Legal Bases*: For each **Privacy Scope Triple** from the **Intended Privacy Scope**, one or more [Legal Bases](./RFC-PRIV.md#legal-bases) - - *Corresponding Systems**: A map of Other Systems with which data is being exchanged. For each System The Privacy Compiler MUST know if they are an `ORGANISATION` or `PARTNERS` System, and have a way to uniquely identify and address them (see [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV), [Working with Provenance](#working-with-provenance)) + - *Corresponding Systems*: A map of Other Systems with which data is being exchanged. For each System The Privacy Compiler MUST know if they are an `ORGANISATION` or `PARTNERS` System, and have a way to uniquely identify and address them (see [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV), [Working with Provenance](#working-with-provenance)) - **Privacy Metadata Store**, updated at runtime: - *All Captures*: a list of all the [Data Capture](./RFC-PRIV.md#data-capture) objects that the Privacy Compiler is aware of @@ -75,8 +75,10 @@ A [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/mast - *Active Consents*: a list of `consent-id`s that is modified when Consent is collected and within [Operations over consents](#operations-over-consents) - *Active Contracts*: a list of `contract-id`s of all active contracts that have not been subject to a `RELATIONSHIP-END` event - *Active Legitimate Interests*: a subset of *All Legitimate Interests* - - Events: - - `RELATIONSHIP-END` events for contracts that end (e.g. user closes the account, or stops a service agreement), that directly impact *Active Contracts* the **Privacy Scope Triple**s of which have not been in the scope of any `DELETE`, `OBJECT`, or `RESTRICT` Privacy Request by the data Subject concerned + - Events, for [Resolving Retention Policies](#resolving-retention-policies): + - `SERVICE-END` events for contracts that end (e.g. user closes the account, or stops a service agreement), that directly impact *Active Contracts* the **Privacy Scope Triple**s of which have not been in the scope of any `DELETE`, `OBJECT`, or `RESTRICT` Privacy Request by the data Subject concerned + - `RELATIONSHIP-END` events the Data Subject ended all contracts and ended the relationship with the System/Organization + - `CAPTURE-DATE` when a Data Capture is made or updated - Transfers: - All the data exchanges with other Systems, as described in [Remembering Transfers](./RFC-PRIV.md#remembering-transfers). - Privacy Scope: @@ -481,11 +483,12 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - their `scope` is included in the **Restriction Scope**, AND - they match the Provenance Restriction criteria (as seen in [Resolving provenance in requests](#resolving-provenance-in-requests)) -> **Note** -> -> Data Capture Fragments the scopes of which fall under the **Restriction Scope** are not the same as (but are a superset of) the Data Capture Fragments included in the **Concerned Fragments** scope. -> -> This is due to [Data Range](./RFC-PRIV.md#data-range), [Capture Restriction](./RFC-PRIV.md#capture-restriction) and [Provenance Restriction](./RFC-PRIV.md#provenance-restriction), all of which might be used to select particular Data Capture Fragments out of many thay may be captured with the same Data Capture Fragment `selector`. + > **Note** + > + > Data Capture Fragments the scopes of which fall under the **Restriction Scope** are not the same as (but are a superset of) the Data Capture Fragments included in the **Concerned Fragments** scope. + > + > This is due to [Data Range](./RFC-PRIV.md#data-range), [Capture Restriction](./RFC-PRIV.md#capture-restriction) and [Provenance Restriction](./RFC-PRIV.md#provenance-restriction), all of which might be used to select particular Data Capture Fragments out of many thay may be captured with the same Data Capture Fragment `selector`. + > - third, with regards to the `action` of the Demand: - `TRANSPARENCY.LEGAL-BASES` Demands, recommend status = `GRANTED`, and data = list of Legal Bases under which any of the Privacy Scope Triples are included in the **Restriction Scope** @@ -529,20 +532,20 @@ When Data Subject ID is provided, the Data Subject is known by the System and au ## Resolving Retention Policies -[Privacy Compilers](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) SHOULD store and resolve [Retention Policies](./RFC-PRIV.md#retention-policy). +[Privacy Compilers](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) SHOULD store and resolve [Retention Policies](./RFC-PRIV.md#retention-policy), as well as to them associated *Events* in **Runtime Maps**. Systems SHOULD define Retention Policies at the time of configuration, and SHOULD cover all Data Categories and Data Capture Fragment `selector`s from the Intended Privacy Scope with at least one Retention Policy. -Retention Policies are resolved upon concrete instances of data. A particular instance of data, given the Data Capture Fragment `selector` to which it corresponds, is considered `EXPIRED` if all of the following is true: -- There is a Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular data, that is of type `NO-LONGER-THAN`, such that the date of the event defined under `after` has passed for a more then the time defined under `duration` -- AND There is no Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular data, that is of type `NO-LESS-THAN`, such that the event defined under `after` is yet to happen or has happened before a period of time inferior to `duration` +Retention Policies are resolved upon concrete instances of Data Capture Fragments. A particular instance of data, given the Data Capture Fragment `selector` to which it corresponds, is considered `EXPIRED` if all of the following is true: +- There is a Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular Data Capture Fragment, that is of type `NO-LONGER-THAN`, such that the date of the event defined under `after` has passed for a more then the time defined under `duration` +- AND There is no Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular Data Capture Fragment, that is of type `NO-LESS-THAN`, such that the event defined under `after` is yet to happen or has happened before a period of time inferior to `duration` Privacy Compilers SHOULD be able to: - provide lists of active policies, in the context of answering to the `TRANSPARENCY.RETENTION` requests - resolve policies and generate `EXPIRED` alerts, upon which the Systems MAY chose to implement automatic data deletion, or other protocols for data archiving or similar - resolve policies for Systems configured not to automatically delete data, but to automatically grant `DELETE` requests only when data is `EXPIRED` -Optionally, for systems wanting to automatically deny `DELETE` requests when data MUST be kept, Privacy Compilers MAY be able deliver resolve policies giving `HOLD` status, when there is at least one Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular data, that is of type `NO-LESS-THAN`, such that the event defined under `after` is yet to happen or has happened before a period of time inferior to `duration`. +Optionally, for systems wanting to automatically deny `DELETE` requests when data MUST be kept, Privacy Compilers MAY be able resolve policies giving `HOLD` status, when there is at least one Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular data, that is of type `NO-LESS-THAN`, such that the event defined under `after` is yet to happen or has happened before a period of time inferior to `duration`. ## Working with Provenance diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json index a72cc257..5d091f89 100644 --- a/refs/schemas/priv/json-schema/priv-terms.schema.json +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -25,7 +25,13 @@ "TRANSPARENCY.RETENTION", "TRANSPARENCY.WHERE", "TRANSPARENCY.WHO", - "OTHER" + "OTHER-DEMAND" + ] + }, + "boolean": { + "enum": [ + "YES", + "NO" ] }, "data-categories": { @@ -38,7 +44,6 @@ "BEHAVIOR.ACTIVITY", "BEHAVIOR.CONNECTION", "BEHAVIOR.PREFERENCE", - "BEHAVIOR.RELATIONSHIPS", "BEHAVIOR.TELEMETRY", "BIOMETRIC", "CONTACT", @@ -65,7 +70,32 @@ "UID", "UID.USER-ACCOUNT", "UID.SOCIAL-MEDIA", - "OTHER", + "OTHER-DATA", + ] + }, + "events": { + "enum": [ + "CAPTURE-DATE", + "RELATIONSHIP-END" + ] + }, + "legal-bases": { + "enum": [ + "CONSENT", + "CONTRACT", + "LEGITIMATE-INTEREST", + "NECESSARY", + "OTHER-LEGAL-BASE" + ] + }, + "motives": { + "enum": [ + "IDENTITY-UNCONFIRMED", + "LANGUAGE-UNSUPPORTED", + "VALID-REASONS", + "IMPOSSIBLE", + "REQUEST-UNSUPPORTED", + "USER-UNKNOWN" ] }, "processing-categories": { @@ -78,9 +108,19 @@ "PUBLISHING", "STORING", "SHARING", - "USING" + "USING", + "OTHER-PROCESSING" ] }, + "provenance": { + "enum": [ + "DERIVED", + "TRANSFERRED", + "USER", + "USER.DATA-SUBJECT" + ] + } + }, "purposes": { "enum": [ "ADVERTISING", @@ -100,30 +140,7 @@ "SOCIAL-PROTECTION", "TRACKING", "VITAL-INTERESTS", - "OTHER", - ] - }, - "targets": { - "enum": [ - "ORGANISATION", - "PARTNERS", - "SYSTEM" - ] - }, - "targets-directional": { - "enum": [ - "PARTNERS.DOWNWARD", - "PARTNERS.UPWARD" - ] - }, - "motives": { - "enum": [ - "IDENTITY-UNCONFIRMED", - "LANGUAGE-UNSUPPORTED", - "LEGAL-BASES", - "LEGAL-OBLIGATIONS", - "REQUEST-UNSUPPORTED", - "USER-UNKNOWN" + "OTHER-PURPOSE", ] }, "retentions": { @@ -132,25 +149,26 @@ "NO-LESS-THAN" ] }, - "events": { + "statuses": { "enum": [ - "DATA-COLLECTION", - "RELATIONSHIP-END" + "GRANTED", + "DENIED", + "PARTIALLY-GRANTED", + "UNDER-REVIEW", + "OTHER-RESPONSE" ] }, - "other": { + "targets": { "enum": [ - "YES", - "NO" + "ORGANISATION", + "PARTNERS", + "SYSTEM" ] }, - "provenance": { + "targets-directional": { "enum": [ - "DERIVED", - "TRANSFERRED", - "USER", - "USER.DATA-SUBJECT" + "PARTNERS.DOWNWARD", + "PARTNERS.UPWARD" ] } - } } From 030bd6ac41d338ca038765c0f7bb7f31865928b3 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 9 Jun 2022 19:50:30 +0200 Subject: [PATCH 143/204] updating categories that I changed --- refs/schemas/priv/examples.md | 36 +++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index ca20a21e..d2b0b638 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -47,7 +47,7 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.13.1.d`, `GDPR.14.1.d` | where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party | action:`TRANSPARENCY.LEGAL-BASES` | | `GDPR.13.1.e`, `GDPR.14.1.e` | the recipients or categories of recipients of the personal data, if any; | action:`TRANSPARENCY.WHO` | | `GDPR.13.1.f`, `GDPR.14.1.f` | where applicable, the fact that the controller intends to transfer personal data to a third country or international organisation | action:`TRANSPARENCY.WHERE` | -| `GDPR.13.1.f`, `GDPR.14.1.f` | the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means by which to obtain a copy of them or where they have been made available. | action:`OTHER` | +| `GDPR.13.1.f`, `GDPR.14.1.f` | the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means by which to obtain a copy of them or where they have been made available. | action:`OTHER-DEMAND` | | `GDPR.13.2.a`, `GDPR.14.2.a` | the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period | action:`TRANSPARENCY.RETENTION` | | `GDPR.13.2.b`, `GDPR.14.2.b` | the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability | action:`TRANSPARENCY.POLICY` | | `GDPR.13.2.c`, `GDPR.14.2.c` | where the processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal | action:`TRANSPARENCY.POLICY` | @@ -120,7 +120,7 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | `MODIFY` | `**TBD**` | `null` | `null` | `null` | `Selector.to-modify`,`data.rectified` | | `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | `DELETE` | `null` | `null` | `null` | `Reason of deletion` | `Data.identifier'=Information to delete* (can be one or several data capture, or limited to a field , Data cat., Process cat. , Purpose, URL, ...) | | `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `Data.identifier'=data cat.+purpose | -| `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `OTHER` | `null` | `null` | `null` | `null` | `null` | +| `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `OTHER-DATA` | `null` | `null` | `null` | `null` | `null` | | `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | `DELETE` | `**TBD**` | `null` | `null` | `Reason of deletion` | `Data.identifier`=URL | | `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/Demandr-le-retrait-de-votre-image-en-ligne) | `DELETE` | `IMAGE` | `null` | `null` | `Reason of deletion` | `Data.identifier`=data cat.+URL| | `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | `RESTRICT`, `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `target`= `ORGANISATION`, `PARTNERS`(propagation) | @@ -266,7 +266,7 @@ In the following examples we show how, requests introduced by different regulati | **user.derived.identifable** | **social** | Social activity and interaction data | `BEHAVIOR.RELATIONSHIPS` | `null` | `null` | Ok ? | | **user.derived.identifable** | **telemetry** | User identifiable measurement data from system sensors and monitoring | `BEHAVIOR.TELEMETRY` | `null` | `null` | `null` | | **user.derived.identifable** | **unique_id** | Unique identifier for a user assigned through system use | `UID` | `null` | `null` | `null` | -| **user.derived.identifable** | **user_sensor** | Measurement data derived about a user's environment through system use | `BEHAVIOR`,`OTHER` | `null` | `null` | Ok ? | +| **user.derived.identifable** | **user_sensor** | Measurement data derived about a user's environment through system use | `BEHAVIOR`,`COLLECTION` | `null` | `null` | | | **user.derived.identifable** | **workplace** | Organization of employment | `AFFILIATION.WORK` | `null` | `null` | `null` | | **user.derived.identifable** | **device** | Data related to a user's device, configuration and setting | `DEVICE` | `null` | `null` | `null` | | **user.derived.identifable** | **cookie_id** | Cookie unique identification number | `BEHAVIOR` | `null` | `null` | Need a more detailed cat ? | @@ -282,9 +282,9 @@ In the following examples we show how, requests introduced by different regulati | ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | | **user.provided** | **identifiable** | Data provided or created directly by a user that is linked to or identifies a user | `**TBD**` | `null` | `null` | TBD, isn't it all the data for us ? | | **user.provided.identifiable** | **identifiable** | Encoded characteristics provided by a user | `**TBD**` | `null` | `null` | `null` | -| **user.provided.identifiable** | **children** | Data relating to children | `OTHER`,`RELATIONSHIP` | `null` | `null` | Ok ? Need a more detailed cat ? | +| **user.provided.identifiable** | **children** | Data relating to children | - | `null` | `null` | @milstan: I don't think the fact someone is a child makes it a separate Data Category. The same person can turn 18 and no longer be a child - and data category can't change due to that. So this should be the responsibility of the System to use AGE to determine if special child-related policies must apply. | | **user.provided.identifiable** | **health_and_medical** | Health records or individual's personal medical information | `HEALTH` | `null` | `null` | `null` | -| **user.provided.identifiable** | **job_title** | Professional data | `OTHER` | `null` | `null` | Ok ? | +| **user.provided.identifiable** | **job_title** | Professional data | `CONTACT` | `null` | `null` | | | **user.provided.identifiable** | **name** | User's real name | `NAME` | `null` | `null` | `null` | | **user.provided.identifiable** | **non_specific_age** | Age range data | `DEMOGRAPHIC.AGE` | `null` | `null` | `null` | | **user.provided.identifiable** | **political_opinion** | Data related to the individual's political opinions | `DEMOGRAPHIC.BELIEFS` | `null` | `null` | `null` | @@ -303,16 +303,16 @@ In the following examples we show how, requests introduced by different regulati | **user.provided.identifiable** | **postal_code** | User's postal code | `CONTACT.ADDRESS` | `null` | `null` | `null` | | **user.provided.identifiable** | **state** | User's state level address data | `CONTACT.ADDRESS` | `null` | `null` | `null` | | **user.provided.identifiable** | **street** | User's street level address data | `CONTACT.ADDRESS` | `null` | `null` | `null` | -| **user.provided.identifiable** | **credentials** | User provided authentication data | `OTHER` | `null` | `null` | Ok ? | -| **user.provided.identifiable** | **biometric_credentials** | User provided authentication data | `OTHER`,`BIOMETRIC` | `null` | `null` | Ok ? | -| **user.provided.identifiable** | **password** | Password for system authentication | `OTHER` | `null` | `null` | Ok ? | +| **user.provided.identifiable** | **credentials** | User provided authentication data | `UID.USER-ACCOUNT` | `null` | `null` | | +| **user.provided.identifiable** | **biometric_credentials** | User provided authentication data | `UID.USER-ACCOUNT`,`BIOMETRIC` | `null` | `null` | | +| **user.provided.identifiable** | **password** | Password for system authentication | `UID.USER-ACCOUNT` | `null` | `null` | | | **user.provided.identifiable** | **financial** | Payment data and financial history | `FINANCIAL` | `null` | `null` | `Broader definition ?`| | **user.provided.identifiable** | **account_number** | User's account number for a payment card, bank account, or other financial system | `FINANCIAL.BANK-ACCOUNT` | `null` | `null` | `Ok ? Need a more detailed cat ?`| -| **user.provided.identifiable** | **government_id** | State provided identification data | `OTHER` | `null` | `null` | `Ok ?`| -| **user.provided.identifiable** | **drivers_license_number** | State issued driving identification number | `UID` | `null` | `null` | `Ok ?`| -| **user.provided.identifiable** | **national_identification_number** | State issued personal identification number | `UID` | `null` | `null` | `null`| -| **user.provided.identifiable** | **passport_number** | State issued passport data | `UID` | `null` | `null` | `null`| -| **user.provided** | **nonidentifiable** | Data provided or created directly by a user that is not identifiable | `**TBD**` | `null` | `null` | TBD: Do we need that ?| +| **user.provided.identifiable** | **government_id** | State provided identification data | `UID.ID` | `null` | `null` | | +| **user.provided.identifiable** | **drivers_license_number** | State issued driving identification number | `UID.ID` | `null` | `null` | `Ok ?`| +| **user.provided.identifiable** | **national_identification_number** | State issued personal identification number | `UID.ID` | `null` | `null` | `null`| +| **user.provided.identifiable** | **passport_number** | State issued passport data | `UID.ID` | `null` | `null` | `null`| +| **user.provided** | **nonidentifiable** | Data provided or created directly by a user that is not identifiable | `OTHER-DATA` | `null` | `null` | TBD: Do we need that ?| #### Transcend @@ -345,8 +345,8 @@ Transcend proposes the following [treatment types](https://github.com/transcend- | TRANSFER | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | processing-category:`COLLECTION`, provenance:`TRANSFERRED` | | SALE | For selling the data to third parties | processing-category:`**any/all**`, purpose:`SALE` | | HR | For personnel training, recruitment, payroll, management, etc. | processing-category:`**any/all**`, purpose:`EMPLOYMENT` | -| OTHER | Other specific purpose not covered above | processing-category:`**any/all**`, purpose:`OTHER` | -| UNSPECIFIED | The purpose is not explicitly stated or is unclear | processing-category:`**any/all**`, purpose:`OTHER` | +| OTHER | Other specific purpose not covered above | processing-category:`**any/all**`, purpose:`OTHER-PURPOSE` | +| UNSPECIFIED | The purpose is not explicitly stated or is unclear | processing-category:`**any/all**`, purpose:`OTHER-PURPOSE` | All of those SHOULD be modeled using our Treatment Types. @@ -365,9 +365,9 @@ Transcend proposes the following [data categories](https://github.com/transcend- | CONNECTION | Connection information for the current browsing session, e.g. device IDs, MAC addresses, IP addresses, etc. | data-category:`DEVICE`,`BEHAVIOR.CONNECTION` | | TRACKING | Cookies and tracking elements | data-category:`BEHAVIOR`, purpose:`TRACKING` | | DEVICE | Computer or device information | data-category:`DEVICE` | -| SURVEY | Any data that is collected through surveys | data-category:`OTHER` | -| OTHER | A specific type of information not covered by the above categories | data-category:`OTHER` | -| UNSPECIFIED | The type of information is not explicitly stated or unclear| data-category:`OTHER` | +| SURVEY | Any data that is collected through surveys | data-category:`OTHER-DATA` | +| OTHER | A specific type of information not covered by the above categories | data-category:`OTHER-DATA` | +| UNSPECIFIED | The type of information is not explicitly stated or unclear| data-category:`OTHER-DATA` | From a594b3f1fbc4cb776a86d6c430b21c18912a54e3 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 9 Jun 2022 20:25:29 +0200 Subject: [PATCH 144/204] UID.ID --- refs/notion-of-privacy/notion-of-privacy.md | 14 +++++++------- refs/schemas/priv/RFC-PRIV.md | 2 +- .../data-categories/en.data-categories.json | 1 + .../priv/json-schema/priv-terms.schema.json | 1 + 4 files changed, 10 insertions(+), 8 deletions(-) diff --git a/refs/notion-of-privacy/notion-of-privacy.md b/refs/notion-of-privacy/notion-of-privacy.md index 4219f2f7..62b65cf1 100644 --- a/refs/notion-of-privacy/notion-of-privacy.md +++ b/refs/notion-of-privacy/notion-of-privacy.md @@ -10,11 +10,11 @@ Among the many definitions proposed in scientific literature, we use the following one: -> « **Privacy is the selective control of access to the self** » — _Irwin Altman[^1]_ +> « **Privacy is the selective control of access to the self** » &msdash; _Irwin Altman[^1]_ -This definition captures the essential features of the concept, in particular the following. +This definition captures the essential features of the concept, in particular: -### Privacy is about the **self**. +- Privacy is about the **self**. The _self_ is a very important element of human experience playing _"an integral part in human motivation, cognition, affect, and social identity"_[^2]. @@ -29,11 +29,11 @@ Also, undoubtedly, in part _"the self emerges through interaction with others"_[ Due to the relational provenance of the knowledge of the self, privacy is one of the key features of the relationship of oneself with the surrounding world (other humans and artefacts) through which the knowledge of the self is formed. Privacy is a "factor of connection to oneself and to others"[^6]. -### Privacy is about **control of access**. +- Privacy is about **control of access**. As relationships play a key role in shaping the view on the self, it is of crucial importance for the individual to control the access to self, and thus maintain control over their own view of the self. -### Privacy is **selective**. +- Privacy is **selective**. It is not an absolute binary "come in" vs. "go away". It is a nuanced choice to control access to parts of the _self_. @@ -141,7 +141,7 @@ Repetetive exposure to technological limitations[^19], as well as the privacy pa The privacy paradox is a phenomenon in which online users state that they are concerned about their privacy but behave as if they were not.[^12] Anecdotal and empirical evidence indicates that individuals are willing to trade their personal information for relatively small rewards[^14]. -However, as we have seen, privacy regulates the conflict of the need for connection with the need for competition, survival and overcoming the power diferential. Habits, and other needs, indeniably play a role in the persons choice of privacy related behavior and may yield behavior inconsistent with the persons beliefs and interests (as outlined by the _privacy paradox_)[^18]. +However, as we have seen, privacy regulates the conflict of the need for connection with the need for competition, survival and overcoming the power diferential.Habits, and other needs, indeniably play a role in the persons choice of privacy related behavior and may yeald behavior inconsistent with the persons beliefs and interests (as outlined by the _privacy paradox_)[^18]. The existence of the privacy paradox is not indicative of a false concern for privacy, but rather of the context not favoring behavior aligned with this concern, as is common with attitude-behavior gap[^13]. Researchers consider privacy-oblivious behavior to be a result of technological limitations as much as a consequence of users' deficiencies[^19]. @@ -151,7 +151,7 @@ Researchers consider privacy-oblivious behavior to be a result of technological ### Internet Systems are Tools For Connection -The rise of Internet Systems and of the Web[^29] is inspired by the concept of Memex, proposed by Vannevar Bush in 1945 in his article *As We May Think*[^25]. Memex is imagined as a theoretical machine that humans can use to augment their cognitive powers. Memex can store information and provide access to it at later times. Also Memex is collaborative, as it can facilitate access to information provided by others - a *collective memory-extension tool*. +The rise of Internet Systems and of the Web[^29] is inspired by the concept of Memex, proposed by Vannevar Bush in 1945 in his article *As We May Think*[^25]. Memex is imagined as a tehorethical machine that humans can use to augment their cognitive powers. Memex can store information and provide access to it at later times. Also Memex is collaborative, as it can facilitate access to information provided by others - a *collective memory-extension tool*. Memex was the inspiration for: - NLS[^26], a system that used the early internet infrastructure to demonstrate the pioneering use of videoconferencing, collaborative document editing, hypermedia, document version control and many other concepts prevalent in modern Internet Systems. Developed in 1968, by Doug Engelbart, it was the first system to implement practical use of hypertext links[^27] for connecting information diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 07a18f10..b2c9a5b7 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -164,7 +164,7 @@ Privacy Scope = (Data Categories) x (Categories of Processing) x (Purposes of Pr | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-categories` | 0-* | `AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, UID.USER-ACCOUNT , UID.SOCIAL-MEDIA , `OTHER-DATA` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | +| `data-categories` | 0-* | `AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, `UID.ID`, UID.USER-ACCOUNT , UID.SOCIAL-MEDIA , `OTHER-DATA` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | When several values are given, Systems MUST interpret the `data-category` dimension as a union of all the categories indicated. diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index db8b80e3..c95e26d8 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -31,6 +31,7 @@ "PROFILING": "Any data establishing a degree of similarity of the person with others (e.g., clusters, user-profiles)", "RELATIONSHIPS": "Data about relationships of the person with others", "UID": "Any data allowing to uniquely identify a person", + "UID.ID": "Official identification number of proof of identity", "UID.USER-ACCOUNT": "Data about a person's account or profile on the first-party website/app and its contents", "UID.SOCIAL-MEDIA": "Data about a person's account or profile from a social media website/app or other third party service", "OTHER-DATA": "Other data" diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json index 5d091f89..ecfe2622 100644 --- a/refs/schemas/priv/json-schema/priv-terms.schema.json +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -68,6 +68,7 @@ "PROFILING", "RELATIONSHIPS", "UID", + "UID.ID", "UID.USER-ACCOUNT", "UID.SOCIAL-MEDIA", "OTHER-DATA", From 137732b2144b36d606ab272bdc2daac62150943e Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 9 Jun 2022 20:28:59 +0200 Subject: [PATCH 145/204] Update notion-of-privacy.md --- refs/notion-of-privacy/notion-of-privacy.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/refs/notion-of-privacy/notion-of-privacy.md b/refs/notion-of-privacy/notion-of-privacy.md index 62b65cf1..4219f2f7 100644 --- a/refs/notion-of-privacy/notion-of-privacy.md +++ b/refs/notion-of-privacy/notion-of-privacy.md @@ -10,11 +10,11 @@ Among the many definitions proposed in scientific literature, we use the following one: -> « **Privacy is the selective control of access to the self** » &msdash; _Irwin Altman[^1]_ +> « **Privacy is the selective control of access to the self** » — _Irwin Altman[^1]_ -This definition captures the essential features of the concept, in particular: +This definition captures the essential features of the concept, in particular the following. -- Privacy is about the **self**. +### Privacy is about the **self**. The _self_ is a very important element of human experience playing _"an integral part in human motivation, cognition, affect, and social identity"_[^2]. @@ -29,11 +29,11 @@ Also, undoubtedly, in part _"the self emerges through interaction with others"_[ Due to the relational provenance of the knowledge of the self, privacy is one of the key features of the relationship of oneself with the surrounding world (other humans and artefacts) through which the knowledge of the self is formed. Privacy is a "factor of connection to oneself and to others"[^6]. -- Privacy is about **control of access**. +### Privacy is about **control of access**. As relationships play a key role in shaping the view on the self, it is of crucial importance for the individual to control the access to self, and thus maintain control over their own view of the self. -- Privacy is **selective**. +### Privacy is **selective**. It is not an absolute binary "come in" vs. "go away". It is a nuanced choice to control access to parts of the _self_. @@ -141,7 +141,7 @@ Repetetive exposure to technological limitations[^19], as well as the privacy pa The privacy paradox is a phenomenon in which online users state that they are concerned about their privacy but behave as if they were not.[^12] Anecdotal and empirical evidence indicates that individuals are willing to trade their personal information for relatively small rewards[^14]. -However, as we have seen, privacy regulates the conflict of the need for connection with the need for competition, survival and overcoming the power diferential.Habits, and other needs, indeniably play a role in the persons choice of privacy related behavior and may yeald behavior inconsistent with the persons beliefs and interests (as outlined by the _privacy paradox_)[^18]. +However, as we have seen, privacy regulates the conflict of the need for connection with the need for competition, survival and overcoming the power diferential. Habits, and other needs, indeniably play a role in the persons choice of privacy related behavior and may yield behavior inconsistent with the persons beliefs and interests (as outlined by the _privacy paradox_)[^18]. The existence of the privacy paradox is not indicative of a false concern for privacy, but rather of the context not favoring behavior aligned with this concern, as is common with attitude-behavior gap[^13]. Researchers consider privacy-oblivious behavior to be a result of technological limitations as much as a consequence of users' deficiencies[^19]. @@ -151,7 +151,7 @@ Researchers consider privacy-oblivious behavior to be a result of technological ### Internet Systems are Tools For Connection -The rise of Internet Systems and of the Web[^29] is inspired by the concept of Memex, proposed by Vannevar Bush in 1945 in his article *As We May Think*[^25]. Memex is imagined as a tehorethical machine that humans can use to augment their cognitive powers. Memex can store information and provide access to it at later times. Also Memex is collaborative, as it can facilitate access to information provided by others - a *collective memory-extension tool*. +The rise of Internet Systems and of the Web[^29] is inspired by the concept of Memex, proposed by Vannevar Bush in 1945 in his article *As We May Think*[^25]. Memex is imagined as a theoretical machine that humans can use to augment their cognitive powers. Memex can store information and provide access to it at later times. Also Memex is collaborative, as it can facilitate access to information provided by others - a *collective memory-extension tool*. Memex was the inspiration for: - NLS[^26], a system that used the early internet infrastructure to demonstrate the pioneering use of videoconferencing, collaborative document editing, hypermedia, document version control and many other concepts prevalent in modern Internet Systems. Developed in 1968, by Doug Engelbart, it was the first system to implement practical use of hypertext links[^27] for connecting information From 62276f70d122ce1928d38fe8ff358326aca05ba5 Mon Sep 17 00:00:00 2001 From: milstan Date: Fri, 10 Jun 2022 01:06:24 +0200 Subject: [PATCH 146/204] turning legacy names to new ones --- refs/schemas/priv/RFC-PRIV.md | 30 ++++++++++++++++++++------ refs/schemas/priv/expected-behavior.md | 2 +- 2 files changed, 25 insertions(+), 7 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index b2c9a5b7..603cae42 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -459,17 +459,34 @@ When Systems do know that one Data Subject Identity corresponds to the same user Systems SHOULD NOT imply Data Subject Identity equivalence from Privacy Requests, especially when granting Privacy Requests that require authentication. -### Data Capture IDs, Data Capture Fragment IDs, Consent IDs, Privacy Request IDs, Demand IDs, Privacy Request Response IDs are Globally Unique +### IDs are Globally Unique -All of the following identifiers `data-capture-id`, `fragment-id`, `consent-id`, `rights-request-id`, `demand-id`, `rights-response-id` MUST be globally unique and be generated according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) in order for the corresponding objects to be easily identifiable across systems. +All of the following identifiers `capture-id`, `fragment-id`, `consent-id`, `request-id`, `demand-id`, `response-id` MUST be globally unique and be generated according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html) in order for the corresponding objects to be easily identifiable across systems. The reason for using UUDIs is to allow Systems to independently generate globally unique identifiers while being autonomous from a central entity that would ensure identifier uniqueness. Having a public ledger for UUDIs MAY be considered for Consents and Data Captures, but serious implications to Data Subject exposure MUST also be considered. However, the design MUST be compatible with building a public decentralised ledger. -### Data Categories, Treatment Types, Actions, and Purposes SHOULD be Unambiguous and Complete +### Term Syntax -The lists of Data Categories, Treatment Types, Actions, and Purposes SHOULD be designed in such a way to be: +The vocabulary defines TERMS to express different aspects of Pravacy Reqeust, Data Captures, Consents etc. + +TERMS follow Term Dot Notation (TDN), defined using the following ABNF (cf. [FRC5234](https://www.rfc-editor.org/info/rfc5234)): +``` +term = category *subcategory + +subcategory = "." category + +category = *(%x41–5A) *((%x2D) 1*(%x41–5A)) + +``` +A category is equivalent to the union of all of its subcategories. +Terms can be specified at different levels of granularity. +E.g. the following statements are equivalent: +- `A.B`, `A` +- `A` + +The lists of TERMS SHOULD be designed in such a way to be: - **Unambiguous** : The developer using the schema knows without ambiguity which one (of which ones) to use in any given situation, AND - **Complete** : They allow to express the totality of possible needs in the context of a user wanting to [regulate their privacy/connectedness](https://github.com/blindnet-io/product-management/blob/dogma/refs/notion-of-privacy/notion-of-privacy.md), as well as the totality of requests defined by the [supported legilsation](#supported-legilsation). @@ -583,7 +600,6 @@ Systems SHOULD keep a log of received [Privacy Requests](#privacy-request), gene - ## Questions and Discussion Topics ### Use UUID for identifying Data Subjects @@ -600,7 +616,7 @@ Should we include restrictions in the schema according to the [JSON-schema-valid In the current proposal, this is the case for target, but not for request types, data categories, and user identity schemas. We might want to include more forma constraints there, or deliberately leave flexibility. This is a discussion we need to have. -### Dot-notation for category hierarchies +### Dot-notation for TERMS Hierarchies of categories are represented using the "supercategory.subcategory" notation. The idea behind this is to allow developers to use the level of granularity that is adapted to them, yet be able to easily situate the subcategory in supercategory when dealing with more generic requests. @@ -721,6 +737,8 @@ This document comes with the following support documents: - **[RFC8259]** Bray, T., ["The JavaScript Object Notation (JSON) Data Interchange Format"](https://datatracker.ietf.org/doc/html/rfc8259), STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. - **[RFC2119]** Bradner, S., ["Key words for use in RFCs to Indicate Requirement Levels"](https://datatracker.ietf.org/doc/html/rfc2119), BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, +- **[RFC5234]** Crocker, D., Ed. and P. Overell, ["Augmented BNF for Syntax Specifications: ABNF"](https://www.rfc-editor.org/info/rfc5234), STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, + ### Initiative with which PRIV seeks to be compatible diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index b955cc1b..3b44ff8e 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -512,7 +512,7 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - if the set of Data Capture Fragments recommended for deletion is *the same as* the **Concerned Fragments** set, recommend status = `ACCEPT`, - else, if the set of Data Capture Fragments recommended for deletion is *included in* the **Concerned Fragments** set, recommend status = `PARTIALLY-GRANTED`, - else, recommend status = `DENIED`, - - when status is one of {`PARTIALLY-GRANTED`, `DENIED`} add one or more motives = `LEGAL-BASES` or `LEGAL-OBLIGATIONS` when **Concerned Fragments** that are not recommended for deletion, have in their `scope` Privacy Scope Triples included in the Eligible Privacy Scope under `CONTRACT` or `NECESSARY` Legal Bases, respectively. + - when status is one of {`PARTIALLY-GRANTED`, `DENIED`} add one or more motives = `VALID-REASONS` or `IMPOSSIBLE` when **Concerned Fragments** that are not recommended for deletion, have in their `scope` Privacy Scope Triples included in the Eligible Privacy Scope under `CONTRACT` or `NECESSARY` Legal Bases, respectively. - `MODIFY` Demands: - If restricted to a Privacy Scope Restriction having a `processing-category` or a `purpose`, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` (A Delete request can only be relative to a category of data, not to a category of processing or a particular purpose.) From 256efd4dd7ba874b58ba364a83f2b6697a7c7d78 Mon Sep 17 00:00:00 2001 From: milstan Date: Fri, 10 Jun 2022 13:13:13 +0200 Subject: [PATCH 147/204] Adding Sequence Diagrams --- refs/schemas/priv/RFC-PRIV.md | 2 +- refs/schemas/priv/expected-behavior.md | 11 +- refs/schemas/priv/scenarios.md | 348 +++++++++++++++++++++++++ 3 files changed, 358 insertions(+), 3 deletions(-) create mode 100644 refs/schemas/priv/scenarios.md diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 603cae42..1aa51a3d 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -357,7 +357,7 @@ A Data Capture concerns one and only one Data Subject who MAY be identified by m | `data` | 0-* | Optionally concrete data (Format **TBD**) | | `legal-base` | 0-* | Optionally an array of values among `CONTRACT`, `CONSENT`, `LEGITIMATE-INTEREST`, `NECESSARY`, `OTHER-LEGAL-BASE` | -`selector`s MUST include the data category of the data. For example selectors 'CONTACT.ADDRESS.SHIPPING' and 'CONTACT.ADDRESS.BILLING' indicate that the data being captured by a particular fragment belong to the `CONTACT.ADDRESS` data category. +`selector`s MUST include the data category of the data. For example selectors 'CONTACT.ADDRESS.SHIPPING' and 'CONTACT.ADDRESS.BILLING' indicate that the data being captured by a particular fragment belonging to the `CONTACT.ADDRESS` data category. While the Data Categories are global, the selectors are defined by the Systems. A `selector` uniquely identifies a particular data field that the Systems works with. When several Systems exchange data among them, they SHOULD align on using the same `selectors` in the same way, in order to be able to correctly interoperate. diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 3b44ff8e..de47dd20 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -33,10 +33,15 @@ The purpose of the document is primarily illustrate a possible behaviour Systems Privacy Requests can be resolved more or less automatically. Privacy Requests that are expressed in unambiguous terms, may be fully processed automatically. -Those that include the term "OTHER" or a textual message with more details about the request likely require human intervention. +Those that include the keyword "OTHER" or a textual message with more details about the request likely require human intervention. +Cf. [different automation scenarios](./scenarios.md#automation) Systems MAY be configured to treat Privacy Requests eligible for automation with or without human validation. In any case, the role of the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) is to calculate the appropriate action, given particular Privacy Request in a particular situation. +Systems MAY also want to direct certain requests (such as `MODIFY`) to dedicated interfaces that they may already have for Data Subjects to provide and modify their data. + +Because of this Systems MUST be able to configure their particular ways of automating the processing of Privacy Requests. + ## Configuration and Prerequisites A [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) serving a particular System MUST have the knowledge of the following key parameters and data structures: @@ -427,7 +432,9 @@ For example, the System can inquire whether a particular data fragment, correspo ## Resolving requests -The [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) evaluates Privacy Request Demands and issues recommendations to the System. The Systems can then be configured to respond to Privacy Requests automatically, blindly following those recommendations (whenever possible), or to await human input just in case. +The [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) evaluates Privacy Request Demands and issues recommendations to the System. The Systems can then be configured to respond to Privacy Requests automatically, blindly following those recommendations (whenever possible), or to await human input just in case. Cf. [different automation scenarios](./scenarios.md#automation) + +Privacy Requests MAY need to be processed in the context of different [authentication scenarios](./scenarios.md#authentication) and different [response scenarios](./scenarios.md#response). Here is how the Privacy Request Response recommendations are calculated: diff --git a/refs/schemas/priv/scenarios.md b/refs/schemas/priv/scenarios.md new file mode 100644 index 00000000..14fd27a7 --- /dev/null +++ b/refs/schemas/priv/scenarios.md @@ -0,0 +1,348 @@ +# Privacy Request Interchange Vocabulary : Scenarios of Use + +| Status | draft | +| :------------ | :------------------------------------------------------------------------------------- | +| **Author(s)** | milstan (milstan@blindnet.io) | +| **Updated** | 2022-06-10 | + +## Introduction + +This document illustrates different scenarios in which [Privacy Request Interchange Vocabulary](./RFC-PRIV.md) MAY be used. + +The goal of this document is to explore the design implications for implementing systems, that might arise from different situations. + +## Terminology + + +- We use all the terms of the [Privacy Request Interchange Vocabulary](./RFC-PRIV.md) as defined there +- We use the term Privacy Request interchangeably with the (deprecated) terms Rights Request and Data Rights Request as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) +- We use the terms Individual, Person, You, and Data Subject as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) +- We use the term System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) +- We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) +- We use the terms Organization, Submitter, Data Consumer as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) as defined there. + + +## Authentication +### Anonymous + +Systems MAY process certain requests without asking the user for their identity. This is especially the case with some of the `TRANSPARENCY` requests, in response to which general information is given. + +```mermaid +sequenceDiagram + actor subject as Data Subject + participant system as System + participant compiler as Privacy Compiler + subject->>system: Privacy Request TRANSPARENCY.WHERE + system->>compiler: Privacy Request + compiler->>system: recommend GRANTED + note right of compiler: data: "France" + system->>subject: Privacy Request GRANTED + note left of system: Our servers are in France +``` + +In certain cases, such as with GDPR ([articles 13 and 14](./examples.md#articles-13-and-14)), Systems MAY find themselves in obligation to provide information prior to capturing any data. However, in such cases, Systems are expected to [respond differently to the same requests](./expected-behavior.md#resolving-requests), with regards to the Data Subject being authenticated or not. For example a `TRANSPARENCY.DATA-CATEGORIES` request for an anonymous Data Subject MAY trigger a response listing all the possible data categories that the System is configured to collect. The same request for the authenticated Data Subject MAY trigger a response listing only the categories of data that the System has on this particular Data Subject. + +### A Priori Authentication + +The Data Subject formulates a Privacy Request when their identity is already confirmed. + +```mermaid +sequenceDiagram + actor subject as Data Subject + participant system as System + participant compiler as Privacy Compiler + subject->>system: authenticates + subject->>system: Privacy Request DELETE CONTACT.PHONE + system->>compiler: Privacy Request + compiler->>system: recommend GRANTED + system->>subject: Privacy Request GRANTED + note left of system: Phone number deleted +``` + + +### A Posteriori Authentication + +The Data Subject formulates a Privacy Request before their identity is confirmed. + +```mermaid +sequenceDiagram + actor subject as Data Subject + participant system as System + participant compiler as Privacy Compiler + subject->>system: Privacy Request DELETE CONTACT.PHONE + system->>subject: please authenticate + note left of system: We must verify your identity in order to process this kind of request + subject->>system: authenticates + system->>compiler: Privacy Request + compiler->>system: recommend GRANTED + system->>subject: Privacy Request GRANTED + note left of system: Phone number deleted +``` + +### Signle Point Authentication for Corresponding Systems + +In a context of multiple corresponding Systems, only one System confirms the identity of the user, and other Systems only process the Privacy Request. + +```mermaid +sequenceDiagram + actor subject as Data Subject + participant systemA as System A + participant compilerA as Privacy Compiler A + participant systemB as System B + participant compilerB as Privacy Compiler B + + alt a priori authentication + subject->>systemA: authenticates + subject->>systemA: Privacy Request DELETE CONTACT.EMAIL target:PARTNERS + + else a posteriori authentication + subject->>systemA: Privacy Request DELETE CONTACT.EMAIL target:PARTNERS + systemA->>subject: please authenticate + subject->>systemA: authenticates + end + + systemA->>compilerA: Privacy Request + + systemA->>systemB: Privacy Request + systemA->>systemB: Data Subject Identity Confirmed + systemB->>compilerB: Privacy Request + + compilerA->>systemA: recommend GRANTED + compilerB->>systemB: recommend GRANTED + + alt coordinated response + systemB->>systemA: Privacy Request GRANTED + systemA->>subject: Privacy Request GRANTED + + else direct response + systemA->>subject: Privacy Request GRANTED + systemB->>subject: Privacy Request GRANTED + end + + note left of systemA: E-mail deleted +``` + +### Independent Authentication for Corresponding Systems + +In a context of multiple corresponding Systems, every System confirms the identity of the Data Subject in their own way. + +```mermaid +sequenceDiagram + actor subject as Data Subject + participant systemA as System A + participant compilerA as Privacy Compiler A + participant systemB as System B + participant compilerB as Privacy Compiler B + + alt a priori authentication + subject->>systemA: authenticates + subject->>systemA: Privacy Request DELETE CONTACT.EMAIL target:PARTNERS + + else a posteriori authentication + subject->>systemA: Privacy Request DELETE CONTACT.EMAIL target:PARTNERS + systemA->>subject: please authenticate + subject->>systemA: authenticates + end + + systemA->>compilerA: Privacy Request + + systemA->>systemB: Privacy Request + systemB->>subject: please authenticate + subject->>systemB: authenticates + systemB->>compilerB: Privacy Request + + compilerA->>systemA: recommend GRANTED + compilerB->>systemB: recommend GRANTED + + alt coordinated response + systemB->>systemA: Privacy Request GRANTED + systemA->>subject: Privacy Request GRANTED + + else direct response + systemA->>subject: Privacy Request GRANTED + systemB->>subject: Privacy Request GRANTED + end + + note left of systemA: E-mail deleted +``` + +## Automation + +### Automatic Processing + +Systems MAY be configured to process certain Privacy Requests automatically. + +```mermaid +sequenceDiagram + actor subject as Data Subject + participant system as System + participant compiler as Privacy Compiler + actor DPO + + note left of subject: New e-mail example@gmail.com + + alt a priori authentication + subject->>system: authenticates + subject->>system: Privacy Request MODIFY CONTACT.EMAIL + + else a posteriori authentication + subject->>system: Privacy Request MODIFY CONTACT.EMAIL + system->>subject: please authenticate + subject->>system: authenticates + + end + + system->>compiler: Privacy Request + compiler->>system: recommend GRANTED + system->>subject: Privacy Request GRANTED + note left of system: E-mail modified + + system->>DPO: Privacy Request GRANTED + +``` + +### Semi-Automatic Processing + +Systems MAY be configured to process certain Privacy Requests with human validation. + +```mermaid +sequenceDiagram + actor subject as Data Subject + participant system as System + participant compiler as Privacy Compiler + actor DPO + + note left of subject: New e-mail example@gmail.com + + alt a priori authentication + subject->>system: authenticates + subject->>system: Privacy Request MODIFY CONTACT.EMAIL + + else a posteriori authentication + subject->>system: Privacy Request MODIFY CONTACT.EMAIL + system->>subject: please authenticate + subject->>system: authenticates + + end + + system->>subject: Privacy Request UNDER-REVIEW + + system->>compiler: Privacy Request + compiler->>system: recommend GRANTED + + system->>DPO: Privacy Request, recommend GRANTED + + DPO->>system: Privacy Request DENIED + note right of DPO: We require a professional e-mail address + + system->>subject: Privacy Request DENIED + +``` + +### Manual Processing + +Certain Privacy Request can't be interpreted automatically and MUST be processed by a human. + +```mermaid +sequenceDiagram + actor subject as Data Subject + participant system as System + participant compiler as Privacy Compiler + actor DPO + + note left of subject: How much CO2 is spent on processing my data + + alt a priori authentication + subject->>system: authenticates + subject->>system: Privacy Request OTHER-DEMAND + + else a posteriori authentication + subject->>system: Privacy Request OTHER-DEMAND + system->>subject: please authenticate + subject->>system: authenticates + + end + + system->>subject: Privacy Request UNDER-REVIEW + + system->>DPO: Privacy Request + + DPO->>system: Privacy Request GRANTED + note right of DPO: 30g + + system->>subject: Privacy Request GRANTED, msg=30g + +``` +## Response + +## Coordinated Response + +When a Privacy Requests concerns corresponding Systems, they MAY be configured to respond to it in a coordinated way. The System having received the Privacy Requests gathers responses from corresponding Systems, and creates one single response to present to the user. + +```mermaid +sequenceDiagram + actor subject as Data Subject + participant systemA as System A + participant compilerA as Privacy Compiler A + participant systemB as System B + participant compilerB as Privacy Compiler B + + + subject->>systemA: Privacy Request TRANSPARENCY.WHERE + + systemA->>compilerA: Privacy Request + + systemA->>systemB: Privacy Request + systemB->>compilerB: Privacy Request + + compilerA->>systemA: recommend GRANTED, France + compilerB->>systemB: recommend GRANTED, USA + + systemB->>systemA: Privacy Request GRANTED, USA + systemA->>subject: Privacy Request GRANTED, France and USA + +``` +## Direct Response + +When a Privacy Requests concerns corresponding Systems, they MAY be configured to have each System reply to the Data Subject independently. + +```mermaid +sequenceDiagram + actor subject as Data Subject + participant systemA as System A + participant compilerA as Privacy Compiler A + participant systemB as System B + participant compilerB as Privacy Compiler B + + + subject->>systemA: Privacy Request TRANSPARENCY.WHERE, target:PARTNERS + + systemA->>systemB: Privacy Request + + systemA->>compilerA: Privacy Request + compilerA->>systemA: recommend GRANTED, France + systemA->>subject: Privacy Request GRANTED, France + + + systemB->>compilerB: Privacy Request + compilerB->>systemB: recommend GRANTED, USA + systemB->>subject: Privacy Request GRANTED, USA + +``` + +## References + +### Normative References + +- **[RFC8259]** Bray, T., ["The JavaScript Object Notation (JSON) Data Interchange Format"](https://datatracker.ietf.org/doc/html/rfc8259), STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. + + +### Supported Legislation + +- [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) +- [CCPA](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5) + +### Yet to be Supported Legilsation + +- CPRA +- HIPPA From 449bf1eb1821d07f5377067e45713f254035d077 Mon Sep 17 00:00:00 2001 From: milstan Date: Fri, 10 Jun 2022 15:33:08 +0200 Subject: [PATCH 148/204] adding a complex Data Capture Scenario --- refs/schemas/priv/RFC-PRIV.md | 7 ++-- refs/schemas/priv/scenarios.md | 71 ++++++++++++++++++++++++++++++++++ 2 files changed, 75 insertions(+), 3 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 1aa51a3d..f4d0baf2 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -16,7 +16,7 @@ The vocabulary introduces a finite set of `concepts`, `properties` and `terms`. This vocabulary corresponds to the [Schemas](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#schemas) component of the [High-Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). -Two additional documents: [Examples of use](./examples.md) and [Expected Behavior of Implementing Systems](./expected-behavior.md), complement this document. +Additional documents: [Examples of use](./examples.md), [Scenarios](./scenarios.md) and [Expected Behavior of Implementing Systems](./expected-behavior.md), complement this document. ## Motivation @@ -285,7 +285,7 @@ Convenient tables of `target` values and corresponding user-facing descriptions, ### Privacy Request Response Systems SHOULD respond to [Privacy Requests](#privacy-request). -Regardless of the [scenario (Responding to the Data Subject directly or to the System)](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#different-rights-request-response-scenrarios) that should be defined by a protocol (**TO BE WRITTEN** - the System SHOULD know when to wait for a response from another system), Systems SHOULD generate a response using the Privacy Request Interchange Vocabulary. +Regardless of the [scenario (Responding to the Data Subject directly or to the System)](./scenarios.md#response) Systems SHOULD generate a response using the Privacy Request Interchange Vocabulary. | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | @@ -309,7 +309,7 @@ A Privacy Request Response MUST have: - a date, - a status. -Privacy Request Responses can be nested. One can imagine a Privacy Request Response to a particular Privacy Request, that `includes` Privacy Request Responses to the particular Demands made in that Privacy Request. Several Systems MAY respond to the same Privacy Request or Demand, and one System MAY nest them in order to gather them and send them back to the Data Subject. +Privacy Request Responses can be nested. One can imagine a Privacy Request Response to a particular Privacy Request, that `includes` Privacy Request Responses to the particular Demands made in that Privacy Request. Several Systems MAY respond to the same Privacy Request or Demand, and one System MAY nest them in order to gather them and send them back to the Data Subject (in the [Coordinated Response secenario](./scenarios.md#coordinated-response)). When a Demand is being denied, the Privacy Request Response MUST provide a `motive`. @@ -730,6 +730,7 @@ However, we might want to allow developers to use our format (properties and con This document comes with the following support documents: - [Examples of use](./examples.md) - [Expected Behavior of Implementing Systems](./expected-behavior.md) +- [Scenarios](./scenarios.md) ## References diff --git a/refs/schemas/priv/scenarios.md b/refs/schemas/priv/scenarios.md index 14fd27a7..11dda5a8 100644 --- a/refs/schemas/priv/scenarios.md +++ b/refs/schemas/priv/scenarios.md @@ -330,6 +330,77 @@ sequenceDiagram ``` +## Capture + +## A Complex Journey of a Data Capture + +A Data Capture MAY end up being shared among several Systems. We illustrate this on an example. System A and System B are a part of the same Organisation, while System C is a part of a Partner Organisation. + +This complex scenario may take place under different [authentication](#authentication), [automation](#automation), and [response](#response) scenarios. For the sake of clarity of the diagram, we don't include all the possible options. We also abstract Privacy Compilers and interactions with them, as well as Data Consumers and DPOs. + +```mermaid +sequenceDiagram + actor subject as Data Subject + participant systemA as System A + participant systemB as System B + participant systemC as System C + + subject->>systemA: name, e-mail + subject->>systemA: phone number + + systemA->>systemA: Data Capture CONTACT, provenance:USER + + systemA->>systemA: Data Capture DEVICE (iPhone 13), provenance:DERIVED + + subject->>systemA: consent1 purpose: ADVERTISING, PERSONALISATION, target: ORGANISATION + subject->>systemA: consent2 purpose: ADVERTISING, PERSONALISATION, target: PARTNERS + + systemA->>systemB: Data Capture, Consent + systemB->>systemC: Data Capture, Consent + + systemC->>subject: Advertising e-mail + + subject->>systemB: Privacy Request REVOKE-CONSENT consent2 target: PARTNERS.DOWNWARD + systemB->>systemC: Privacy Request REVOKE-CONSENT consent2 + + systemC->>systemB: Privacy Request GRANTED + systemC->>systemC: Delete Data Subject's data, Delete consent2 + + systemB->>subject: Privacy Request GRANTED + + systemA->>subject: Advertising e-mail + + subject->>systemA: Privacy Request OBJECT purpose:ADVERTISING, target: ORGANISATION + systemA->>systemB: Privacy Request OBJECT purpose:ADVERTISING + + systemA->>systemA: consent1->consent1.1 purpose: PERSONALISATION, target: ORGANISATION + systemB->>systemB: consent1->consent1.1 purpose: PERSONALISATION, target: ORGANISATION + + systemB->>systemA: Privacy Request GRANTED + systemA->>subject: Privacy Request GRANTED + + subject->>systemA: Privacy Request ACCESS provenance:TRANSFERRED,DERIVED target: ORGANISATION + + systemA->>subject: Privacy Request GRANTED + note left of systemA: DEVICE (iPhone 13) + + systemB->>subject: Privacy Request GRANTED + note left of systemB: CONTACT (name, e-mail, phone) DEVICE (iPhone 13) + + subject->>systemA: Privacy Request RESTRICT provenance:USER target: ORGANISATION + systemA->>systemB: Privacy Request RESTRICT provenance:USER target: ORGANISATION + + systemA->>systemA: Delete DEVICE (iPhone 13) + systemB->>systemB: Delete DEVICE (iPhone 13) + systemB->>systemA: Privacy Request PARTIALLY-GRANTED + note right of systemB: VALID-REASONS not to delete CONTACT (name, e-mail, phone) + + systemA->>subject: Privacy Request PARTIALLY-GRANTED + note right of systemA: DEVICE (iPhone 13) deleted from all Systems. Contact data kept. + +``` + + ## References ### Normative References From cc8320f84482c0760d5a0d195d5146cd8659238a Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Fri, 10 Jun 2022 15:35:32 +0200 Subject: [PATCH 149/204] Updated format CNIL REQ TEMPLATE + DAILY LIFE E.G. --- refs/schemas/priv/examples.md | 78 +++++++++++++++++------------------ 1 file changed, 38 insertions(+), 40 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index d2b0b638..cda4479d 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -105,29 +105,29 @@ In the following examples we show how, requests introduced by different regulati ### GDPR REQUEST TEMPLATES FROM CNIL -| LAW | Demand | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | `Other properties` | -| -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | -| `GDPR.15` | [Acces](https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces) | `ACCESS` | `null` | `null` | `null` | `null` | | -| `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | `ACCESS` | `IMAGE` | `null` | `SECURITY` | ~~video surveillance data from 01 Feb 2021 to 03 Feb 2021~~ | `from-to` | -| `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | `ACCESS` | `HEALTH` | `null` | `null` | `null` | | -| `GDPR.15` | [Access to data "Preventel" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel) | `ACCESS` | `null` | `null` | `null` | `null` | | -| `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier): Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me | `ACCESS`, `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `null` | -| `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | `ACCESS` | `null` | `null` | `null` | `null` | `null` | -| `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | `ACCESS` | `null` | `null` | `null` | `null` | `null` | -| `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | `ACCESS` | `null` | `null` | `null` | `null` | `from-to` | -| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-Demand-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| `ACCESS`,`PORTABILITY`| `null` | `null` | `null` | `null` | `null` | -| `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| `MODIFY` | `**TBD**` | `null` | `null` | `null` | `Selector.to-modify`,`data.rectified` | -| `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | `MODIFY` | `**TBD**` | `null` | `null` | `null` | `Selector.to-modify`,`data.rectified` | -| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | `DELETE` | `null` | `null` | `null` | `Reason of deletion` | `Data.identifier'=Information to delete* (can be one or several data capture, or limited to a field , Data cat., Process cat. , Purpose, URL, ...) | -| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `Data.identifier'=data cat.+purpose | -| `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `OTHER-DATA` | `null` | `null` | `null` | `null` | `null` | -| `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | `DELETE` | `**TBD**` | `null` | `null` | `Reason of deletion` | `Data.identifier`=URL | -| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/Demandr-le-retrait-de-votre-image-en-ligne) | `DELETE` | `IMAGE` | `null` | `null` | `Reason of deletion` | `Data.identifier`=data cat.+URL| -| `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | `RESTRICT`, `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `target`= `ORGANISATION`, `PARTNERS`(propagation) | -| `GDPR.21.1`,`GDPR.17.1.c`,,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | `RESTRICT`,`DELETE` | `null` | `null` | `null` | `Reason of deletion` | `Data.identifier`=all,`target`= `ORGANISATION`+`PARTNERS`(propagation) | -| `GDPR.21`, GDPR.18.1 | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | `RESTRICT` | `**choice?**` | `**choice?**` | `**choice?**` | `null` | `null` | -| `GDRP.4`,`GDRP.6`,`GDRP.7`, `GDPR.13.2.c`| [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | `REVOKE-CONSENT` | `null` | `**choice?**` | `**choice?**` | `null` | `null` | -| `GDPR.13.2.a`, `GDPR.14.2.a` | [For how long the data organization has on me will be kept](https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees) | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | `null` | `null` | +| LAW | Demand | Representation | +| -------- | -------------------------------------- | ------------ | +| `GDPR.15` | [Acces](https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces) | action:`ACCESS` | +| `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | action:`ACCESS`, data-category:`IMAGE`, purpose:`SECURITY`, other-property:`from-to` | +| `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | action:`ACCESS`, data-category:`HEALTH` | +| `GDPR.15` | [Access to data "Preventel" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel) | action:`ACCESS` | +| `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier): Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me | action:`ACCESS`,`TRANSPARENCY.PROVENANCE` | +| `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | action:`ACCESS` | +| `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | action:`ACCESS` | +| `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | action:`ACCESS`, other-property:`from-to` | +| `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-Demand-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| action:`ACCESS`,`PORTABILITY` | +| `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| action:`MODIFY`, other-property:`Selector.to-modify`,`data.rectified` | +| `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | action:`MODIFY`, other-property:`Selector.to-modify`,`data.rectified` | +| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | action:`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier'=Information to delete* (can be one or several data capture, or limited to a field , Data cat., Process cat. , Purpose, URL, ...) | +| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | action:`DELETE`, data-category:`CONTACT`, purpose:`MARKETING` | +| `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | action:`OTHER-DATA` | +| `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | action:`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`=data + URL | +| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/Demandr-le-retrait-de-votre-image-en-ligne) | action: `DELETE`, data-category:`IMAGE`, message:`Reason of deletion`, other-property:`Data.identifier`=data + URL | +| `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | action:`RESTRICT`,`DELETE`, data-category:`CONTACT`, purpose:`MARKETING`, target: `ORGANISATION`,`PARTNERS`(propagation) | +| `GDPR.21.1`,`GDPR.17.1.c`,,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | action:`RESTRICT`,`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`,`target`= `ORGANISATION`,`PARTNERS`(propagation) | +| `GDPR.21`, GDPR.18.1 | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | action:`RESTRICT`, processing-category:**any/all** | +| `GDRP.4`,`GDRP.6`,`GDRP.7`, `GDPR.13.2.c`| [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | `REVOKE-CONSENT`, processing-category:**any/all** | +| `GDPR.13.2.a`, `GDPR.14.2.a` | [For how long the data organization has on me will be kept](https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees) | action:`TRANSPARENCY.RETENTION` | >**Note** > @@ -135,23 +135,21 @@ In the following examples we show how, requests introduced by different regulati ### OTHER EXAMPLES FROM DAILY LIFE -*Change my address* - -| LAW | Demand (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Other properties | -| -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | -| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | `MODIFY` | `CONTACT.ADDRESS` | `null` | `null` | `null` | `null` | -| `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | `DELETE` | `CONTACT` | `null` | `MARKETING` | `null` | `null` | -| `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | `RESTRICT` | `null` | `AUTOMATED-DECISION-MAKING` | `null` | `null` | `null` | -| `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `null` | -| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | `RESTRICT` | `BEHAVIOR,`DEVICE`,`LOCATION` | `COLLECTION` | `TRACKING` | `null` | `null` | -| `GDPR.13.1.f`, `GDPR.14.1.f` | Storage information : know where is stored the data organization has on me | `TRANSPARENCY.WHERE` | `null` | `null` | `null` | `null` | `null` | -| `GDPR.14.1.e` | Accessibility information : know who can access the data organization has on me | `TRANSPARENCY.WHO` | `null` | `null` | `null` | `null` | `null` | -| `GDPR.14.2.f` | Provenance information : know the provenance of data organization has on me | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `null` | -| `GDPR.13.2.a`, `GDPR.14.2.a` | Know when my data will be deleted | `TRANSPARENCY.RETENTION` | `null` | `null` | `null` | `null` | `ID` | -| `**GDPR.13?**` | Know what is the policy of the organization to keep data it has on me | `TRANSPARENCY.POLICY` | `null` | `null` | `null` | `null` | `null` | -| `GDPR.15.1.a` | Know the purpose of the processing organization does on the data it has on me | `TRANSPARENCY.PURPOSE` | | `null` | `null` | `null` | `null` | -| `GDPR.12.1` | Know what type(s) of treatment organization does on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `null` | `null` | `null` | `null` | -| `GDPR.12.1` | Know if a particular type of treatment is done by organisation on the data it has on me | `TRANSPARENCY.PROCESSING-CATEGORIES` | `null` | `**choice?**` | `null` | `null` | `null` | +| LAW | Demand | Representation | +| -------- | -------------------------------------- | ------------ | +| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | action:`MODIFY`, data-category:`CONTACT.ADDRESS` | +| `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | action:`DELETE`, data-category:`CONTACT`, purpose:`MARKETING` | +| `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | action:`RESTRICT`, processing-category:`AUTOMATED-DECISION-MAKING` | +| `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | action:`RESTRICT`, processing-category:`SHARING`, purpose`SALE` | +| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | action:`RESTRICT`, data-category:`BEHAVIOR,`DEVICE`,`LOCATION`, processing-category:`COLLECTION`, purpose:`TRACKING` | +| `GDPR.13.1.f`, `GDPR.14.1.f` | Storage information : know where is stored the data organization has on me | action:`TRANSPARENCY.WHERE` | +| `GDPR.14.1.e` | Accessibility information : know who can access the data organization has on me | action:`TRANSPARENCY.WHO` | +| `GDPR.14.2.f` | Provenance information : know the provenance of data organization has on me | action:`TRANSPARENCY.PROVENANCE` | +| `GDPR.13.2.a`, `GDPR.14.2.a` | Know when my data will be deleted | action:`TRANSPARENCY.RETENTION` | +| `**GDPR.13?**` | Know what is the policy of the organization to keep data it has on me | action:`TRANSPARENCY.POLICY` | +| `GDPR.15.1.a` | Know the purpose of the processing organization does on the data it has on me | action:`TRANSPARENCY.PURPOSE` | +| `GDPR.12.1` | Know what type(s) of treatment organization does on the data it has on me | action:`TRANSPARENCY.PROCESSING-CATEGORIES` | +| `GDPR.12.1` | Know if a particular type of treatment is done by organisation on the data it has on me | action:`TRANSPARENCY.PROCESSING-CATEGORIES`, `processing-category:**any/all**` | >**Note** > From 0e23507e169d3bb0d4226ba5c32c4805fd1ee22d Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Fri, 10 Jun 2022 15:40:43 +0200 Subject: [PATCH 150/204] Typo --- refs/schemas/priv/examples.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index cda4479d..32046715 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -118,15 +118,15 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-Demand-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| action:`ACCESS`,`PORTABILITY` | | `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| action:`MODIFY`, other-property:`Selector.to-modify`,`data.rectified` | | `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | action:`MODIFY`, other-property:`Selector.to-modify`,`data.rectified` | -| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | action:`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier'=Information to delete* (can be one or several data capture, or limited to a field , Data cat., Process cat. , Purpose, URL, ...) | +| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | action:`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier'(Information to delete-can be one or several data capture, or limited to a field , Data cat., Process cat. , Purpose, URL, ...) | | `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | action:`DELETE`, data-category:`CONTACT`, purpose:`MARKETING` | | `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | action:`OTHER-DATA` | -| `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | action:`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`=data + URL | -| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/Demandr-le-retrait-de-votre-image-en-ligne) | action: `DELETE`, data-category:`IMAGE`, message:`Reason of deletion`, other-property:`Data.identifier`=data + URL | +| `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | action:`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`(data + URL) | +| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/Demandr-le-retrait-de-votre-image-en-ligne) | action: `DELETE`, data-category:`IMAGE`, message:`Reason of deletion`, other-property:`Data.identifier`(data + URL) | | `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | action:`RESTRICT`,`DELETE`, data-category:`CONTACT`, purpose:`MARKETING`, target: `ORGANISATION`,`PARTNERS`(propagation) | -| `GDPR.21.1`,`GDPR.17.1.c`,,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | action:`RESTRICT`,`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`,`target`= `ORGANISATION`,`PARTNERS`(propagation) | -| `GDPR.21`, GDPR.18.1 | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | action:`RESTRICT`, processing-category:**any/all** | -| `GDRP.4`,`GDRP.6`,`GDRP.7`, `GDPR.13.2.c`| [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | `REVOKE-CONSENT`, processing-category:**any/all** | +| `GDPR.21.1`,`GDPR.17.1.c`,,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | action:`RESTRICT`,`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`,target:`ORGANISATION`,`PARTNERS`(propagation) | +| `GDPR.21`, GDPR.18.1 | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | action:`RESTRICT`, processing-category:`**any/all**` | +| `GDRP.4`,`GDRP.6`,`GDRP.7`, `GDPR.13.2.c`| [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | action:`REVOKE-CONSENT`, processing-category:`**any/all**` | | `GDPR.13.2.a`, `GDPR.14.2.a` | [For how long the data organization has on me will be kept](https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees) | action:`TRANSPARENCY.RETENTION` | >**Note** @@ -141,7 +141,7 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | action:`DELETE`, data-category:`CONTACT`, purpose:`MARKETING` | | `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | action:`RESTRICT`, processing-category:`AUTOMATED-DECISION-MAKING` | | `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | action:`RESTRICT`, processing-category:`SHARING`, purpose`SALE` | -| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | action:`RESTRICT`, data-category:`BEHAVIOR,`DEVICE`,`LOCATION`, processing-category:`COLLECTION`, purpose:`TRACKING` | +| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | action:`RESTRICT`, data-category:`BEHAVIOR`,`DEVICE`,`LOCATION`, processing-category:`COLLECTION`, purpose:`TRACKING` | | `GDPR.13.1.f`, `GDPR.14.1.f` | Storage information : know where is stored the data organization has on me | action:`TRANSPARENCY.WHERE` | | `GDPR.14.1.e` | Accessibility information : know who can access the data organization has on me | action:`TRANSPARENCY.WHO` | | `GDPR.14.2.f` | Provenance information : know the provenance of data organization has on me | action:`TRANSPARENCY.PROVENANCE` | @@ -149,7 +149,7 @@ In the following examples we show how, requests introduced by different regulati | `**GDPR.13?**` | Know what is the policy of the organization to keep data it has on me | action:`TRANSPARENCY.POLICY` | | `GDPR.15.1.a` | Know the purpose of the processing organization does on the data it has on me | action:`TRANSPARENCY.PURPOSE` | | `GDPR.12.1` | Know what type(s) of treatment organization does on the data it has on me | action:`TRANSPARENCY.PROCESSING-CATEGORIES` | -| `GDPR.12.1` | Know if a particular type of treatment is done by organisation on the data it has on me | action:`TRANSPARENCY.PROCESSING-CATEGORIES`, `processing-category:**any/all**` | +| `GDPR.12.1` | Know if a particular type of treatment is done by organisation on the data it has on me | action:`TRANSPARENCY.PROCESSING-CATEGORIES`, processing-category:`**any/all**` | >**Note** > From 9115793c8f888faf11d781ed16fe5d96f975a037 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Fri, 10 Jun 2022 15:41:45 +0200 Subject: [PATCH 151/204] Update examples.md --- refs/schemas/priv/examples.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 32046715..1fde3422 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -106,7 +106,7 @@ In the following examples we show how, requests introduced by different regulati ### GDPR REQUEST TEMPLATES FROM CNIL | LAW | Demand | Representation | -| -------- | -------------------------------------- | ------------ | +| -------- | ----------------------------------------------------- | ------------ | | `GDPR.15` | [Acces](https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces) | action:`ACCESS` | | `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | action:`ACCESS`, data-category:`IMAGE`, purpose:`SECURITY`, other-property:`from-to` | | `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | action:`ACCESS`, data-category:`HEALTH` | @@ -136,7 +136,7 @@ In the following examples we show how, requests introduced by different regulati ### OTHER EXAMPLES FROM DAILY LIFE | LAW | Demand | Representation | -| -------- | -------------------------------------- | ------------ | +| -------- | ----------------------------------------------------- | ------------ | | `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | action:`MODIFY`, data-category:`CONTACT.ADDRESS` | | `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | action:`DELETE`, data-category:`CONTACT`, purpose:`MARKETING` | | `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | action:`RESTRICT`, processing-category:`AUTOMATED-DECISION-MAKING` | From bedcefacb08d77fb609edb81bce3d86240a57af4 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Fri, 10 Jun 2022 16:28:49 +0200 Subject: [PATCH 152/204] Update format Ethyca examples --- refs/schemas/priv/examples.md | 223 +++++++++++++++------------------- 1 file changed, 97 insertions(+), 126 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 1fde3422..fd3cde63 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -124,7 +124,7 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | action:`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`(data + URL) | | `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/Demandr-le-retrait-de-votre-image-en-ligne) | action: `DELETE`, data-category:`IMAGE`, message:`Reason of deletion`, other-property:`Data.identifier`(data + URL) | | `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | action:`RESTRICT`,`DELETE`, data-category:`CONTACT`, purpose:`MARKETING`, target: `ORGANISATION`,`PARTNERS`(propagation) | -| `GDPR.21.1`,`GDPR.17.1.c`,,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | action:`RESTRICT`,`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`,target:`ORGANISATION`,`PARTNERS`(propagation) | +| `GDPR.21.1`,`GDPR.17.1.c`,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | action:`RESTRICT`,`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`,target:`ORGANISATION`,`PARTNERS`(propagation) | | `GDPR.21`, GDPR.18.1 | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | action:`RESTRICT`, processing-category:`**any/all**` | | `GDRP.4`,`GDRP.6`,`GDRP.7`, `GDPR.13.2.c`| [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | action:`REVOKE-CONSENT`, processing-category:`**any/all**` | | `GDPR.13.2.a`, `GDPR.14.2.a` | [For how long the data organization has on me will be kept](https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees) | action:`TRANSPARENCY.RETENTION` | @@ -156,48 +156,20 @@ In the following examples we show how, requests introduced by different regulati >we need to add a schema field for providing new data, and date of validity of new data (not necessairly the date of trnasmission) ### CCPA REQUESTS -| LAW | Demand (as introduced by regulation) | `action`(s) | `data-categories` | `processing-categories` | `purposes` | `message` | Other properties | -| -------- | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | ------------ | -| `CCPA.1798.100.1` | A consumer shall have the right to request that a business that collects a consumer’s personal information disclose to that consumer the categories and specific pieces of personal information the business has collected | `TRANSPARENCY.KNOWN`,`TRANSPARENCY.DATA-CATEGORIES` | `null` | `null` | `null` | `null` | `null` | -| `CCPA.1798.100.4` | A business that receives a verifiable consumer request from a consumer to access personal information shall promptly take steps to disclose and deliver, free of charge to the consumer, the personal information required by this section. | `ACCESS` | `null` | `null` | `null` | `null` | `null` | -| `1798.105.1` | A consumer shall have the right to request that a business delete any personal information about the consumer which the business has collected from the consumer | `DELETE` | `null` | `null` | `null` | `null` | `null` | -| `1798.110.1.1` | A consumer shall have the right to request that a business that collects personal information about the consumer disclose to the consumer the following: The categories of personal information it has collected about that consumer | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `null` | `null` | `null` | `null` | -| `1798.110.1.2` | ...The categories of sources from which the personal information is collected | `TRANSPARENCY.PROVENANCE` | `null` | `null` | `null` | `null` | `null` | -| `1798.110.1.3` | ...The business or commercial purpose for collecting or selling personal information | `TRANSPARENCY.PURPOSE` | `null` | `null` | `null` | `null` | `null` | -| `1798.110.1.4` | ...The categories of third parties with whom the business shares personal information | `TRANSPARENCY.WHO` | `null` | `SHARING` | `null` | `null` | `target`=`PARTNERS` | -| `1798.110.1.5` | ...The specific pieces of personal information it has collected about that consumer | `ACCESS` | `null` | `null` | `null` | `null` | `null` | -| `1798.115.1.1` | A consumer shall have the right to request that a business that sells the consumer’s personal information, or that discloses it for a business purpose, disclose to that consumer: The categories of personal information that the business collected about the consumer | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `SHARING` | `SALE` | `null` | `null` | -| `1798.115.1.2` | ...The categories of personal information that the business sold about the consumer and the categories of third parties to whom the personal information was sold, by category or categories of personal information for each category of third parties to whom the personal information was sold | `TRANSPARENCY.DATA-CATEGORIES`,`TRANSPARENCY.WHO` | `null` | `SHARING` | `SALE` | `null` | `null` | -| `1798.115.1.3` | ...The categories of personal information that the business disclosed about the consumer for a business purpose | `TRANSPARENCY.DATA-CATEGORIES` | `null` | `SHARING` | `SALE` | `null` | `null` | -| `1798.120.1` | A consumer shall have the right, at any time, to direct a business that sells personal information about the consumer to third parties not to sell the consumer’s personal information. This right may be referred to as the right to opt-out | `RESTRICT` | `null` | `SHARING` | `SALE` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `X` | X | `X` | `null` | `null` | `null` | `null` | `null` | -| `1798.125.1.1` | A business shall not discriminate against a consumer because the consumer exercised any of the consumer’s rights | `X` | `null` | `null` | `null` | `null` | `null` | -| `1798.130.1.1` | Make available to consumers two or more designated methods for submitting requests for information, including, at a minimum, a toll-free telephone number. | `X` | `null` | `null` | `null` | `null` | `null` | -| `1798.130.1.2` | Disclose and deliver the required information to a consumer free of charge within 45 days of receiving a verifiable consumer request from the consumer. | `X` | `null` | `null` | `null` | `null` | `null` | +| LAW | Demand (as introduced by regulation) | Representation | +| -------- | ----------------------------------------------------- | ------------ | +| `CCPA.1798.100.1` | A consumer shall have the right to request that a business that collects a consumer’s personal information disclose to that consumer the categories and specific pieces of personal information the business has collected | action:`TRANSPARENCY.KNOWN`,`TRANSPARENCY.DATA-CATEGORIES` | +| `CCPA.1798.100.4` | A business that receives a verifiable consumer request from a consumer to access personal information shall promptly take steps to disclose and deliver, free of charge to the consumer, the personal information required by this section. | action:`ACCESS` | +| `1798.105.1` | A consumer shall have the right to request that a business delete any personal information about the consumer which the business has collected from the consumer | action:`DELETE` | +| `1798.110.1.1` | A consumer shall have the right to request that a business that collects personal information about the consumer disclose to the consumer the following: The categories of personal information it has collected about that consumer | action:`TRANSPARENCY.DATA-CATEGORIES` | +| `1798.110.1.2` | ...The categories of sources from which the personal information is collected | action:`TRANSPARENCY.PROVENANCE` | +| `1798.110.1.3` | ...The business or commercial purpose for collecting or selling personal information | action:`TRANSPARENCY.PURPOSE` | +| `1798.110.1.4` | ...The categories of third parties with whom the business shares personal information | action:`TRANSPARENCY.WHO` | `null` | processing-category:`SHARING`, `target`:`PARTNERS` | +| `1798.110.1.5` | ...The specific pieces of personal information it has collected about that consumer | action:`ACCESS` | +| `1798.115.1.1` | A consumer shall have the right to request that a business that sells the consumer’s personal information, or that discloses it for a business purpose, disclose to that consumer: The categories of personal information that the business collected about the consumer | action:`TRANSPARENCY.DATA-CATEGORIES`, processing-category:`SHARING`, purpose:`SALE` | +| `1798.115.1.2` | ...The categories of personal information that the business sold about the consumer and the categories of third parties to whom the personal information was sold, by category or categories of personal information for each category of third parties to whom the personal information was sold | action:`TRANSPARENCY.DATA-CATEGORIES`,`TRANSPARENCY.WHO`, processing-category:`SHARING`, purpose:`SALE` | +| `1798.115.1.3` | ...The categories of personal information that the business disclosed about the consumer for a business purpose | action:`TRANSPARENCY.DATA-CATEGORIES`, processing-category:`SHARING`, purpose:`SALE` | +| `1798.120.1` | A consumer shall have the right, at any time, to direct a business that sells personal information about the consumer to third parties not to sell the consumer’s personal information. This right may be referred to as the right to opt-out | action:`RESTRICT`, processing-category:`SHARING`, purpose:`SALE` | ### Alternatives Considered @@ -210,30 +182,29 @@ In the following examples we show how, requests introduced by different regulati ###### Account Contact Data -| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment | -| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | -| **account** | **Contact** | Contact data related to a system account | `CONTACT` | `null` | `null` | `null` | -| **account.contact** | **email** | Account's email address | `CONTACT.EMAIL` | `null` | `null` | `null` | -| **account.contact** | **phone_number** | Account's phone number | `CONTACT.PHONE` | `null` | `null` | `null` | -| **account.contact** | **City** | Account's city level address data | `CONTACT.ADDRESS` | `null` | `null` | Need a more detailed cat ? | -| **account.contact** | **Country** | Account's country level address data | `CONTACT.ADDRESS` | `null` | `null` | Need a more detailed cat ? | -| **account.contact** | **postal_code** | Account's postal code | `CONTACT.ADDRESS` | `null` | `null` | Need more detail ? | -| **account.contact** | **state** | Account's state level address data | `CONTACT.ADDRESS` | `null` | `null` | Need a more detailed cat ? | -| **account.contact** | **street** | Account's street level address | `CONTACT.ADDRESS` | `null` | `null` | Need a more detailed cat ? | - +| Ethyca Parent key | **Ethyca Label** | Ethyca Description |Representation | +| ------------ | -------------------------------------- | ------------ | ------------ | +| **account** | **Contact** | Contact data related to a system account | data-category:`CONTACT` | +| **account.contact** | **email** | Account's email address | data-category:`CONTACT.EMAIL` | +| **account.contact** | **phone_number** | Account's phone number | data-category:`CONTACT.PHONE` | +| **account.contact** | **City** | Account's city level address data | data-category:`CONTACT.ADDRESS` | +| **account.contact** | **Country** | Account's country level address data | data-category:`CONTACT.ADDRESS` | +| **account.contact** | **postal_code** | Account's postal code | data-category:`CONTACT.ADDRESS` | +| **account.contact** | **state** | Account's state level address data | data-category:`CONTACT.ADDRESS` | +| **account.contact** | **street** | Account's street level address | data-category:`CONTACT.ADDRESS` | ###### Account Payment Data -| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | -| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | -| **account** | **payment** | Payment data related to system account | `FINANCIAL` | `null` | `null` | Broader definition ? | -| **account.payment** | **financial_account_number** | Payment data related to system account | `FINANCIAL.BANK-ACCOUNT` | `null` | `null` | `null` | +| Ethyca Parent key | **Ethyca Label** | Ethyca Description | Representation | +| ------------ | -------------------------------------- | ------------ | ------------ | +| **account** | **payment** | Payment data related to system account | data-category:`FINANCIAL` | +| **account.payment** | **financial_account_number** | Payment data related to system account | data-category:`FINANCIAL.BANK-ACCOUNT` | ##### System Data Categories > Data unique to, and under control of the system -| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | -| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | -| **system** | **authentication** | Data used to manage access to the system | `**TBD**` | `null` | `null` | Add AUTHENTICATION ? (as a meta cat of biometric ?) | -| **system** | **operations** | Data used for system operations | `**Any/all**` | `**Any/all**` | `null` | Ok ? | +| Ethyca Parent key | **Ethyca Label** | Ethyca Description | Representation | +| ------------ | -------------------------------------- | ------------ | ------------ | +| **system** | **authentication** | Data used to manage access to the system | data-category:`OTHER-DATA` | +| **system** | **operations** | Data used for system operations | data-category:`**Any/all**`, processing-category:`**Any/all**` | ##### User Data Categories > Data related to the user of the system @@ -243,74 +214,74 @@ In the following examples we show how, requests introduced by different regulati ###### User Derived Data > Data derived from user provided data or as a result of user actions in the system -| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | -| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | -| **user.derived** | **identifiable** | Derived data that is linked to, or identifies a user | `**TBD**` | `null` | `null` | TBD, isn't it all the data for us ? | -| **user.derived.identifable** | **biometric_health** | Encoded characteristic collected about a user | `BIOMETRIC`,`HEALTH` | `null` | `null` | Ok ? | -| **user.derived.identifable** | **browsing_history** | Content browsing history of a user | `BEHAVIOR` | `null` | `null` | Ok ? | -| **user.derived.identifable** | **contact** | Contact data collected about a user | `CONTACT` | `null` | `null` | Ok ? | -| **user.derived.identifable** | **demographic** | Demographic data about a user | `DEMOGRAPHIC` | `null` | `null` | `null` | -| **user.derived.identifable** | **gender** | Gender of an individual | `DEMOGRAPHIC.GENDER` | `null` | `null` | `null` | -| **user.derived.identifable** | **location** | Records of the location of a user | `LOCATION` | `null` | `null` | `null` | -| **user.derived.identifable** | **media_consumption** | Media type consumption data of a user | `BEHAVIOR` | `null` | `null` | Ok ? | -| **user.derived.identifable** | **non_specific_age** | Age range data | `DEMOGRAPHIC.AGE` | `null` | `null` | `null` | -| **user.derived.identifable** | **observed** | Data collected through observation of use of the system | `BEHAVIOR` | `null` | `null` | Ok ? | -| **user.derived.identifable** | **organization** | Derived data that is linked to, or identifies an organization | `AFFILIATION` | `null` | `null` | OK ? Or here does Ethyca means user = organisation ? | -| **user.derived.identifable** | **profiling** | Preference and interest data about a user | `BEHAVIOR.PREFERENCE` | `null` | `null` | /!\ not same meaning for our profiling cat | -| **user.derived.identifable** | **race** | Racial or ethnic origin data | `DEMOGRAPHIC.RACE` | `null` | `null` | `null` | -| **user.derived.identifable** | **religious_belief** | Religion or religious belief | `DEMOGRAPHIC.BELIEFS` | `null` | `null` | `null` | -| **user.derived.identifable** | **search_history** | Records of search history and queries of a user | `BEHAVIOR` | `null` | `null` | Ok ? | -| **user.derived.identifable** | **sexual_orientation** | Personal sex life or sexual data | `DEMOGRAPHIC.SEXUAL-ORIENTATION` | `null` | `null` | `null` | -| **user.derived.identifable** | **social** | Social activity and interaction data | `BEHAVIOR.RELATIONSHIPS` | `null` | `null` | Ok ? | -| **user.derived.identifable** | **telemetry** | User identifiable measurement data from system sensors and monitoring | `BEHAVIOR.TELEMETRY` | `null` | `null` | `null` | -| **user.derived.identifable** | **unique_id** | Unique identifier for a user assigned through system use | `UID` | `null` | `null` | `null` | -| **user.derived.identifable** | **user_sensor** | Measurement data derived about a user's environment through system use | `BEHAVIOR`,`COLLECTION` | `null` | `null` | | -| **user.derived.identifable** | **workplace** | Organization of employment | `AFFILIATION.WORK` | `null` | `null` | `null` | -| **user.derived.identifable** | **device** | Data related to a user's device, configuration and setting | `DEVICE` | `null` | `null` | `null` | -| **user.derived.identifable** | **cookie_id** | Cookie unique identification number | `BEHAVIOR` | `null` | `null` | Need a more detailed cat ? | -| **user.derived.identifable** | **device_id** | Device unique identification number | `DEVICE` | `null` | `null` | Need a more detailed cat ? | -| **user.derived.identifable** | **ip_address** | Unique identifier related to device connection | `DEVICE` | `null` | `null` | Need a more detailed cat ? | -| **user.derived** | **nonidentifiable** | Non-user identifiable data derived related to a user as a result of user actions in the system | `**TBD**` | `null` | `null` | TBD, do we need that ? | -| **user.derived.nonidentifiable** | **nonsensor** | Non-user identifiable measurement data derived from sensors and monitoring systems | `**TBD**` | `null` | `null` | TBD, do we need that ? | +| Ethyca Parent key | **Ethyca Label** | Ethyca Description | Representation | +| ------------ | -------------------------------------- | ------------ | ------------ | +| **user.derived** | **identifiable** | Derived data that is linked to, or identifies a user | data-category:`**Any/all**`, provenance:`DERIVED` | +| **user.derived.identifable** | **biometric_health** | Encoded characteristic collected about a user | data-category:`BIOMETRIC`,`HEALTH`, provenance:`DERIVED` | +| **user.derived.identifable** | **browsing_history** | Content browsing history of a user | data-category:`BEHAVIOR`, provenance:`DERIVED` | +| **user.derived.identifable** | **contact** | Contact data collected about a user | data-category:`CONTACT`,provenance:`DERIVED` | +| **user.derived.identifable** | **demographic** | Demographic data about a user | data-category:`DEMOGRAPHIC`, provenance:`DERIVED` | +| **user.derived.identifable** | **gender** | Gender of an individual | data-category:`DEMOGRAPHIC.GENDER`, provenance:`DERIVED` | +| **user.derived.identifable** | **location** | Records of the location of a user | data-category:`LOCATION`, provenance:`DERIVED` | +| **user.derived.identifable** | **media_consumption** | Media type consumption data of a user | data-category:`BEHAVIOR`, provenance:`DERIVED` | +| **user.derived.identifable** | **non_specific_age** | Age range data | data-category:`DEMOGRAPHIC.AGE`, provenance:`DERIVED` | +| **user.derived.identifable** | **observed** | Data collected through observation of use of the system | data-category:`BEHAVIOR`, provenance:`DERIVED` | +| **user.derived.identifable** | **organization** | Derived data that is linked to, or identifies an organization | data-category:`AFFILIATION`, provenance:`DERIVED` | +| **user.derived.identifable** | **profiling** | Preference and interest data about a user | data-category:`BEHAVIOR.PREFERENCE` (/!\ not same meaning for our PROFILING cat), provenance:`DERIVED` | +| **user.derived.identifable** | **race** | Racial or ethnic origin data | data-category:`DEMOGRAPHIC.RACE`, provenance:`DERIVED` | +| **user.derived.identifable** | **religious_belief** | Religion or religious belief | data-category:`DEMOGRAPHIC.BELIEFS`, provenance:`DERIVED` | +| **user.derived.identifable** | **search_history** | Records of search history and queries of a user | data-category:`BEHAVIOR`, provenance:`DERIVED` | +| **user.derived.identifable** | **sexual_orientation** | Personal sex life or sexual data | data-category:`DEMOGRAPHIC.SEXUAL-ORIENTATION`, provenance:`DERIVED` | +| **user.derived.identifable** | **social** | Social activity and interaction data | data-category:`BEHAVIOR.RELATIONSHIPS`, provenance:`DERIVED` | +| **user.derived.identifable** | **telemetry** | User identifiable measurement data from system sensors and monitoring | data-category:`BEHAVIOR.TELEMETRY`, provenance:`DERIVED` | +| **user.derived.identifable** | **unique_id** | Unique identifier for a user assigned through system use | data-category:`UID`, provenance:`DERIVED` | +| **user.derived.identifable** | **user_sensor** | Measurement data derived about a user's environment through system use | data-category:`BEHAVIOR`,`COLLECTION`, provenance:`DERIVED` | +| **user.derived.identifable** | **workplace** | Organization of employment | data-category:`AFFILIATION.WORK`, provenance:`DERIVED` | +| **user.derived.identifable** | **device** | Data related to a user's device, configuration and setting | data-category:`DEVICE`, provenance:`DERIVED` | +| **user.derived.identifable** | **cookie_id** | Cookie unique identification number | data-category:`BEHAVIOR`, provenance:`DERIVED` | +| **user.derived.identifable** | **device_id** | Device unique identification number | data-category:`DEVICE`, provenance:`DERIVED` | +| **user.derived.identifable** | **ip_address** | Unique identifier related to device connection | data-category:`DEVICE`, provenance:`DERIVED` | +| **user.derived** | **nonidentifiable** | Non-user identifiable data derived related to a user as a result of user actions in the system | `OTHER-DATA`, provenance:`DERIVED` | +| **user.derived.nonidentifiable** | **nonsensor** | Non-user identifiable measurement data derived from sensors and monitoring systems | `OTHER-DATA`, provenance:`DERIVED` | ###### User Provided Data > Data provided or created directly by a user of the system -| Ethyca Parent key | **Ethyca Label** | Ethyca Description | `data-categories` | `processing-categories` | `purposes` | `Comment` | -| ------------ | -------------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ | -| **user.provided** | **identifiable** | Data provided or created directly by a user that is linked to or identifies a user | `**TBD**` | `null` | `null` | TBD, isn't it all the data for us ? | -| **user.provided.identifiable** | **identifiable** | Encoded characteristics provided by a user | `**TBD**` | `null` | `null` | `null` | -| **user.provided.identifiable** | **children** | Data relating to children | - | `null` | `null` | @milstan: I don't think the fact someone is a child makes it a separate Data Category. The same person can turn 18 and no longer be a child - and data category can't change due to that. So this should be the responsibility of the System to use AGE to determine if special child-related policies must apply. | -| **user.provided.identifiable** | **health_and_medical** | Health records or individual's personal medical information | `HEALTH` | `null` | `null` | `null` | -| **user.provided.identifiable** | **job_title** | Professional data | `CONTACT` | `null` | `null` | | -| **user.provided.identifiable** | **name** | User's real name | `NAME` | `null` | `null` | `null` | -| **user.provided.identifiable** | **non_specific_age** | Age range data | `DEMOGRAPHIC.AGE` | `null` | `null` | `null` | -| **user.provided.identifiable** | **political_opinion** | Data related to the individual's political opinions | `DEMOGRAPHIC.BELIEFS` | `null` | `null` | `null` | -| **user.provided.identifiable** | **race** | Racial or ethnic origin data | `DEMOGRAPHIC.RACE` | `null` | `null` | `null` | -| **user.provided.identifiable** | **religious_belief** | Religion or religious belief | `DEMOGRAPHIC.BELIEFS` | `null` | `null` | `null` | -| **user.provided.identifiable** | **sexual_orientation** | Personal sex life or sexual data | `DEMOGRAPHIC.SEXUAL-ORIENTATION` | `null` | `null` | Ok ? Need a more detailed cat ? | -| **user.provided.identifiable** | **workplace** | Organization of employment | `AFFILIATION.WORK` | `null` | `null` | `null` | -| **user.provided.identifiable** | **date_of_birth** | User's date of birth | `DEMOGRAPHIC.AGE` | `null` | `null` | `null` | -| **user.provided.identifiable** | **gender** | Gender of an individual | `DEMOGRAPHIC.GENDER` | `null` | `null` | `null` | -| **user.provided.identifiable** | **genetic** | Data about the genetic makeup provided by a user | `GENETIC` | `null` | `null` | `null` | -| **user.provided.identifiable** | **contact** | User provided contact data for purposes other than account management | `CONTACT` | `null` | `null` | `null` | -| **user.provided.identifiable** | **city** | User's city level address data | `CONTACT.ADDRESS` | `null` | `null` | `null` | -| **user.provided.identifiable** | **country** | User's country level address data | `CONTACT.ADDRESS` | `null` | `null` | `null` | -| **user.provided.identifiable** | **email** | User's provided email address | `CONTACT.EMAIL` | `null` | `null` | `null` | -| **user.provided.identifiable** | **phone_number** | User's phone number | `CONTACT.PHONE` | `null` | `null` | `null` | -| **user.provided.identifiable** | **postal_code** | User's postal code | `CONTACT.ADDRESS` | `null` | `null` | `null` | -| **user.provided.identifiable** | **state** | User's state level address data | `CONTACT.ADDRESS` | `null` | `null` | `null` | -| **user.provided.identifiable** | **street** | User's street level address data | `CONTACT.ADDRESS` | `null` | `null` | `null` | -| **user.provided.identifiable** | **credentials** | User provided authentication data | `UID.USER-ACCOUNT` | `null` | `null` | | -| **user.provided.identifiable** | **biometric_credentials** | User provided authentication data | `UID.USER-ACCOUNT`,`BIOMETRIC` | `null` | `null` | | -| **user.provided.identifiable** | **password** | Password for system authentication | `UID.USER-ACCOUNT` | `null` | `null` | | -| **user.provided.identifiable** | **financial** | Payment data and financial history | `FINANCIAL` | `null` | `null` | `Broader definition ?`| -| **user.provided.identifiable** | **account_number** | User's account number for a payment card, bank account, or other financial system | `FINANCIAL.BANK-ACCOUNT` | `null` | `null` | `Ok ? Need a more detailed cat ?`| -| **user.provided.identifiable** | **government_id** | State provided identification data | `UID.ID` | `null` | `null` | | -| **user.provided.identifiable** | **drivers_license_number** | State issued driving identification number | `UID.ID` | `null` | `null` | `Ok ?`| -| **user.provided.identifiable** | **national_identification_number** | State issued personal identification number | `UID.ID` | `null` | `null` | `null`| -| **user.provided.identifiable** | **passport_number** | State issued passport data | `UID.ID` | `null` | `null` | `null`| -| **user.provided** | **nonidentifiable** | Data provided or created directly by a user that is not identifiable | `OTHER-DATA` | `null` | `null` | TBD: Do we need that ?| +| Ethyca Parent key | **Ethyca Label** | Ethyca Description | Representation | +| ------------ | -------------------------------------- | ------------ | ------------ | +| **user.provided** | **identifiable** | Data provided or created directly by a user that is linked to or identifies a user | data-category :`**any/all**`, provenance:`USER` | +| **user.provided.identifiable** | **identifiable** | Encoded characteristics provided by a user | data-category :`**any/all**`, provenance:`USER`| +| **user.provided.identifiable** | **children** | Data relating to children | data-category :`**any/all**`, provenance:`USER` @milstan: I don't think the fact someone is a child makes it a separate Data Category. The same person can turn 18 and no longer be a child - and data category can't change due to that. So this should be the responsibility of the System to use AGE to determine if special child-related policies must apply. | +| **user.provided.identifiable** | **health_and_medical** | Health records or individual's personal medical information | data-category :`HEALTH` provenance:`USER` | +| **user.provided.identifiable** | **job_title** | Professional data | data-category :`CONTACT`, provenance:`USER` | +| **user.provided.identifiable** | **name** | User's real name | data-category :`NAME`, provenance:`USER` | +| **user.provided.identifiable** | **non_specific_age** | Age range data | data-category :`DEMOGRAPHIC.AGE`, provenance:`USER` | +| **user.provided.identifiable** | **political_opinion** | Data related to the individual's political opinions | data-category :`DEMOGRAPHIC.BELIEFS`, provenance:`USER` | +| **user.provided.identifiable** | **race** | Racial or ethnic origin data | data-category :`DEMOGRAPHIC.RACE`, provenance:`USER` | +| **user.provided.identifiable** | **religious_belief** | Religion or religious belief | data-category :`DEMOGRAPHIC.BELIEFS`, provenance:`USER` | +| **user.provided.identifiable** | **sexual_orientation** | Personal sex life or sexual data | data-category :`DEMOGRAPHIC.SEXUAL-ORIENTATION`, provenance:`USER` | +| **user.provided.identifiable** | **workplace** | Organization of employment | data-category :`AFFILIATION.WORK`, provenance:`USER` | +| **user.provided.identifiable** | **date_of_birth** | User's date of birth | data-category :`DEMOGRAPHIC.AGE`, provenance:`USER` | +| **user.provided.identifiable** | **gender** | Gender of an individual | data-category :`DEMOGRAPHIC.GENDER`, provenance:`USER` | +| **user.provided.identifiable** | **genetic** | Data about the genetic makeup provided by a user | data-category :`GENETIC`, provenance:`USER` | +| **user.provided.identifiable** | **contact** | User provided contact data for purposes other than account management | data-category :`CONTACT`, provenance:`USER` | +| **user.provided.identifiable** | **city** | User's city level address data | data-category :`CONTACT.ADDRESS`, provenance:`USER` | +| **user.provided.identifiable** | **country** | User's country level address data | data-category :`CONTACT.ADDRESS`, provenance:`USER` | +| **user.provided.identifiable** | **email** | User's provided email address | data-category :`CONTACT.EMAIL`, provenance:`USER` | +| **user.provided.identifiable** | **phone_number** | User's phone number | data-category :`CONTACT.PHONE`, provenance:`USER` | +| **user.provided.identifiable** | **postal_code** | User's postal code | data-category :`CONTACT.ADDRESS`, provenance:`USER` | +| **user.provided.identifiable** | **state** | User's state level address data | data-category :`CONTACT.ADDRESS`, provenance:`USER` | +| **user.provided.identifiable** | **street** | User's street level address data | data-category :`CONTACT.ADDRESS`, provenance:`USER` | +| **user.provided.identifiable** | **credentials** | User provided authentication data | data-category :`UID.USER-ACCOUNT`, provenance:`USER` | +| **user.provided.identifiable** | **biometric_credentials** | User provided authentication data | data-category :`UID.USER-ACCOUNT`,`BIOMETRIC`, provenance:`USER` | +| **user.provided.identifiable** | **password** | Password for system authentication | data-category :`UID.USER-ACCOUNT`, provenance:`USER` | +| **user.provided.identifiable** | **financial** | Payment data and financial history | data-category :`FINANCIAL`, provenance:`USER` | +| **user.provided.identifiable** | **account_number** | User's account number for a payment card, bank account, or other financial system | data-category :`FINANCIAL.BANK-ACCOUNT`, provenance:`USER` | +| **user.provided.identifiable** | **government_id** | State provided identification data | data-category :`UID.ID`, provenance:`USER` | +| **user.provided.identifiable** | **drivers_license_number** | State issued driving identification number | data-category :`UID.ID`, provenance:`USER` | +| **user.provided.identifiable** | **national_identification_number** | State issued personal identification number |data-category :`UID.ID`, provenance:`USER` | +| **user.provided.identifiable** | **passport_number** | State issued passport data | data-category :`UID.ID`, provenance:`USER` | +| **user.provided** | **nonidentifiable** | Data provided or created directly by a user that is not identifiable | data-category :`OTHER-DATA`, provenance:`USER` | #### Transcend From 577b0d30111e22eb5d14eaa423bcd3247e6ae7e8 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Fri, 10 Jun 2022 16:29:45 +0200 Subject: [PATCH 153/204] Update examples.md --- refs/schemas/priv/examples.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index fd3cde63..2c37846f 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -241,8 +241,8 @@ In the following examples we show how, requests introduced by different regulati | **user.derived.identifable** | **cookie_id** | Cookie unique identification number | data-category:`BEHAVIOR`, provenance:`DERIVED` | | **user.derived.identifable** | **device_id** | Device unique identification number | data-category:`DEVICE`, provenance:`DERIVED` | | **user.derived.identifable** | **ip_address** | Unique identifier related to device connection | data-category:`DEVICE`, provenance:`DERIVED` | -| **user.derived** | **nonidentifiable** | Non-user identifiable data derived related to a user as a result of user actions in the system | `OTHER-DATA`, provenance:`DERIVED` | -| **user.derived.nonidentifiable** | **nonsensor** | Non-user identifiable measurement data derived from sensors and monitoring systems | `OTHER-DATA`, provenance:`DERIVED` | +| **user.derived** | **nonidentifiable** | Non-user identifiable data derived related to a user as a result of user actions in the system | data-category:`OTHER-DATA`, provenance:`DERIVED` | +| **user.derived.nonidentifiable** | **nonsensor** | Non-user identifiable measurement data derived from sensors and monitoring systems | data-category:`OTHER-DATA`, provenance:`DERIVED` | ###### User Provided Data > Data provided or created directly by a user of the system From 40bf038a0557c81960cfe0be72c7a630e689e049 Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Fri, 10 Jun 2022 16:43:38 +0200 Subject: [PATCH 154/204] Changed BEHAVIOR.RELATIONSHIPS to RELATIONSHIPS --- refs/schemas/priv/examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 2c37846f..f0f4058d 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -232,7 +232,7 @@ In the following examples we show how, requests introduced by different regulati | **user.derived.identifable** | **religious_belief** | Religion or religious belief | data-category:`DEMOGRAPHIC.BELIEFS`, provenance:`DERIVED` | | **user.derived.identifable** | **search_history** | Records of search history and queries of a user | data-category:`BEHAVIOR`, provenance:`DERIVED` | | **user.derived.identifable** | **sexual_orientation** | Personal sex life or sexual data | data-category:`DEMOGRAPHIC.SEXUAL-ORIENTATION`, provenance:`DERIVED` | -| **user.derived.identifable** | **social** | Social activity and interaction data | data-category:`BEHAVIOR.RELATIONSHIPS`, provenance:`DERIVED` | +| **user.derived.identifable** | **social** | Social activity and interaction data | data-category:`RELATIONSHIPS`, provenance:`DERIVED` | | **user.derived.identifable** | **telemetry** | User identifiable measurement data from system sensors and monitoring | data-category:`BEHAVIOR.TELEMETRY`, provenance:`DERIVED` | | **user.derived.identifable** | **unique_id** | Unique identifier for a user assigned through system use | data-category:`UID`, provenance:`DERIVED` | | **user.derived.identifable** | **user_sensor** | Measurement data derived about a user's environment through system use | data-category:`BEHAVIOR`,`COLLECTION`, provenance:`DERIVED` | From 228d13ebd40d7c0ca9d264d074b913ac04e6827f Mon Sep 17 00:00:00 2001 From: Clementinev <89908145+Clementinev@users.noreply.github.com> Date: Fri, 10 Jun 2022 16:51:55 +0200 Subject: [PATCH 155/204] Update examples.md --- refs/schemas/priv/examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index f0f4058d..54e77042 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -118,7 +118,7 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-Demand-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| action:`ACCESS`,`PORTABILITY` | | `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| action:`MODIFY`, other-property:`Selector.to-modify`,`data.rectified` | | `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | action:`MODIFY`, other-property:`Selector.to-modify`,`data.rectified` | -| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | action:`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier'(Information to delete-can be one or several data capture, or limited to a field , Data cat., Process cat. , Purpose, URL, ...) | +| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | action:`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`(Information to delete-can be one or several data capture, or limited to a field , Data cat., Process cat. , Purpose, URL, ...) | | `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | action:`DELETE`, data-category:`CONTACT`, purpose:`MARKETING` | | `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | action:`OTHER-DATA` | | `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | action:`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`(data + URL) | From fbb1031a5173656c887f19412025f8389f156214 Mon Sep 17 00:00:00 2001 From: Milan Date: Sat, 11 Jun 2022 08:37:53 +0200 Subject: [PATCH 156/204] Update refs/schemas/priv/dictionary/data-categories/en.data-categories.json Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- .../priv/dictionary/data-categories/en.data-categories.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index c95e26d8..e8b09aec 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -29,7 +29,7 @@ "LOCATION": "Geographic location", "NAME": "First names, last names, nicknames, and other names", "PROFILING": "Any data establishing a degree of similarity of the person with others (e.g., clusters, user-profiles)", - "RELATIONSHIPS": "Data about relationships of the person with others", + "RELATIONSHIPS": "Data about relationships of the person with others, social activity and interaction", "UID": "Any data allowing to uniquely identify a person", "UID.ID": "Official identification number of proof of identity", "UID.USER-ACCOUNT": "Data about a person's account or profile on the first-party website/app and its contents", From 2f744d0d3936e0ae5cb31c7543813812e9bc6da1 Mon Sep 17 00:00:00 2001 From: milstan Date: Mon, 13 Jun 2022 12:29:26 +0200 Subject: [PATCH 157/204] fixes --- refs/schemas/priv/examples.md | 46 +++++++++++++++++------------------ 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 54e77042..395cf021 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -3,7 +3,7 @@ | Status | draft | | :------------ | :------------------------------------------------------------------------------------- | | **Author(s)** | milstan (milstan@blindnet.io), Clémentine VINCENT (clementine@blindnet.io) | -| **Updated** | 2022-05-25 | +| **Updated** | 2022-06-13 | ## Introduction @@ -98,8 +98,8 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.17` | The data subject shall have the right to obtain from the controller the erasure of personal data concerning him | action:`DELETE` | | `GDPR.18` | The data subject shall have the right to obtain from the controller restriction of processing | action:`RESTRICT` | | `GDPR.20` | The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided | action:`PORTABILITY` | -| `GDPR.21` | The data subject shall have the right to object, on grounds relating to his or her particular situation, at any time to processing of personal data concerning him or her which is based on point (e) or (f) of Article 6(1), including profiling based on those provisions. *(note: 21.2 is not yet supported by the schema)*| action:`RESTRICT` | -| `GDPR.22` | The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her | action:`RESTRICT`, processing-category:`AUTOMATED-DECISION-MAKING` | +| `GDPR.21` | The data subject shall have the right to object, on grounds relating to his or her particular situation, at any time to processing of personal data concerning him or her which is based on point (e) or (f) of Article 6(1), including profiling based on those provisions. *(note: 21.2 is not yet supported by the schema)*| action:`OBJECT` | +| `GDPR.22` | The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her | action:`OBJECT`, processing-category:`AUTOMATED-DECISION-MAKING` | @@ -108,19 +108,19 @@ In the following examples we show how, requests introduced by different regulati | LAW | Demand | Representation | | -------- | ----------------------------------------------------- | ------------ | | `GDPR.15` | [Acces](https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces) | action:`ACCESS` | -| `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | action:`ACCESS`, data-category:`IMAGE`, purpose:`SECURITY`, other-property:`from-to` | +| `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | action:`ACCESS`, data-category:`IMAGE`, purpose:`SECURITY`, Data Range restriction `from:2021-02-01` `to:2021-02-03` | | `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | action:`ACCESS`, data-category:`HEALTH` | | `GDPR.15` | [Access to data "Preventel" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel) | action:`ACCESS` | | `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier): Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me | action:`ACCESS`,`TRANSPARENCY.PROVENANCE` | | `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | action:`ACCESS` | | `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | action:`ACCESS` | -| `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | action:`ACCESS`, other-property:`from-to` | +| `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | action:`ACCESS`, Data Range Restriction `from`,`to` | | `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-Demand-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| action:`ACCESS`,`PORTABILITY` | -| `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| action:`MODIFY`, other-property:`Selector.to-modify`,`data.rectified` | -| `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | action:`MODIFY`, other-property:`Selector.to-modify`,`data.rectified` | -| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | action:`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`(Information to delete-can be one or several data capture, or limited to a field , Data cat., Process cat. , Purpose, URL, ...) | -| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | action:`DELETE`, data-category:`CONTACT`, purpose:`MARKETING` | -| `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | action:`OTHER-DATA` | +| `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| action:`MODIFY`, `data-category`: particular `selector` to modify, `data`: new data | +| `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | action:`MODIFY`, `data-category`: particular `selector` to modify, `data`: new data | +| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | action:`DELETE`,`data-category`: category or particular `selector` of the data to be deleted, or any Capture Restriction or Data Range Restriction, (optional) `message`:Reason of deletion | +| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | action:`OBJECT`, data-category:`CONTACT`, purpose:`ADVERTISING` | +| `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `action`:`DELETE`,`data-category`: `UID.USER-ACCOUNT` | | `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | action:`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`(data + URL) | | `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/Demandr-le-retrait-de-votre-image-en-ligne) | action: `DELETE`, data-category:`IMAGE`, message:`Reason of deletion`, other-property:`Data.identifier`(data + URL) | | `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | action:`RESTRICT`,`DELETE`, data-category:`CONTACT`, purpose:`MARKETING`, target: `ORGANISATION`,`PARTNERS`(propagation) | @@ -144,7 +144,7 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | action:`RESTRICT`, data-category:`BEHAVIOR`,`DEVICE`,`LOCATION`, processing-category:`COLLECTION`, purpose:`TRACKING` | | `GDPR.13.1.f`, `GDPR.14.1.f` | Storage information : know where is stored the data organization has on me | action:`TRANSPARENCY.WHERE` | | `GDPR.14.1.e` | Accessibility information : know who can access the data organization has on me | action:`TRANSPARENCY.WHO` | -| `GDPR.14.2.f` | Provenance information : know the provenance of data organization has on me | action:`TRANSPARENCY.PROVENANCE` | +| `GDPR.14.2.f` | Provenance information : know the provenance of data organization has on me | action:`TRANSPARENCY.PROVENANCE` | | `GDPR.13.2.a`, `GDPR.14.2.a` | Know when my data will be deleted | action:`TRANSPARENCY.RETENTION` | | `**GDPR.13?**` | Know what is the policy of the organization to keep data it has on me | action:`TRANSPARENCY.POLICY` | | `GDPR.15.1.a` | Know the purpose of the processing organization does on the data it has on me | action:`TRANSPARENCY.PURPOSE` | @@ -161,7 +161,7 @@ In the following examples we show how, requests introduced by different regulati | `CCPA.1798.100.1` | A consumer shall have the right to request that a business that collects a consumer’s personal information disclose to that consumer the categories and specific pieces of personal information the business has collected | action:`TRANSPARENCY.KNOWN`,`TRANSPARENCY.DATA-CATEGORIES` | | `CCPA.1798.100.4` | A business that receives a verifiable consumer request from a consumer to access personal information shall promptly take steps to disclose and deliver, free of charge to the consumer, the personal information required by this section. | action:`ACCESS` | | `1798.105.1` | A consumer shall have the right to request that a business delete any personal information about the consumer which the business has collected from the consumer | action:`DELETE` | -| `1798.110.1.1` | A consumer shall have the right to request that a business that collects personal information about the consumer disclose to the consumer the following: The categories of personal information it has collected about that consumer | action:`TRANSPARENCY.DATA-CATEGORIES` | +| `1798.110.1.1` | A consumer shall have the right to request that a business that collects personal information about the consumer disclose to the consumer the following: The categories of personal information it has collected about that consumer | action:`TRANSPARENCY.DATA-CATEGORIES` | | `1798.110.1.2` | ...The categories of sources from which the personal information is collected | action:`TRANSPARENCY.PROVENANCE` | | `1798.110.1.3` | ...The business or commercial purpose for collecting or selling personal information | action:`TRANSPARENCY.PURPOSE` | | `1798.110.1.4` | ...The categories of third parties with whom the business shares personal information | action:`TRANSPARENCY.WHO` | `null` | processing-category:`SHARING`, `target`:`PARTNERS` | @@ -183,7 +183,7 @@ In the following examples we show how, requests introduced by different regulati ###### Account Contact Data | Ethyca Parent key | **Ethyca Label** | Ethyca Description |Representation | -| ------------ | -------------------------------------- | ------------ | ------------ | +| ------------ | -------------------------------------- | ------------ | ------------ | | **account** | **Contact** | Contact data related to a system account | data-category:`CONTACT` | | **account.contact** | **email** | Account's email address | data-category:`CONTACT.EMAIL` | | **account.contact** | **phone_number** | Account's phone number | data-category:`CONTACT.PHONE` | @@ -194,8 +194,8 @@ In the following examples we show how, requests introduced by different regulati | **account.contact** | **street** | Account's street level address | data-category:`CONTACT.ADDRESS` | ###### Account Payment Data | Ethyca Parent key | **Ethyca Label** | Ethyca Description | Representation | -| ------------ | -------------------------------------- | ------------ | ------------ | -| **account** | **payment** | Payment data related to system account | data-category:`FINANCIAL` | +| ------------ | -------------------------------------- | ------------ | ------------ | +| **account** | **payment** | Payment data related to system account | data-category:`FINANCIAL` | | **account.payment** | **financial_account_number** | Payment data related to system account | data-category:`FINANCIAL.BANK-ACCOUNT` | ##### System Data Categories @@ -215,10 +215,10 @@ In the following examples we show how, requests introduced by different regulati > Data derived from user provided data or as a result of user actions in the system | Ethyca Parent key | **Ethyca Label** | Ethyca Description | Representation | -| ------------ | -------------------------------------- | ------------ | ------------ | +| ------------ | -------------------------------------- | ------------ | ------------ | | **user.derived** | **identifiable** | Derived data that is linked to, or identifies a user | data-category:`**Any/all**`, provenance:`DERIVED` | | **user.derived.identifable** | **biometric_health** | Encoded characteristic collected about a user | data-category:`BIOMETRIC`,`HEALTH`, provenance:`DERIVED` | -| **user.derived.identifable** | **browsing_history** | Content browsing history of a user | data-category:`BEHAVIOR`, provenance:`DERIVED` | +| **user.derived.identifable** | **browsing_history** | Content browsing history of a user | data-category:`BEHAVIOR`, provenance:`DERIVED` | | **user.derived.identifable** | **contact** | Contact data collected about a user | data-category:`CONTACT`,provenance:`DERIVED` | | **user.derived.identifable** | **demographic** | Demographic data about a user | data-category:`DEMOGRAPHIC`, provenance:`DERIVED` | | **user.derived.identifable** | **gender** | Gender of an individual | data-category:`DEMOGRAPHIC.GENDER`, provenance:`DERIVED` | @@ -235,7 +235,7 @@ In the following examples we show how, requests introduced by different regulati | **user.derived.identifable** | **social** | Social activity and interaction data | data-category:`RELATIONSHIPS`, provenance:`DERIVED` | | **user.derived.identifable** | **telemetry** | User identifiable measurement data from system sensors and monitoring | data-category:`BEHAVIOR.TELEMETRY`, provenance:`DERIVED` | | **user.derived.identifable** | **unique_id** | Unique identifier for a user assigned through system use | data-category:`UID`, provenance:`DERIVED` | -| **user.derived.identifable** | **user_sensor** | Measurement data derived about a user's environment through system use | data-category:`BEHAVIOR`,`COLLECTION`, provenance:`DERIVED` | +| **user.derived.identifable** | **user_sensor** | Measurement data derived about a user's environment through system use | data-category:`BEHAVIOR`,`COLLECTION`, provenance:`DERIVED` | | **user.derived.identifable** | **workplace** | Organization of employment | data-category:`AFFILIATION.WORK`, provenance:`DERIVED` | | **user.derived.identifable** | **device** | Data related to a user's device, configuration and setting | data-category:`DEVICE`, provenance:`DERIVED` | | **user.derived.identifable** | **cookie_id** | Cookie unique identification number | data-category:`BEHAVIOR`, provenance:`DERIVED` | @@ -254,14 +254,14 @@ In the following examples we show how, requests introduced by different regulati | **user.provided.identifiable** | **children** | Data relating to children | data-category :`**any/all**`, provenance:`USER` @milstan: I don't think the fact someone is a child makes it a separate Data Category. The same person can turn 18 and no longer be a child - and data category can't change due to that. So this should be the responsibility of the System to use AGE to determine if special child-related policies must apply. | | **user.provided.identifiable** | **health_and_medical** | Health records or individual's personal medical information | data-category :`HEALTH` provenance:`USER` | | **user.provided.identifiable** | **job_title** | Professional data | data-category :`CONTACT`, provenance:`USER` | -| **user.provided.identifiable** | **name** | User's real name | data-category :`NAME`, provenance:`USER` | +| **user.provided.identifiable** | **name** | User's real name | data-category :`NAME`, provenance:`USER` | | **user.provided.identifiable** | **non_specific_age** | Age range data | data-category :`DEMOGRAPHIC.AGE`, provenance:`USER` | | **user.provided.identifiable** | **political_opinion** | Data related to the individual's political opinions | data-category :`DEMOGRAPHIC.BELIEFS`, provenance:`USER` | | **user.provided.identifiable** | **race** | Racial or ethnic origin data | data-category :`DEMOGRAPHIC.RACE`, provenance:`USER` | | **user.provided.identifiable** | **religious_belief** | Religion or religious belief | data-category :`DEMOGRAPHIC.BELIEFS`, provenance:`USER` | -| **user.provided.identifiable** | **sexual_orientation** | Personal sex life or sexual data | data-category :`DEMOGRAPHIC.SEXUAL-ORIENTATION`, provenance:`USER` | +| **user.provided.identifiable** | **sexual_orientation** | Personal sex life or sexual data | data-category :`DEMOGRAPHIC.SEXUAL-ORIENTATION`, provenance:`USER` | | **user.provided.identifiable** | **workplace** | Organization of employment | data-category :`AFFILIATION.WORK`, provenance:`USER` | -| **user.provided.identifiable** | **date_of_birth** | User's date of birth | data-category :`DEMOGRAPHIC.AGE`, provenance:`USER` | +| **user.provided.identifiable** | **date_of_birth** | User's date of birth | data-category :`DEMOGRAPHIC.AGE`, provenance:`USER` | | **user.provided.identifiable** | **gender** | Gender of an individual | data-category :`DEMOGRAPHIC.GENDER`, provenance:`USER` | | **user.provided.identifiable** | **genetic** | Data about the genetic makeup provided by a user | data-category :`GENETIC`, provenance:`USER` | | **user.provided.identifiable** | **contact** | User provided contact data for purposes other than account management | data-category :`CONTACT`, provenance:`USER` | @@ -269,10 +269,10 @@ In the following examples we show how, requests introduced by different regulati | **user.provided.identifiable** | **country** | User's country level address data | data-category :`CONTACT.ADDRESS`, provenance:`USER` | | **user.provided.identifiable** | **email** | User's provided email address | data-category :`CONTACT.EMAIL`, provenance:`USER` | | **user.provided.identifiable** | **phone_number** | User's phone number | data-category :`CONTACT.PHONE`, provenance:`USER` | -| **user.provided.identifiable** | **postal_code** | User's postal code | data-category :`CONTACT.ADDRESS`, provenance:`USER` | +| **user.provided.identifiable** | **postal_code** | User's postal code | data-category :`CONTACT.ADDRESS`, provenance:`USER` | | **user.provided.identifiable** | **state** | User's state level address data | data-category :`CONTACT.ADDRESS`, provenance:`USER` | | **user.provided.identifiable** | **street** | User's street level address data | data-category :`CONTACT.ADDRESS`, provenance:`USER` | -| **user.provided.identifiable** | **credentials** | User provided authentication data | data-category :`UID.USER-ACCOUNT`, provenance:`USER` | +| **user.provided.identifiable** | **credentials** | User provided authentication data | data-category :`UID.USER-ACCOUNT`, provenance:`USER` | | **user.provided.identifiable** | **biometric_credentials** | User provided authentication data | data-category :`UID.USER-ACCOUNT`,`BIOMETRIC`, provenance:`USER` | | **user.provided.identifiable** | **password** | Password for system authentication | data-category :`UID.USER-ACCOUNT`, provenance:`USER` | | **user.provided.identifiable** | **financial** | Payment data and financial history | data-category :`FINANCIAL`, provenance:`USER` | From 5a414e041f14d76843233e243ca0215e25b04bbf Mon Sep 17 00:00:00 2001 From: milstan Date: Mon, 13 Jun 2022 12:37:33 +0200 Subject: [PATCH 158/204] Data Reference Restriction --- refs/schemas/priv/RFC-PRIV.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index f4d0baf2..1301b69e 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -247,6 +247,14 @@ A Demand can be restricted to particular `provenance-category`, for example the Optionally the Provenance Restriction may also include a particular [Target](#targets). E.g. the Data Subject might demand to have `ACCESS` to data that was `TRANSFERRED` by partner Systems (`target`:`PARTNERS`). +###### Data Reference Restriction + +A Demand can be restricted to particular `data-reference` to precisely identify particular data to which the Data Subject wants to refer in their Demand. E.g., a Data Subject can request from a law-firm to `DELETE` data from a particular file and provide the reference of that file. A Data Subject may request from a website to `DELETE` their photo from a particular web URL. + +| Property | Expected cardinality | Expected values | +| --------------- | ------ | -------------------- | +| `data-reference` | 1-* | one or more references that uniquely identify the data that the Demand concerns (e.g. URLs, file IDs, etc.)| + #### Targets It is common for Internet Systems to be distributed (organised in a set of connected websites and applications) and to exchange data among themselves. From 0e75af0a5a8ff3c40d74575f6e9a803feac1e343 Mon Sep 17 00:00:00 2001 From: milstan Date: Mon, 13 Jun 2022 13:12:07 +0200 Subject: [PATCH 159/204] some fixes --- refs/schemas/priv/examples.md | 44 +++++++++++++++-------------------- 1 file changed, 19 insertions(+), 25 deletions(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 395cf021..5a1b94e7 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -12,10 +12,7 @@ This document examines how the [Privacy Request Interchange Vocabulary](./RFC-PR - illustrated by tutorials and request templates from regulatory bodies (e.g. [CNIL](https://www.cnil.fr/)), - or made possible by existing software solutions with which interoperability SHOULD be achieved (e.g. Transcend, Alias.dev) - -## Motivation - -Elaborating the examples in detail should allow us to test the Privacy Request Interchange Vocabulary for exhaustivity. +The document is not normative, and often uses inconsistent language and format. It serves in the design process in order to test the Privacy Request Interchange Vocabulary for exhaustivity. It can be archived once design is finished and tutorials made. ## Terminology @@ -121,12 +118,12 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | action:`DELETE`,`data-category`: category or particular `selector` of the data to be deleted, or any Capture Restriction or Data Range Restriction, (optional) `message`:Reason of deletion | | `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | action:`OBJECT`, data-category:`CONTACT`, purpose:`ADVERTISING` | | `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `action`:`DELETE`,`data-category`: `UID.USER-ACCOUNT` | -| `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | action:`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`(data + URL) | -| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/Demandr-le-retrait-de-votre-image-en-ligne) | action: `DELETE`, data-category:`IMAGE`, message:`Reason of deletion`, other-property:`Data.identifier`(data + URL) | -| `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | action:`RESTRICT`,`DELETE`, data-category:`CONTACT`, purpose:`MARKETING`, target: `ORGANISATION`,`PARTNERS`(propagation) | -| `GDPR.21.1`,`GDPR.17.1.c`,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | action:`RESTRICT`,`DELETE`, message:`Reason of deletion`, other-property:`Data.identifier`,target:`ORGANISATION`,`PARTNERS`(propagation) | -| `GDPR.21`, GDPR.18.1 | [Limit the treatment (oppose to particular type of treatment) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | action:`RESTRICT`, processing-category:`**any/all**` | -| `GDRP.4`,`GDRP.6`,`GDRP.7`, `GDPR.13.2.c`| [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | action:`REVOKE-CONSENT`, processing-category:`**any/all**` | +| `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | action:`DELETE`, Data Reference Restriction (`data-reference`: concrete URLs), optional `message`:Reason of deletion, | +| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/Demandr-le-retrait-de-votre-image-en-ligne) | action: `DELETE`, data-category:`IMAGE`, Data Reference Restriction (`data-reference`: concrete URLs), (optional) message:`Reason of deletion` | +| `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | action:`OBJECT`(purpose:`MARKETING`), action:`DELETE`(data-category:`CONTACT`), , target: `ORGANISATION`,`PARTNERS`(propagation) | +| `GDPR.21.1`,`GDPR.17.1.c`,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | action:`TRANSPARENCY.RETENTION`; action:`DELETE`, target:`ORGANISATION`,`PARTNERS`(propagation); action:`OBJECT` | +| `GDPR.21`, GDPR.18.1 | [Limit the processing (oppose to particular type of processing) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | action:`OBJECT` | +| `GDRP.4`,`GDRP.6`,`GDRP.7`, `GDPR.13.2.c`| [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | action:`REVOKE-CONSENT`, Consent Restriction | | `GDPR.13.2.a`, `GDPR.14.2.a` | [For how long the data organization has on me will be kept](https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees) | action:`TRANSPARENCY.RETENTION` | >**Note** @@ -137,11 +134,11 @@ In the following examples we show how, requests introduced by different regulati | LAW | Demand | Representation | | -------- | ----------------------------------------------------- | ------------ | -| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | action:`MODIFY`, data-category:`CONTACT.ADDRESS` | -| `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | action:`DELETE`, data-category:`CONTACT`, purpose:`MARKETING` | -| `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | action:`RESTRICT`, processing-category:`AUTOMATED-DECISION-MAKING` | -| `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | action:`RESTRICT`, processing-category:`SHARING`, purpose`SALE` | -| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | action:`RESTRICT`, data-category:`BEHAVIOR`,`DEVICE`,`LOCATION`, processing-category:`COLLECTION`, purpose:`TRACKING` | +| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | action:`MODIFY`, data-category:`CONTACT.ADDRESS`, Data Range restriction `from`:2021-01-01; `data`:1 blindnet street, 75000 blindcity, France | +| `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | action:`DELETE`, data-category:`CONTACT`; action:`OBJECT` (`purpose`:`MARKETING`, `ADVERTISING`) | +| `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | action:`OBJECT`, processing-category:`AUTOMATED-DECISION-MAKING` | +| `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | action:`OBJECT`, purpose`SALE` | +| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | action:`OBJECT`, data-category:`BEHAVIOR`,`DEVICE`,`LOCATION`, processing-category:`COLLECTION`, purpose:`TRACKING` | | `GDPR.13.1.f`, `GDPR.14.1.f` | Storage information : know where is stored the data organization has on me | action:`TRANSPARENCY.WHERE` | | `GDPR.14.1.e` | Accessibility information : know who can access the data organization has on me | action:`TRANSPARENCY.WHO` | | `GDPR.14.2.f` | Provenance information : know the provenance of data organization has on me | action:`TRANSPARENCY.PROVENANCE` | @@ -164,7 +161,7 @@ In the following examples we show how, requests introduced by different regulati | `1798.110.1.1` | A consumer shall have the right to request that a business that collects personal information about the consumer disclose to the consumer the following: The categories of personal information it has collected about that consumer | action:`TRANSPARENCY.DATA-CATEGORIES` | | `1798.110.1.2` | ...The categories of sources from which the personal information is collected | action:`TRANSPARENCY.PROVENANCE` | | `1798.110.1.3` | ...The business or commercial purpose for collecting or selling personal information | action:`TRANSPARENCY.PURPOSE` | -| `1798.110.1.4` | ...The categories of third parties with whom the business shares personal information | action:`TRANSPARENCY.WHO` | `null` | processing-category:`SHARING`, `target`:`PARTNERS` | +| `1798.110.1.4` | ...The categories of third parties with whom the business shares personal information | action:`TRANSPARENCY.WHO` processing-category:`SHARING`| | `1798.110.1.5` | ...The specific pieces of personal information it has collected about that consumer | action:`ACCESS` | | `1798.115.1.1` | A consumer shall have the right to request that a business that sells the consumer’s personal information, or that discloses it for a business purpose, disclose to that consumer: The categories of personal information that the business collected about the consumer | action:`TRANSPARENCY.DATA-CATEGORIES`, processing-category:`SHARING`, purpose:`SALE` | | `1798.115.1.2` | ...The categories of personal information that the business sold about the consumer and the categories of third parties to whom the personal information was sold, by category or categories of personal information for each category of third parties to whom the personal information was sold | action:`TRANSPARENCY.DATA-CATEGORIES`,`TRANSPARENCY.WHO`, processing-category:`SHARING`, purpose:`SALE` | @@ -314,8 +311,8 @@ Transcend proposes the following [treatment types](https://github.com/transcend- | TRANSFER | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | processing-category:`COLLECTION`, provenance:`TRANSFERRED` | | SALE | For selling the data to third parties | processing-category:`**any/all**`, purpose:`SALE` | | HR | For personnel training, recruitment, payroll, management, etc. | processing-category:`**any/all**`, purpose:`EMPLOYMENT` | -| OTHER | Other specific purpose not covered above | processing-category:`**any/all**`, purpose:`OTHER-PURPOSE` | -| UNSPECIFIED | The purpose is not explicitly stated or is unclear | processing-category:`**any/all**`, purpose:`OTHER-PURPOSE` | +| OTHER | Other specific purpose not covered above | processing-category:`**any/all**`, purpose:`OTHER-PURPOSE` use `message` to specify| +| UNSPECIFIED | The purpose is not explicitly stated or is unclear | processing-category:`**any/all**`, purpose:`OTHER-PURPOSE` use `message` to specify| All of those SHOULD be modeled using our Treatment Types. @@ -335,8 +332,8 @@ Transcend proposes the following [data categories](https://github.com/transcend- | TRACKING | Cookies and tracking elements | data-category:`BEHAVIOR`, purpose:`TRACKING` | | DEVICE | Computer or device information | data-category:`DEVICE` | | SURVEY | Any data that is collected through surveys | data-category:`OTHER-DATA` | -| OTHER | A specific type of information not covered by the above categories | data-category:`OTHER-DATA` | -| UNSPECIFIED | The type of information is not explicitly stated or unclear| data-category:`OTHER-DATA` | +| OTHER | A specific type of information not covered by the above categories | data-category:`OTHER-DATA` use `message` to specify| +| UNSPECIFIED | The type of information is not explicitly stated or unclear| data-category:`OTHER-DATA` use `message` to specify| @@ -350,9 +347,6 @@ Transcend proposes the following [data categories](https://github.com/transcend- - **[RFC8259]** Bray, T., ["The JavaScript Object Notation (JSON) Data Interchange Format"](https://datatracker.ietf.org/doc/html/rfc8259), STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. -### Informative References - -- ### Supported Legislation @@ -361,5 +355,5 @@ Transcend proposes the following [data categories](https://github.com/transcend- ### Yet to be Supported Legilsation -- [CPRA]([https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://vig.cdn.sos.ca.gov/2020/general/pdf/topl-prop24.pdf)) -- [HIPPA]([https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5](https://www.govinfo.gov/content/pkg/PLAW-104publ191/pdf/PLAW-104publ191.pdf)) +- CPRA +- HIPPA From fb475b56cf02e98d02f4caa2c9c6576995998ccc Mon Sep 17 00:00:00 2001 From: milstan Date: Mon, 13 Jun 2022 13:33:49 +0200 Subject: [PATCH 160/204] adding data reference --- refs/schemas/priv/RFC-PRIV.md | 3 ++- refs/schemas/priv/expected-behavior.md | 6 +++++- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 1301b69e..18417585 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -4,7 +4,7 @@ | :------------ | :------------------------------------------------------------------------------------- | | **PR #** | [659](https://github.com/blindnet-io/product-management/pull/659) | | **Author(s)** | [milstan](https://github.com/milstan) (milstan@blindnet.io) | -| **Updated** | 2022-06-07 | +| **Updated** | 2022-06-13 | @@ -346,6 +346,7 @@ A Data Capture is given by one Data Subject which can be identified by one or mo | --------------- | ------ | -------------------- | | `data-subject` | 1-* | [Data Subject Identities](#decentralized-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| | `capture-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `data-reference` | 1-* | one or more references that uniquely identify the data that the capture concerns (e.g. a legal case file reference, account ID, contract ID, a URL)| | `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | | `fragments` | 1-* | One or more [Data Capture Fragments](#data-capture-fragments) | diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index de47dd20..20e8576d 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -465,7 +465,8 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - [Consent Restriction](./RFC-PRIV.md#consent-restriction) with any other type of Restriction, - [Consent Restriction](./RFC-PRIV.md#consent-restriction) within a Demand other than `REVOKE-CONSENT`, - More than one [Capture Restriction](./RFC-PRIV.md#capture-restriction), - - A Capture Restriction and any other restriction that is not a Privacy Scope Restriction, + - More than one [Data Reference Restriction](./RFC-PRIV.md#data-reference-restriction) + - A Capture Restriction and any other restriction that is not a Privacy Scope Restriction, or a Data Reference Restriction, - More than one [Data Range](./RFC-PRIV.md#data-range) Restriction. - second, Calculate **Restriction Scope** and **Concerned Fragments**. This is done by processing every Restriction according to the following approach: @@ -480,6 +481,8 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - their `scope` is included in the **Restriction Scope**, AND - they are part of one of the Data Captures the `capture-id` of which is listed under `capture-ids` of that Capture Restriction + - when processing a [Data Reference Restriction](./RFC-PRIV.md#data-reference-restriction) look for all the Data Capture the `data-reference` of which matches the `data-reference` of the Restriction. Then for each such Data Capture `capture-id` proceed as if when processing when processing a [Capture Restriction](./RFC-PRIV.md#capture-restriction). + - when processing a [Data Range](./RFC-PRIV.md#data-range), look for all the Data Capture Fragments the dates of which are within the given Data Range, and set the new **Restriction Scope** to be the intersection of the previous **Restriction Scope** with union of the [Privacy Scope](./RFC-PRIV.md#privacy-scope)s of each of those Data Capture fragments **Concerned Fragments** is set to all Data Capture Fragments that satisfy both of the criteria: - their `scope` is included in the **Restriction Scope**, AND @@ -490,6 +493,7 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - their `scope` is included in the **Restriction Scope**, AND - they match the Provenance Restriction criteria (as seen in [Resolving provenance in requests](#resolving-provenance-in-requests)) + > **Note** > > Data Capture Fragments the scopes of which fall under the **Restriction Scope** are not the same as (but are a superset of) the Data Capture Fragments included in the **Concerned Fragments** scope. From e52419ddd6cae0eb8dcb91bcb747d52e08365782 Mon Sep 17 00:00:00 2001 From: milstan Date: Mon, 13 Jun 2022 13:38:52 +0200 Subject: [PATCH 161/204] fixes wrong data range mention in examples --- refs/schemas/priv/examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 5a1b94e7..75479527 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -134,7 +134,7 @@ In the following examples we show how, requests introduced by different regulati | LAW | Demand | Representation | | -------- | ----------------------------------------------------- | ------------ | -| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | action:`MODIFY`, data-category:`CONTACT.ADDRESS`, Data Range restriction `from`:2021-01-01; `data`:1 blindnet street, 75000 blindcity, France | +| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | action:`MODIFY`, data-category:`CONTACT.ADDRESS`, `data`:1 blindnet street, 75000 blindcity, France , `message`: as of 01.01.2021 (*NB: can't be modeled as a Data Range as Data Ragnge MUST resolve to particular Data Capture Fragments*)| | `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | action:`DELETE`, data-category:`CONTACT`; action:`OBJECT` (`purpose`:`MARKETING`, `ADVERTISING`) | | `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | action:`OBJECT`, processing-category:`AUTOMATED-DECISION-MAKING` | | `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | action:`OBJECT`, purpose`SALE` | From c11ffae0b7c313557799a551b065c34227856e04 Mon Sep 17 00:00:00 2001 From: milstan Date: Mon, 13 Jun 2022 13:48:21 +0200 Subject: [PATCH 162/204] precisions on `Partners` target scope --- refs/schemas/priv/RFC-PRIV.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 18417585..0ce8bc27 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -269,11 +269,11 @@ It is therefore convenient for a Data Subject to be able to formulate Privacy Re `ORGANISATION` includes, in addition to the `SYSTEM`, all other Systems belonging to the same Organisation. Those are understood as being a part of the same First-Party Set (**TODO** ref and compatibility check) -`PARTNERS.DOWNWARD` includes, in addition to the `SYSTEM`, all other Systems belonging to Organisations with which the data about the Data Subject has been shared. +`PARTNERS.DOWNWARD` includes, in addition to the `SYSTEM`, and to all other Systems belonging to the same Organisation, all other Systems belonging to Organisations with which the data about the Data Subject has been shared. -`PARTNERS.UPWARD` includes, in addition to the `SYSTEM`, all other Systems belonging to Organisations from which the data about the Data Subject has been obtained. +`PARTNERS.UPWARD` includes, in addition to the `SYSTEM`, and to all other Systems belonging to the same Organisation, all other Systems belonging to Organisations from which the data about the Data Subject has been obtained. -`PARTNERS` includes, in addition to the `SYSTEM`, all other Systems belonging to Organisations with which any sort of exchange of data concerning the Data Subject has been performed. +`PARTNERS` includes, in addition to the `SYSTEM`, and to all other Systems belonging to the same Organisation, all other Systems belonging to Organisations with which any sort of exchange of data concerning the Data Subject has been performed. Different values of the `target` Property imply different obligations for the System receiving a Privacy Request to transfer that request to other Systems. From 52caf749c259576e2a13d101f4973952d9ed79fa Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 13 Jun 2022 15:31:13 +0200 Subject: [PATCH 163/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Clementinev <89908145+Clementinev@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 0ce8bc27..a7d6b296 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -164,7 +164,7 @@ Privacy Scope = (Data Categories) x (Categories of Processing) x (Purposes of Pr | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-categories` | 0-* | `AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, `UID.ID`, UID.USER-ACCOUNT , UID.SOCIAL-MEDIA , `OTHER-DATA` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | +| `data-categories` | 0-* | `AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, `UID.ID`, `UID.USER-ACCOUNT` , `UID.SOCIAL-MEDIA` , `OTHER-DATA` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | When several values are given, Systems MUST interpret the `data-category` dimension as a union of all the categories indicated. From 92f445981f8e5149f3bccc88444d940399fb237a Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 13 Jun 2022 15:31:58 +0200 Subject: [PATCH 164/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Marko <71560916+m4rk055@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index a7d6b296..e158ff6e 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -67,7 +67,7 @@ With this design we seek: ### Design Choices We have made the following choices: -- **Language Independence**. The Privacy Request Interchange Vocabulary is independent from any programming language, or any format or language for expressing structured data, and can be materialised in different forms such as json, xml, or other. A [json schema](PRIV.schema.json) is provided for convenience. +- **Language Independence**. The Privacy Request Interchange Vocabulary is independent from any programming language, or any format or language for expressing structured data, and can be materialised in different forms such as json, xml, or other. A [json schema](./json-schema/priv.schema.json) is provided for convenience. - **Rich Semantics**. The Privacy Request Interchange Vocabulary includes `terms` - reserved words to describe common types of Privacy Requests, categories of data, categories of data processing and other key notions. This choice is made to facilitate their uniform interpretation by the implementing systems. Their [human-readable titles and descriptions](dictionary) are provided in json format for convenience. From b4e15640da5b4a128c97264bb1c3bcdc88611e32 Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 13 Jun 2022 15:32:13 +0200 Subject: [PATCH 165/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Marko <71560916+m4rk055@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index e158ff6e..64d75284 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -90,7 +90,7 @@ Data Subject is the author of a Privacy Request. | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-subject` | 1-* | [Data Subject Identities](#decentralized-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| +| `data-subject` | 1-* | [Data Subject Identities](#decentralised-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| A Privacy Request is made by one and only one Data Subject. From 97be9fc62f12ba01f86cb020803442cf03cb975c Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 13 Jun 2022 15:32:41 +0200 Subject: [PATCH 166/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Marko <71560916+m4rk055@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 64d75284..95f790e2 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -186,7 +186,7 @@ When several values are given, Systems MUST interpret the `processing-categories In the absence of indication of any `processing-categories` dimension, Systems MUST interpret the Demand as being related to all and any `processing-categories` of treatment. -[A list of eligible `processing-categories` values with corresponding user-facing descriptions is provided](dictionary/purposes) for convenience. +[A list of eligible `processing-categories` values with corresponding user-facing descriptions is provided](dictionary/processing-categories/) for convenience. *Purposes of Processing* From 94cc929d833f07d5eee7daa0b827f758bde7af83 Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 13 Jun 2022 15:46:21 +0200 Subject: [PATCH 167/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Marko <71560916+m4rk055@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 95f790e2..81e4ae4f 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -141,7 +141,7 @@ A Demand MAY refer to only certain Privacy Scope (categories of data, certain ty | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `restrictions` | 0-* | An optional array of restriction objects, each being one of [Privacy Scope](#privacy-scope), [Consent Restriction](#consent-restriction), [Capture Restriction](#capture-restriction), [Data Range](#data-range)| +| `restrictions` | 0-* | An optional array of restriction objects, each being one of [Privacy Scope](#privacy-scope), [Consent Restriction](#consent-restriction), [Capture Restriction](#capture-restriction), [Data Range](#data-range), [Provenance](#provenance-restriction)| When more than one restriction is specified, the System MUST interpret the Demand as referring to the intersection of restrictions. For example let us consider a `DELETE` demand having two restrictions: `LOCATION` `data-category` as Privacy Scope, and from 11th to 15th of June 2022 as Data Range. The System SHOULD understand that the Data Subject wants the System to delete only their location data processed in this precise period. From f0e7cdbcb6595dfe9cfe294832b18c0c6d6addc9 Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 13 Jun 2022 15:55:39 +0200 Subject: [PATCH 168/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Marko <71560916+m4rk055@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 81e4ae4f..e56fd3a7 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -265,7 +265,7 @@ It is therefore convenient for a Data Subject to be able to formulate Privacy Re | --------------- | ------ | -------------------- | | `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `PARTNERS.DOWNWARD`, `PARTNERS.UPWARD`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | -`SYSTEM` refers to the particular System with witch the Data Subject is in direct interaction while making the Privacy Request (or giving the Consent). +`SYSTEM` refers to the particular System with which the Data Subject is in direct interaction while making the Privacy Request (or giving the Consent). `ORGANISATION` includes, in addition to the `SYSTEM`, all other Systems belonging to the same Organisation. Those are understood as being a part of the same First-Party Set (**TODO** ref and compatibility check) From 274b651b9aa7b95b32ab9889a8b307f70a8910c0 Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 13 Jun 2022 16:16:53 +0200 Subject: [PATCH 169/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Marko <71560916+m4rk055@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index e56fd3a7..f9d20ef6 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -417,7 +417,7 @@ Therefore, we use a set of attributes to uniquely identify one Data Subject. One #### Globally Unique Data Subject Identities -The identifiers used to refer to Data Subjects MUST be globally unique. One Data Subject identity corresponds to one Data Subject. One Data Subject can have several Data Subject Identity. +The identifiers used to refer to Data Subjects MUST be globally unique. One Data Subject identity corresponds to one Data Subject. One Data Subject can have several Data Subject Identities. When refering to a Data Subject, Systems MUST use both of the following attributes: - `dsid` - Data Subject ID From ae542cc79730ae65accdbef05651f9af911cca52 Mon Sep 17 00:00:00 2001 From: milstan Date: Mon, 13 Jun 2022 17:11:37 +0200 Subject: [PATCH 170/204] changes after Marko's review --- refs/schemas/priv/RFC-PRIV.md | 18 ++++++++++-------- refs/schemas/priv/examples.md | 8 ++++---- refs/schemas/priv/expected-behavior.md | 10 +++++----- 3 files changed, 19 insertions(+), 17 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index f9d20ef6..5aa83f01 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -141,9 +141,9 @@ A Demand MAY refer to only certain Privacy Scope (categories of data, certain ty | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `restrictions` | 0-* | An optional array of restriction objects, each being one of [Privacy Scope](#privacy-scope), [Consent Restriction](#consent-restriction), [Capture Restriction](#capture-restriction), [Data Range](#data-range), [Provenance](#provenance-restriction)| +| `restrictions` | 0-* | An optional array of restriction objects, each being one of [Privacy Scope](#privacy-scope), [Consent Restriction](#consent-restriction), [Capture Restriction](#capture-restriction), [Date Range](#date-range), [Provenance Restriction](#provenance-restriction), [Data Reference Restriction](#data-reference-restriction)| -When more than one restriction is specified, the System MUST interpret the Demand as referring to the intersection of restrictions. For example let us consider a `DELETE` demand having two restrictions: `LOCATION` `data-category` as Privacy Scope, and from 11th to 15th of June 2022 as Data Range. The System SHOULD understand that the Data Subject wants the System to delete only their location data processed in this precise period. +When more than one restriction is specified, the System MUST interpret the Demand as referring to the intersection of restrictions. For example let us consider a `DELETE` demand having two restrictions: `LOCATION` `data-category` as Privacy Scope, and from 11th to 15th of June 2022 as Date Range. The System SHOULD understand that the Data Subject wants the System to delete only their location data processed in this precise period. A demand with multiple restrictions MUST NOT have more than one restriction of the same type. @@ -224,17 +224,17 @@ A Demand can be restricted to particular Capture ID(s). For example, a Data Subj When one or more `capture-ids` are indicated, Systems MUST interpret the demand all related to all the data captured as part of those Data Captures. -###### Data Range +###### Date Range -A Demand can be restricted to particular Data Range, for example the Data Subject may `OBJECT` to data collection in a particular time period, or they might want to `DELETE` only data collected at certain dates. +A Demand can be restricted to particular Date Range, for example the Data Subject may `OBJECT` to data collection in a particular time period, or they might want to `DELETE` only data collected at certain dates. | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `from` | 0-* | Date and Time when the Data Range starts in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| `to` | 0-* | Date and Time when the Data Range ends in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `from` | 0-* | Date and Time when the Date Range starts in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `to` | 0-* | Date and Time when the Date Range ends in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -A Data Range defined by only one of the {`from`, `to`} properties indicates a period of time after or before a certain date, unbounded on the other end. +A Date Range defined by only one of the {`from`, `to`} properties indicates a period of time after or before a certain date, unbounded on the other end. ###### Provenance Restriction @@ -247,6 +247,8 @@ A Demand can be restricted to particular `provenance-category`, for example the Optionally the Provenance Restriction may also include a particular [Target](#targets). E.g. the Data Subject might demand to have `ACCESS` to data that was `TRANSFERRED` by partner Systems (`target`:`PARTNERS`). +[A list of eligible `provenance-category` values with corresponding user-facing descriptions is provided](./dictionary/provenance/) for convenience. + ###### Data Reference Restriction A Demand can be restricted to particular `data-reference` to precisely identify particular data to which the Data Subject wants to refer in their Demand. E.g., a Data Subject can request from a law-firm to `DELETE` data from a particular file and provide the reference of that file. A Data Subject may request from a website to `DELETE` their photo from a particular web URL. @@ -405,7 +407,7 @@ We provide a [JSON Schema document](./priv.schema.json) for machine-readable int ### Authenticated exchanges -Systems exchanging Privacy Requests MUST be able to do so in a way allowing them to very the integrity of their content, and the identity of the system having emitted the Privacy Request. +Systems exchanging Privacy Requests MUST be able to do so in a way allowing them to verify the integrity of their content, and the identity of the system having emitted the Privacy Request. Ideally, Privacy Requests MAY be signed by Data Subjects themselves. For this purposes Privacy Requests MAY be embedded as 'Claims' in [JWTs (RFC7519)](https://datatracker.ietf.org/doc/html/rfc7519). diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 75479527..4370c26a 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -105,17 +105,17 @@ In the following examples we show how, requests introduced by different regulati | LAW | Demand | Representation | | -------- | ----------------------------------------------------- | ------------ | | `GDPR.15` | [Acces](https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces) | action:`ACCESS` | -| `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | action:`ACCESS`, data-category:`IMAGE`, purpose:`SECURITY`, Data Range restriction `from:2021-02-01` `to:2021-02-03` | +| `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | action:`ACCESS`, data-category:`IMAGE`, purpose:`SECURITY`, Date Range restriction `from:2021-02-01` `to:2021-02-03` | | `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | action:`ACCESS`, data-category:`HEALTH` | | `GDPR.15` | [Access to data "Preventel" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel) | action:`ACCESS` | | `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier): Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me | action:`ACCESS`,`TRANSPARENCY.PROVENANCE` | | `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | action:`ACCESS` | | `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | action:`ACCESS` | -| `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | action:`ACCESS`, Data Range Restriction `from`,`to` | +| `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | action:`ACCESS`, Date Range Restriction `from`,`to` | | `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-Demand-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| action:`ACCESS`,`PORTABILITY` | | `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| action:`MODIFY`, `data-category`: particular `selector` to modify, `data`: new data | | `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | action:`MODIFY`, `data-category`: particular `selector` to modify, `data`: new data | -| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | action:`DELETE`,`data-category`: category or particular `selector` of the data to be deleted, or any Capture Restriction or Data Range Restriction, (optional) `message`:Reason of deletion | +| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | action:`DELETE`,`data-category`: category or particular `selector` of the data to be deleted, or any Capture Restriction or Date Range Restriction, (optional) `message`:Reason of deletion | | `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | action:`OBJECT`, data-category:`CONTACT`, purpose:`ADVERTISING` | | `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `action`:`DELETE`,`data-category`: `UID.USER-ACCOUNT` | | `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | action:`DELETE`, Data Reference Restriction (`data-reference`: concrete URLs), optional `message`:Reason of deletion, | @@ -134,7 +134,7 @@ In the following examples we show how, requests introduced by different regulati | LAW | Demand | Representation | | -------- | ----------------------------------------------------- | ------------ | -| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | action:`MODIFY`, data-category:`CONTACT.ADDRESS`, `data`:1 blindnet street, 75000 blindcity, France , `message`: as of 01.01.2021 (*NB: can't be modeled as a Data Range as Data Ragnge MUST resolve to particular Data Capture Fragments*)| +| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | action:`MODIFY`, data-category:`CONTACT.ADDRESS`, `data`:1 blindnet street, 75000 blindcity, France , `message`: as of 01.01.2021 (*NB: can't be modeled as a Date Range as Data Ragnge MUST resolve to particular Data Capture Fragments*)| | `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | action:`DELETE`, data-category:`CONTACT`; action:`OBJECT` (`purpose`:`MARKETING`, `ADVERTISING`) | | `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | action:`OBJECT`, processing-category:`AUTOMATED-DECISION-MAKING` | | `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | action:`OBJECT`, purpose`SALE` | diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 20e8576d..a17126af 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -467,7 +467,7 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - More than one [Capture Restriction](./RFC-PRIV.md#capture-restriction), - More than one [Data Reference Restriction](./RFC-PRIV.md#data-reference-restriction) - A Capture Restriction and any other restriction that is not a Privacy Scope Restriction, or a Data Reference Restriction, - - More than one [Data Range](./RFC-PRIV.md#data-range) Restriction. + - More than one [Date Range](./RFC-PRIV.md#date-range) Restriction. - second, Calculate **Restriction Scope** and **Concerned Fragments**. This is done by processing every Restriction according to the following approach: - at the beginning set **Restriction Scope** to be equal to the Eligible Privacy Scope of the Data Subject @@ -483,10 +483,10 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - when processing a [Data Reference Restriction](./RFC-PRIV.md#data-reference-restriction) look for all the Data Capture the `data-reference` of which matches the `data-reference` of the Restriction. Then for each such Data Capture `capture-id` proceed as if when processing when processing a [Capture Restriction](./RFC-PRIV.md#capture-restriction). - - when processing a [Data Range](./RFC-PRIV.md#data-range), look for all the Data Capture Fragments the dates of which are within the given Data Range, and set the new **Restriction Scope** to be the intersection of the previous **Restriction Scope** with union of the [Privacy Scope](./RFC-PRIV.md#privacy-scope)s of each of those Data Capture fragments + - when processing a [Date Range](./RFC-PRIV.md#date-range), look for all the Data Capture Fragments the dates of which are within the given Date Range, and set the new **Restriction Scope** to be the intersection of the previous **Restriction Scope** with union of the [Privacy Scope](./RFC-PRIV.md#privacy-scope)s of each of those Data Capture fragments **Concerned Fragments** is set to all Data Capture Fragments that satisfy both of the criteria: - their `scope` is included in the **Restriction Scope**, AND - - their `date` falls within the Data Range of the Restriction + - their `date` falls within the Date Range of the Restriction - when processing a [Provenance Restriction](./RFC-PRIV.md#provenance-restriction) look for all the Data Capture Fragments that match the Provenance Restriction criteria (as seen in [Resolving provenance in requests](#resolving-provenance-in-requests)) and set the new **Restriction Scope** to be the intersection of the previous **Restriction Scope** with union of the [Privacy Scope](./RFC-PRIV.md#privacy-scope)s of each of those Data Capture fragments **Concerned Fragments** is set to all Data Capture Fragments that satisfy both of the criteria: @@ -498,7 +498,7 @@ When Data Subject ID is provided, the Data Subject is known by the System and au > > Data Capture Fragments the scopes of which fall under the **Restriction Scope** are not the same as (but are a superset of) the Data Capture Fragments included in the **Concerned Fragments** scope. > - > This is due to [Data Range](./RFC-PRIV.md#data-range), [Capture Restriction](./RFC-PRIV.md#capture-restriction) and [Provenance Restriction](./RFC-PRIV.md#provenance-restriction), all of which might be used to select particular Data Capture Fragments out of many thay may be captured with the same Data Capture Fragment `selector`. + > This is due to [Date Range](./RFC-PRIV.md#date-range), [Capture Restriction](./RFC-PRIV.md#capture-restriction) and [Provenance Restriction](./RFC-PRIV.md#provenance-restriction), all of which might be used to select particular Data Capture Fragments out of many thay may be captured with the same Data Capture Fragment `selector`. > - third, with regards to the `action` of the Demand: @@ -509,7 +509,7 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - If restricted to concrete consent IDs with a [Consent Restriction](./RFC-PRIV.md#consent-restriction), recommend status = `GRANTED` and recalculate Eligible Privacy Scope to drop any Privacy Scope Triples that have been included as a result of Consents being revoked. - If Demand is restricted by a Privacy Scope, recommend status = `GRANTED` and [update consents](#updateConsent) - If no Restriction is given in the Demand, revoke all consents given by this Data Subject - - If only a Data Range restriction is present, recommend status = `GRANTED` and revoke all consents that have been collected in the given Data Range + - If only a Date Range restriction is present, recommend status = `GRANTED` and revoke all consents that have been collected in the given Date Range - In other combinations of Restrictions, take the resulting **Restriction Scope**, recommend status = `GRANTED` and [update consents](#updateConsent) as if an `OBJECT` Demand has been made with the **Restriction Scope** - `OBJECT`, `RESTRICT` Demands: From 82d9743e67c208467d1747a75cad69c66332e14d Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 14 Jun 2022 17:09:45 +0200 Subject: [PATCH 171/204] vocabulary harmonization across documents --- refs/schemas/priv/RFC-PRIV.md | 74 +++++++++++++++----------- refs/schemas/priv/examples.md | 16 +++--- refs/schemas/priv/expected-behavior.md | 44 +++++++-------- refs/schemas/priv/scenarios.md | 16 +++--- 4 files changed, 82 insertions(+), 68 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 5aa83f01..59906417 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -4,7 +4,7 @@ | :------------ | :------------------------------------------------------------------------------------- | | **PR #** | [659](https://github.com/blindnet-io/product-management/pull/659) | | **Author(s)** | [milstan](https://github.com/milstan) (milstan@blindnet.io) | -| **Updated** | 2022-06-13 | +| **Updated** | 2022-06-14 | @@ -14,30 +14,28 @@ We propose a simple vocabulary for representing [Privacy Requests](https://githu The vocabulary introduces a finite set of `concepts`, `properties` and `terms`. `Concepts` define the objects of exchange, `properties` define their characteristics, and `terms` define commonly understood values of properties. -This vocabulary corresponds to the [Schemas](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#schemas) component of the [High-Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). +This vocabulary corresponds to the [Schemas](../high-level-architecture#schemas) component of the [High-Level Architecture](../high-level-architecture). Additional documents: [Examples of use](./examples.md), [Scenarios](./scenarios.md) and [Expected Behavior of Implementing Systems](./expected-behavior.md), complement this document. ## Motivation -An individual is in connection with software Systems (and Organisations operating them) that process the individual's data. -In order to [regulate the relationship](https://github.com/blindnet-io/product-management/blob/main/refs/notion-of-privacy/notion-of-privacy.md) with those Systems (and Organisations), the individual makes requests related to their privacy. +An individual is in connection with software Systems (and Organizations operating them) that process the individual's data. +In order to [regulate the relationship](../notion-of-privacy/notion-of-privacy.md) with those Systems (and Organizations), the individual makes requests related to their privacy. With a Privacy Request the individual aims to gain a degree of transparency about data processing and a degree of control over the data and over the data processing. Allowing individuals to make Privacy Requests is becoming more and more a legal obligation. -Different Systems, and different components of a single System, including different components of blindnet devkit are likely to exchange information about Privacy Requests. Therefore, a common format is needed to facilitate exchange of information without loss of semantics. The goal of Privacy Request Interchange Vocabulary is to establish a shared conceptualisation and format of Privacy Request so that their processing can be, as much as possible, automatised by the Systems. +Different Systems, and different components of a single System, including different components of blindnet devkit are likely to exchange information about Privacy Requests. Therefore, a common format is needed to facilitate exchange of information without loss of semantics. The goal of Privacy Request Interchange Vocabulary is to establish a shared conceptualization and format of Privacy Request so that their processing can be, as much as possible, automatized by the Systems. ## Terminology ->**TO BE Updated** once Lexicon and High Level Conceptualization are synchronised - -- We use the term Privacy Request interchangeably with the (deprecated) terms Rights Request and Data Rights Request as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) -- We use the terms Individual, Person, You, and Data Subject as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) -- We use the term System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) -- We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) -- We use the terms Organization, Submitter, Data Consumer as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) as defined there. +- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) +- The key word "CAN" denotes ability of someone or something, and is interpreted as "MUST be able to" +- The key words "blindnet devkit", "CCPA", "CPRA", "Capture Fragment", "Component", "Data Capture", "Data Capture Fragment", "Data Consumer", "Data Subject", "DPO", "Fragment", "GDPR", "HIPPA", "Internet User", "Organization", "Privateform", "Privacy Request", "System", "Submitter", "User" are to be interpreted as described in [RFC-Lexicon-2](../lexicon/RFC-Lexicon-2.md) +- Any additional precision about the key words defined in [RFC-Lexicon-2](../lexicon/RFC-Lexicon-2.md), as well as additional key words such as "Consent" and "Legal Base", provided in [High Level Conceptualization](../high-level-conceptualization/) is to be considered normative +- All key words denoting components of [blindnet devkit](../lexicon/RFC-Lexicon-2.md#blindnet-devkit), such as "Capture Component", "Encryption and Access Management Engine", "Privacy Computation Engine", "Privacy Compiler", "Privacy Request Capture Interface", "Customization API", "Data Consumer Interface", "Schemas" and "Storage Component" are to be interpreted as defined in [High Level Architecture](../high-level-architecture/) ## Version @@ -49,7 +47,7 @@ This document defines the version `1.0` of the Privacy Request Interchange Vocab - **Smart data structures and dumb code works a lot better than the other way around.** lesson No 9 from Raymond, Eric Steven. ["The Cathedral and the Bazaar"](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar). We want PRIF to embody a smart way of thinking about privacy, solving common challenges through the data structure itself. -- **Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.** lesson No 12 from Raymond, Eric Steven. ["The Cathedral and the Bazaar"](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar). We indeed now have novel understanding of the [problem of Privacy in Software Systems](https://github.com/blindnet-io/product-management/blob/main/refs/notion-of-privacy/notion-of-privacy.md). +- **Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.** lesson No 12 from Raymond, Eric Steven. ["The Cathedral and the Bazaar"](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar). We indeed now have novel understanding of the [problem of Privacy in Software Systems](../notion-of-privacy/notion-of-privacy.md). ### Design Goals @@ -67,22 +65,35 @@ With this design we seek: ### Design Choices We have made the following choices: -- **Language Independence**. The Privacy Request Interchange Vocabulary is independent from any programming language, or any format or language for expressing structured data, and can be materialised in different forms such as json, xml, or other. A [json schema](./json-schema/priv.schema.json) is provided for convenience. +- **Language Independence**. The Privacy Request Interchange Vocabulary is independent from any programming language, or any format or language for expressing structured data, and can be materialized in different forms such as json, xml, or other. A [json schema](./json-schema/priv.schema.json) is provided for convenience. - **Rich Semantics**. The Privacy Request Interchange Vocabulary includes `terms` - reserved words to describe common types of Privacy Requests, categories of data, categories of data processing and other key notions. This choice is made to facilitate their uniform interpretation by the implementing systems. Their [human-readable titles and descriptions](dictionary) are provided in json format for convenience. - **Multiple User Identities**. The Privacy Request Interchange Vocabulary allows for a Data Subject to be identified using more than one user identity. This choice is made to enable the Privacy Request to be easily exchanged across Systems that use different user identifiers. -- **Systems resolve Privacy Requests**. The Privacy Requests are interpreted at the level of a particular System. If an Organisation operates several Systems, and if the Data Subject wants to have the Privacy Request transmitted to all of them, each System may respond differently. While a Privacy Request can target a group of Systems, the most atomic target of a Privacy Request is thus the System exposing an API for Privacy Requests, and it is only at this level that a Privacy Request can be resolved. +- **Systems resolve Privacy Requests**. The Privacy Requests are interpreted at the level of a particular System. If an Organization operates several Systems, and if the Data Subject wants to have the Privacy Request transmitted to all of them, each System may respond differently. While a Privacy Request can target a group of Systems, the most atomic target of a Privacy Request is thus the System exposing an API for Privacy Requests, and it is only at this level that a Privacy Request can be resolved. -- **Decentralised IDs**. The Privacy Request Interchange Vocabulary uses decentralised ways to uniquely identify Data Subjects, Systems, Requests and their elements. The exchange of Privacy Requests can happen without a centralised entity to control identity disambiguation. +- **Decentralized IDs**. The Privacy Request Interchange Vocabulary uses decentralized ways to uniquely identify Data Subjects, Systems, Requests and their elements. The exchange of Privacy Requests can happen without a centralized entity to control identity disambiguation. ## Proposal The Privacy Request Interchange Vocabulary includes the following: -- Key Concepts: [Consent](#consent), [Data Capture](#data-capture), [Data Capture Fragment](#data-capture-fragments), [Demand](#demands), [Privacy Request](#privacy-request), [Privacy Scope](#privacy-scope) -- Properties: **TBD** full list of properties -- Terms: **TBD** full list of terms + +- Concepts: +[Consent](#consent), +[Data Capture](#data-capture), +[Data Capture Fragment](#data-capture-fragments), +[Data Subject Identity](#decentralized-identity-of-data-subjects), +[Demand](#demands), +[Demand Restriction](#demand-restrictions) (including [Privacy Scope Restriction](#privacy-scope),[Consent Restriction](#consent-restriction), [Capture Restriction](#capture-restriction), [Date Range](#date-range), [Provenance Restriction](#provenance-restriction), [Data Reference Restriction](#data-reference-restriction)), +[Privacy Request](#privacy-request), +[Privacy Request Response](#privacy-request-response), [Privacy Scope](#privacy-scope)(and its dimensions: *Data Category*, *Processing Category* and *Purpose*), [Provenance](#provenance), +[Retention Policy](#retention-policy), +[Data Subject Identity](#decentralized-identity-of-data-subjects) + +- Properties: `action`, `after`, `answers`, `capture-id`, `capture-ids`, `consent-id`,`consent-ids`, `data-subject`,`data`, `data-categories`, `data-reference`, `data-subject`, `date`,`demand-id`, `demands`, `dsid`, `dsid-schema`, `duration`, `expires`,`fragment-id`, `fragments`, `from`, `includes`, `in-response-to`,`lang`, `legal-base`, `message`, `motive`, `policy-type`, `processing-categories`, `provenance, ``provenance-category`, `purposes`, `replaces`, `response-id`, `restrictions`, `request-id`, `replaced-by`, `retention`, `requested-action`, `scope`, `selector`, `status`, `system`, `target`, `to`, `vocab` + +- Terms: all terms included in [the dictionary](./dictionary) ### Privacy Request @@ -168,7 +179,7 @@ Privacy Scope = (Data Categories) x (Categories of Processing) x (Purposes of Pr When several values are given, Systems MUST interpret the `data-category` dimension as a union of all the categories indicated. -Categories are organised as a hierarchy, denoted with a dot ".", the more general category being written on the left. +Categories are organized as a hierarchy, denoted with a dot ".", the more general category being written on the left. E.g. the following two `data-category` restrictions are equivalent: - `CONTACT`,`CONTACT.EMAIL` - `CONTACT` @@ -269,21 +280,21 @@ It is therefore convenient for a Data Subject to be able to formulate Privacy Re `SYSTEM` refers to the particular System with which the Data Subject is in direct interaction while making the Privacy Request (or giving the Consent). -`ORGANISATION` includes, in addition to the `SYSTEM`, all other Systems belonging to the same Organisation. Those are understood as being a part of the same First-Party Set (**TODO** ref and compatibility check) +`ORGANISATION` includes, in addition to the `SYSTEM`, all other Systems belonging to the same Organization. Those are understood as being a part of the same First-Party Set (**TODO** ref and compatibility check) -`PARTNERS.DOWNWARD` includes, in addition to the `SYSTEM`, and to all other Systems belonging to the same Organisation, all other Systems belonging to Organisations with which the data about the Data Subject has been shared. +`PARTNERS.DOWNWARD` includes, in addition to the `SYSTEM`, and to all other Systems belonging to the same Organization, all other Systems belonging to Organizations with which the data about the Data Subject has been shared. -`PARTNERS.UPWARD` includes, in addition to the `SYSTEM`, and to all other Systems belonging to the same Organisation, all other Systems belonging to Organisations from which the data about the Data Subject has been obtained. +`PARTNERS.UPWARD` includes, in addition to the `SYSTEM`, and to all other Systems belonging to the same Organization, all other Systems belonging to Organizations from which the data about the Data Subject has been obtained. -`PARTNERS` includes, in addition to the `SYSTEM`, and to all other Systems belonging to the same Organisation, all other Systems belonging to Organisations with which any sort of exchange of data concerning the Data Subject has been performed. +`PARTNERS` includes, in addition to the `SYSTEM`, and to all other Systems belonging to the same Organization, all other Systems belonging to Organizations with which any sort of exchange of data concerning the Data Subject has been performed. Different values of the `target` Property imply different obligations for the System receiving a Privacy Request to transfer that request to other Systems. -Let us imagine the following situation: System A gave information about the Data Subject to System B, and System B gave information about the Data Subject to System C. The same Organisation that operates System B, also operates System D. +Let us imagine the following situation: System A gave information about the Data Subject to System B, and System B gave information about the Data Subject to System C. The same Organization that operates System B, also operates System D. When System B receives a Privacy Request having `target` value: - `SYSTEM`, it SHOULD NOT transfer it to any other system. -- `ORGANISATION` for a `target`, it MUST transfer it to all other systems operated by the same Organisation (System D in our example). +- `ORGANISATION` for a `target`, it MUST transfer it to all other systems operated by the same Organization (System D in our example). - `PARTNERS.DOWNWARD` it MUST also send it to all systems to which it transferred data about the Data Subject (System C). - `PARTNERS.UPWARD` it MUST also send it to all systems from which it obtained data about the Data Subject (System A). - `PARTNERS`, it MUST also send it to all systems from which it obtained data about the Data Subject or to which it gave information about the Data Subject (System A and System C). @@ -302,7 +313,7 @@ Regardless of the [scenario (Responding to the Data Subject directly or to the S | `response-id` | 1 | Unique ID for referring to this request in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `in-response-to` | 1 | `request-id` of the Privacy Request to which response is made or `demand-id` of the particular Demand to which response is made, in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Privacy Request Response was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| `by` | 1 | **TBD ID of the System having generated the response** | +| `system` | 1 | System ID of the System having generated the response (**Format TBD**) | | `requested-action` | 0-1 | Optional information about the action that was demanded, and to which the response is made. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER-DEMAND`} | | `data-subject` | 0-* | Optional indication of the [Data Subject Identities](#decentralized-identity-of-data-subjects) to which the response refers to | | `status` | 1 | One of {`GRANTED`, `DENIED`, `PARTIALLY-GRANTED`, `UNDER-REVIEW`} | @@ -712,9 +723,12 @@ Is the mechanism for extending the vocabulary appropriate? We need a way for Systems to encrypt the data (that compatible also with encryption libraries other then our own). ### Motivation or explanation of Demand ->**Note** -> -> The motivation or explanation of Demand is modelled by a message, and the message is optional. If law regulations state that motivation or explanation of Demand is mandatory, it is not supported. + +When a Demand is motivated by a `message`, then it can't be processed automatically. +To the best of our knowledge, motivating a Demand is optional under [supported legislation](#supported-legilsation). +The `message` is thus optional. + +If PRIV is ever to support a legislation under which a message might be mandatory, this design SHOULD be reconsidered. ## Alternatives diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 4370c26a..900bfca3 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -16,14 +16,14 @@ The document is not normative, and often uses inconsistent language and format. ## Terminology ->**TBD** - -- We use the term Privacy Request interchangeably with the (deprecated) terms Rights Request and Data Rights Request as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) -- We use the terms Individual, Person, You, and Data Subject as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) -- We use the term System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) -- We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) -- We use the terms Organization, Submitter, Data Consumer as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) as defined there. - +- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) +- The key word "CAN" denotes ability of someone or something, and is interpreted as "MUST be able to" +- The key words "blindnet devkit", "CCPA", "CPRA", "Capture Fragment", "Component", "Data Capture", "Data Capture Fragment", "Data Consumer", "Data Subject", "DPO", "Fragment", "GDPR", "HIPPA", "Internet User", "Organization", "Privateform", "Privacy Request", "System", "Submitter", "User" are to be interpreted as described in [RFC-Lexicon-2](../lexicon/RFC-Lexicon-2.md) +- Any additional precision about the key words defined in [RFC-Lexicon-2](../lexicon/RFC-Lexicon-2.md), as well as additional key words such as "Consent" and "Legal Base", provided in [High Level Conceptualization](../high-level-conceptualization/) is to be considered normative +- All key words denoting components of [blindnet devkit](../lexicon/RFC-Lexicon-2.md#blindnet-devkit), such as "Capture Component", "Encryption and Access Management Engine", "Privacy Computation Engine", "Privacy Compiler", "Privacy Request Capture Interface", "Customization API", "Data Consumer Interface", "Schemas" and "Storage Component" are to be interpreted as defined in [High Level Architecture](../high-level-architecture/) +- Privacy Compiler was formerly known as Data Rights Compiler +- Privacy Request was formerly known as Data Rights Request +- All the concepts, properties and terms listed in the [Proposal](./RFC-PRIV.md#proposal) section of PRIV(Privacy Request Interchange Vocabulary are to be interpreted as defined in [Privacy Request Interchange Vocabulary](./RFC-PRIV.md#proposal) ## Examples diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index a17126af..ebabedcf 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -3,31 +3,31 @@ | Status | draft | | :------------ | :------------------------------------------------------------------------------------- | | **Author(s)** | milstan (milstan@blindnet.io) | -| **Updated** | 2022-06-07 | +| **Updated** | 2022-06-14 | ## Introduction -This document specifies the expected behaviour of Systems implementing [Privacy Request Interchange Vocabulary](./RFC-PRIV.md). It defines actions that the systems MAY undertake with regards to particular Privacy Requests and particular situations. +This document specifies the expected behavior of Systems implementing [Privacy Request Interchange Vocabulary](./RFC-PRIV.md). It defines actions that the systems MAY undertake with regards to particular Privacy Requests and particular situations. -It is a first step towards the specification of the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler), formerly known as Data Rights Compiler in the [High Level Architecture](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture). +It is a first step towards the specification of the [Privacy Compiler](../high-level-architecture#data-rights-compiler), formerly known as Data Rights Compiler in the [High Level Architecture](../high-level-architecture). ## Motivation -While this document is a first step in the definition of the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler), it is not intended to be its formal specification nor to influence the design choices related to formalisation of rules and configurations. +While this document is a first step in the definition of the [Privacy Compiler](../high-level-architecture#data-rights-compiler), it is not intended to be its formal specification nor to influence the design choices related to formalization of rules and configurations. -The purpose of the document is primarily illustrate a possible behaviour Systems (And their Privacy Compilers) MAY implement in response to Privacy Requests, in order to test the completeness of the [Privacy Request Interchange Vocabulary](./RFC-PRIV.md). +The purpose of the document is primarily illustrate a possible behavior Systems (And their Privacy Compilers) MAY implement in response to Privacy Requests, in order to test the completeness of the [Privacy Request Interchange Vocabulary](./RFC-PRIV.md). ## Terminology - -- We use all the terms of the [Privacy Request Interchange Vocabulary](./RFC-PRIV.md) as defined there -- We use the term Privacy Request interchangeably with the (deprecated) terms Rights Request and Data Rights Request as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) -- We use the terms Individual, Person, You, and Data Subject as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) -- We use the term System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) -- We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) -- We use the terms Organization, Submitter, Data Consumer as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) as defined there. - +- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) +- The key word "CAN" denotes ability of someone or something, and is interpreted as "MUST be able to" +- The key words "blindnet devkit", "CCPA", "CPRA", "Capture Fragment", "Component", "Data Capture", "Data Capture Fragment", "Data Consumer", "Data Subject", "DPO", "Fragment", "GDPR", "HIPPA", "Internet User", "Organization", "Privateform", "Privacy Request", "System", "Submitter", "User" are to be interpreted as described in [RFC-Lexicon-2](../lexicon/RFC-Lexicon-2.md) +- Any additional precision about the key words defined in [RFC-Lexicon-2](../lexicon/RFC-Lexicon-2.md), as well as additional key words such as "Consent" and "Legal Base", provided in [High Level Conceptualization](../high-level-conceptualization/) is to be considered normative +- All key words denoting components of [blindnet devkit](../lexicon/RFC-Lexicon-2.md#blindnet-devkit), such as "Capture Component", "Encryption and Access Management Engine", "Privacy Computation Engine", "Privacy Compiler", "Privacy Request Capture Interface", "Customization API", "Data Consumer Interface", "Schemas" and "Storage Component" are to be interpreted as defined in [High Level Architecture](../high-level-conceptualization/) +- Privacy Compiler was formerly known as Data Rights Compiler +- Privacy Request was formerly known as Data Rights Request +- All the concepts, properties and terms listed in the [Proposal](./RFC-PRIV.md#proposal) section of PRIV(Privacy Request Interchange Vocabulary are to be interpreted as defined in [Privacy Request Interchange Vocabulary](./RFC-PRIV.md#proposal) ## Scope of automation @@ -36,7 +36,7 @@ Privacy Requests that are expressed in unambiguous terms, may be fully processed Those that include the keyword "OTHER" or a textual message with more details about the request likely require human intervention. Cf. [different automation scenarios](./scenarios.md#automation) -Systems MAY be configured to treat Privacy Requests eligible for automation with or without human validation. In any case, the role of the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) is to calculate the appropriate action, given particular Privacy Request in a particular situation. +Systems MAY be configured to treat Privacy Requests eligible for automation with or without human validation. In any case, the role of the [Privacy Compiler](../high-level-architecture#data-rights-compiler) is to calculate the appropriate action, given particular Privacy Request in a particular situation. Systems MAY also want to direct certain requests (such as `MODIFY`) to dedicated interfaces that they may already have for Data Subjects to provide and modify their data. @@ -44,7 +44,7 @@ Because of this Systems MUST be able to configure their particular ways of autom ## Configuration and Prerequisites -A [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) serving a particular System MUST have the knowledge of the following key parameters and data structures: +A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a particular System MUST have the knowledge of the following key parameters and data structures: - **Parameters**: a set of parameters defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV) needed to resolve `TRANSPARENCY` requests. @@ -92,7 +92,7 @@ A [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/mast ## Privacy Algebra -For each Data Subject, at all times, the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) maintains an **Eligible Privacy Scope**. +For each Data Subject, at all times, the [Privacy Compiler](../high-level-architecture#data-rights-compiler) maintains an **Eligible Privacy Scope**. For each Data Capture Fragment `selector`, the Privacy Compiler knows the **Intended Privacy Scope**. At the same time the Privacy Compiler knows about a set of Privacy Scope triples that are associated with an active Legal Base (in the **Runtime Maps**) @@ -176,7 +176,7 @@ Now this same Data Subject, makes a Privacy Request. In their request, they don' } ``` -The [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) SHOULD resolve this request by: +The [Privacy Compiler](../high-level-architecture#data-rights-compiler) SHOULD resolve this request by: - Generating a Privacy Request Response with the `GRANTED` Status, ``` @@ -243,7 +243,7 @@ When the System gets this request, the scope of the consent MUST change. The rem - `SHARING` of all `CONTACT` data other then `CONTACT.EMAIL`, for `PERSONALISATION` purposes, and - `STORING` of all `CONTACT` for `PERSONALISATION` purposes -The [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) SHOULD resolve this request by: +The [Privacy Compiler](../high-level-architecture#data-rights-compiler) SHOULD resolve this request by: - Generating a Privacy Request Response with the `GRANTED` Status, ``` @@ -326,7 +326,7 @@ At the time of receiving this request, the System has consent for `STORING` of a Afther processing the `RESTRICT` request, only the consent for `STORING` of all `CONTACT` for `PERSONALISATION` purposes remains valid. -The [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) SHOULD resolve this request by: +The [Privacy Compiler](../high-level-architecture#data-rights-compiler) SHOULD resolve this request by: - Generating a Privacy Request Response with the `GRANTED` Status, ``` @@ -425,14 +425,14 @@ However, the remaining purpose (`SERVICES`) now only allows the System to send e ### Calculating Permissions -Since the [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) maintains the Eligible Privacy Scope at any time, it can (given a Data Capture ID, or a Data Capture Fragment ID) answer whether at that time, a particular data processing operation is permitted. +Since the [Privacy Compiler](../high-level-architecture#data-rights-compiler) maintains the Eligible Privacy Scope at any time, it can (given a Data Capture ID, or a Data Capture Fragment ID) answer whether at that time, a particular data processing operation is permitted. For example, the System can inquire whether a particular data fragment, corresponding to `CONTACT.EMAIL` data category, can be used to invoice the user (processing = `USING`; purpose = `SERVICES`), or whether it can be shared with some other partner system for user profiling (processing = `SHARING`; purpose = `AUTOMATED-INFERENCE`). ## Resolving requests -The [Privacy Compiler](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) evaluates Privacy Request Demands and issues recommendations to the System. The Systems can then be configured to respond to Privacy Requests automatically, blindly following those recommendations (whenever possible), or to await human input just in case. Cf. [different automation scenarios](./scenarios.md#automation) +The [Privacy Compiler](../high-level-architecture#data-rights-compiler) evaluates Privacy Request Demands and issues recommendations to the System. The Systems can then be configured to respond to Privacy Requests automatically, blindly following those recommendations (whenever possible), or to await human input just in case. Cf. [different automation scenarios](./scenarios.md#automation) Privacy Requests MAY need to be processed in the context of different [authentication scenarios](./scenarios.md#authentication) and different [response scenarios](./scenarios.md#response). @@ -543,7 +543,7 @@ When Data Subject ID is provided, the Data Subject is known by the System and au ## Resolving Retention Policies -[Privacy Compilers](https://github.com/blindnet-io/product-management/tree/master/refs/high-level-architecture#data-rights-compiler) SHOULD store and resolve [Retention Policies](./RFC-PRIV.md#retention-policy), as well as to them associated *Events* in **Runtime Maps**. +[Privacy Compilers](../high-level-architecture#data-rights-compiler) SHOULD store and resolve [Retention Policies](./RFC-PRIV.md#retention-policy), as well as to them associated *Events* in **Runtime Maps**. Systems SHOULD define Retention Policies at the time of configuration, and SHOULD cover all Data Categories and Data Capture Fragment `selector`s from the Intended Privacy Scope with at least one Retention Policy. diff --git a/refs/schemas/priv/scenarios.md b/refs/schemas/priv/scenarios.md index 11dda5a8..11759141 100644 --- a/refs/schemas/priv/scenarios.md +++ b/refs/schemas/priv/scenarios.md @@ -13,14 +13,14 @@ The goal of this document is to explore the design implications for implementing ## Terminology - -- We use all the terms of the [Privacy Request Interchange Vocabulary](./RFC-PRIV.md) as defined there -- We use the term Privacy Request interchangeably with the (deprecated) terms Rights Request and Data Rights Request as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) -- We use the terms Individual, Person, You, and Data Subject as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) -- We use the term System as defined in [High Level Conceptualization](https://github.com/blindnet-io/product-management/blob/master/refs/high-level-conceptualization/README.md) -- We use MUST, MUST NOT and MAY, as defined in [IETF RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) -- We use the terms Organization, Submitter, Data Consumer as defined in the [Lexicon](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/privateform-lexicon.csv) as defined there. - +- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) +- The key word "CAN" denotes ability of someone or something, and is interpreted as "MUST be able to" +- The key words "blindnet devkit", "CCPA", "CPRA", "Capture Fragment", "Component", "Data Capture", "Data Capture Fragment", "Data Consumer", "Data Subject", "DPO", "Fragment", "GDPR", "HIPPA", "Internet User", "Organization", "Privateform", "Privacy Request", "System", "Submitter", "User" are to be interpreted as described in [RFC-Lexicon-2](../lexicon/RFC-Lexicon-2.md) +- Any additional precision about the key words defined in [RFC-Lexicon-2](../lexicon/RFC-Lexicon-2.md), as well as additional key words such as "Consent" and "Legal Base", provided in [High Level Conceptualization](../high-level-conceptualization/) is to be considered normative +- All key words denoting components of [blindnet devkit](../lexicon/RFC-Lexicon-2.md#blindnet-devkit), such as "Capture Component", "Encryption and Access Management Engine", "Privacy Computation Engine", "Privacy Compiler", "Privacy Request Capture Interface", "Customization API", "Data Consumer Interface", "Schemas" and "Storage Component" are to be interpreted as defined in [High Level Architecture](../high-level-conceptualization/) +- Privacy Compiler was formerly known as Data Rights Compiler +- Privacy Request was formerly known as Data Rights Request +- All the concepts, properties and terms listed in the [Proposal](./RFC-PRIV.md#proposal) section of PRIV(Privacy Request Interchange Vocabulary are to be interpreted as defined in [Privacy Request Interchange Vocabulary](./RFC-PRIV.md#proposal) ## Authentication ### Anonymous From 76adeaefd912ab699689291bdfa44cf32a8656cd Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 14 Jun 2022 19:37:20 +0200 Subject: [PATCH 172/204] fixing decisions folder readme --- decisions/README.md | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/decisions/README.md b/decisions/README.md index 96f37935..f827e81f 100644 --- a/decisions/README.md +++ b/decisions/README.md @@ -2,7 +2,25 @@ > SMART Goals, Decisions Records and RFCs for blindnet products management -- [NN-XXXX](./NN-XXXX-mmmm.md) - Title +## Decisions Records + +- Yet to be made + +## RFCs + +- [RFC-PRIV](../ref/schemas/priv/RFC-PRIV.md) - Privacy Request Interchange Vocabulary +- [RFC-Lexicon-2](../ref/lexicon/RFC-Lexicon-2.md) - Lexicon used across blindnet devkit documents +- [HLA](../ref/high-level-architecture) - High Level Architecture of blindnet devkit + + +## Old Format + +- [Product Design Choices](../ref/Product-design-choices.md) - Design choices common to all blindnet products +- [Product Design Principles](../ref/Product-design-principles.md) - Design principles that blindnet applies +- [HLC](../ref/high-level-conceptualization) - High Level Conceptualization. Key Concepts of the blindnet devkit + + +## Guidelines For new documents, please use our [templates](https://github.com/blindnet-io/openness-framework/tree/main/DecisionFramework/templates) as basis. For more information, refer to our [Decision Framework](https://github.com/blindnet-io/openness-framework/tree/main/DecisionFramework). From 007e86ef2e363b47c368c8c85fabb2155202fc5c Mon Sep 17 00:00:00 2001 From: milstan Date: Wed, 15 Jun 2022 19:09:34 +0200 Subject: [PATCH 173/204] hippa categories and other standards --- refs/schemas/priv/RFC-PRIV.md | 24 ++++++++++++++++--- .../data-categories/en.data-categories.json | 1 + refs/schemas/priv/examples.md | 24 +++++++++++++++++++ refs/schemas/priv/expected-behavior.md | 8 +++++++ .../priv/json-schema/priv-terms.schema.json | 1 + 5 files changed, 55 insertions(+), 3 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 59906417..96bb37b5 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -87,7 +87,7 @@ The Privacy Request Interchange Vocabulary includes the following: [Demand](#demands), [Demand Restriction](#demand-restrictions) (including [Privacy Scope Restriction](#privacy-scope),[Consent Restriction](#consent-restriction), [Capture Restriction](#capture-restriction), [Date Range](#date-range), [Provenance Restriction](#provenance-restriction), [Data Reference Restriction](#data-reference-restriction)), [Privacy Request](#privacy-request), -[Privacy Request Response](#privacy-request-response), [Privacy Scope](#privacy-scope)(and its dimensions: *Data Category*, *Processing Category* and *Purpose*), [Provenance](#provenance), +[Privacy Request Response](#privacy-request-response), [Privacy Scope](#privacy-scope)(and its dimensions: *Data Category*, *Processing Category* and *Purpose*), [Provenance](#provenance), [Retention Policy](#retention-policy), [Data Subject Identity](#decentralized-identity-of-data-subjects) @@ -175,7 +175,7 @@ Privacy Scope = (Data Categories) x (Categories of Processing) x (Purposes of Pr | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-categories` | 0-* | `AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, `UID.ID`, `UID.USER-ACCOUNT` , `UID.SOCIAL-MEDIA` , `OTHER-DATA` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | +| `data-categories` | 0-* | `AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, `UID.ID`, `UID.IP`, `UID.USER-ACCOUNT` , `UID.SOCIAL-MEDIA` , `OTHER-DATA` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | When several values are given, Systems MUST interpret the `data-category` dimension as a union of all the categories indicated. @@ -742,7 +742,7 @@ Their support for purposes, and per-purpose consents is limited. Yet, we want to be compatible with them. -Still the question remains, should we fully reuse what they have built (in terms of categories of data) and try to extend it? My view is that that would limit our ability to offer automation in many use-cases. +We examine, in [examples.md](./examples.md#ethyca-data-categories) how users of Ethyca can map their matadata PRIV terms. ### ISO 19944 @@ -750,6 +750,24 @@ There is an ISO standard for data categories and processing categories. They are However, we might want to allow developers to use our format (properties and concepts) with ISO 19944 categories instead of our terms. +### HL7 Standards + +The [HL7 Version 3 Standard: Role-based Access Control Healthcare Permission Catalog](http://www.hl7.org/documentcenter/private/standards/v3/V3_HACC_R3_2016_R2021.pdf) offers terms for describing a variety of: +- Operations: OPERATE, CREATE, READ, UPDATE, APPEND, ANNOTATE, DELETE, PURGE, EXECUTE, REPRODUCE, COPY, BACKUP, RESTORE, EXPORT, PRINT, DERIVE, CONVERT, EXCERPT, TRANSLATE, MOVE, ARCHIVE, REPLACE, FORWARD, TRANSFER, SIGN, VERIFY, NOTARIZE, ALARM +- Permissions (associating those Processing Categories with different types of information objects.) + +Users of this standard SHOULD be able to easily associate those Operations with PRIV Processing Categories, and treat them as subcategories according to the DOT NOTATION. + +### HIPAA Identifiers + +[HIPPA](https://www.hhs.gov/hipaa) regulation introduces 18 categories of Protected Health Information: +Name, Address (all geographic subdivisions smaller than state, including street address, city county, and zip code), All elements (except years) of dates related to an individual (including birthdate, admission date, discharge date, date of death, and exact age if over 89), Telephone numbers, Fax number, Email address, Social Security Number, Medical record number, Health plan beneficiary number, Account number, Certificate or license number, Vehicle identifiers and serial numbers, including license plate numbers, Device identifiers and serial numbers, Web URL, Internet, Protocol (IP) Address, Finger or voice print, Photographic image - Photographic images are not limited to images of the face, Any other characteristic that could uniquely identify the individual. + +We examine, in [examples.md](./examples.md#hippa) how those categories can be mapped to PRIV's Data Categories. + + + + ## See also This document comes with the following support documents: diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index e8b09aec..be5f71b0 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -34,5 +34,6 @@ "UID.ID": "Official identification number of proof of identity", "UID.USER-ACCOUNT": "Data about a person's account or profile on the first-party website/app and its contents", "UID.SOCIAL-MEDIA": "Data about a person's account or profile from a social media website/app or other third party service", + "UID.IP" : "IP address of a person", "OTHER-DATA": "Other data" } diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 900bfca3..5522f473 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -335,6 +335,30 @@ Transcend proposes the following [data categories](https://github.com/transcend- | OTHER | A specific type of information not covered by the above categories | data-category:`OTHER-DATA` use `message` to specify| | UNSPECIFIED | The type of information is not explicitly stated or unclear| data-category:`OTHER-DATA` use `message` to specify| +#### Transcend + +The following correspondence of [HIPPA](https://www.hhs.gov/hipaa) categories can be used: + +| HIPPA Category | PRIV Data Category | +| -------------- | ------------------ | +| Name | `NAME` | +| Address (all geographic subdivisions smaller than state, including street address, city county, and zip code) | `CONTACT.ADDRESS` | +| All elements (except years) of dates related to an individual (including birthdate, admission date, discharge date, date of death, and exact age if over 89) | `DEMOGRAPHIC.AGE` for birth date, death date, recommended `selector` for admission date `BEHAVIOR.ACTIVITY.ADMISSION`, discharge date `BEHAVIOR.ACTIVITY.DISCHARGE`| +| Telephone numbers | `CONTACT.PHONE` | +| Fax number | recommended `selector` `CONTACT.FAX` | +| Email address | `CONTACT.EMAIL` | +| Social Security Number | `UID.ID` | +| Medical record number | recommended `selector` `HEALTH.RECORD`| +| Health plan beneficiary number | recommended `selector` `HEALTH.PLAN-BENEFICIARY-NUMBER` | +| Account number | `UID.USER-ACCOUNT` | +| Certificate or license number | recommended `selector` `UID.ID.LICENCE-NUMBER` | +| Vehicle identifiers and serial numbers, including license plate numbers | recommended `selector` `UID.ID.VEHICULE-ID` | +| Device identifiers and serial numbers | `DEVICE` | +| Web URL | `UID.USER-ACCOUNT` or `selector` `UID.WEB-URL` | +| Internet Protocol (IP) Address | `UID.IP` | +| Finger or voice print | `BIOMETRIC` | +| Photographic image - Photographic images are not limited to images of the face. | `IMAGE` | +| Any other characteristic that could uniquely identify the individual | `UID` | ## Questions and Discussion Topics diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index ebabedcf..b7ebaad5 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -61,6 +61,14 @@ A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a - a Purpose Each **Known Selector** MUST be included in the The Intended Privacy Scope. +> **Note** +> +> In addition to `selectors` that are a native mechanism for extending Data Categories with System-specific subcategories, it is necessary to allow Systems to also extend Processing Categories and Purposes, with potentially System-specific terms following PRIV's DOT NOTATION. +> +> This is necessary for interoperability with the specific Processing Categories of the [HL7 Standards](./RFC-PRIV.md#hl7-standards) +> + + - *Legal Bases*: For each **Privacy Scope Triple** from the **Intended Privacy Scope**, one or more [Legal Bases](./RFC-PRIV.md#legal-bases) - *Corresponding Systems*: A map of Other Systems with which data is being exchanged. For each System The Privacy Compiler MUST know if they are an `ORGANISATION` or `PARTNERS` System, and have a way to uniquely identify and address them (see [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV), [Working with Provenance](#working-with-provenance)) diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json index ecfe2622..0b292567 100644 --- a/refs/schemas/priv/json-schema/priv-terms.schema.json +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -69,6 +69,7 @@ "RELATIONSHIPS", "UID", "UID.ID", + "UID.IP", "UID.USER-ACCOUNT", "UID.SOCIAL-MEDIA", "OTHER-DATA", From 5ee11e6570d21ab2ea3f33c3c12b865f962a99cd Mon Sep 17 00:00:00 2001 From: milstan Date: Wed, 15 Jun 2022 19:56:29 +0200 Subject: [PATCH 174/204] possibility for extending the set of terms --- refs/schemas/priv/RFC-PRIV.md | 37 +++++++++++++++++--------- refs/schemas/priv/examples.md | 2 +- refs/schemas/priv/expected-behavior.md | 6 ++--- 3 files changed, 29 insertions(+), 16 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 96bb37b5..2934d957 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -93,7 +93,7 @@ The Privacy Request Interchange Vocabulary includes the following: - Properties: `action`, `after`, `answers`, `capture-id`, `capture-ids`, `consent-id`,`consent-ids`, `data-subject`,`data`, `data-categories`, `data-reference`, `data-subject`, `date`,`demand-id`, `demands`, `dsid`, `dsid-schema`, `duration`, `expires`,`fragment-id`, `fragments`, `from`, `includes`, `in-response-to`,`lang`, `legal-base`, `message`, `motive`, `policy-type`, `processing-categories`, `provenance, ``provenance-category`, `purposes`, `replaces`, `response-id`, `restrictions`, `request-id`, `replaced-by`, `retention`, `requested-action`, `scope`, `selector`, `status`, `system`, `target`, `to`, `vocab` -- Terms: all terms included in [the dictionary](./dictionary) +- TERMS: all terms included in [the dictionary](./dictionary) ### Privacy Request @@ -175,7 +175,7 @@ Privacy Scope = (Data Categories) x (Categories of Processing) x (Purposes of Pr | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-categories` | 0-* | `AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, `UID.ID`, `UID.IP`, `UID.USER-ACCOUNT` , `UID.SOCIAL-MEDIA` , `OTHER-DATA` or any [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | +| `data-categories` | 0-* | One of {`AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, `UID.ID`, `UID.IP`, `UID.USER-ACCOUNT` , `UID.SOCIAL-MEDIA` , `OTHER-DATA`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation) including any [Data Capture Fragment](#data-capture-fragments) `selector`| When several values are given, Systems MUST interpret the `data-category` dimension as a union of all the categories indicated. @@ -191,7 +191,7 @@ In the absence of indication of any `data-category` dimension, Systems MUST inte | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `processing-categories` | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `USING`, `OTHER-PROCESSING`} | +| `processing-categories` | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `USING`, `OTHER-PROCESSING`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation) | When several values are given, Systems MUST interpret the `processing-categories` dimension as a union of all the processing categories indicated. @@ -203,7 +203,7 @@ In the absence of indication of any `processing-categories` dimension, Systems M | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `purposes` | 0-* | `ADVERTISING`, `COMPLIANCE`, `EMPLOYMENT`, `JUSTICE`, `MARKETING`, `MEDICAL`, `PERSONALISATION`, `PUBLIC-INTERESTS`, `RESEARCH`, `SALE`, `SECURITY`, `SERVICES`, `SERVICES.ADDITIONAL-SERVICES`, `SERVICES.BASIC-SERVICE`, `SOCIAL-PROTECTION`, `TRACKING`, `VITAL-INTERESTS`, `OTHER-PURPOSE` | +| `purposes` | 0-* | One of {`ADVERTISING`, `COMPLIANCE`, `EMPLOYMENT`, `JUSTICE`, `MARKETING`, `MEDICAL`, `PERSONALISATION`, `PUBLIC-INTERESTS`, `RESEARCH`, `SALE`, `SECURITY`, `SERVICES`, `SERVICES.ADDITIONAL-SERVICES`, `SERVICES.BASIC-SERVICE`, `SOCIAL-PROTECTION`, `TRACKING`, `VITAL-INTERESTS`, `OTHER-PURPOSE`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation) | When several values are given, Systems MUST interpret the `purposes` restriction as a union of all the purposes indicated. @@ -370,7 +370,7 @@ A Data Capture concerns one and only one Data Subject who MAY be identified by m | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `fragment-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `selector` | 1 | a string used to uniquely identify a data field (in the System's data model) to which the fragment corresponds | +| `selector` | 1 | a string used to uniquely identify a data field (in the System's data model) to which the fragment corresponds. MUST be a subcategory of a *Data Category* and MUST be defined according to [Term Dot Notation](#term-dot-notation) | | `date` | 1 | Date and Time when data was Captured was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the fragment SHOULD be interpreted as unlimited | | `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | @@ -489,9 +489,9 @@ The reason for using UUDIs is to allow Systems to independently generate globall Having a public ledger for UUDIs MAY be considered for Consents and Data Captures, but serious implications to Data Subject exposure MUST also be considered. However, the design MUST be compatible with building a public decentralised ledger. -### Term Syntax +### Term Dot Notation -The vocabulary defines TERMS to express different aspects of Pravacy Reqeust, Data Captures, Consents etc. +The vocabulary defines TERMS to express different aspects of Privacy Request, Data Captures, Consents etc. TERMS follow Term Dot Notation (TDN), defined using the following ABNF (cf. [FRC5234](https://www.rfc-editor.org/info/rfc5234)): ``` @@ -508,10 +508,24 @@ E.g. the following statements are equivalent: - `A.B`, `A` - `A` -The lists of TERMS SHOULD be designed in such a way to be: +PRIV includes a set of TERMS, provided in [the dictionary](./dictionary). + +This list is designed with the aim to be: - **Unambiguous** : The developer using the schema knows without ambiguity which one (of which ones) to use in any given situation, AND - **Complete** : They allow to express the totality of possible needs in the context of a user wanting to [regulate their privacy/connectedness](https://github.com/blindnet-io/product-management/blob/dogma/refs/notion-of-privacy/notion-of-privacy.md), as well as the totality of requests defined by the [supported legilsation](#supported-legilsation). +Implementing Systems SHOULD be able to interpret and operate with all the TERMS. + +#### Extending TERMS + +When needed, Systems MAY include support for additional terms, not included in [the dictionary](./dictionary). +Such additional terms MUST be subcategories of one of the TERMS, and they MUST follow the same syntax of the [Term Dot Notation](#term-dot-notation). + +Such Systems MAY manifest specific behavior in reaction to those additional terms, yet they may end-up communicating them with other Systems that only support the TERMS from [the dictionary](./dictionary). +In that case, Systems MUST interpret the additional terms, as being equivalent to the first super-category that they support. + +In that way, interoperability can always be expected at the level of TERMS. + ### Extending the vocabulary Systems MAY specify the vocabulary used to express data being exchanged. The value indicating this version of this vocabulary is `priv.1.0`. @@ -520,9 +534,10 @@ Systems MAY specify the vocabulary used to express data being exchanged. The val | --------------- | ------ | -------------------- | | `vocab` | 0-1 | The name of the vocabulary used to describe data. In absence of indication `priv.1.0` is assumed. | -This vocabulary can be extended by defining a new identifier for the new vocabulary. New vocabularies MAY include other vocabularies as long as their sets of concepts, properties and terms are disjoint. +When [addition additional terms](#extending-terms) is not sufficient, and additional Concepts or Properties are needed, it is possible to extend the vocabulary. -In addition, the Systems implementing PRIV can simply define their own subcategories of terms (not properties not concepts) defined by PRIV. This might be useful for their own internal operation, however the interoperability with other system can only be expected at the level of the particular, shared, version of the vocabulary. +This vocabulary can be extended by defining a new identifier for the new vocabulary. +New vocabularies MAY include other vocabularies as long as their sets of concepts, properties and terms are disjoint. ## Examples @@ -658,8 +673,6 @@ Maybe there are reasons for it (although similar notations are used for packages A candidate for a standard notation is the [URN](https://datatracker.ietf.org/doc/html/rfc8141). It is - less pretty (still human-readable), + standard, = equally searchable, = equally bad for storage and time. However we would still need to specify our own notation of the part of the URN that we want to customise. So the advantages are limited (if any). -Or if none (which would be surprising) we could define our syntax using [Backus-Naur Form](https://datatracker.ietf.org/doc/html/rfc4234). Advantage: geeks will love us. -We would need to ensure: that any string used on any side of any dot, it is not contained in any other string not containing a dot. Disadvantage: using a non-standard notation we expose ourselves to unpredictable risks. ### Schema elegance and modularity diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 5522f473..41efeb1d 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -337,7 +337,7 @@ Transcend proposes the following [data categories](https://github.com/transcend- #### Transcend -The following correspondence of [HIPPA](https://www.hhs.gov/hipaa) categories can be used: +The following correspondence of [data categories](https://www.luc.edu/its/aboutits/itspoliciesguidelines/hipaainformation/18hipaaidentifiers/) needed for [HIPPA](https://www.hhs.gov/hipaa) compliance can be used: | HIPPA Category | PRIV Data Category | | -------------- | ------------------ | diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index b7ebaad5..e8dd4a0f 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -57,13 +57,13 @@ A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a - **Intended Privacy Scope** : A set of **Privacy Scope Triple**s that describe the usage the System is likely to make with data. Each triple consists of: - a `selector` (or Data Category implying every `selector` used within that Data Category) - - a Processing Category that the System is likely to perform on that data - - a Purpose + - a Processing Category (or any of their subcategories defined according to [Term Dot Notation](./RFC-PRIV.md#term-dot-notation)) that the System is likely to perform on that data + - a Purpose (or any of their subcategories defined according to [Term Dot Notation](./RFC-PRIV.md#term-dot-notation) Each **Known Selector** MUST be included in the The Intended Privacy Scope. > **Note** > -> In addition to `selectors` that are a native mechanism for extending Data Categories with System-specific subcategories, it is necessary to allow Systems to also extend Processing Categories and Purposes, with potentially System-specific terms following PRIV's DOT NOTATION. +> In addition to `selectors` that are a native mechanism for extending Data Categories with System-specific subcategories, it is necessary to allow Systems to also extend Processing Categories and Purposes, with potentially System-specific terms following PRIV's [Term Dot Notation](./RFC-PRIV.md#term-dot-notation). > > This is necessary for interoperability with the specific Processing Categories of the [HL7 Standards](./RFC-PRIV.md#hl7-standards) > From 11409d88e94d4b0ca1452d1ad8ef30b704d26427 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 16 Jun 2022 13:52:01 +0200 Subject: [PATCH 175/204] restructuring and typo fixing --- refs/schemas/priv/RFC-PRIV.md | 261 ++++++++++------- .../priv/dictionary/actions/en.actions.json | 2 +- .../priv/dictionary/purposes/en.purposes.json | 2 +- .../priv/dictionary/targets/en.targets.json | 8 +- refs/schemas/priv/examples.md | 262 +++++++++--------- refs/schemas/priv/expected-behavior.md | 158 ++++++----- .../priv/json-schema/priv-terms.schema.json | 6 +- refs/schemas/priv/scenarios.md | 18 +- 8 files changed, 399 insertions(+), 318 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 2934d957..184c7bab 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -60,7 +60,7 @@ With this design we seek: - Exhaustivity with regards to situations we need to support in response to [supported legislation](#supported-legislation) yet Extensibility in case new situations arise in the future. - Highly normative minimal specification, using as much as possible the [Plain Language](https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf) while at the same time making clear references to the (often misfortunate) language of the [supported legislations](#supported-legislation) - Limit, as much as possible, the possibility of representing the same meaning in more than one way -- Decentralised design compatible with both the Internet's Client-Server Architecture and Metaverse/Web3 Architecture +- Decentralized design compatible with both the Internet's Client-Server Architecture and Metaverse/Web3 Architecture ### Design Choices @@ -79,7 +79,7 @@ We have made the following choices: The Privacy Request Interchange Vocabulary includes the following: -- Concepts: +- **Concepts**: [Consent](#consent), [Data Capture](#data-capture), [Data Capture Fragment](#data-capture-fragments), @@ -87,13 +87,40 @@ The Privacy Request Interchange Vocabulary includes the following: [Demand](#demands), [Demand Restriction](#demand-restrictions) (including [Privacy Scope Restriction](#privacy-scope),[Consent Restriction](#consent-restriction), [Capture Restriction](#capture-restriction), [Date Range](#date-range), [Provenance Restriction](#provenance-restriction), [Data Reference Restriction](#data-reference-restriction)), [Privacy Request](#privacy-request), -[Privacy Request Response](#privacy-request-response), [Privacy Scope](#privacy-scope)(and its dimensions: *Data Category*, *Processing Category* and *Purpose*), [Provenance](#provenance), +[Privacy Request Response](#privacy-request-response), +[Privacy Scope](#privacy-scope)(and its dimensions: *Data Category*, *Processing Category* and *Purpose*), [Provenance](#provenance), [Retention Policy](#retention-policy), [Data Subject Identity](#decentralized-identity-of-data-subjects) -- Properties: `action`, `after`, `answers`, `capture-id`, `capture-ids`, `consent-id`,`consent-ids`, `data-subject`,`data`, `data-categories`, `data-reference`, `data-subject`, `date`,`demand-id`, `demands`, `dsid`, `dsid-schema`, `duration`, `expires`,`fragment-id`, `fragments`, `from`, `includes`, `in-response-to`,`lang`, `legal-base`, `message`, `motive`, `policy-type`, `processing-categories`, `provenance, ``provenance-category`, `purposes`, `replaces`, `response-id`, `restrictions`, `request-id`, `replaced-by`, `retention`, `requested-action`, `scope`, `selector`, `status`, `system`, `target`, `to`, `vocab` +- **Properties**: `action`, `after`, `answers`, `capture-id`, `capture-ids`, `consent-id`,`consent-ids`, `data-subject`,`data`, `data-categories`, `data-reference`, `data-subject`, `date`,`demand-id`, `demands`, `dsid`, `dsid-schema`, `duration`, `expires`,`fragment-id`, `fragments`, `from`, `includes`, `in-response-to`,`lang`, `legal-base`, `message`, `motive`, `policy-type`, `processing-categories`, `provenance, `provenance-category`, `purposes`, `replaces`, `response-id`, `restrictions`, `request-id`, `replaced-by`, `retention`, `requested-action`, `scope`, `selector`, `status`, `system`, `target`, `to`, `vocab` -- TERMS: all terms included in [the dictionary](./dictionary) +- **Terms**: all terms included in the [dictionary](./dictionary), and particularly: + + - **Action Terms**: {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANIZATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER-DEMAND`} or any of their subcategories defined using the [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/actions](./dictionary/actions).* + + - **Data Category Terms**: {`AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, `UID.ID`, `UID.IP`, `UID.USER-ACCOUNT` , `UID.SOCIAL-MEDIA` , `OTHER-DATA`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation) including any [Data Capture Fragment](#data-capture-fragments) `selector`s. *See definitions in the [dictionary/data-categories](./dictionary/data-categories).* + + - **Processing Category Terms**: {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `USING`, `OTHER-PROCESSING`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/processing-categories](./dictionary/processing-categories).* + + - **Purposes Terms**: {`ADVERTISING`, `COMPLIANCE`, `EMPLOYMENT`, `JUSTICE`, `MARKETING`, `MEDICAL`, `PERSONALIZATION`, `PUBLIC-INTERESTS`, `RESEARCH`, `SALE`, `SECURITY`, `SERVICES`, `SERVICES.ADDITIONAL-SERVICES`, `SERVICES.BASIC-SERVICE`, `SOCIAL-PROTECTION`, `TRACKING`, `VITAL-INTERESTS`, `OTHER-PURPOSE`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/purposes](./dictionary/purposes).* + + - **Provenance Terms**: {`DERIVED`, `TRANSFERRED`, `USER`, `USER.DATA-SUBJECT`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/provenance](./dictionary/provenance).* + + - **Target Terms**: {`ORGANIZATION`, `PARTNERS`, `SYSTEM`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/targets](./dictionary/targets).* + + - **Target Direction Terms**: {`PARTNERS.DOWNWARD`, `PARTNERS.UPWARD`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/targets](./dictionary/targets).* + + - **Status Terms**: {`GRANTED`, `DENIED`, `PARTIALLY-GRANTED`, `UNDER-REVIEW`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/statuses](./dictionary/statuses).* + + - **Motive Terms**: {`IDENTITY-UNCONFIRMED`, `LANGUAGE-UNSUPPORTED`, `VALID-REASONS`, `IMPOSSIBLE`, `NO-SUCH-DATA`, `REQUEST-UNSUPPORTED`, `USER-UNKNOWN`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/motives](./dictionary/motives).* + + - **Boolean Terms**: {`YES`, `NO`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/boolean](./dictionary/boolean).* + + - **Legal Base Terms**: {`CONTRACT`, `CONSENT`, `LEGITIMATE-INTEREST`, `NECESSARY`, `OTHER-LEGAL-BASE`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/legal-bases](./dictionary/legal-bases).* + + - **Retention Terms**: {NO-LONGER-THAN, "NO-LESS-THAN"} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/retentions](./dictionary/retentions).* + + - **Event Terms**: {`CAPTURE-DATE`,`RELATIONSHIP-END`, `SERVICE-END`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/events](./dictionary/events).* ### Privacy Request @@ -101,7 +128,7 @@ Data Subject is the author of a Privacy Request. | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-subject` | 1-* | [Data Subject Identities](#decentralised-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| +| `data-subject` | 1-* | [Data Subject Identities](#decentralized-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| A Privacy Request is made by one and only one Data Subject. @@ -130,90 +157,93 @@ A Demand is a concrete action that the user requests. | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `demand-id` | 1 | Unique ID for referring to this demand in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `action` | 1 | Unique value. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER-DEMAND`} | +| `action` | 1 | Unique value. One of the [Action Terms](#actions) | | `message` | 0-1 | Optional string comment, motivation or explanation of Demand | | `lang` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | -| `data` | 0-* | Optionally concrete data (Format **TBD**) | +| `data` | 0-* | Optionally concrete data | The key element that defines the nature of the Demand is the `action`. A Demand MUST have one and only one `action`. -Actions are hierarchical. -Their relationships are denoted with a dot "." separating two actions, the more general one being written on the left. -`TRANSPARENCY` includes `TRANSPARENCY.WHERE`. -When `TRANSPARENCY` is demanded, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` were demanded. +Actions are hierarchical, and defined using the [Term Dot Notation](#term-dot-notation). + +E.g. when `TRANSPARENCY` is demanded, Systems MUST interpret the demand as if all the subcategories of `TRANSPARENCY` were demanded. Certain Demands MAY include data, such as a `MODIFY` Demand where new data MAY be provided by the Data Subject. ##### Demand Restrictions The `action` that the Data Subject requests with a particular Demand MUST be interpreted in the context of restrictions. -A Demand MAY refer to only certain Privacy Scope (categories of data, certain types of processing, certain purposes of processing) or may only refer to particular Consents (e.g. those that the Data Subject wants to revoke) or to particular Data Captures (e.g. those that the Data Subject want to delete). + +A Demand MAY refer to only certain Privacy Scope (Data Categories, certain Processing Categories, certain Purposes of processing) or may only refer to particular Consents (e.g. those that the Data Subject wants to revoke) or to particular Data Captures (e.g. those that the Data Subject want to delete). | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `restrictions` | 0-* | An optional array of restriction objects, each being one of [Privacy Scope](#privacy-scope), [Consent Restriction](#consent-restriction), [Capture Restriction](#capture-restriction), [Date Range](#date-range), [Provenance Restriction](#provenance-restriction), [Data Reference Restriction](#data-reference-restriction)| -When more than one restriction is specified, the System MUST interpret the Demand as referring to the intersection of restrictions. For example let us consider a `DELETE` demand having two restrictions: `LOCATION` `data-category` as Privacy Scope, and from 11th to 15th of June 2022 as Date Range. The System SHOULD understand that the Data Subject wants the System to delete only their location data processed in this precise period. +When more than one restriction is specified, the System MUST interpret the Demand as referring to the **intersection of restrictions**. +For example let us consider a `DELETE` demand having two restrictions: `data-category`:`LOCATION` as Privacy Scope, and from 11th to 15th of June 2022 as Date Range. +The System SHOULD understand that the Data Subject wants the System to delete only their location data processed in this precise period. A demand with multiple restrictions MUST NOT have more than one restriction of the same type. ###### Privacy Scope -A Privacy Scope MAY be defined by three dimensions: Data Categories, Categories of Processing, and Purposes of Processing. -A Data Subject can formulate a Demand or give Consent within a particular Privacy Scope, e.g. only referring to `COLLECTING` (Category of Processing) `CONTACT` data (Category of Data) for `PERSONALISATION` (Purpose of Processing). +A Privacy Scope is be defined by three dimensions: Data Categories, Categories of Processing, and Purposes of Processing. + +A Data Subject can formulate a Demand or give Consent within a particular Privacy Scope, e.g. only referring to `COLLECTING` (Category of Processing) `CONTACT` data (Category of Data) for `PERSONALIZATION` (Purpose of Processing). Privacy Scope can be understood as a vector space defined by those three dimensions. ``` -Privacy Scope = (Data Categories) x (Categories of Processing) x (Purposes of Processing) +Privacy Scope = (Data Categories) x (Processing Category) x (Purposes of Processing) ``` +It is possible to specify a Privacy Scope by referring to only one or two, or none (out of those tree) dimensions. +An unspecified dimension MUST be interpreted as designating the totality of Terms that are eligible as one of its Expected values. + +E.g. A Privacy Scope defined only by `data-categories`: `CONTACT` is interpreted as any [Processing](#processing-categories), for any [Purpose](#purpose) or any data marked with `CONTACT` or any of its subcategories including `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`. +This Privacy Scope includes Privacy Scope Triples that are all possible combinations of those known subcategories (including [Data Capture Fragment](#data-capture-fragments) `selectors`) of `CONTACT` with all known [Processing](#processing-categories) and with all known [Purpose Terms](#purpose). + *Data Categories* | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-categories` | 0-* | One of {`AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, `UID.ID`, `UID.IP`, `UID.USER-ACCOUNT` , `UID.SOCIAL-MEDIA` , `OTHER-DATA`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation) including any [Data Capture Fragment](#data-capture-fragments) `selector`| +| `data-categories` | 0-* | [Data Category Terms](#data-categories)| + +When several values are given, Systems MUST interpret the `data-categories` dimension as a **union** of all the categories indicated. -When several values are given, Systems MUST interpret the `data-category` dimension as a union of all the categories indicated. +E.g. if `GENETIC` and `FINANCIAL` are specified, the `data-categories` dimension includes all known subcategories of those two [Data Category Terms](#data-categories), including `FINANCIAL.BANK-ACCOUNT`. If the the System knows of a system-specific subcategory `GENERIC.GENOME`, then the `data-categories` dimension includes that as well. -Categories are organized as a hierarchy, denoted with a dot ".", the more general category being written on the left. -E.g. the following two `data-category` restrictions are equivalent: -- `CONTACT`,`CONTACT.EMAIL` -- `CONTACT` +In the absence of indication of any `data-categories` dimension, Systems MUST interpret the Privacy Scope as being related to all and any known [Data Category](#data-categories). -In the absence of indication of any `data-category` dimension, Systems MUST interpret the Privacy Scope as being related to all categories of data. -[A list of eligible `data-category` values with corresponding user-facing descriptions is provided](dictionary/data-categories/) for convenience. -*Categories of Processing* +*Processing Categories* | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `processing-categories` | 0-* | One of {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `USING`, `OTHER-PROCESSING`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation) | +| `processing-categories` | 0-* | [Processing Category Terms](#processing-categories) | -When several values are given, Systems MUST interpret the `processing-categories` dimension as a union of all the processing categories indicated. +When several values are given, Systems MUST interpret the `processing-categories` dimension as a **union** of all the processing categories indicated. -In the absence of indication of any `processing-categories` dimension, Systems MUST interpret the Demand as being related to all and any `processing-categories` of treatment. +E.g. if `STORING` and `GENERATING` are specified, the `processing-categories` dimension includes all known subcategories of those two [Processing Category Terms](#processing-categories). If the the System knows of a system-specific subcategory `GENERATING.TRANSLATING`, then the `processing-categories` dimension includes that as well. + +In the absence of indication of any `processing-categories` dimension, Systems MUST interpret the Demand as being related to all and any known [Processing Category](#processing-categories). -[A list of eligible `processing-categories` values with corresponding user-facing descriptions is provided](dictionary/processing-categories/) for convenience. *Purposes of Processing* | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `purposes` | 0-* | One of {`ADVERTISING`, `COMPLIANCE`, `EMPLOYMENT`, `JUSTICE`, `MARKETING`, `MEDICAL`, `PERSONALISATION`, `PUBLIC-INTERESTS`, `RESEARCH`, `SALE`, `SECURITY`, `SERVICES`, `SERVICES.ADDITIONAL-SERVICES`, `SERVICES.BASIC-SERVICE`, `SOCIAL-PROTECTION`, `TRACKING`, `VITAL-INTERESTS`, `OTHER-PURPOSE`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation) | - -When several values are given, Systems MUST interpret the `purposes` restriction as a union of all the purposes indicated. +| `purposes` | 0-* | [Purposes Terms](#purposes) | -Purposes are organised as a hierarchy, denoted with a dot ".", the more general purpose being written on the left. E.g. the following two `pruposes` restrictions are equivalent: -- `SERVICES`,`SERVICES.BASIC-SERVICE` -- `SERVICES` +When several values are given, Systems MUST interpret the `purposes` restriction as a **union** of all the purposes indicated. -In the absence of indication of any `purpose` restriction, Systems MUST interpret the Demand as being related to all and any purpose of treatment. +E.g. if `RESEARCH` and `SERVICES` are specified, the `purposes` dimension includes all known subcategories of those two [Purposes Terms](#purposes) including `SERVICES.BASIC-SERVICE` and `SERVICES.ADDITIONAL-SERVICES`. If the the System knows of a system-specific subcategory `RESEARCH.MEDICAL-RESEARCH`, then the `purposes` dimension includes that as well. -[A list of eligible `purposes` values with corresponding user-facing descriptions is provided](./dictionary/purposes/) for convenience. +In the absence of indication of any `purpose` restriction, Systems MUST interpret the Demand as being related to all and any known [Purpose](#purposes). ###### Consent Restriction @@ -227,13 +257,13 @@ When one or more `consent-ids` are indicated, Systems MUST interpret the Demand ###### Capture Restriction -A Demand can be restricted to particular Capture ID(s). For example, a Data Subject to delete a particular data, they indicate the data capture concerned by their Demand. +A Demand can be restricted to particular Capture ID(s). For example, a Data Subject to delete a particular data, they indicate the [Data Capture](#data-capture) concerned by their Demand. | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `capture-ids` | 0-* | Optional array of Data Capture IDs to indicate that the Demand (e.g. a `DELETE` Demand) is restricted to data captured within particular Data Captures. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | +| `capture-ids` | 0-* | Optional array of [Data Capture](#data-capture) IDs to indicate that the Demand (e.g. a `DELETE` Demand) is restricted to data captured within particular Data Captures. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -When one or more `capture-ids` are indicated, Systems MUST interpret the demand all related to all the data captured as part of those Data Captures. +When one or more `capture-ids` are indicated, Systems MUST interpret the demand all related to (the **union** of) all the data captured as part of those Data Captures. ###### Date Range @@ -244,7 +274,6 @@ A Demand can be restricted to particular Date Range, for example the Data Subjec | `from` | 0-* | Date and Time when the Date Range starts in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `to` | 0-* | Date and Time when the Date Range ends in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | - A Date Range defined by only one of the {`from`, `to`} properties indicates a period of time after or before a certain date, unbounded on the other end. ###### Provenance Restriction @@ -253,12 +282,14 @@ A Demand can be restricted to particular `provenance-category`, for example the | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `provenance-category` | 1 | one of {`DERIVED`, `TRANSFERRED`, `USER`, `USER.DATA-SUBJECT`} | -| `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | +| `provenance-category` | 1 | [Provenance Terms](#provenance-categories) | +| `target` | 0-1 | [Target Terms](#targets). In absence of indication `SYSTEM` is assumed | + +Optionally the Provenance Restriction may also include a particular [Target](#targets). -Optionally the Provenance Restriction may also include a particular [Target](#targets). E.g. the Data Subject might demand to have `ACCESS` to data that was `TRANSFERRED` by partner Systems (`target`:`PARTNERS`). +E.g. the Data Subject might demand to have `ACCESS` to data that was `TRANSFERRED` by partner Systems (`target`:`PARTNERS`). -[A list of eligible `provenance-category` values with corresponding user-facing descriptions is provided](./dictionary/provenance/) for convenience. +Not to be confused with [Provenance](#provenance). ###### Data Reference Restriction @@ -276,11 +307,12 @@ It is therefore convenient for a Data Subject to be able to formulate Privacy Re | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `PARTNERS.DOWNWARD`, `PARTNERS.UPWARD`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | +| `target` | 0-1 | [Target Terms](#targets) or [Target Direction Terms](#target-directions) + In absence of indication `SYSTEM` is assumed | `SYSTEM` refers to the particular System with which the Data Subject is in direct interaction while making the Privacy Request (or giving the Consent). -`ORGANISATION` includes, in addition to the `SYSTEM`, all other Systems belonging to the same Organization. Those are understood as being a part of the same First-Party Set (**TODO** ref and compatibility check) +`ORGANIZATION` includes, in addition to the `SYSTEM`, all other Systems belonging to the same Organization. In the context of Systems that are essentially wbesites, the `ORGANIZATION` Term SHOULD be understood as all Systems being a part of the same [First-Party Set](https://github.com/WICG/first-party-sets). `PARTNERS.DOWNWARD` includes, in addition to the `SYSTEM`, and to all other Systems belonging to the same Organization, all other Systems belonging to Organizations with which the data about the Data Subject has been shared. @@ -294,14 +326,14 @@ Let us imagine the following situation: System A gave information about the Data When System B receives a Privacy Request having `target` value: - `SYSTEM`, it SHOULD NOT transfer it to any other system. -- `ORGANISATION` for a `target`, it MUST transfer it to all other systems operated by the same Organization (System D in our example). +- `ORGANIZATION` for a `target`, it MUST transfer it to all other systems operated by the same Organization (System D in our example). - `PARTNERS.DOWNWARD` it MUST also send it to all systems to which it transferred data about the Data Subject (System C). - `PARTNERS.UPWARD` it MUST also send it to all systems from which it obtained data about the Data Subject (System A). - `PARTNERS`, it MUST also send it to all systems from which it obtained data about the Data Subject or to which it gave information about the Data Subject (System A and System C). -Systems should interpret the target of Privacy Request the same way regardless of the Privacy Request being received directly from the Data Subject or from a corresponding System. +Systems should interpret the target of Privacy Request regardless of the Privacy Request being received directly from the Data Subject or from a corresponding System. +This means that the same `target` value of the same Privacy Request transferred across several Systems may end-up being interpreted differently by those Systems (e.g. in every System `PARTNERS.DOWNWARD` is likely to be resolved to different Systems) -Convenient tables of `target` values and corresponding user-facing descriptions, in different languages, are provided [here](dictionary/targets). ### Privacy Request Response @@ -314,15 +346,15 @@ Regardless of the [scenario (Responding to the Data Subject directly or to the S | `in-response-to` | 1 | `request-id` of the Privacy Request to which response is made or `demand-id` of the particular Demand to which response is made, in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Privacy Request Response was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `system` | 1 | System ID of the System having generated the response (**Format TBD**) | -| `requested-action` | 0-1 | Optional information about the action that was demanded, and to which the response is made. One of {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER-DEMAND`} | +| `requested-action` | 0-1 | Optional information about the action that was demanded, and to which the response is made. [Action](#actions)| | `data-subject` | 0-* | Optional indication of the [Data Subject Identities](#decentralized-identity-of-data-subjects) to which the response refers to | -| `status` | 1 | One of {`GRANTED`, `DENIED`, `PARTIALLY-GRANTED`, `UNDER-REVIEW`} | -| `motive` | 0-* | Optionally one of {`IDENTITY-UNCONFIRMED`, `LANGUAGE-UNSUPPORTED`, `VALID-REASONS`, `IMPOSSIBLE`, `NO-SUCH-DATA`, `REQUEST-UNSUPPORTED`, `USER-UNKNOWN`} | -| `answers` | 0-* | Any of the terms the meaning of which is defined by the present vocabulary | +| `status` | 1 | [Status Terms](#statuses) | +| `motive` | 0-* | [Motive Terms](#motives) | +| `answers` | 0-* | [Terms](#terms) | | `message` | 0-1 | Optional string comment, motivation or explanation of Demand | | `lang` | 0-1 | Optional string Language of textual message associated with demands in the format of [FRC5646](https://datatracker.ietf.org/doc/rfc5646/) | | `includes` | 0-* | Optionally an array of one or more [Privacy Request Response](#privacy-request-response)s | -| `data` | 0-* | Optionally concrete data to which access is being given (Format **TBD**) | +| `data` | 0-* | Optionally concrete data to which access is being given| A Privacy Request Response MUST have: - a unique ID, @@ -330,11 +362,11 @@ A Privacy Request Response MUST have: - a date, - a status. -Privacy Request Responses can be nested. One can imagine a Privacy Request Response to a particular Privacy Request, that `includes` Privacy Request Responses to the particular Demands made in that Privacy Request. Several Systems MAY respond to the same Privacy Request or Demand, and one System MAY nest them in order to gather them and send them back to the Data Subject (in the [Coordinated Response secenario](./scenarios.md#coordinated-response)). +Privacy Request Responses CAN be nested. One can imagine a Privacy Request Response to a particular Privacy Request, that `includes` Privacy Request Responses to the particular Demands made in that Privacy Request. Several Systems MAY respond to the same Privacy Request or Demand, and one System MAY nest them in order to gather them and send them back to the Data Subject (in the [Coordinated Response secenario](./scenarios.md#coordinated-response)). When a Demand is being denied, the Privacy Request Response MUST provide a `motive`. ->To illustrate the `answers` value, we can imagine a `TRANSPARENCY.DATA-CATEGORIES` Demand, to which a response may include `answers`: `CONTACT`, `IMAGE`. Or a `TRANSPARENCY.KNOWN` Demand to which the answer may include `answers`: `YES`. +>To illustrate the `answers` value, we can imagine a `TRANSPARENCY.DATA-CATEGORIES` Demand, to which a response may include `answers`: `CONTACT`, `IMAGE`. Or a `TRANSPARENCY.KNOWN` Demand to which the answer may include `answers`: `YES` from [Boolean Terms](#boolean). ### Consent @@ -346,10 +378,10 @@ A Consent is given by one Data Subject which can be identified by one or more [D | `consent-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Consent was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `expires` | 0-1 | Date and Time when Consent expires in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`} to indicate the category of Systems to which consent for processing is given. In absence of indication `SYSTEM` is assumed. | +| `target` | 0-1 | [Target Terms](#targets) to indicate the category of Systems to which consent for processing is given. In absence of indication `SYSTEM` is assumed. | | `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the Consent SHOULD be interpreted as unlimited | -| `replaces` | 0-* | Optionally one or more 'consent-id's of previous consents that have became void when this consent was made | -| `replaced-by` | 0-* | Optionally one or more 'consent-id's of previous consents that have became void when this consent was made | +| `replaces` | 0-* | Optionally one or more 'consent-id's of previous [Consents](#consent) that have became void when this consent was made | +| `replaced-by` | 0-* | Optionally one or more 'consent-id's of previous [Consents](#consent) that have became void when this consent was made | ### Data Capture @@ -360,30 +392,37 @@ A Data Capture is given by one Data Subject which can be identified by one or mo | `data-subject` | 1-* | [Data Subject Identities](#decentralized-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| | `capture-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `data-reference` | 1-* | one or more references that uniquely identify the data that the capture concerns (e.g. a legal case file reference, account ID, contract ID, a URL)| -| `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | +| `target` | 0-1 | [Target Terms](#targets). In absence of indication `SYSTEM` is assumed | | `fragments` | 1-* | One or more [Data Capture Fragments](#data-capture-fragments) | -A Data Capture concerns one and only one Data Subject who MAY be identified by multiple Data Subject Identities. +A Data Capture concerns one and only one Data Subject who CAN be identified by multiple Data Subject Identities. #### Data Capture Fragments | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `fragment-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | -| `selector` | 1 | a string used to uniquely identify a data field (in the System's data model) to which the fragment corresponds. MUST be a subcategory of a *Data Category* and MUST be defined according to [Term Dot Notation](#term-dot-notation) | +| `selector` | 1 | a string used to uniquely identify a data field (in the System's data model) to which the fragment corresponds. MUST be a subcategory of a [Data Category](#data-categories) and MUST be defined according to [Term Dot Notation](#term-dot-notation) | | `date` | 1 | Date and Time when data was Captured was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the fragment SHOULD be interpreted as unlimited | -| `target` | 0-1 | Optionally one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}. In absence of indication `SYSTEM` is assumed | +| `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the fragment SHOULD be interpreted as unlimited, including all categories of all dimensions | +| `target` | 0-1 | [Target Terms](#targets). In absence of indication `SYSTEM` is assumed | | `retention` | 1-* | one or more [Retention Policies](#retention-policy) | | `provenance` | 1-* | one or more [Provenance](#provenance) | | `data` | 0-* | Optionally concrete data (Format **TBD**) | -| `legal-base` | 0-* | Optionally an array of values among `CONTRACT`, `CONSENT`, `LEGITIMATE-INTEREST`, `NECESSARY`, `OTHER-LEGAL-BASE` | +| `legal-base` | 0-* | [Legal Bases](#legal-bases) | -`selector`s MUST include the data category of the data. For example selectors 'CONTACT.ADDRESS.SHIPPING' and 'CONTACT.ADDRESS.BILLING' indicate that the data being captured by a particular fragment belonging to the `CONTACT.ADDRESS` data category. +A `selector` MUST include, at the beginning of its string, one of the [Data Category Terms](#data-categories). +Its syntax MUST follow the [Term Dot Notation](#term-dot-notation). +A `selector` is considered a subcategory (in the sense of the [Term Dot Notation](#term-dot-notation)) of the most granular [Data Category Term](#data-categories) that it includes at at the beginning of its string. -While the Data Categories are global, the selectors are defined by the Systems. A `selector` uniquely identifies a particular data field that the Systems works with. When several Systems exchange data among them, they SHOULD align on using the same `selectors` in the same way, in order to be able to correctly interoperate. +For example selectors 'CONTACT.ADDRESS.SHIPPING' and 'CONTACT.ADDRESS.BILLING' indicate that the data being captured by a particular fragment belonging to the `CONTACT.ADDRESS` [Data Category](#data-categories) of which they are considered to be a subcategory. -Processing MAY be legitimate according to several legal bases for processing. For example, a Data Subject can give explicit `CONSENT` when creating an account with a particular online service, and at the time, the System providing some service to the Data Subject might need to process their data in order to deliver a service or honour a `CONTRACT` (e.g. deliver the purchased goods to the Data Subjects address and issue an invoice). +While the Data Categories are globally defined by PRIV and interpreted the same way by all implementing Systems, the selectors are defined by the Systems. +A `selector` uniquely identifies a particular data field that the Systems works with. +When several Systems exchange data among them, they SHOULD align on using the same `selectors` in the same way, in order to be able to correctly interoperate. + +Processing MAY be legitimate according to one or more [Legal Bases](#legal-bases) for processing. +For example, a Data Subject can give explicit `CONSENT` when creating an account with a particular online service, and at the time, the System providing a service to the Data Subject might need to process their data in order to deliver a service or honor a `CONTRACT` (e.g. deliver the purchased goods to the Data Subjects address and issue an invoice). Certain processing is made legitimate (`LEGITIMATE-INTEREST`) or mandatory (`NECESSARY`) by law, e.g. [Article 6 og GDPR](https://gdpr-info.eu/art-6-gdpr/). @@ -391,26 +430,31 @@ Certain processing is made legitimate (`LEGITIMATE-INTEREST`) or mandatory (`NEC | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `provenance-category` | 1 | one of {`DERIVED`, `TRANSFERRED`, `USER`, `USER.DATA-SUBJECT`} | +| `provenance-category` | 1 | [Provenance Terms](#provenance-categories) | | `system` | 1 | System ID (**Format TBD**) | Data provenance is interpreted in relation to a particular System. -The same Data Capture Fragment might be data collected from the `USER` for one System that is in direct interaction with the Data Subject, and be data `TRANSFERRED` in the eyes of another System that obtained in through transfer from the user-facing System. + +The same Data Capture Fragment might be: +- data collected from the `USER` for one System (the one being in direct interaction with the Data Subject), and be +- data `TRANSFERRED` in the eyes of another System that obtained it through transfer from the user-facing System. + +Not to be confused with [Provenance Restriction](#provenance-restriction). ##### Retention Policy | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `data-category` | 1-* | Any of the any Data Category terms or concrete Data Capture Fragment `selector`s within those categories | -| `policy-type` | 1 | one of {NO-LONGER-THAN, "NO-LESS-THAN"} | +| `data-categories` | 1-* | Any of the any [Data Category Terms](#data-categories) or concrete [Data Capture Fragment](#data-capture-fragments) `selector`s within those categories | +| `policy-type` | 1 | [Retention](#retentions) | | `duration` | 1 | Duration in JSON Schema [duration](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| `after` | 1 | Event to which the retention duration is relative to. One of {`CAPTURE-DATE`,`RELATIONSHIP-END`, `SERVICE-END`} +| `after` | 1 | Event to which the retention duration is relative to. [Events](#events) | -When several `data-category` values are given, they are interpreted as a union. +When several `data-categories` values are given, they are interpreted as a **union**. ## Detailed Design -A separate document gives a list of [examples](examples.md) on how to represent real-life Privacy Requests, as defined in [supported legislation](#supported-legislation), or as modelled in existing systems with which we seek interoperability. +A separate document gives a list of [examples](examples.md) on how to represent real-life Privacy Requests, as defined in [supported legislation](#supported-legislation), or as modeled in existing systems with which we seek interoperability. ### JSON format @@ -422,7 +466,7 @@ Systems exchanging Privacy Requests MUST be able to do so in a way allowing them For this purposes Privacy Requests MAY be embedded as 'Claims' in [JWTs (RFC7519)](https://datatracker.ietf.org/doc/html/rfc7519). -### Decentralised Identity of Data Subjects +### Decentralized Identity of Data Subjects The Systems are only able to provide control to Data Subjects if they can identify them. On the other hand, there is no central authority to manage Data Subject identity globally. @@ -470,7 +514,7 @@ However, in most cases, Systems MUST require the Data Subject to be authenticate When processing Privacy Request, Systems MAY automatically disregard the (`dsid`,`dsid-schema`) paris for which they have not been able to establish Data Subject authentication. -However, the authentication does not necessarily have to be performed during the collection of the Privacy Request. It can be done separately. The design of PRIV aims to support several authentication workflows, as many as possible authentication methods (i.e. be as much as possible agnostic from the authentication method). +However, the authentication does not necessarily have to be performed during the collection of the Privacy Request. It can be done separately. The design of PRIV aims to support [several authentication workflows](./scenarios.md#authentication), as many as possible authentication methods (i.e. be as much as possible agnostic from the authentication method). #### Matching Multiple Data Subject Identities @@ -487,13 +531,13 @@ All of the following identifiers `capture-id`, `fragment-id`, `consent-id`, `req The reason for using UUDIs is to allow Systems to independently generate globally unique identifiers while being autonomous from a central entity that would ensure identifier uniqueness. Having a public ledger for UUDIs MAY be considered for Consents and Data Captures, but serious implications to Data Subject exposure MUST also be considered. -However, the design MUST be compatible with building a public decentralised ledger. +However, the design MUST be compatible with building a public decentralized ledger. ### Term Dot Notation -The vocabulary defines TERMS to express different aspects of Privacy Request, Data Captures, Consents etc. +The vocabulary defines [Terms](#terms) to express different aspects of Privacy Request, Data Captures, Consents etc. -TERMS follow Term Dot Notation (TDN), defined using the following ABNF (cf. [FRC5234](https://www.rfc-editor.org/info/rfc5234)): +[Terms](#terms) follow Term Dot Notation (TDN), defined using the following ABNF (cf. [FRC5234](https://www.rfc-editor.org/info/rfc5234)): ``` term = category *subcategory @@ -502,29 +546,41 @@ subcategory = "." category category = *(%x41–5A) *((%x2D) 1*(%x41–5A)) ``` -A category is equivalent to the union of all of its subcategories. +A category includes the union of all of its subcategories. Terms can be specified at different levels of granularity. E.g. the following statements are equivalent: - `A.B`, `A` - `A` -PRIV includes a set of TERMS, provided in [the dictionary](./dictionary). +PRIV includes a set of [Terms](#terms), provided in the [dictionary](./dictionary). This list is designed with the aim to be: -- **Unambiguous** : The developer using the schema knows without ambiguity which one (of which ones) to use in any given situation, AND -- **Complete** : They allow to express the totality of possible needs in the context of a user wanting to [regulate their privacy/connectedness](https://github.com/blindnet-io/product-management/blob/dogma/refs/notion-of-privacy/notion-of-privacy.md), as well as the totality of requests defined by the [supported legilsation](#supported-legilsation). +- **Unambiguous** : The developer using the schema knows without ambiguity which one (or which ones) to use in any given situation, AND +- **Complete** : They allow to express the totality of possible needs in the context of a user wanting to [regulate their privacy/connectedness](https://github.com/blindnet-io/product-management/blob/dogma/refs/notion-of-privacy/notion-of-privacy.md), as well as the totality of requests defined by the [supported legislation](#supported-legislation). + +Implementing Systems SHOULD be able to interpret and operate with all the [Terms](#terms). + +#### Interpreting subcategories + +A term (`A.B`) is a subcategory of another term (`A`) if an only if the subcategory term's string includes at its beginning the totality of this other (supercategory) term's string. -Implementing Systems SHOULD be able to interpret and operate with all the TERMS. +E.g. `TRANSPARENCY.ORGANIZATION` is a subcategory if `TRANSPARENCY`. +`TRANSPARENCY.ORGANIZATION` is not a subcategory of `ORGANIZATION` -#### Extending TERMS +E.g. `CONTACT.ADDRESS.SHIPPING` is a subcategory of `CONTACT.ADDRESS`. +`CONTACT.ADDRESS.SHIPPING` is a subcategory of `CONTACT` -When needed, Systems MAY include support for additional terms, not included in [the dictionary](./dictionary). -Such additional terms MUST be subcategories of one of the TERMS, and they MUST follow the same syntax of the [Term Dot Notation](#term-dot-notation). -Such Systems MAY manifest specific behavior in reaction to those additional terms, yet they may end-up communicating them with other Systems that only support the TERMS from [the dictionary](./dictionary). -In that case, Systems MUST interpret the additional terms, as being equivalent to the first super-category that they support. +#### Extending Terms -In that way, interoperability can always be expected at the level of TERMS. +When needed, Systems MAY include support for additional terms, not included in the [dictionary](./dictionary). +Such additional terms MUST be subcategories of one of the [Terms](#terms), and they MUST follow the same syntax of the [Term Dot Notation](#term-dot-notation). + +Such Systems MAY manifest specific behavior in reaction to those additional terms, yet they may end-up communicating them with other Systems that only support the [Terms](#terms) from the [dictionary](./dictionary). + +Systems processing Privacy Requests (or other Concepts) containing a term unknown to them, SHOULD deploy behavior they are programmed to deploy in response to the first known supercategory of such term. + +In that way, interoperability CAN always be expected at the level of [Terms](#terms). ### Extending the vocabulary @@ -536,12 +592,12 @@ Systems MAY specify the vocabulary used to express data being exchanged. The val When [addition additional terms](#extending-terms) is not sufficient, and additional Concepts or Properties are needed, it is possible to extend the vocabulary. -This vocabulary can be extended by defining a new identifier for the new vocabulary. +This vocabulary is extended by defining a new identifier for the new vocabulary. New vocabularies MAY include other vocabularies as long as their sets of concepts, properties and terms are disjoint. ## Examples -A [JSON schema of the PRIV](./priv.schema.json) is provided for convenience. To illustrate a request, let us take the example of a data subject wanting to know if a an organisation (and any of its partners if applicable) have any data on them, and if so, have their contact data deleted. +A [JSON schema of the PRIV](./priv.schema.json) is provided for convenience. To illustrate a request, let us take the example of a data subject wanting to know if a an Organization (and any of its partners if applicable) have any data on them, and if so, have their contact data deleted. This request can be represented with the following json data: ``` @@ -568,7 +624,7 @@ This request can be represented with the following json data: } ``` -In [here](./examples.md) we provide an overview of various Privacy Requests that a Data Subject might want to formulate according to [supported legislation](#supported-legislation) and we give indications on how each of those can be modelled with the Privacy Request Interchange Vocabulary. +In [here](./examples.md) we provide an overview of various Privacy Requests that a Data Subject might want to formulate according to [supported legislation](#supported-legislation) and we give indications on how each of those can be modeled with the Privacy Request Interchange Vocabulary. ## Design Implications for Systems Implementing PRIV @@ -592,7 +648,7 @@ When data about Data Subjects is transmitted from one system to another, in orde In order to automatically respond to `TRANSPARENCY` demands, Systems should store general information about: - Countries where data servers are located (`TRANSPARENCY.WHERE`) -- The identity of the organisation controlling them, and the Organization's representative(s) (`TRANSPARENCY.WHO`) +- The identity of the Organization controlling them, and the Organization's representative(s) (`TRANSPARENCY.WHO`) - The categories of Data Consumers, and access policies (`TRANSPARENCY.WHO`) - Identity and contact of a Data Protection Officer (`TRANSPARENCY.DPO`) - A link to their Privacy Policy (`TRANSPARENCY.POLICY`) @@ -604,7 +660,7 @@ In order to automatically respond to `TRANSPARENCY` demands, Systems should stor > - the right to lodge a complaint with a supervisory authority; > - whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data and of the possible consequences of failure to provide such data > - the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject. -> - Where personal data are transferred to a third country or to an international organisation, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer. +> - Where personal data are transferred to a third country or to an international Organization, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer. ### Storing Capture-related Information @@ -633,8 +689,7 @@ It SHOULD be possible for systems to expose Privacy Request APIs in such a way t ### Compliance History -Systems SHOULD keep a log of received [Privacy Requests](#privacy-request), generated [responses](#privacy-request-response), and as much as possible proofs of response delivery and visualisation. - +Systems SHOULD keep a log of received [Privacy Requests](#privacy-request), generated [responses](#privacy-request-response), and as much as possible proofs of response delivery and visualization. ## Questions and Discussion Topics @@ -653,7 +708,7 @@ Should we include restrictions in the schema according to the [JSON-schema-valid In the current proposal, this is the case for target, but not for request types, data categories, and user identity schemas. We might want to include more forma constraints there, or deliberately leave flexibility. This is a discussion we need to have. -### Dot-notation for TERMS +### Dot-notation for Terms Hierarchies of categories are represented using the "supercategory.subcategory" notation. The idea behind this is to allow developers to use the level of granularity that is adapted to them, yet be able to easily situate the subcategory in supercategory when dealing with more generic requests. @@ -693,7 +748,7 @@ This would make sense if the Systems would be responsible for finding a way to r A Data Subject can formulate a request to know about processing generally practiced by the System, or to know about processing being done on Data Subejct's particular data. Those can be different. Yet we have only one category 'TRANSPARENCY.PROCESSING-CATEGORIES'. Same goes for other `TRANSPARENCY` requests. -Currently we don't offer any way to distinguish between those two kinds of demands. We will offer instructions for Systems (under [Expected Behavior](expected-behavior.md) - **TO BE WRITTEN**) on how to interpret them based on context (whether the request is made during capture, or prior to capture where request scope SHOULD be interpreted as general, or in some other context where the request scope SHOULD be interpreted as related to user's particular data). +Currently we don't offer any way to distinguish between those two kinds of demands. We offer instructions for Systems, under [Expected Behavior](expected-behavior.md), on how to interpret them based on context (whether the request is made during capture, or prior to capture where request scope SHOULD be interpreted as general, or in some other context where the request scope SHOULD be interpreted as related to user's particular data). This design choice MAY be a bad idea. @@ -738,7 +793,7 @@ We need a way for Systems to encrypt the data (that compatible also with encrypt ### Motivation or explanation of Demand When a Demand is motivated by a `message`, then it can't be processed automatically. -To the best of our knowledge, motivating a Demand is optional under [supported legislation](#supported-legilsation). +To the best of our knowledge, motivating a Demand is optional under [supported legislation](#supported-legislation). The `message` is thus optional. If PRIV is ever to support a legislation under which a message might be mandatory, this design SHOULD be reconsidered. diff --git a/refs/schemas/priv/dictionary/actions/en.actions.json b/refs/schemas/priv/dictionary/actions/en.actions.json index 522e661b..f0642f9e 100644 --- a/refs/schemas/priv/dictionary/actions/en.actions.json +++ b/refs/schemas/priv/dictionary/actions/en.actions.json @@ -11,7 +11,7 @@ "TRANSPARENCY.DPO": "To know the contact details of the data protection officer", "TRANSPARENCY.KNOWN": "To know if the System has data on me", "TRANSPARENCY.LEGAL-BASES": "To know the legal bases for processing my data (including legitimate interests)", - "TRANSPARENCY.ORGANISATION": "To know the identity and the contact details of the organisation processing my data", + "TRANSPARENCY.ORGANIZATION": "To know the identity and the contact details of the organization processing my data", "TRANSPARENCY.POLICY": "To know the policies being applied to processing of data concerning me", "TRANSPARENCY.PROCESSING-CATEGORIES": "To know the categories of processing being done on the data the System has on me", "TRANSPARENCY.PROVENANCE": "To know the sources that the data concerning me come from", diff --git a/refs/schemas/priv/dictionary/purposes/en.purposes.json b/refs/schemas/priv/dictionary/purposes/en.purposes.json index 6e9ff816..9559a6a7 100644 --- a/refs/schemas/priv/dictionary/purposes/en.purposes.json +++ b/refs/schemas/priv/dictionary/purposes/en.purposes.json @@ -5,7 +5,7 @@ "JUSTICE": "Processing is necessary for the establishment, exercise or defence of legal claims or whenever courts are acting in their judicial capacity", "MARKETING": "To contact the user to offer products, services, or other promotions", "MEDICAL": "Processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services", - "PERSONALISATION": "For providing user with a personalized experience", + "PERSONALIZATION": "For providing user with a personalized experience", "PUBLIC-INTERESTS": "Processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority", "RESEARCH": "Scientific and Market Research", "SALE": "Selling data to third parties", diff --git a/refs/schemas/priv/dictionary/targets/en.targets.json b/refs/schemas/priv/dictionary/targets/en.targets.json index 0c3e6504..f309ddf0 100644 --- a/refs/schemas/priv/dictionary/targets/en.targets.json +++ b/refs/schemas/priv/dictionary/targets/en.targets.json @@ -1,7 +1,7 @@ { - "ORGANISATION": "This System and all other Systems belonging to the same Organisation", - "PARTNERS": "Systems belinging to any Organisation with which the data is exchanged", - "PARTNERS.DOWNWARD": "Systems belinging to any Organisation with which the data is shared", - "PARTNERS.UPWARD": "Systems belinging to any Organisation from which the data is obtained", + "ORGANIZATION": "This System and all other Systems belonging to the same Organization", + "PARTNERS": "Systems belinging to any Organization with which the data is exchanged", + "PARTNERS.DOWNWARD": "Systems belinging to any Organization with which the data is shared", + "PARTNERS.UPWARD": "Systems belinging to any Organization from which the data is obtained", "SYSTEM": "Only this System" } diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 41efeb1d..13d1455f 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -23,7 +23,7 @@ The document is not normative, and often uses inconsistent language and format. - All key words denoting components of [blindnet devkit](../lexicon/RFC-Lexicon-2.md#blindnet-devkit), such as "Capture Component", "Encryption and Access Management Engine", "Privacy Computation Engine", "Privacy Compiler", "Privacy Request Capture Interface", "Customization API", "Data Consumer Interface", "Schemas" and "Storage Component" are to be interpreted as defined in [High Level Architecture](../high-level-architecture/) - Privacy Compiler was formerly known as Data Rights Compiler - Privacy Request was formerly known as Data Rights Request -- All the concepts, properties and terms listed in the [Proposal](./RFC-PRIV.md#proposal) section of PRIV(Privacy Request Interchange Vocabulary are to be interpreted as defined in [Privacy Request Interchange Vocabulary](./RFC-PRIV.md#proposal) +- All the concepts, properties and [Terms](./RFC-PRIV.md#terms) listed in the [Proposal](./RFC-PRIV.md#proposal) section of PRIV(Privacy Request Interchange Vocabulary are to be interpreted as defined in [Privacy Request Interchange Vocabulary](./RFC-PRIV.md#proposal) ## Examples @@ -37,13 +37,13 @@ In the following examples we show how, requests introduced by different regulati | Law | Demand (as introduced by regulation) | Representation | | -------- | ----------------------------------------------------- | ------------ | -| `GDPR.13.1.a`, `GDPR.14.1.a` | the identity and the contact details of the controller and, where applicable, of the controller’s representative | action:`TRANSPARENCY.ORGANISATION` | +| `GDPR.13.1.a`, `GDPR.14.1.a` | the identity and the contact details of the controller and, where applicable, of the controller’s representative | action:`TRANSPARENCY.ORGANIZATION` | | `GDPR.13.1.b`, `GDPR.14.1.b` | the contact details of the data protection officer, where applicable; | action:`TRANSPARENCY.DPO` | | `GDPR.13.1.c`, `GDPR.14.1.c` | the purposes of the processing for which the personal data are intended | action:`TRANSPARENCY.PURPOSE` | | `GDPR.13.1.c`, `GDPR.14.1.c` | ... legal basis for the processing | action:`TRANSPARENCY.LEGAL-BASES` | | `GDPR.13.1.d`, `GDPR.14.1.d` | where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party | action:`TRANSPARENCY.LEGAL-BASES` | | `GDPR.13.1.e`, `GDPR.14.1.e` | the recipients or categories of recipients of the personal data, if any; | action:`TRANSPARENCY.WHO` | -| `GDPR.13.1.f`, `GDPR.14.1.f` | where applicable, the fact that the controller intends to transfer personal data to a third country or international organisation | action:`TRANSPARENCY.WHERE` | +| `GDPR.13.1.f`, `GDPR.14.1.f` | where applicable, the fact that the controller intends to transfer personal data to a third country or international Organization | action:`TRANSPARENCY.WHERE` | | `GDPR.13.1.f`, `GDPR.14.1.f` | the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means by which to obtain a copy of them or where they have been made available. | action:`OTHER-DEMAND` | | `GDPR.13.2.a`, `GDPR.14.2.a` | the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period | action:`TRANSPARENCY.RETENTION` | | `GDPR.13.2.b`, `GDPR.14.2.b` | the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability | action:`TRANSPARENCY.POLICY` | @@ -69,7 +69,7 @@ In the following examples we show how, requests introduced by different regulati | -------- | ----------------------------------------------------- | ------------ | | `GDPR.15.1.a` | the purposes of the processing | action:`TRANSPARENCY.PURPOSE` | | `GDPR.15.1.b` | the categories of personal data concerned | action:`TRANSPARENCY.DATA-CATEGORIES` | -| `GDPR.15.1.c` | the recipients or categories of recipient to whom the personal data have been or will be disclosed, in particular recipients in third countries or international organisations; | action:`TRANSPARENCY.WHO` | +| `GDPR.15.1.c` | the recipients or categories of recipient to whom the personal data have been or will be disclosed, in particular recipients in third countries or international Organizations; | action:`TRANSPARENCY.WHO` | | `GDPR.15.1.d` | where possible, the envisaged period for which the personal data will be stored, or, if not possible, the criteria used to determine that period; | action:`TRANSPARENCY.RETENTION` | | `GDPR.15.1.e` | the existence of the right to request from the controller rectification or erasure of personal data or restriction of processing of personal data concerning the data subject or to object to such processing; | action:`TRANSPARENCY.POLICY` | | `GDPR.15.1.f` | the right to lodge a complaint with a supervisory authority | action:`TRANSPARENCY.POLICY` | @@ -84,7 +84,7 @@ In the following examples we show how, requests introduced by different regulati | LAW | Demand (as introduced by regulation) | Representation | | -------- | ----------------------------------------------------- | ------------ | -| `GDPR.15.2` | Where personal data are transferred to a third country or to an international organisation, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer | action:`TRANSPARENCY.POLICY` | +| `GDPR.15.2` | Where personal data are transferred to a third country or to an international Organization, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer | action:`TRANSPARENCY.POLICY` | | `GDPR.15.3` | The controller shall provide a copy of the personal data undergoing processing | action:`ACCESS` | #### Article 16-22 @@ -96,7 +96,7 @@ In the following examples we show how, requests introduced by different regulati | `GDPR.18` | The data subject shall have the right to obtain from the controller restriction of processing | action:`RESTRICT` | | `GDPR.20` | The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided | action:`PORTABILITY` | | `GDPR.21` | The data subject shall have the right to object, on grounds relating to his or her particular situation, at any time to processing of personal data concerning him or her which is based on point (e) or (f) of Article 6(1), including profiling based on those provisions. *(note: 21.2 is not yet supported by the schema)*| action:`OBJECT` | -| `GDPR.22` | The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her | action:`OBJECT`, processing-category:`AUTOMATED-DECISION-MAKING` | +| `GDPR.22` | The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her | action:`OBJECT`, `processing-categories`:`AUTOMATED-DECISION-MAKING` | @@ -105,23 +105,23 @@ In the following examples we show how, requests introduced by different regulati | LAW | Demand | Representation | | -------- | ----------------------------------------------------- | ------------ | | `GDPR.15` | [Acces](https://www.cnil.fr/fr/modele/courrier/exercer-son-droit-dacces) | action:`ACCESS` | -| `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | action:`ACCESS`, data-category:`IMAGE`, purpose:`SECURITY`, Date Range restriction `from:2021-02-01` `to:2021-02-03` | -| `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | action:`ACCESS`, data-category:`HEALTH` | +| `GDPR.15` | [Access to video surveillance data](https://www.cnil.fr/fr/modele/courrier/acceder-des-images-video-vous-concernant) from 01 Feb 2021 to 03 Feb 2021 | action:`ACCESS`, `data-categories`:`IMAGE`, purpose:`SECURITY`, Date Range restriction `from:2021-02-01` `to:2021-02-03` | +| `Code de la santé publique art. L. 1111-7` | [Acces to my medical record](https://www.cnil.fr/fr/modele/courrier/acceder-son-dossier-medical) | action:`ACCESS`, `data-categories`:`HEALTH` | | `GDPR.15` | [Access to data "Preventel" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-aux-informations-contenues-dans-preventel) | action:`ACCESS` | | `GDPR.15` | [Access to data a financial organization has on me](https://www.cnil.fr/fr/modele/courrier/connaitre-les-informations-detenues-par-un-etablissement-financier): Access to all data the (financial)organization has on me, Provide with any available information on the origin of this data concerning me | action:`ACCESS`,`TRANSPARENCY.PROVENANCE` | | `GDPR.15` | [Access to data "Fichier central des Chèques (FCC)" has on me](https://www.cnil.fr/fr/modele/courrier/acceder-au-fichier-central-des-cheques-fcc) | action:`ACCESS` | | `GDPR.15` | [Access to data "Fichier national des Incidents de remboursement de Crédit (FICP)](https://www.cnil.fr/fr/modele/courrier/acceder-aux-donnees-du-fichier-national-des-incidents-de-remboursement-de-credit) | action:`ACCESS` | | `GDPR.15` | [Access to geolocation data or an access control device an organization has on me](https://www.cnil.fr/fr/modele/courrier/acceder-des-donnees-de-geolocalisation-ou-un-dispositif-de-controle-dacces) on a specific period of time | action:`ACCESS`, Date Range Restriction `from`,`to` | | `GDPR.20` | [Exerce my right to portability](https://www.cnil.fr/fr/professionnels-comment-repondre-une-Demand-de-droit-la-portabilite) : Receive the data that concerns me to reuse them and transmit them to another data controller| action:`ACCESS`,`PORTABILITY` | -| `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| action:`MODIFY`, `data-category`: particular `selector` to modify, `data`: new data | -| `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | action:`MODIFY`, `data-category`: particular `selector` to modify, `data`: new data | -| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | action:`DELETE`,`data-category`: category or particular `selector` of the data to be deleted, or any Capture Restriction or Date Range Restriction, (optional) `message`:Reason of deletion | -| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | action:`OBJECT`, data-category:`CONTACT`, purpose:`ADVERTISING` | -| `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `action`:`DELETE`,`data-category`: `UID.USER-ACCOUNT` | +| `GDPR.16` | [Rectify incorrect data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-inexactes)| action:`MODIFY`, `data-categories`: particular `selector` to modify, `data`: new data | +| `GDPR.16` | [Rectify incomplete data organization has on me](https://www.cnil.fr/fr/modele/courrier/rectifier-des-donnees-incompletes) | action:`MODIFY`, `data-categories`: particular `selector` to modify, `data`: new data | +| `GDPR.17.1` | [Deletion](https://www.cnil.fr/fr/modele/courrier/supprimer-des-donnees-personnelles) | action:`DELETE`,`data-categories`: category or particular `selector` of the data to be deleted, or any Capture Restriction or Date Range Restriction, (optional) `message`:Reason of deletion | +| `GDPR.21.2` | [Stop receiving advertising from organization](https://www.cnil.fr/fr/modele/courrier/ne-plus-recevoir-de-publicites) | action:`OBJECT`, `data-categories`:`CONTACT`, purpose:`ADVERTISING` | +| `GDPR.17.1` | [Closing an online account](https://www.cnil.fr/fr/modele/courrier/cloturer-un-compte-en-ligne) | `action`:`DELETE`,``data-categories``: `UID.USER-ACCOUNT` | | `GDPR.21.1`,`GDPR.17.1.c` | [Delete my data that are published on a webiste](https://www.cnil.fr/fr/modele/courrier/supprimer-des-informations-vous-concernant-dun-site-internet) : Delete my data a website has published, Pages where my data appears are no longer referenced by search engines | action:`DELETE`, Data Reference Restriction (`data-reference`: concrete URLs), optional `message`:Reason of deletion, | -| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/Demandr-le-retrait-de-votre-image-en-ligne) | action: `DELETE`, data-category:`IMAGE`, Data Reference Restriction (`data-reference`: concrete URLs), (optional) message:`Reason of deletion` | -| `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | action:`OBJECT`(purpose:`MARKETING`), action:`DELETE`(data-category:`CONTACT`), , target: `ORGANISATION`,`PARTNERS`(propagation) | -| `GDPR.21.1`,`GDPR.17.1.c`,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an organisation's legal obligation | action:`TRANSPARENCY.RETENTION`; action:`DELETE`, target:`ORGANISATION`,`PARTNERS`(propagation); action:`OBJECT` | +| `GDPR.21.1`,`GDPR.17.1.c` | [Removal of my image online](https://www.cnil.fr/fr/Demandr-le-retrait-de-votre-image-en-ligne) | action: `DELETE`, `data-categories`:`IMAGE`, Data Reference Restriction (`data-reference`: concrete URLs), (optional) message:`Reason of deletion` | +| `GDPR.21.2`,`GDPR.17.1`,`GDPR.19` | [Opposition to commercial prospecting](https://www.cnil.fr/fr/modele/courrier/sopposer-la-prospection-commerciale-par-telephone-sms-mail-courriers) : Opposition to treatment of all data the organization has on me for prospecting purpose, Deletion of my contact details from organization's prospecting files , Propagation of request | action:`OBJECT`(purpose:`MARKETING`), action:`DELETE`(`data-categories`:`CONTACT`), , target: `ORGANIZATION`,`PARTNERS`(propagation) | +| `GDPR.21.1`,`GDPR.17.1.c`,`GDPR.19` | [Opposition to treatment of all data an organization has on me](https://www.cnil.fr/fr/modele/courrier/sopposer-au-traitement-de-donnees) Opposition to treatment of all data the organization has on me, Deletion of all data the organization has on me, Propagation of request, Information on how long data will be kept on archive database if it is an Organization's legal obligation | action:`TRANSPARENCY.RETENTION`; action:`DELETE`, target:`ORGANIZATION`,`PARTNERS`(propagation); action:`OBJECT` | | `GDPR.21`, GDPR.18.1 | [Limit the processing (oppose to particular type of processing) organization does on the data it has on me](https://www.cnil.fr/fr/le-droit-dopposition-refuser-lutilisation-de-vos-donnees) | action:`OBJECT` | | `GDRP.4`,`GDRP.6`,`GDRP.7`, `GDPR.13.2.c`| [Revoke consent](https://www.cnil.fr/fr/les-bases-legales/consentement) : Revoke specific consent that I previously gave for a type of treatment on the data the organization has on me | action:`REVOKE-CONSENT`, Consent Restriction | | `GDPR.13.2.a`, `GDPR.14.2.a` | [For how long the data organization has on me will be kept](https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees) | action:`TRANSPARENCY.RETENTION` | @@ -134,11 +134,11 @@ In the following examples we show how, requests introduced by different regulati | LAW | Demand | Representation | | -------- | ----------------------------------------------------- | ------------ | -| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | action:`MODIFY`, data-category:`CONTACT.ADDRESS`, `data`:1 blindnet street, 75000 blindcity, France , `message`: as of 01.01.2021 (*NB: can't be modeled as a Date Range as Data Ragnge MUST resolve to particular Data Capture Fragments*)| -| `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | action:`DELETE`, data-category:`CONTACT`; action:`OBJECT` (`purpose`:`MARKETING`, `ADVERTISING`) | -| `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | action:`OBJECT`, processing-category:`AUTOMATED-DECISION-MAKING` | +| `GDPR.16` | Change my address, with new address being 1 blindnet street, 75000 blindcity, France, as of 01.01.2021 | action:`MODIFY`, `data-categories`:`CONTACT.ADDRESS`, `data`:1 blindnet street, 75000 blindcity, France , `message`: as of 01.01.2021 (*NB: can't be modeled as a Date Range as Data Ragnge MUST resolve to particular Data Capture Fragments*)| +| `GDPR.17` | Opt out of contact lists : Delete my contact details from all contact lists an ornaginzation has with my contact details | action:`DELETE`, `data-categories`:`CONTACT`; action:`OBJECT` (`purpose`:`MARKETING`, `ADVERTISING`) | +| `GDPR.21`,`GDPR.18.1` | Opt out of automated decision making | action:`OBJECT`, `processing-categories`:`AUTOMATED-DECISION-MAKING` | | `GDPR.21`,`GDPR.18.1` | Opt out of sale of my data | action:`OBJECT`, purpose`SALE` | -| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | action:`OBJECT`, data-category:`BEHAVIOR`,`DEVICE`,`LOCATION`, processing-category:`COLLECTION`, purpose:`TRACKING` | +| `GDPR.21`,`GDPR.18.1` | Opt out of tracking on my data | action:`OBJECT`, `data-categories`:`BEHAVIOR`,`DEVICE`,`LOCATION`, `processing-categories`:`COLLECTION`, purpose:`TRACKING` | | `GDPR.13.1.f`, `GDPR.14.1.f` | Storage information : know where is stored the data organization has on me | action:`TRANSPARENCY.WHERE` | | `GDPR.14.1.e` | Accessibility information : know who can access the data organization has on me | action:`TRANSPARENCY.WHO` | | `GDPR.14.2.f` | Provenance information : know the provenance of data organization has on me | action:`TRANSPARENCY.PROVENANCE` | @@ -146,7 +146,7 @@ In the following examples we show how, requests introduced by different regulati | `**GDPR.13?**` | Know what is the policy of the organization to keep data it has on me | action:`TRANSPARENCY.POLICY` | | `GDPR.15.1.a` | Know the purpose of the processing organization does on the data it has on me | action:`TRANSPARENCY.PURPOSE` | | `GDPR.12.1` | Know what type(s) of treatment organization does on the data it has on me | action:`TRANSPARENCY.PROCESSING-CATEGORIES` | -| `GDPR.12.1` | Know if a particular type of treatment is done by organisation on the data it has on me | action:`TRANSPARENCY.PROCESSING-CATEGORIES`, processing-category:`**any/all**` | +| `GDPR.12.1` | Know if a particular type of treatment is done by Organization on the data it has on me | action:`TRANSPARENCY.PROCESSING-CATEGORIES`, `processing-categories`:`**any/all**` | >**Note** > @@ -161,12 +161,12 @@ In the following examples we show how, requests introduced by different regulati | `1798.110.1.1` | A consumer shall have the right to request that a business that collects personal information about the consumer disclose to the consumer the following: The categories of personal information it has collected about that consumer | action:`TRANSPARENCY.DATA-CATEGORIES` | | `1798.110.1.2` | ...The categories of sources from which the personal information is collected | action:`TRANSPARENCY.PROVENANCE` | | `1798.110.1.3` | ...The business or commercial purpose for collecting or selling personal information | action:`TRANSPARENCY.PURPOSE` | -| `1798.110.1.4` | ...The categories of third parties with whom the business shares personal information | action:`TRANSPARENCY.WHO` processing-category:`SHARING`| +| `1798.110.1.4` | ...The categories of third parties with whom the business shares personal information | action:`TRANSPARENCY.WHO` `processing-categories`:`SHARING`| | `1798.110.1.5` | ...The specific pieces of personal information it has collected about that consumer | action:`ACCESS` | -| `1798.115.1.1` | A consumer shall have the right to request that a business that sells the consumer’s personal information, or that discloses it for a business purpose, disclose to that consumer: The categories of personal information that the business collected about the consumer | action:`TRANSPARENCY.DATA-CATEGORIES`, processing-category:`SHARING`, purpose:`SALE` | -| `1798.115.1.2` | ...The categories of personal information that the business sold about the consumer and the categories of third parties to whom the personal information was sold, by category or categories of personal information for each category of third parties to whom the personal information was sold | action:`TRANSPARENCY.DATA-CATEGORIES`,`TRANSPARENCY.WHO`, processing-category:`SHARING`, purpose:`SALE` | -| `1798.115.1.3` | ...The categories of personal information that the business disclosed about the consumer for a business purpose | action:`TRANSPARENCY.DATA-CATEGORIES`, processing-category:`SHARING`, purpose:`SALE` | -| `1798.120.1` | A consumer shall have the right, at any time, to direct a business that sells personal information about the consumer to third parties not to sell the consumer’s personal information. This right may be referred to as the right to opt-out | action:`RESTRICT`, processing-category:`SHARING`, purpose:`SALE` | +| `1798.115.1.1` | A consumer shall have the right to request that a business that sells the consumer’s personal information, or that discloses it for a business purpose, disclose to that consumer: The categories of personal information that the business collected about the consumer | action:`TRANSPARENCY.DATA-CATEGORIES`, `processing-categories`:`SHARING`, purpose:`SALE` | +| `1798.115.1.2` | ...The categories of personal information that the business sold about the consumer and the categories of third parties to whom the personal information was sold, by category or categories of personal information for each category of third parties to whom the personal information was sold | action:`TRANSPARENCY.DATA-CATEGORIES`,`TRANSPARENCY.WHO`, `processing-categories`:`SHARING`, purpose:`SALE` | +| `1798.115.1.3` | ...The categories of personal information that the business disclosed about the consumer for a business purpose | action:`TRANSPARENCY.DATA-CATEGORIES`, `processing-categories`:`SHARING`, purpose:`SALE` | +| `1798.120.1` | A consumer shall have the right, at any time, to direct a business that sells personal information about the consumer to third parties not to sell the consumer’s personal information. This right may be referred to as the right to opt-out | action:`RESTRICT`, `processing-categories`:`SHARING`, purpose:`SALE` | ### Alternatives Considered @@ -181,27 +181,27 @@ In the following examples we show how, requests introduced by different regulati | Ethyca Parent key | **Ethyca Label** | Ethyca Description |Representation | | ------------ | -------------------------------------- | ------------ | ------------ | -| **account** | **Contact** | Contact data related to a system account | data-category:`CONTACT` | -| **account.contact** | **email** | Account's email address | data-category:`CONTACT.EMAIL` | -| **account.contact** | **phone_number** | Account's phone number | data-category:`CONTACT.PHONE` | -| **account.contact** | **City** | Account's city level address data | data-category:`CONTACT.ADDRESS` | -| **account.contact** | **Country** | Account's country level address data | data-category:`CONTACT.ADDRESS` | -| **account.contact** | **postal_code** | Account's postal code | data-category:`CONTACT.ADDRESS` | -| **account.contact** | **state** | Account's state level address data | data-category:`CONTACT.ADDRESS` | -| **account.contact** | **street** | Account's street level address | data-category:`CONTACT.ADDRESS` | +| **account** | **Contact** | Contact data related to a system account | `data-categories`:`CONTACT` | +| **account.contact** | **email** | Account's email address | `data-categories`:`CONTACT.EMAIL` | +| **account.contact** | **phone_number** | Account's phone number | `data-categories`:`CONTACT.PHONE` | +| **account.contact** | **City** | Account's city level address data | `data-categories`:`CONTACT.ADDRESS` | +| **account.contact** | **Country** | Account's country level address data | `data-categories`:`CONTACT.ADDRESS` | +| **account.contact** | **postal_code** | Account's postal code | `data-categories`:`CONTACT.ADDRESS` | +| **account.contact** | **state** | Account's state level address data | `data-categories`:`CONTACT.ADDRESS` | +| **account.contact** | **street** | Account's street level address | `data-categories`:`CONTACT.ADDRESS` | ###### Account Payment Data | Ethyca Parent key | **Ethyca Label** | Ethyca Description | Representation | | ------------ | -------------------------------------- | ------------ | ------------ | -| **account** | **payment** | Payment data related to system account | data-category:`FINANCIAL` | -| **account.payment** | **financial_account_number** | Payment data related to system account | data-category:`FINANCIAL.BANK-ACCOUNT` | +| **account** | **payment** | Payment data related to system account | `data-categories`:`FINANCIAL` | +| **account.payment** | **financial_account_number** | Payment data related to system account | `data-categories`:`FINANCIAL.BANK-ACCOUNT` | ##### System Data Categories > Data unique to, and under control of the system | Ethyca Parent key | **Ethyca Label** | Ethyca Description | Representation | | ------------ | -------------------------------------- | ------------ | ------------ | -| **system** | **authentication** | Data used to manage access to the system | data-category:`OTHER-DATA` | -| **system** | **operations** | Data used for system operations | data-category:`**Any/all**`, processing-category:`**Any/all**` | +| **system** | **authentication** | Data used to manage access to the system | `data-categories`:`OTHER-DATA` | +| **system** | **operations** | Data used for system operations | `data-categories`:`**Any/all**`, `processing-categories`:`**Any/all**` | ##### User Data Categories > Data related to the user of the system @@ -213,72 +213,72 @@ In the following examples we show how, requests introduced by different regulati | Ethyca Parent key | **Ethyca Label** | Ethyca Description | Representation | | ------------ | -------------------------------------- | ------------ | ------------ | -| **user.derived** | **identifiable** | Derived data that is linked to, or identifies a user | data-category:`**Any/all**`, provenance:`DERIVED` | -| **user.derived.identifable** | **biometric_health** | Encoded characteristic collected about a user | data-category:`BIOMETRIC`,`HEALTH`, provenance:`DERIVED` | -| **user.derived.identifable** | **browsing_history** | Content browsing history of a user | data-category:`BEHAVIOR`, provenance:`DERIVED` | -| **user.derived.identifable** | **contact** | Contact data collected about a user | data-category:`CONTACT`,provenance:`DERIVED` | -| **user.derived.identifable** | **demographic** | Demographic data about a user | data-category:`DEMOGRAPHIC`, provenance:`DERIVED` | -| **user.derived.identifable** | **gender** | Gender of an individual | data-category:`DEMOGRAPHIC.GENDER`, provenance:`DERIVED` | -| **user.derived.identifable** | **location** | Records of the location of a user | data-category:`LOCATION`, provenance:`DERIVED` | -| **user.derived.identifable** | **media_consumption** | Media type consumption data of a user | data-category:`BEHAVIOR`, provenance:`DERIVED` | -| **user.derived.identifable** | **non_specific_age** | Age range data | data-category:`DEMOGRAPHIC.AGE`, provenance:`DERIVED` | -| **user.derived.identifable** | **observed** | Data collected through observation of use of the system | data-category:`BEHAVIOR`, provenance:`DERIVED` | -| **user.derived.identifable** | **organization** | Derived data that is linked to, or identifies an organization | data-category:`AFFILIATION`, provenance:`DERIVED` | -| **user.derived.identifable** | **profiling** | Preference and interest data about a user | data-category:`BEHAVIOR.PREFERENCE` (/!\ not same meaning for our PROFILING cat), provenance:`DERIVED` | -| **user.derived.identifable** | **race** | Racial or ethnic origin data | data-category:`DEMOGRAPHIC.RACE`, provenance:`DERIVED` | -| **user.derived.identifable** | **religious_belief** | Religion or religious belief | data-category:`DEMOGRAPHIC.BELIEFS`, provenance:`DERIVED` | -| **user.derived.identifable** | **search_history** | Records of search history and queries of a user | data-category:`BEHAVIOR`, provenance:`DERIVED` | -| **user.derived.identifable** | **sexual_orientation** | Personal sex life or sexual data | data-category:`DEMOGRAPHIC.SEXUAL-ORIENTATION`, provenance:`DERIVED` | -| **user.derived.identifable** | **social** | Social activity and interaction data | data-category:`RELATIONSHIPS`, provenance:`DERIVED` | -| **user.derived.identifable** | **telemetry** | User identifiable measurement data from system sensors and monitoring | data-category:`BEHAVIOR.TELEMETRY`, provenance:`DERIVED` | -| **user.derived.identifable** | **unique_id** | Unique identifier for a user assigned through system use | data-category:`UID`, provenance:`DERIVED` | -| **user.derived.identifable** | **user_sensor** | Measurement data derived about a user's environment through system use | data-category:`BEHAVIOR`,`COLLECTION`, provenance:`DERIVED` | -| **user.derived.identifable** | **workplace** | Organization of employment | data-category:`AFFILIATION.WORK`, provenance:`DERIVED` | -| **user.derived.identifable** | **device** | Data related to a user's device, configuration and setting | data-category:`DEVICE`, provenance:`DERIVED` | -| **user.derived.identifable** | **cookie_id** | Cookie unique identification number | data-category:`BEHAVIOR`, provenance:`DERIVED` | -| **user.derived.identifable** | **device_id** | Device unique identification number | data-category:`DEVICE`, provenance:`DERIVED` | -| **user.derived.identifable** | **ip_address** | Unique identifier related to device connection | data-category:`DEVICE`, provenance:`DERIVED` | -| **user.derived** | **nonidentifiable** | Non-user identifiable data derived related to a user as a result of user actions in the system | data-category:`OTHER-DATA`, provenance:`DERIVED` | -| **user.derived.nonidentifiable** | **nonsensor** | Non-user identifiable measurement data derived from sensors and monitoring systems | data-category:`OTHER-DATA`, provenance:`DERIVED` | +| **user.derived** | **identifiable** | Derived data that is linked to, or identifies a user | `data-categories`:`**Any/all**`, provenance:`DERIVED` | +| **user.derived.identifable** | **biometric_health** | Encoded characteristic collected about a user | `data-categories`:`BIOMETRIC`,`HEALTH`, provenance:`DERIVED` | +| **user.derived.identifable** | **browsing_history** | Content browsing history of a user | `data-categories`:`BEHAVIOR`, provenance:`DERIVED` | +| **user.derived.identifable** | **contact** | Contact data collected about a user | `data-categories`:`CONTACT`,provenance:`DERIVED` | +| **user.derived.identifable** | **demographic** | Demographic data about a user | `data-categories`:`DEMOGRAPHIC`, provenance:`DERIVED` | +| **user.derived.identifable** | **gender** | Gender of an individual | `data-categories`:`DEMOGRAPHIC.GENDER`, provenance:`DERIVED` | +| **user.derived.identifable** | **location** | Records of the location of a user | `data-categories`:`LOCATION`, provenance:`DERIVED` | +| **user.derived.identifable** | **media_consumption** | Media type consumption data of a user | `data-categories`:`BEHAVIOR`, provenance:`DERIVED` | +| **user.derived.identifable** | **non_specific_age** | Age range data | `data-categories`:`DEMOGRAPHIC.AGE`, provenance:`DERIVED` | +| **user.derived.identifable** | **observed** | Data collected through observation of use of the system | `data-categories`:`BEHAVIOR`, provenance:`DERIVED` | +| **user.derived.identifable** | **organization** | Derived data that is linked to, or identifies an organization | `data-categories`:`AFFILIATION`, provenance:`DERIVED` | +| **user.derived.identifable** | **profiling** | Preference and interest data about a user | `data-categories`:`BEHAVIOR.PREFERENCE` (/!\ not same meaning for our PROFILING cat), provenance:`DERIVED` | +| **user.derived.identifable** | **race** | Racial or ethnic origin data | `data-categories`:`DEMOGRAPHIC.RACE`, provenance:`DERIVED` | +| **user.derived.identifable** | **religious_belief** | Religion or religious belief | `data-categories`:`DEMOGRAPHIC.BELIEFS`, provenance:`DERIVED` | +| **user.derived.identifable** | **search_history** | Records of search history and queries of a user | `data-categories`:`BEHAVIOR`, provenance:`DERIVED` | +| **user.derived.identifable** | **sexual_orientation** | Personal sex life or sexual data | `data-categories`:`DEMOGRAPHIC.SEXUAL-ORIENTATION`, provenance:`DERIVED` | +| **user.derived.identifable** | **social** | Social activity and interaction data | `data-categories`:`RELATIONSHIPS`, provenance:`DERIVED` | +| **user.derived.identifable** | **telemetry** | User identifiable measurement data from system sensors and monitoring | `data-categories`:`BEHAVIOR.TELEMETRY`, provenance:`DERIVED` | +| **user.derived.identifable** | **unique_id** | Unique identifier for a user assigned through system use | `data-categories`:`UID`, provenance:`DERIVED` | +| **user.derived.identifable** | **user_sensor** | Measurement data derived about a user's environment through system use | `data-categories`:`BEHAVIOR`,`COLLECTION`, provenance:`DERIVED` | +| **user.derived.identifable** | **workplace** | Organization of employment | `data-categories`:`AFFILIATION.WORK`, provenance:`DERIVED` | +| **user.derived.identifable** | **device** | Data related to a user's device, configuration and setting | `data-categories`:`DEVICE`, provenance:`DERIVED` | +| **user.derived.identifable** | **cookie_id** | Cookie unique identification number | `data-categories`:`BEHAVIOR`, provenance:`DERIVED` | +| **user.derived.identifable** | **device_id** | Device unique identification number | `data-categories`:`DEVICE`, provenance:`DERIVED` | +| **user.derived.identifable** | **ip_address** | Unique identifier related to device connection | `data-categories`:`DEVICE`, provenance:`DERIVED` | +| **user.derived** | **nonidentifiable** | Non-user identifiable data derived related to a user as a result of user actions in the system | `data-categories`:`OTHER-DATA`, provenance:`DERIVED` | +| **user.derived.nonidentifiable** | **nonsensor** | Non-user identifiable measurement data derived from sensors and monitoring systems | `data-categories`:`OTHER-DATA`, provenance:`DERIVED` | ###### User Provided Data > Data provided or created directly by a user of the system | Ethyca Parent key | **Ethyca Label** | Ethyca Description | Representation | | ------------ | -------------------------------------- | ------------ | ------------ | -| **user.provided** | **identifiable** | Data provided or created directly by a user that is linked to or identifies a user | data-category :`**any/all**`, provenance:`USER` | -| **user.provided.identifiable** | **identifiable** | Encoded characteristics provided by a user | data-category :`**any/all**`, provenance:`USER`| -| **user.provided.identifiable** | **children** | Data relating to children | data-category :`**any/all**`, provenance:`USER` @milstan: I don't think the fact someone is a child makes it a separate Data Category. The same person can turn 18 and no longer be a child - and data category can't change due to that. So this should be the responsibility of the System to use AGE to determine if special child-related policies must apply. | -| **user.provided.identifiable** | **health_and_medical** | Health records or individual's personal medical information | data-category :`HEALTH` provenance:`USER` | -| **user.provided.identifiable** | **job_title** | Professional data | data-category :`CONTACT`, provenance:`USER` | -| **user.provided.identifiable** | **name** | User's real name | data-category :`NAME`, provenance:`USER` | -| **user.provided.identifiable** | **non_specific_age** | Age range data | data-category :`DEMOGRAPHIC.AGE`, provenance:`USER` | -| **user.provided.identifiable** | **political_opinion** | Data related to the individual's political opinions | data-category :`DEMOGRAPHIC.BELIEFS`, provenance:`USER` | -| **user.provided.identifiable** | **race** | Racial or ethnic origin data | data-category :`DEMOGRAPHIC.RACE`, provenance:`USER` | -| **user.provided.identifiable** | **religious_belief** | Religion or religious belief | data-category :`DEMOGRAPHIC.BELIEFS`, provenance:`USER` | -| **user.provided.identifiable** | **sexual_orientation** | Personal sex life or sexual data | data-category :`DEMOGRAPHIC.SEXUAL-ORIENTATION`, provenance:`USER` | -| **user.provided.identifiable** | **workplace** | Organization of employment | data-category :`AFFILIATION.WORK`, provenance:`USER` | -| **user.provided.identifiable** | **date_of_birth** | User's date of birth | data-category :`DEMOGRAPHIC.AGE`, provenance:`USER` | -| **user.provided.identifiable** | **gender** | Gender of an individual | data-category :`DEMOGRAPHIC.GENDER`, provenance:`USER` | -| **user.provided.identifiable** | **genetic** | Data about the genetic makeup provided by a user | data-category :`GENETIC`, provenance:`USER` | -| **user.provided.identifiable** | **contact** | User provided contact data for purposes other than account management | data-category :`CONTACT`, provenance:`USER` | -| **user.provided.identifiable** | **city** | User's city level address data | data-category :`CONTACT.ADDRESS`, provenance:`USER` | -| **user.provided.identifiable** | **country** | User's country level address data | data-category :`CONTACT.ADDRESS`, provenance:`USER` | -| **user.provided.identifiable** | **email** | User's provided email address | data-category :`CONTACT.EMAIL`, provenance:`USER` | -| **user.provided.identifiable** | **phone_number** | User's phone number | data-category :`CONTACT.PHONE`, provenance:`USER` | -| **user.provided.identifiable** | **postal_code** | User's postal code | data-category :`CONTACT.ADDRESS`, provenance:`USER` | -| **user.provided.identifiable** | **state** | User's state level address data | data-category :`CONTACT.ADDRESS`, provenance:`USER` | -| **user.provided.identifiable** | **street** | User's street level address data | data-category :`CONTACT.ADDRESS`, provenance:`USER` | -| **user.provided.identifiable** | **credentials** | User provided authentication data | data-category :`UID.USER-ACCOUNT`, provenance:`USER` | -| **user.provided.identifiable** | **biometric_credentials** | User provided authentication data | data-category :`UID.USER-ACCOUNT`,`BIOMETRIC`, provenance:`USER` | -| **user.provided.identifiable** | **password** | Password for system authentication | data-category :`UID.USER-ACCOUNT`, provenance:`USER` | -| **user.provided.identifiable** | **financial** | Payment data and financial history | data-category :`FINANCIAL`, provenance:`USER` | -| **user.provided.identifiable** | **account_number** | User's account number for a payment card, bank account, or other financial system | data-category :`FINANCIAL.BANK-ACCOUNT`, provenance:`USER` | -| **user.provided.identifiable** | **government_id** | State provided identification data | data-category :`UID.ID`, provenance:`USER` | -| **user.provided.identifiable** | **drivers_license_number** | State issued driving identification number | data-category :`UID.ID`, provenance:`USER` | -| **user.provided.identifiable** | **national_identification_number** | State issued personal identification number |data-category :`UID.ID`, provenance:`USER` | -| **user.provided.identifiable** | **passport_number** | State issued passport data | data-category :`UID.ID`, provenance:`USER` | -| **user.provided** | **nonidentifiable** | Data provided or created directly by a user that is not identifiable | data-category :`OTHER-DATA`, provenance:`USER` | +| **user.provided** | **identifiable** | Data provided or created directly by a user that is linked to or identifies a user | `data-categories`:`**any/all**`, provenance:`USER` | +| **user.provided.identifiable** | **identifiable** | Encoded characteristics provided by a user | data-categories :`**any/all**`, provenance:`USER`| +| **user.provided.identifiable** | **children** | Data relating to children | `data-categories` :`**any/all**`, provenance:`USER` @milstan: I don't think the fact someone is a child makes it a separate Data Category. The same person can turn 18 and no longer be a child - and data category can't change due to that. So this should be the responsibility of the System to use AGE to determine if special child-related policies must apply. | +| **user.provided.identifiable** | **health_and_medical** | Health records or individual's personal medical information | `data-categories` :`HEALTH` provenance:`USER` | +| **user.provided.identifiable** | **job_title** | Professional data | `data-categories` :`CONTACT`, provenance:`USER` | +| **user.provided.identifiable** | **name** | User's real name | `data-categories` :`NAME`, provenance:`USER` | +| **user.provided.identifiable** | **non_specific_age** | Age range data | `data-categories` :`DEMOGRAPHIC.AGE`, provenance:`USER` | +| **user.provided.identifiable** | **political_opinion** | Data related to the individual's political opinions | `data-categories` :`DEMOGRAPHIC.BELIEFS`, provenance:`USER` | +| **user.provided.identifiable** | **race** | Racial or ethnic origin data | `data-categories` :`DEMOGRAPHIC.RACE`, provenance:`USER` | +| **user.provided.identifiable** | **religious_belief** | Religion or religious belief | `data-categories` :`DEMOGRAPHIC.BELIEFS`, provenance:`USER` | +| **user.provided.identifiable** | **sexual_orientation** | Personal sex life or sexual data | `data-categories` :`DEMOGRAPHIC.SEXUAL-ORIENTATION`, provenance:`USER` | +| **user.provided.identifiable** | **workplace** | Organization of employment | `data-categories` :`AFFILIATION.WORK`, provenance:`USER` | +| **user.provided.identifiable** | **date_of_birth** | User's date of birth | `data-categories` :`DEMOGRAPHIC.AGE`, provenance:`USER` | +| **user.provided.identifiable** | **gender** | Gender of an individual | `data-categories` :`DEMOGRAPHIC.GENDER`, provenance:`USER` | +| **user.provided.identifiable** | **genetic** | Data about the genetic makeup provided by a user | `data-categories` :`GENETIC`, provenance:`USER` | +| **user.provided.identifiable** | **contact** | User provided contact data for purposes other than account management | `data-categories` :`CONTACT`, provenance:`USER` | +| **user.provided.identifiable** | **city** | User's city level address data | `data-categories` :`CONTACT.ADDRESS`, provenance:`USER` | +| **user.provided.identifiable** | **country** | User's country level address data | `data-categories` :`CONTACT.ADDRESS`, provenance:`USER` | +| **user.provided.identifiable** | **email** | User's provided email address | `data-categories` :`CONTACT.EMAIL`, provenance:`USER` | +| **user.provided.identifiable** | **phone_number** | User's phone number | `data-categories` :`CONTACT.PHONE`, provenance:`USER` | +| **user.provided.identifiable** | **postal_code** | User's postal code | `data-categories` :`CONTACT.ADDRESS`, provenance:`USER` | +| **user.provided.identifiable** | **state** | User's state level address data | `data-categories` :`CONTACT.ADDRESS`, provenance:`USER` | +| **user.provided.identifiable** | **street** | User's street level address data | `data-categories` :`CONTACT.ADDRESS`, provenance:`USER` | +| **user.provided.identifiable** | **credentials** | User provided authentication data | `data-categories` :`UID.USER-ACCOUNT`, provenance:`USER` | +| **user.provided.identifiable** | **biometric_credentials** | User provided authentication data | `data-categories` :`UID.USER-ACCOUNT`,`BIOMETRIC`, provenance:`USER` | +| **user.provided.identifiable** | **password** | Password for system authentication | `data-categories` :`UID.USER-ACCOUNT`, provenance:`USER` | +| **user.provided.identifiable** | **financial** | Payment data and financial history | `data-categories` :`FINANCIAL`, provenance:`USER` | +| **user.provided.identifiable** | **account_number** | User's account number for a payment card, bank account, or other financial system | `data-categories` :`FINANCIAL.BANK-ACCOUNT`, provenance:`USER` | +| **user.provided.identifiable** | **government_id** | State provided identification data | `data-categories` :`UID.ID`, provenance:`USER` | +| **user.provided.identifiable** | **drivers_license_number** | State issued driving identification number | `data-categories` :`UID.ID`, provenance:`USER` | +| **user.provided.identifiable** | **national_identification_number** | State issued personal identification number |`data-categories` :`UID.ID`, provenance:`USER` | +| **user.provided.identifiable** | **passport_number** | State issued passport data | `data-categories` :`UID.ID`, provenance:`USER` | +| **user.provided** | **nonidentifiable** | Data provided or created directly by a user that is not identifiable | `data-categories` :`OTHER-DATA`, provenance:`USER` | #### Transcend @@ -289,9 +289,9 @@ Transcend proposes the following [action (demand) types](https://github.com/tran | ERASURE | Erase the file completely | action:`DELETE`, other properties:`Data-identifier` | | ACCOUNT_DELETION | Run an account deletion instead of a fully compliant deletion | action:`DELETE`, other properties: `Data-identifier` | | AUTOMATED_DECISION_MAKING_OPT_OUT | Opt out of automated decision making | action:`RESTRICT`, processing-categories:`AUTOMATED-DECISION-MAKING`| -| CONTACT_OPT_OUT | A contact opt out request | action:`RESTRICT`, data-category:`CONTACT`, processing-category:`USING`, purpose:`MARKETING`| -| SALE_OPT_OUT | Opt-out of the sale of personal data | action:`RESTRICT`, processing-category:`SHARE`, purpose:`SALE` | -| TRACKING_OPT_OUT | A tracking opt out request | action:`RESTRICT`, processing-category:`COLLECTION`, purpose:`TRACKING` | +| CONTACT_OPT_OUT | A contact opt out request | action:`RESTRICT`, `data-categories`:`CONTACT`, `processing-categories`:`USING`, purpose:`MARKETING`| +| SALE_OPT_OUT | Opt-out of the sale of personal data | action:`RESTRICT`, `processing-categories`:`SHARE`, purpose:`SALE` | +| TRACKING_OPT_OUT | A tracking opt out request | action:`RESTRICT`, `processing-categories`:`COLLECTION`, purpose:`TRACKING` | | RECTIFICATION | Make an update to an inaccurate record | action:`MODIFY`, other properties: `Selector.to-modify`,`Data.rectified` | | RESTRICTION | A restriction of processing request | action:`RESTRICT` | @@ -300,42 +300,42 @@ All of those can be modeled using our Demand Types. Transcend proposes the following [treatment types](https://github.com/transcend-io/privacy-types/blob/main/src/objects.ts): | Transcend Treatment Type | Transcend Description | Representation | | -------------- | ----------------------------------------- | ------------------------ | -| ESSENTIAL | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality| processing-category:`**any/all**`, purpose:`SERVICES.BASIC-SERVICE` | -| ADDITIONAL_FUNCTIONALITY | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | processing-category:`**any/all**`, purpose:`SERVICES.ADDITIONAL-SERVICE` | -| ADVERTISING | To show ads that are either targeted to the specific user or not targeted | processing-category:`**any/all**`, purpose:`ADVERTISING` | -| MARKETING | To contact the user to offer products, services, or other promotions | processing-category:`**any/all**`, purpose:`MARKETING` | -| ANALYTICS | For understanding the product’s audience, improving the product, inform company strategy, or general research | processing-category:`**any/all**`, purpose:`RESEARCH` | -| PERSONALIZATION | For providing user with a personalized experience | processing-category:`**any/all**`, purpose:`PERSONALISATION` | -| OPERATION_SECURITY | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | processing-category:`**any/all**`, purpose:`SECURITY` | -| LEGAL | For compliance with legal obligations | processing-category:`**any/all**`, purpose:`COMPLIANCE` | -| TRANSFER | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | processing-category:`COLLECTION`, provenance:`TRANSFERRED` | -| SALE | For selling the data to third parties | processing-category:`**any/all**`, purpose:`SALE` | -| HR | For personnel training, recruitment, payroll, management, etc. | processing-category:`**any/all**`, purpose:`EMPLOYMENT` | -| OTHER | Other specific purpose not covered above | processing-category:`**any/all**`, purpose:`OTHER-PURPOSE` use `message` to specify| -| UNSPECIFIED | The purpose is not explicitly stated or is unclear | processing-category:`**any/all**`, purpose:`OTHER-PURPOSE` use `message` to specify| +| ESSENTIAL | Provide a service that the user explicitly requests and that is part of the product's basic service or functionality| `processing-categories`:`**any/all**`, purpose:`SERVICES.BASIC-SERVICE` | +| ADDITIONAL_FUNCTIONALITY | Provide a service that the user explicitly requests but that is not a necessary part of the product's basic service | `processing-categories`:`**any/all**`, purpose:`SERVICES.ADDITIONAL-SERVICE` | +| ADVERTISING | To show ads that are either targeted to the specific user or not targeted | `processing-categories`:`**any/all**`, purpose:`ADVERTISING` | +| MARKETING | To contact the user to offer products, services, or other promotions | `processing-categories`:`**any/all**`, purpose:`MARKETING` | +| ANALYTICS | For understanding the product’s audience, improving the product, inform company strategy, or general research | `processing-categories`:`**any/all**`, purpose:`RESEARCH` | +| PERSONALIZATION | For providing user with a personalized experience | `processing-categories`:`**any/all**`, purpose:`PERSONALIZATION` | +| OPERATION_SECURITY | For product operation and security, enforcement of terms of service, fraud prevention, protecting users and property, etc. | `processing-categories`:`**any/all**`, purpose:`SECURITY` | +| LEGAL | For compliance with legal obligations | `processing-categories`:`**any/all**`, purpose:`COMPLIANCE` | +| TRANSFER | For data that was transferred as part of a change in circumstance (e.g. a merger or acquisition) | `processing-categories`:`COLLECTION`, provenance:`TRANSFERRED` | +| SALE | For selling the data to third parties | `processing-categories`:`**any/all**`, purpose:`SALE` | +| HR | For personnel training, recruitment, payroll, management, etc. | `processing-categories`:`**any/all**`, purpose:`EMPLOYMENT` | +| OTHER | Other specific purpose not covered above | `processing-categories`:`**any/all**`, purpose:`OTHER-PURPOSE` use `message` to specify| +| UNSPECIFIED | The purpose is not explicitly stated or is unclear | `processing-categories`:`**any/all**`, purpose:`OTHER-PURPOSE` use `message` to specify| All of those SHOULD be modeled using our Treatment Types. Transcend proposes the following [data categories](https://github.com/transcend-io/privacy-types/blob/main/src/objects.ts): | Transcend Data Category | Transcend Description | Representation | | -------------- | ----------------------------------------- | ------------------------ | -| FINANCIAL | Financial information | data-category:`FINANCIAL` | -| HEALTH | Health information | data-category:`HEALTH` | -| CONTACT | Contact information | data-category:`CONTACT` | -| LOCATION | Geo-location information | data-category:`LOCATION` | -| DEMOGRAPHIC | Demographic Information | data-category:`DEMOGRAPHIC` | -| ID | Identifiers that uniquely identify a person | data-category:`UID` | -| ONLINE_ACTIVITY | The user's online activities on the first party website/app or other websites/apps | data-category:`BEHAVIOR.ACTIVITY` | -| USER_PROFILE | he user’s profile on the first-party website/app and its contents | data-category:`UID.USER-ACCOUNT` | -| SOCIAL_MEDIA | User profile and data from a social media website/app or other third party service | data-category:`UID.SOCIAL-MEDIA` | -| CONNECTION | Connection information for the current browsing session, e.g. device IDs, MAC addresses, IP addresses, etc. | data-category:`DEVICE`,`BEHAVIOR.CONNECTION` | -| TRACKING | Cookies and tracking elements | data-category:`BEHAVIOR`, purpose:`TRACKING` | -| DEVICE | Computer or device information | data-category:`DEVICE` | -| SURVEY | Any data that is collected through surveys | data-category:`OTHER-DATA` | -| OTHER | A specific type of information not covered by the above categories | data-category:`OTHER-DATA` use `message` to specify| -| UNSPECIFIED | The type of information is not explicitly stated or unclear| data-category:`OTHER-DATA` use `message` to specify| - -#### Transcend +| FINANCIAL | Financial information | `data-categories`:`FINANCIAL` | +| HEALTH | Health information | `data-categories`:`HEALTH` | +| CONTACT | Contact information | `data-categories`:`CONTACT` | +| LOCATION | Geo-location information | `data-categories`:`LOCATION` | +| DEMOGRAPHIC | Demographic Information | `data-categories`:`DEMOGRAPHIC` | +| ID | Identifiers that uniquely identify a person | `data-categories`:`UID` | +| ONLINE_ACTIVITY | The user's online activities on the first party website/app or other websites/apps | `data-categories`:`BEHAVIOR.ACTIVITY` | +| USER_PROFILE | he user’s profile on the first-party website/app and its contents | `data-categories`:`UID.USER-ACCOUNT` | +| SOCIAL_MEDIA | User profile and data from a social media website/app or other third party service | `data-categories`:`UID.SOCIAL-MEDIA` | +| CONNECTION | Connection information for the current browsing session, e.g. device IDs, MAC addresses, IP addresses, etc. | `data-categories`:`DEVICE`,`BEHAVIOR.CONNECTION` | +| TRACKING | Cookies and tracking elements | `data-categories`:`BEHAVIOR`, purpose:`TRACKING` | +| DEVICE | Computer or device information | `data-categories`:`DEVICE` | +| SURVEY | Any data that is collected through surveys | `data-categories`:`OTHER-DATA` | +| OTHER | A specific type of information not covered by the above categories | `data-categories`:`OTHER-DATA` use `message` to specify| +| UNSPECIFIED | The type of information is not explicitly stated or unclear| `data-categories`:`OTHER-DATA` use `message` to specify| + +#### HIPPA The following correspondence of [data categories](https://www.luc.edu/its/aboutits/itspoliciesguidelines/hipaainformation/18hipaaidentifiers/) needed for [HIPPA](https://www.hhs.gov/hipaa) compliance can be used: diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index e8dd4a0f..279202b6 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -1,4 +1,4 @@ -# Privacy Request Interchange Vocabulary : Expected Behavior of Implementing Systems +*[Privacy Scope Triples](#privacy-scope-triples)# Privacy Request Interchange Vocabulary : Expected Behavior of Implementing Systems | Status | draft | | :------------ | :------------------------------------------------------------------------------------- | @@ -27,18 +27,18 @@ The purpose of the document is primarily illustrate a possible behavior Systems - All key words denoting components of [blindnet devkit](../lexicon/RFC-Lexicon-2.md#blindnet-devkit), such as "Capture Component", "Encryption and Access Management Engine", "Privacy Computation Engine", "Privacy Compiler", "Privacy Request Capture Interface", "Customization API", "Data Consumer Interface", "Schemas" and "Storage Component" are to be interpreted as defined in [High Level Architecture](../high-level-conceptualization/) - Privacy Compiler was formerly known as Data Rights Compiler - Privacy Request was formerly known as Data Rights Request -- All the concepts, properties and terms listed in the [Proposal](./RFC-PRIV.md#proposal) section of PRIV(Privacy Request Interchange Vocabulary are to be interpreted as defined in [Privacy Request Interchange Vocabulary](./RFC-PRIV.md#proposal) +- All the concepts, properties and [Terms](./RFC-PRIV.md#terms) listed in the [Proposal](./RFC-PRIV.md#proposal) section of PRIV(Privacy Request Interchange Vocabulary are to be interpreted as defined in [Privacy Request Interchange Vocabulary](./RFC-PRIV.md#proposal) ## Scope of automation Privacy Requests can be resolved more or less automatically. -Privacy Requests that are expressed in unambiguous terms, may be fully processed automatically. -Those that include the keyword "OTHER" or a textual message with more details about the request likely require human intervention. +Privacy Requests that are expressed in unambiguous [Terms](./RFC-PRIV.md#terms), may be fully processed automatically. +Those that include any [Terms](./RFC-PRIV.md#terms) containing the string "OTHER" or a textual message with more details about the request likely require human intervention. Cf. [different automation scenarios](./scenarios.md#automation) Systems MAY be configured to treat Privacy Requests eligible for automation with or without human validation. In any case, the role of the [Privacy Compiler](../high-level-architecture#data-rights-compiler) is to calculate the appropriate action, given particular Privacy Request in a particular situation. -Systems MAY also want to direct certain requests (such as `MODIFY`) to dedicated interfaces that they may already have for Data Subjects to provide and modify their data. +Systems CAN also direct certain requests (such as `MODIFY`) to dedicated interfaces that they may already have for Data Subjects to provide and modify their data. Because of this Systems MUST be able to configure their particular ways of automating the processing of Privacy Requests. @@ -55,10 +55,8 @@ A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a - *Provenance*: For every **Known Selector** keep track of one or more [Provenance](./RFC-PRIV.md#provenance) objects. - - **Intended Privacy Scope** : A set of **Privacy Scope Triple**s that describe the usage the System is likely to make with data. Each triple consists of: - - a `selector` (or Data Category implying every `selector` used within that Data Category) - - a Processing Category (or any of their subcategories defined according to [Term Dot Notation](./RFC-PRIV.md#term-dot-notation)) that the System is likely to perform on that data - - a Purpose (or any of their subcategories defined according to [Term Dot Notation](./RFC-PRIV.md#term-dot-notation) + - **Intended Privacy Scope** : A set of **[Privacy Scope Triples](#privacy-scope-triples)** that describe the usage the System is likely to make with data. + Each **Known Selector** MUST be included in the The Intended Privacy Scope. > **Note** @@ -68,10 +66,9 @@ A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a > This is necessary for interoperability with the specific Processing Categories of the [HL7 Standards](./RFC-PRIV.md#hl7-standards) > + - *Legal Bases*: For each [Privacy Scope Triple](#privacy-scope-triples) from the **Intended Privacy Scope**, one or more [Legal Bases](./RFC-PRIV.md#legal-bases) - - *Legal Bases*: For each **Privacy Scope Triple** from the **Intended Privacy Scope**, one or more [Legal Bases](./RFC-PRIV.md#legal-bases) - - - *Corresponding Systems*: A map of Other Systems with which data is being exchanged. For each System The Privacy Compiler MUST know if they are an `ORGANISATION` or `PARTNERS` System, and have a way to uniquely identify and address them (see [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV), [Working with Provenance](#working-with-provenance)) + - *Corresponding Systems*: A map of Other Systems with which data is being exchanged. For each System The Privacy Compiler MUST know if they are an `ORGANIZATION` or `PARTNERS` System, and have a way to uniquely identify and address them (see [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV), [Working with Provenance](#working-with-provenance)) - **Privacy Metadata Store**, updated at runtime: - *All Captures*: a list of all the [Data Capture](./RFC-PRIV.md#data-capture) objects that the Privacy Compiler is aware of @@ -80,8 +77,8 @@ A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a - Legal Bases: - *All Consents*: a list of all the [Consent](./RFC-PRIV.md#consent) objects that the Privacy Compiler is aware of - *All Contracts*: establishing a correspondence between a Data Subject and a `contract-id` being an identifier of a particular relationship that the Data Subject has with the system (e.g. a user account open with the system, employment contract, a court case treated by a lawfirm, etc.) with a `start` date and (optionally, if ended) a `end` date. - - *All Legitimate Interests*: establishing a correspondence between a Data Subject and each **Privacy Scope Triple** included in the **Intended Privacy Scope** under `LEGITIMATE-INTEREST` - - *Necessary*: establishing a correspondence between a Data Subject and each **Privacy Scope Triple** included in the **Intended Privacy Scope** under `NECESSARY` Legal Base + - *All Legitimate Interests*: establishing a correspondence between a Data Subject and each [Privacy Scope Triples](#privacy-scope-triples) included in the **Intended Privacy Scope** under `LEGITIMATE-INTEREST` + - *Necessary*: establishing a correspondence between a Data Subject and each [Privacy Scope Triple](#privacy-scope-triples) included in the **Intended Privacy Scope** under `NECESSARY` Legal Base - **Runtime Maps**, updated at runtime: - Active Legal Bases: @@ -89,26 +86,55 @@ A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a - *Active Contracts*: a list of `contract-id`s of all active contracts that have not been subject to a `RELATIONSHIP-END` event - *Active Legitimate Interests*: a subset of *All Legitimate Interests* - Events, for [Resolving Retention Policies](#resolving-retention-policies): - - `SERVICE-END` events for contracts that end (e.g. user closes the account, or stops a service agreement), that directly impact *Active Contracts* the **Privacy Scope Triple**s of which have not been in the scope of any `DELETE`, `OBJECT`, or `RESTRICT` Privacy Request by the data Subject concerned + - `SERVICE-END` events for contracts that end (e.g. user closes the account, or stops a service agreement), that directly impact *Active Contracts* the [Privacy Scope Triples](#privacy-scope-triples) of which have not been in the scope of any `DELETE`, `OBJECT`, or `RESTRICT` Privacy Request by the data Subject concerned - `RELATIONSHIP-END` events the Data Subject ended all contracts and ended the relationship with the System/Organization - `CAPTURE-DATE` when a Data Capture is made or updated - Transfers: - All the data exchanges with other Systems, as described in [Remembering Transfers](./RFC-PRIV.md#remembering-transfers). - Privacy Scope: - For each Data Subject, an **Eligible Privacy Scope**, according to [Privacy Algebra](#privacy-algebra). - This **Eligible Privacy Scope** is easily resolved at the level of each Data Capture Fragment (or `selector`) + This **Eligible Privacy Scope** is easily resolved at the level of each [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) (or its `selector`) + +## [Privacy Scope Triples](#privacy-scope-triples) + +A **Privacy Scope Triple** is a unit of [Privacy Scope](RFC-PRIV.md#privacy-scope) +and it consists of (in that order): + - one [Data Category Term](./RFC-PRIV.md#data-categories) or `*` + - one [Processing Category Term](./RFC-PRIV.md#processing-categories) or `*` + - one [Purpose Term](./RFC-PRIV.md#purpose) or `*` + +When `*` is indicated at one of the places of the triple, it is interpreted as all [Data Categores](./RFC-PRIV.md#data-categories), all [Processing Categories](./RFC-PRIV.md#processing-categories) or all [Purposes](./RFC-PRIV.md#purpose) depending on its place in the triple. + +Each [Privacy Scope Triple](#privacy-scope-triples) that includes a `*` or a [Term](./RFC-PRIV.md#terms) of which subcategory terms are known (including [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) `selectors` for [Data Category Terms](./RFC-PRIV.md#data-categories)) is equivalent to the set of Privacy Scope Triples including all combinations of such known subcategories (or all categories in case of `*`). + +E.g. `FINANCIAL` x `SHARING` x `SERVICES` is equivalent to the following set: + +`FINANCIAL` x `SHARING` x `SERVICES.ADDITIONAL-SERVICES` +`FINANCIAL` x `SHARING` x `SERVICES.BASIC-SERVICE` +`FINANCIAL.BANK-ACCOUNT` x `SHARING` x `SERVICES` +`FINANCIAL.BANK-ACCOUNT` x `SHARING` x `SERVICES.ADDITIONAL-SERVICES` +`FINANCIAL.BANK-ACCOUNT` x `SHARING` x `SERVICES.BASIC-SERVICE` + +If the System also knows of a `selector` `FINANCIAL.BANK-ACCOUNT.PRIMARY`, then the equivalent set also includes: + +`FINANCIAL.BANK-ACCOUNT.PRIMARY` x `SHARING` x `SERVICES` +`FINANCIAL.BANK-ACCOUNT.PRIMARY` x `SHARING` x `SERVICES.ADDITIONAL-SERVICES` +`FINANCIAL.BANK-ACCOUNT.PRIMARY` x `SHARING` x `SERVICES.BASIC-SERVICE` + +Systems MUST apply any operation concerning a Privacy Scope Triple to all of the Privacy Scope Triples equivalent to it. + ## Privacy Algebra For each Data Subject, at all times, the [Privacy Compiler](../high-level-architecture#data-rights-compiler) maintains an **Eligible Privacy Scope**. For each Data Capture Fragment `selector`, the Privacy Compiler knows the **Intended Privacy Scope**. -At the same time the Privacy Compiler knows about a set of Privacy Scope triples that are associated with an active Legal Base (in the **Runtime Maps**) +At the same time the Privacy Compiler knows about a set of [Privacy Scope Triples](#privacy-scope-triples) that are associated with an active Legal Base (in the **Runtime Maps**) -The **Eligible Privacy Scope**, is a set of Privacy Scope Triples, that is the INTERSECTION of: -- set of Privacy Scope triples in the **Intended Privacy Scope**, -- AND the set of Privacy Scope triples for which at least one of the following statements is true: - - They are associated with `CONSENT` legal base, and there is an active Consent such that the Privacy Scope Triple is contained in the Privacy Scope of that Consent +The **Eligible Privacy Scope**, is a set of [Privacy Scope Triples](#privacy-scope-triples), that is the INTERSECTION of: +- set of [Privacy Scope Triples](#privacy-scope-triples) in the **Intended Privacy Scope**, +- AND the set of [Privacy Scope Triples](#privacy-scope-triples) for which at least one of the following statements is true: + - They are associated with `CONSENT` legal base, and there is an active Consent such that the [Privacy Scope Triple](#privacy-scope-triples) is contained in the Privacy Scope of that Consent - They are associated with `CONTRACT` legal base, and there is an active relationship (`contract-id` in *Active Contracts*) with the Data Subject in question for which no `RELATIONSHIP-END` event has been registered - They are associated with `LEGITIMATE-INTEREST` legal base, and - IF the Data Subject made any `OBJECT` Demand, they are not part of Privacy Scope of any such Demand @@ -116,10 +142,10 @@ The **Eligible Privacy Scope**, is a set of Privacy Scope Triples, that is the I - They are associated with `NECESSARY` legal base The Privacy Compilers can be configured to evaluate Eligible Privacy Scopes in the context of particular regulations. -In this case, Privacy Compilers maintain a list of Privacy Scope triples prohibited by that regulation and they exclude them from the Eligible Privacy Scope. +In this case, Privacy Compilers maintain a list of [Privacy Scope Triples](#privacy-scope-triples) prohibited by that regulation and they exclude them from the Eligible Privacy Scope. E.g. under GDPR, it is prohibited to process gender and genetic data under any Legal Base other than Consent. -For convenience, Privacy Compilers MAY also keep track of a set of **Prohibited (Privacy Scope)-(Legal Base) Pairs**, in which they SHOULD include Privacy Scope triples made illegal by the legislation that they want to support. It might also be convenient, when Data Subject's `OBJECT` or `RESTRICT` Demands are granted over a particular Privacy Scope, to list that scope under `LEGITIMATE-INTEREST` in the **Prohibited (Privacy Scope)-(Legal Base) Pairs** for making sure not to re-include them in the **Eligible Privacy Scope** unless the user gives explicit consent, signs a contract or becomes subject to mandatory data keeping. +For convenience, Privacy Compilers MAY also keep track of a set of **Prohibited (Privacy Scope)-(Legal Base) Pairs**, in which they SHOULD include [Privacy Scope Triples](#privacy-scope-triples) made illegal by the legislation that they want to support. It might also be convenient, when Data Subject's `OBJECT` or `RESTRICT` Demands are granted over a particular Privacy Scope, to list that scope under `LEGITIMATE-INTEREST` in the **Prohibited (Privacy Scope)-(Legal Base) Pairs** for making sure not to re-include them in the **Eligible Privacy Scope** unless the user gives explicit consent, signs a contract or becomes subject to mandatory data keeping. > E.g. under GDPR, as processing of RACE data is only allowed under 'CONSENT' for medical research purposes, examples of **Prohibited (Privacy Scope)-(Legal Base) Pairs** include > @@ -158,7 +184,7 @@ Let us imagine a System, processing data about a Data Subject, and having collec "scope": { "data-categories":["CONTACT"], "processing-categories": ["SHARING", "STORING"], - "purposes":["PERSONALISATION", "MARKETING", "ADVERTISING"] + "purposes":["PERSONALIZATION", "MARKETING", "ADVERTISING"] } } ``` @@ -210,7 +236,7 @@ The [Privacy Compiler](../high-level-architecture#data-rights-compiler) SHOULD r "scope": { "data-categories":["CONTACT"], "processing-categories": ["SHARING", "STORING"], - "purposes":["PERSONALISATION"] + "purposes":["PERSONALIZATION"] } } ``` @@ -224,7 +250,7 @@ The [Privacy Compiler](../high-level-architecture#data-rights-compiler) SHOULD r ``` - Consider active the new consent: `4ec28dc8-8714-45a3-a710-c72cea6e6da4` -The System MAY continue to use the Data Subjects' data for personalising their experience but no longer has consent to use the data for marketing and advertising. +The System MAY continue to use the Data Subjects' data for personalizing their experience but no longer has consent to use the data for marketing and advertising. Let us now imagine the Data Subject making another Privacy Request, this time to object to any sharing of their e-mail address. For this, the following Privacy Request is made: @@ -246,10 +272,10 @@ Let us now imagine the Data Subject making another Privacy Request, this time to }], } ``` -At the time of receiving this request, the System has consent for `STORING` and `SHARING` all `CONTACT` data for `PERSONALISATION` purposes. +At the time of receiving this request, the System has consent for `STORING` and `SHARING` all `CONTACT` data for `PERSONALIZATION` purposes. When the System gets this request, the scope of the consent MUST change. The remaining scope of the consent will only include: -- `SHARING` of all `CONTACT` data other then `CONTACT.EMAIL`, for `PERSONALISATION` purposes, and -- `STORING` of all `CONTACT` for `PERSONALISATION` purposes +- `SHARING` of all `CONTACT` data other then `CONTACT.EMAIL`, for `PERSONALIZATION` purposes, and +- `STORING` of all `CONTACT` for `PERSONALIZATION` purposes The [Privacy Compiler](../high-level-architecture#data-rights-compiler) SHOULD resolve this request by: - Generating a Privacy Request Response with the `GRANTED` Status, @@ -277,7 +303,7 @@ The [Privacy Compiler](../high-level-architecture#data-rights-compiler) SHOULD r "scope": { "data-categories":["CONTACT"], "processing-categories": ["STORING"], - "purposes":["PERSONALISATION"] + "purposes":["PERSONALIZATION"] } } @@ -292,7 +318,7 @@ The [Privacy Compiler](../high-level-architecture#data-rights-compiler) SHOULD r "scope": { "data-categories":["CONTACT.ADDRESS", "CONTACT.PHONE"], "processing-categories": ["SHARING"], - "purposes":["PERSONALISATION"] + "purposes":["PERSONALIZATION"] } } ``` @@ -314,7 +340,7 @@ Let us now imagine the Data Subject making another Privacy Request, this time to ``` { - "request-id": "e848d0e0-41ab-492c-ae90-ca891b70abc1", + "request-id": "e848d0e0-41ab-492c-ae90-ca891b70abc1",TRANSPARENCY.ORGANIZATION "date": "2022-06-17T15:10:00+0000", "data-subject":[{ "dsid-schema": "email-sha-256", @@ -330,9 +356,9 @@ Let us now imagine the Data Subject making another Privacy Request, this time to } ``` -At the time of receiving this request, the System has consent for `STORING` of all `CONTACT` for `PERSONALISATION` purposes, and for `SHARING` of all `CONTACT` data other then `CONTACT.EMAIL`, for `PERSONALISATION` purposes. +At the time of receiving this request, the System has consent for `STORING` of all `CONTACT` for `PERSONALIZATION` purposes, and for `SHARING` of all `CONTACT` data other then `CONTACT.EMAIL`, for `PERSONALIZATION` purposes. -Afther processing the `RESTRICT` request, only the consent for `STORING` of all `CONTACT` for `PERSONALISATION` purposes remains valid. +After processing the `RESTRICT` request, only the consent for `STORING` of all `CONTACT` for `PERSONALIZATION` purposes remains valid. The [Privacy Compiler](../high-level-architecture#data-rights-compiler) SHOULD resolve this request by: - Generating a Privacy Request Response with the `GRANTED` Status, @@ -370,7 +396,7 @@ The system receives the following Privacy Request: The System MUST no longer consider this Consent (nor any other consent derived from it) active. The list of active consents MUST now become empty, because the only active consent `6c8211c7-c152-4ef4-b264-098ee6533f75` is derived from `4ec28dc8-8714-45a3-a710-c72cea6e6da4` which is derived from `6b3ad78c-2d4a-4575-8a9f-a69c2bfe0bd2` that the user now revokes. -The System SHOULD be able to deliver a timeline of Consents, Requests and Responses, that may serve as a proof of compliance and good faith. +The System SHOULD be able to deliver a timeline of Consents, Privacy Requests and Privacy Request Responses, that may serve as a proof of compliance and good faith. > **Note** > @@ -385,49 +411,49 @@ Also, as [we have seen](#updateConsent), `OBJECT` and `RESTRICT` Privacy Request In addition, when such Demands are received, the Eligible Privacy Scope SHOULD be recalculated. However, it is important to note that the `OBJECT` and `RESTRICT` Privacy Request Demands behave in very specific ways. Concretely: -- They don't affect Privacy Scope Triples that are included in the Eligible Privacy Scope under `CONTRACT` or `NECESSARY` legal bases, +- They don't affect [Privacy Scope Triples](#privacy-scope-triples) that are included in the Eligible Privacy Scope under `CONTRACT` or `NECESSARY` legal bases, - with regards to Consents, they affect only existing Consents, not the future ones. - Let us imagine for example that the Data Subject gave consent for processing of their data for any purpose. - Then later, the Data Subject makes an `OBJECT` Demand related to `SALE` purposes. - At this point all Privacy Scope Triples having `SALE` as purpose exit the Eligible Privacy Scope. - - This same Data Subject MAY again give consent for processing of their data for any purpose in which case the Privacy Scope Triples having `SALE` as purpose re-enter the Eligible Privacy Scope. + At this point all [Privacy Scope Triples](#privacy-scope-triples) having `SALE` as purpose exit the Eligible Privacy Scope. + - This same Data Subject MAY again give consent for processing of their data for any purpose in which case the [Privacy Scope Triples](#privacy-scope-triples) having `SALE` as purpose re-enter the Eligible Privacy Scope. -- with regards to Privacy Scope Triples that are integrated in the Eligible Privacy Scope under `LEGITIMATE-INTEREST`, once `OBJECT` or `RESTRICT` Demands are made, they affect present and future Eligible Privacy Scope. In other words, the Privacy Scope Triples that have exited the Eligible Privacy Scope due to `OBJECT` or `RESTRICT` Demands, can't re-enter Eligible Privacy Scope under `LEGITIMATE-INTEREST`. When several `OBJECT` or `RESTRICT` Demands are made over time, a particular Privacy Scope Triple that entered the Eligible Privacy Scope under `LEGITIMATE-INTEREST`, can remain in the Eligible Privacy Scope if and only if: +- with regards to [Privacy Scope Triples](#privacy-scope-triples) that are integrated in the Eligible Privacy Scope under `LEGITIMATE-INTEREST`, once `OBJECT` or `RESTRICT` Demands are made, they affect present and future Eligible Privacy Scope. In other words, the [Privacy Scope Triples](#privacy-scope-triples) that have exited the Eligible Privacy Scope due to `OBJECT` or `RESTRICT` Demands, can't re-enter Eligible Privacy Scope under `LEGITIMATE-INTEREST`. When several `OBJECT` or `RESTRICT` Demands are made over time, a particular [Privacy Scope Triple](#privacy-scope-triples) that entered the Eligible Privacy Scope under `LEGITIMATE-INTEREST`, can remain in the Eligible Privacy Scope if and only if: - It is not a part of union of Privacy Scopes of all `OBJECT` Demands, AND if - It is a part of the intersection of Privacy Scopes of all `RESTRICT` Demands Let us take an example to illustrate updating of Eligible Privacy Scope. At the beginning the System holds the Data Subjects e-mail address for prospecting purposes, under `LEGITIMATE-INTEREST` Legal Base. ``` Eligible Privacy Scope: -CONTACT.EMAIL x ALL x MARKETING (LEGITIMATE-INTEREST) +CONTACT.EMAIL x * x MARKETING (LEGITIMATE-INTEREST) ``` The Data Subject, after receiving a marketing e-mail, decides to open an account and start using the service. They provide their postal address for billing. While creating an account, they also give consent for their postal address to be used for advertising purposes. ``` Eligible Privacy Scope: -CONTACT.EMAIL x ALL x MARKETING (LEGITIMATE-INTEREST) -CONTACT.EMAIL x ALL x SERVICES (CONTRACT) -CONTACT.ADDRESS x ALL x SERVICES (CONTRACT) -CONTACT.ADDRESS x ALL x ADVERTISING (CONSENT) +CONTACT.EMAIL x * x MARKETING (LEGITIMATE-INTEREST) +CONTACT.EMAIL x * x SERVICES (CONTRACT) +CONTACT.ADDRESS x * x SERVICES (CONTRACT) +CONTACT.ADDRESS x * x ADVERTISING (CONSENT) ``` -The Data Subject realises that they are receiving too much advertising material and they formulate a Privacy Request with one `REVOKE-CONSENT` demand targeting particular consent that they gave. +The Data Subject realizes that they are receiving too much advertising material and they formulate a Privacy Request with one `REVOKE-CONSENT` demand targeting particular consent that they gave. ``` Eligible Privacy Scope: -CONTACT.EMAIL x ALL x MARKETING (LEGITIMATE-INTEREST) -CONTACT.EMAIL x ALL x SERVICES (CONTRACT) -CONTACT.ADDRESS x ALL x SERVICES (CONTRACT) +CONTACT.EMAIL x * x MARKETING (LEGITIMATE-INTEREST) +CONTACT.EMAIL x * x SERVICES (CONTRACT) +CONTACT.ADDRESS x * x SERVICES (CONTRACT) ``` -The Data Subject realises that they are still receiving maketing e-mail and they formulate a Privacy Request with one `OBJECT` demand with `CONTACT.EMAIL` being defined as its Privacy Scope. Yet, this Demand only affects the Privacy Scope Triples held under `LEGITIMATE-INTEREST`. The System can still, continue to keep the `CONTACT.EMAIL` and `CONTACT.ADDRESS` for the same of the ongoing contractual relationship with the user. +The Data Subject realizes that they are still receiving marketing e-mail and they formulate a Privacy Request with one `OBJECT` demand with `CONTACT.EMAIL` being defined as its Privacy Scope. Yet, this Demand only affects the [Privacy Scope Triples](#privacy-scope-triples) held under `LEGITIMATE-INTEREST`. The System can still, continue to keep the `CONTACT.EMAIL` and `CONTACT.ADDRESS` for the same of the ongoing contractual relationship with the user. ``` Eligible Privacy Scope: -CONTACT.EMAIL x ALL x SERVICES (CONTRACT) -CONTACT.ADDRESS x ALL x SERVICES (CONTRACT) +CONTACT.EMAIL x * x SERVICES (CONTRACT) +CONTACT.ADDRESS x * x SERVICES (CONTRACT) ``` However, the remaining purpose (`SERVICES`) now only allows the System to send e-mail related to the services being provided, and no longer supports sending marketing e-mail to this Data Subject. @@ -464,9 +490,9 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - Regardless of restrictions - `OTHER` Demands: recommend human review and status = `UNDER-REVIEW` - `TRANSPARENCY.KNOWN` Demands: recommend status = `GRANTED`, and data = `YES`. - - `TRANSPARENCY.DATA-CATEGORIES` Demands: recommend status = `GRANTED`, and data = list of Data Categories that are included in any of the Privacy Scope Triples included in the Eligible Privacy Scope. + - `TRANSPARENCY.DATA-CATEGORIES` Demands: recommend status = `GRANTED`, and data = list of Data Categories that are included in any of the [Privacy Scope Triples](#privacy-scope-triples) included in the Eligible Privacy Scope. - `TRANSPARENCY.PROVENANCE`, see [Resolving provenance in requests](#resolving-provenance-in-requests) - - `TRANSPARENCY.ORGANISATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.DPO`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, Demands: recommend status = `GRANTED`, and data = information corresponding to the request taken from configuration settings as defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV) and under [Configuration and Prerequisites](#configuration-and-prerequisites). + - `TRANSPARENCY.ORGANIZATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.DPO`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, Demands: recommend status = `GRANTED`, and data = information corresponding to the request taken from configuration settings as defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV) and under [Configuration and Prerequisites](#configuration-and-prerequisites). - With regards to Demand restrictions (if any) limiting the scope of the Demand: - first, check for presence of incompatible restrictions (and if incompatible recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED`): @@ -510,11 +536,11 @@ When Data Subject ID is provided, the Data Subject is known by the System and au > - third, with regards to the `action` of the Demand: - - `TRANSPARENCY.LEGAL-BASES` Demands, recommend status = `GRANTED`, and data = list of Legal Bases under which any of the Privacy Scope Triples are included in the **Restriction Scope** - - `TRANSPARENCY.PROCESSING-CATEGORIES` Demands: recommend status = `GRANTED`, and data = list of Processing Categories that are included in any of the Privacy Scope Triples included in the **Restriction Scope**. - - `TRANSPARENCY.PURPOSE` Demands: recommend status = `GRANTED`, and data = list of Purposes that are included in any of the Privacy Scope Triples included in the **Restriction Scope** + - `TRANSPARENCY.LEGAL-BASES` Demands, recommend status = `GRANTED`, and data = list of Legal Bases under which any of the [Privacy Scope Triples](#privacy-scope-triples) are included in the **Restriction Scope** + - `TRANSPARENCY.PROCESSING-CATEGORIES` Demands: recommend status = `GRANTED`, and data = list of Processing Categories that are included in any of the [Privacy Scope Triples](#privacy-scope-triples) included in the **Restriction Scope**. + - `TRANSPARENCY.PURPOSE` Demands: recommend status = `GRANTED`, and data = list of Purposes that are included in any of the [Privacy Scope Triples](#privacy-scope-triples) included in the **Restriction Scope** - `REVOKE-CONSENT` Demands: - - If restricted to concrete consent IDs with a [Consent Restriction](./RFC-PRIV.md#consent-restriction), recommend status = `GRANTED` and recalculate Eligible Privacy Scope to drop any Privacy Scope Triples that have been included as a result of Consents being revoked. + - If restricted to concrete consent IDs with a [Consent Restriction](./RFC-PRIV.md#consent-restriction), recommend status = `GRANTED` and recalculate Eligible Privacy Scope to drop any [Privacy Scope Triples](#privacy-scope-triples) that have been included as a result of Consents being revoked. - If Demand is restricted by a Privacy Scope, recommend status = `GRANTED` and [update consents](#updateConsent) - If no Restriction is given in the Demand, revoke all consents given by this Data Subject - If only a Date Range restriction is present, recommend status = `GRANTED` and revoke all consents that have been collected in the given Date Range @@ -527,7 +553,7 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - `DELETE` Demands: - If the **Concerned Fragments** set is empty, recommend status = `DENIED`, motive = `NO-SUCH-DATA` - If it is non-empty: - - recommend for deletion the Data Capture Fragments from that set, the `scope` of which only includes Privacy Scope Triples that are introduced in the Eligible Privacy Scope under Legal Bases belonging to {`LEGITIMATE-INTEREST`, `CONSENT`} + - recommend for deletion the Data Capture Fragments from that set, the `scope` of which only includes [Privacy Scope Triples](#privacy-scope-triples) that are introduced in the Eligible Privacy Scope under Legal Bases belonging to {`LEGITIMATE-INTEREST`, `CONSENT`} - if the set of Data Capture Fragments recommended for deletion is *the same as* the **Concerned Fragments** set, recommend status = `ACCEPT`, - else, if the set of Data Capture Fragments recommended for deletion is *included in* the **Concerned Fragments** set, recommend status = `PARTIALLY-GRANTED`, - else, recommend status = `DENIED`, @@ -556,22 +582,22 @@ When Data Subject ID is provided, the Data Subject is known by the System and au Systems SHOULD define Retention Policies at the time of configuration, and SHOULD cover all Data Categories and Data Capture Fragment `selector`s from the Intended Privacy Scope with at least one Retention Policy. Retention Policies are resolved upon concrete instances of Data Capture Fragments. A particular instance of data, given the Data Capture Fragment `selector` to which it corresponds, is considered `EXPIRED` if all of the following is true: -- There is a Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular Data Capture Fragment, that is of type `NO-LONGER-THAN`, such that the date of the event defined under `after` has passed for a more then the time defined under `duration` -- AND There is no Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular Data Capture Fragment, that is of type `NO-LESS-THAN`, such that the event defined under `after` is yet to happen or has happened before a period of time inferior to `duration` +- There is a Retention Policy the `data-categories` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular Data Capture Fragment, that is of type `NO-LONGER-THAN`, such that the date of the event defined under `after` has passed for a more then the time defined under `duration` +- AND There is no Retention Policy the `data-categories` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular Data Capture Fragment, that is of type `NO-LESS-THAN`, such that the event defined under `after` is yet to happen or has happened before a period of time inferior to `duration` Privacy Compilers SHOULD be able to: - provide lists of active policies, in the context of answering to the `TRANSPARENCY.RETENTION` requests - resolve policies and generate `EXPIRED` alerts, upon which the Systems MAY chose to implement automatic data deletion, or other protocols for data archiving or similar - resolve policies for Systems configured not to automatically delete data, but to automatically grant `DELETE` requests only when data is `EXPIRED` -Optionally, for systems wanting to automatically deny `DELETE` requests when data MUST be kept, Privacy Compilers MAY be able resolve policies giving `HOLD` status, when there is at least one Retention Policy the `data-category` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular data, that is of type `NO-LESS-THAN`, such that the event defined under `after` is yet to happen or has happened before a period of time inferior to `duration`. +Optionally, for systems wanting to automatically deny `DELETE` requests when data MUST be kept, Privacy Compilers MAY be able resolve policies giving `HOLD` status, when there is at least one Retention Policy the `data-categories` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular data, that is of type `NO-LESS-THAN`, such that the event defined under `after` is yet to happen or has happened before a period of time inferior to `duration`. ## Working with Provenance ### Remembering provenance -In order to correctly process `TRANSPARENCY.PROVENANCE` requests as well as requests that are intended to be transferred (`target` = `ORGANISATION`, `PARTNERS`), the Privacy Compiler MUST: +In order to correctly process `TRANSPARENCY.PROVENANCE` requests as well as requests that are intended to be transferred (`target` = `ORGANIZATION`, `PARTNERS`), the Privacy Compiler MUST: - Keep track of transfers, as described in [Implications for Systems](./RFC-PRIV.md#remembering-transfers) -- Keep track of System IDs that correspond to particular targets values, i.e. know which Systems are in `ORGANISATION`, and which are in `PARTNERS` +- Keep track of System IDs that correspond to particular targets values, i.e. know which Systems are in `ORGANIZATION`, and which are in `PARTNERS` - For every **Known Selector** keep track of one or more [Provenance](./RFC-PRIV.md#provenance) objects. > When a System generates data about the Data Subject, it creates a Data Capture and associates its Fragments with a [Provenance](./RFC-PRIV.md#provenance) object having `provenance-category`: `DERIVED` @@ -584,15 +610,15 @@ In order to correctly process `TRANSPARENCY.PROVENANCE` requests as well as requ ### Resolving provenance in requests In response to `TRANSPARENCY.PROVENANCE` Demands, the Privacy Compiler can: -- look for Data Capture Fragments related to particular Data Subject, +- look for [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) related to particular Data Subject, - specifically, when the `TRANSPARENCY.PROVENANCE` Demand is constrained to a particular Privacy Scope, look for only Data Capture Fragments corresponding to this particular Privacy Scope, and - retrieve the [Provenance](./RFC-PRIV.md#provenance) objects provided in `provenance` of such Data Capture Fragments When a Demand is restricted by a [Provenance Restriction](./RFC-PRIV.md#provenance-restriction), the Privacy Compiler is tasked with a more complex interpretation: -- The [Provenance Restriction](./RFC-PRIV.md#provenance-restriction) either includes an explicit `target`, one of {`ORGANISATION`, `PARTNERS`, `SYSTEM`}, or `SYSTEM` is assumed. +- The [Provenance Restriction](./RFC-PRIV.md#provenance-restriction) either includes an explicit `target`, one of {`ORGANIZATION`, `PARTNERS`, `SYSTEM`}, or `SYSTEM` is assumed. - The Privacy Compiler MUST resolve this information in the context of the particular System that it serves. - `SYSTEM` is understood as the System that the Privacy Compiler serves. - - To resolve `ORGANISATION` and `PARTNERS` The Privacy Compiler looks into the correspondence table it keeps, to know which System IDs are `ORGANISATION` and `PARTNERS` Systems to the System it serves. + - To resolve `ORGANIZATION` and `PARTNERS` The Privacy Compiler looks into the correspondence table it keeps, to know which System IDs are `ORGANIZATION` and `PARTNERS` Systems to the System it serves. After having resolved the `target` value to concrete Systems IDs, the Privacy Compiler looks for Data Capture Fragments, the `provenance` of which matches both: - the `provenance-category` of the Demand's [Provenance Restriction](./RFC-PRIV.md#provenance-restriction), AND diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json index 0b292567..fcac0d3d 100644 --- a/refs/schemas/priv/json-schema/priv-terms.schema.json +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -17,7 +17,7 @@ "TRANSPARENCY.DPO", "TRANSPARENCY.KNOWN", "TRANSPARENCY.LEGAL-BASES", - "TRANSPARENCY.ORGANISATION", + "TRANSPARENCY.ORGANIZATION", "TRANSPARENCY.POLICY", "TRANSPARENCY.PROCESSING-CATEGORIES", "TRANSPARENCY.PROVENANCE", @@ -131,7 +131,7 @@ "JUSTICE", "MARKETING", "MEDICAL", - "PERSONALISATION", + "PERSONALIZATION", "PUBLIC-INTERESTS", "RESEARCH", "SALE", @@ -162,7 +162,7 @@ }, "targets": { "enum": [ - "ORGANISATION", + "ORGANIZATION", "PARTNERS", "SYSTEM" ] diff --git a/refs/schemas/priv/scenarios.md b/refs/schemas/priv/scenarios.md index 11759141..5b2797ef 100644 --- a/refs/schemas/priv/scenarios.md +++ b/refs/schemas/priv/scenarios.md @@ -334,7 +334,7 @@ sequenceDiagram ## A Complex Journey of a Data Capture -A Data Capture MAY end up being shared among several Systems. We illustrate this on an example. System A and System B are a part of the same Organisation, while System C is a part of a Partner Organisation. +A Data Capture MAY end up being shared among several Systems. We illustrate this on an example. System A and System B are a part of the same Organization, while System C is a part of a Partner Organization. This complex scenario may take place under different [authentication](#authentication), [automation](#automation), and [response](#response) scenarios. For the sake of clarity of the diagram, we don't include all the possible options. We also abstract Privacy Compilers and interactions with them, as well as Data Consumers and DPOs. @@ -352,8 +352,8 @@ sequenceDiagram systemA->>systemA: Data Capture DEVICE (iPhone 13), provenance:DERIVED - subject->>systemA: consent1 purpose: ADVERTISING, PERSONALISATION, target: ORGANISATION - subject->>systemA: consent2 purpose: ADVERTISING, PERSONALISATION, target: PARTNERS + subject->>systemA: consent1 purpose: ADVERTISING, PERSONALIZATION, target: ORGANIZATION + subject->>systemA: consent2 purpose: ADVERTISING, PERSONALIZATION, target: PARTNERS systemA->>systemB: Data Capture, Consent systemB->>systemC: Data Capture, Consent @@ -370,16 +370,16 @@ sequenceDiagram systemA->>subject: Advertising e-mail - subject->>systemA: Privacy Request OBJECT purpose:ADVERTISING, target: ORGANISATION + subject->>systemA: Privacy Request OBJECT purpose:ADVERTISING, target: ORGANIZATION systemA->>systemB: Privacy Request OBJECT purpose:ADVERTISING - systemA->>systemA: consent1->consent1.1 purpose: PERSONALISATION, target: ORGANISATION - systemB->>systemB: consent1->consent1.1 purpose: PERSONALISATION, target: ORGANISATION + systemA->>systemA: consent1->consent1.1 purpose: PERSONALIZATION, target: ORGANIZATION + systemB->>systemB: consent1->consent1.1 purpose: PERSONALIZATION, target: ORGANIZATION systemB->>systemA: Privacy Request GRANTED systemA->>subject: Privacy Request GRANTED - subject->>systemA: Privacy Request ACCESS provenance:TRANSFERRED,DERIVED target: ORGANISATION + subject->>systemA: Privacy Request ACCESS provenance:TRANSFERRED,DERIVED target: ORGANIZATION systemA->>subject: Privacy Request GRANTED note left of systemA: DEVICE (iPhone 13) @@ -387,8 +387,8 @@ sequenceDiagram systemB->>subject: Privacy Request GRANTED note left of systemB: CONTACT (name, e-mail, phone) DEVICE (iPhone 13) - subject->>systemA: Privacy Request RESTRICT provenance:USER target: ORGANISATION - systemA->>systemB: Privacy Request RESTRICT provenance:USER target: ORGANISATION + subject->>systemA: Privacy Request RESTRICT provenance:USER target: ORGANIZATION + systemA->>systemB: Privacy Request RESTRICT provenance:USER target: ORGANIZATION systemA->>systemA: Delete DEVICE (iPhone 13) systemB->>systemB: Delete DEVICE (iPhone 13) From 167b46789660c5af4d59018ceb98772059a120bf Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 16 Jun 2022 13:53:57 +0200 Subject: [PATCH 176/204] typo --- refs/schemas/priv/RFC-PRIV.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 184c7bab..c2ce0947 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -92,7 +92,7 @@ The Privacy Request Interchange Vocabulary includes the following: [Retention Policy](#retention-policy), [Data Subject Identity](#decentralized-identity-of-data-subjects) -- **Properties**: `action`, `after`, `answers`, `capture-id`, `capture-ids`, `consent-id`,`consent-ids`, `data-subject`,`data`, `data-categories`, `data-reference`, `data-subject`, `date`,`demand-id`, `demands`, `dsid`, `dsid-schema`, `duration`, `expires`,`fragment-id`, `fragments`, `from`, `includes`, `in-response-to`,`lang`, `legal-base`, `message`, `motive`, `policy-type`, `processing-categories`, `provenance, `provenance-category`, `purposes`, `replaces`, `response-id`, `restrictions`, `request-id`, `replaced-by`, `retention`, `requested-action`, `scope`, `selector`, `status`, `system`, `target`, `to`, `vocab` +- **Properties**: `action`, `after`, `answers`, `capture-id`, `capture-ids`, `consent-id`,`consent-ids`, `data-subject`,`data`, `data-categories`, `data-reference`, `data-subject`, `date`,`demand-id`, `demands`, `dsid`, `dsid-schema`, `duration`, `expires`,`fragment-id`, `fragments`, `from`, `includes`, `in-response-to`,`lang`, `legal-base`, `message`, `motive`, `policy-type`, `processing-categories`, `provenance`, `provenance-category`, `purposes`, `replaces`, `response-id`, `restrictions`, `request-id`, `replaced-by`, `retention`, `requested-action`, `scope`, `selector`, `status`, `system`, `target`, `to`, `vocab` - **Terms**: all terms included in the [dictionary](./dictionary), and particularly: @@ -118,7 +118,7 @@ The Privacy Request Interchange Vocabulary includes the following: - **Legal Base Terms**: {`CONTRACT`, `CONSENT`, `LEGITIMATE-INTEREST`, `NECESSARY`, `OTHER-LEGAL-BASE`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/legal-bases](./dictionary/legal-bases).* - - **Retention Terms**: {NO-LONGER-THAN, "NO-LESS-THAN"} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/retentions](./dictionary/retentions).* + - **Retention Terms**: {`NO-LONGER-THAN`, `NO-LESS-THAN`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/retentions](./dictionary/retentions).* - **Event Terms**: {`CAPTURE-DATE`,`RELATIONSHIP-END`, `SERVICE-END`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/events](./dictionary/events).* From dd6eeaffb8cf5d1b697ff509a1f701c78f3a3385 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 16 Jun 2022 14:07:02 +0200 Subject: [PATCH 177/204] fixing broken links --- refs/schemas/priv/RFC-PRIV.md | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index c2ce0947..6816aafc 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -106,7 +106,7 @@ The Privacy Request Interchange Vocabulary includes the following: - **Provenance Terms**: {`DERIVED`, `TRANSFERRED`, `USER`, `USER.DATA-SUBJECT`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/provenance](./dictionary/provenance).* - - **Target Terms**: {`ORGANIZATION`, `PARTNERS`, `SYSTEM`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/targets](./dictionary/targets).* + - **Target Terms**: {`ORGANIZATION`, `PARTNERS`, `SYSTEM`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/targets](./dictionary/targets).* - **Target Direction Terms**: {`PARTNERS.DOWNWARD`, `PARTNERS.UPWARD`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/targets](./dictionary/targets).* @@ -205,7 +205,7 @@ It is possible to specify a Privacy Scope by referring to only one or two, or no An unspecified dimension MUST be interpreted as designating the totality of Terms that are eligible as one of its Expected values. E.g. A Privacy Scope defined only by `data-categories`: `CONTACT` is interpreted as any [Processing](#processing-categories), for any [Purpose](#purpose) or any data marked with `CONTACT` or any of its subcategories including `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`. -This Privacy Scope includes Privacy Scope Triples that are all possible combinations of those known subcategories (including [Data Capture Fragment](#data-capture-fragments) `selectors`) of `CONTACT` with all known [Processing](#processing-categories) and with all known [Purpose Terms](#purpose). +This Privacy Scope includes Privacy Scope Triples that are all possible combinations of those known subcategories (including [Data Capture Fragment](#data-capture-fragments) `selectors`) of `CONTACT` with all known [Processing Terms](#processing-categories) and with all known [Purpose Terms](#purposes). *Data Categories* @@ -283,9 +283,9 @@ A Demand can be restricted to particular `provenance-category`, for example the | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `provenance-category` | 1 | [Provenance Terms](#provenance-categories) | -| `target` | 0-1 | [Target Terms](#targets). In absence of indication `SYSTEM` is assumed | +| `target` | 0-1 | [Target Terms](#target-terms). In absence of indication `SYSTEM` is assumed | -Optionally the Provenance Restriction may also include a particular [Target](#targets). +Optionally the Provenance Restriction may also include a particular [Target](#target-terms). E.g. the Data Subject might demand to have `ACCESS` to data that was `TRANSFERRED` by partner Systems (`target`:`PARTNERS`). @@ -301,13 +301,13 @@ A Demand can be restricted to particular `data-reference` to precisely identify #### Targets -It is common for Internet Systems to be distributed (organised in a set of connected websites and applications) and to exchange data among themselves. +It is common for Internet Systems to be distributed (organized in a set of connected websites and applications) and to exchange data among themselves. It is therefore convenient for a Data Subject to be able to formulate Privacy Requests (but also give Consents) targeting well-defined Systems. | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `target` | 0-1 | [Target Terms](#targets) or [Target Direction Terms](#target-directions) +| `target` | 0-1 | [Target Terms](#target-terms) or [Target Direction Terms](#target-directions) In absence of indication `SYSTEM` is assumed | `SYSTEM` refers to the particular System with which the Data Subject is in direct interaction while making the Privacy Request (or giving the Consent). @@ -378,7 +378,7 @@ A Consent is given by one Data Subject which can be identified by one or more [D | `consent-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Consent was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `expires` | 0-1 | Date and Time when Consent expires in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| `target` | 0-1 | [Target Terms](#targets) to indicate the category of Systems to which consent for processing is given. In absence of indication `SYSTEM` is assumed. | +| `target` | 0-1 | [Target Terms](#target-terms) to indicate the category of Systems to which consent for processing is given. In absence of indication `SYSTEM` is assumed. | | `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the Consent SHOULD be interpreted as unlimited | | `replaces` | 0-* | Optionally one or more 'consent-id's of previous [Consents](#consent) that have became void when this consent was made | | `replaced-by` | 0-* | Optionally one or more 'consent-id's of previous [Consents](#consent) that have became void when this consent was made | @@ -392,7 +392,7 @@ A Data Capture is given by one Data Subject which can be identified by one or mo | `data-subject` | 1-* | [Data Subject Identities](#decentralized-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| | `capture-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `data-reference` | 1-* | one or more references that uniquely identify the data that the capture concerns (e.g. a legal case file reference, account ID, contract ID, a URL)| -| `target` | 0-1 | [Target Terms](#targets). In absence of indication `SYSTEM` is assumed | +| `target` | 0-1 | [Target Terms](#target-terms). In absence of indication `SYSTEM` is assumed | | `fragments` | 1-* | One or more [Data Capture Fragments](#data-capture-fragments) | A Data Capture concerns one and only one Data Subject who CAN be identified by multiple Data Subject Identities. @@ -405,10 +405,10 @@ A Data Capture concerns one and only one Data Subject who CAN be identified by m | `selector` | 1 | a string used to uniquely identify a data field (in the System's data model) to which the fragment corresponds. MUST be a subcategory of a [Data Category](#data-categories) and MUST be defined according to [Term Dot Notation](#term-dot-notation) | | `date` | 1 | Date and Time when data was Captured was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `scope` | 0-1 | a [Privacy Scope](#privacy-scope) in absence of which the fragment SHOULD be interpreted as unlimited, including all categories of all dimensions | -| `target` | 0-1 | [Target Terms](#targets). In absence of indication `SYSTEM` is assumed | +| `target` | 0-1 | [Target Terms](#target-terms). In absence of indication `SYSTEM` is assumed | | `retention` | 1-* | one or more [Retention Policies](#retention-policy) | -| `provenance` | 1-* | one or more [Provenance](#provenance) | -| `data` | 0-* | Optionally concrete data (Format **TBD**) | +| `provenance` | 1-* | one or more [Provenance](#provenance) to indicate how the data was obtained | +| `data` | 0-* | Optionally concrete data | | `legal-base` | 0-* | [Legal Bases](#legal-bases) | A `selector` MUST include, at the beginning of its string, one of the [Data Category Terms](#data-categories). @@ -421,6 +421,8 @@ While the Data Categories are globally defined by PRIV and interpreted the same A `selector` uniquely identifies a particular data field that the Systems works with. When several Systems exchange data among them, they SHOULD align on using the same `selectors` in the same way, in order to be able to correctly interoperate. +The value of the `target` indicates whether the data in question is going to be processed only by the System collecting it, of within a larger target scope. See [Targets](#targets). + Processing MAY be legitimate according to one or more [Legal Bases](#legal-bases) for processing. For example, a Data Subject can give explicit `CONSENT` when creating an account with a particular online service, and at the time, the System providing a service to the Data Subject might need to process their data in order to deliver a service or honor a `CONTRACT` (e.g. deliver the purchased goods to the Data Subjects address and issue an invoice). From ae6938e79bea006be09e5baee0b4bb3c50894516 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 16 Jun 2022 14:10:53 +0200 Subject: [PATCH 178/204] Update expected-behavior.md --- refs/schemas/priv/expected-behavior.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 279202b6..4cc50d08 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -71,7 +71,10 @@ A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a - *Corresponding Systems*: A map of Other Systems with which data is being exchanged. For each System The Privacy Compiler MUST know if they are an `ORGANIZATION` or `PARTNERS` System, and have a way to uniquely identify and address them (see [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV), [Working with Provenance](#working-with-provenance)) - **Privacy Metadata Store**, updated at runtime: - - *All Captures*: a list of all the [Data Capture](./RFC-PRIV.md#data-capture) objects that the Privacy Compiler is aware of + - *All Captures*: a list of all the [Data Capture](./RFC-PRIV.md#data-capture) objects that the Privacy Compiler is aware of. + + > Data Captures are not only generated on user input, but may result from user tracking, or from data transfers. All such Data Captures objects are of interest to the Privacy Compiler. + - *All Requests*: a list of all the [Privacy Request](./RFC-PRIV.md#privacy-request) objects that the Privacy Compiler is aware of - *All Responses*: a list of all the [Privacy Request Response](./RFC-PRIV.md#privacy-request-response) objects that the Privacy Compiler is aware of - Legal Bases: From af55006903e2064ed8509ed3425f9385829981fd Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 16 Jun 2022 19:12:58 +0200 Subject: [PATCH 179/204] solving the issue of System IDs --- refs/schemas/priv/RFC-PRIV.md | 29 +++++++++++++++++++------- refs/schemas/priv/expected-behavior.md | 6 ++++-- refs/schemas/priv/scenarios.md | 2 +- 3 files changed, 27 insertions(+), 10 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 6816aafc..e21cca56 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -1,6 +1,6 @@ # Privacy Request Interchange Vocabulary (PRIV) -| Status | draft | +| Status | proposed | | :------------ | :------------------------------------------------------------------------------------- | | **PR #** | [659](https://github.com/blindnet-io/product-management/pull/659) | | **Author(s)** | [milstan](https://github.com/milstan) (milstan@blindnet.io) | @@ -345,7 +345,7 @@ Regardless of the [scenario (Responding to the Data Subject directly or to the S | `response-id` | 1 | Unique ID for referring to this request in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `in-response-to` | 1 | `request-id` of the Privacy Request to which response is made or `demand-id` of the particular Demand to which response is made, in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Privacy Request Response was created in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| `system` | 1 | System ID of the System having generated the response (**Format TBD**) | +| `system` | 1 | System ID of the System having generated the response. A String in the format of URI according to [RFC3986 of IETF](https://www.rfc-editor.org/rfc/rfc3986) | | `requested-action` | 0-1 | Optional information about the action that was demanded, and to which the response is made. [Action](#actions)| | `data-subject` | 0-* | Optional indication of the [Data Subject Identities](#decentralized-identity-of-data-subjects) to which the response refers to | | `status` | 1 | [Status Terms](#statuses) | @@ -433,7 +433,7 @@ Certain processing is made legitimate (`LEGITIMATE-INTEREST`) or mandatory (`NEC | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `provenance-category` | 1 | [Provenance Terms](#provenance-categories) | -| `system` | 1 | System ID (**Format TBD**) | +| `system` | 1 | the ID of the System having generated the Data Capture Fragment (when data is collected from a user, or derived), or ID of the System having initiated a transfer (when data is transferred). A String in the format of URI according to [RFC3986 of IETF](https://www.rfc-editor.org/rfc/rfc3986) | Data provenance is interpreted in relation to a particular System. @@ -441,6 +441,21 @@ The same Data Capture Fragment might be: - data collected from the `USER` for one System (the one being in direct interaction with the Data Subject), and be - data `TRANSFERRED` in the eyes of another System that obtained it through transfer from the user-facing System. +E.g. let us imagine a Data Capture Fragment that contains information that the Data Subject provided to System A. System A transferred this Data Capture Fragment to System B. + +In the System A, this Data Capture Fragment SHOULD be associated with one Provenance object, having `provenance-category`:`USER.DATA-SUBJECT`, and `system`: `URL of the System A` + +In the System B, this Data Capture Fragment SHOULD be associated with two Provenance objects: +- one having `provenance-category`:`USER.DATA-SUBJECT`, and `system`: `URL of the System A` +- one having `provenance-category`:`TRANSFERRED`, and `system`: `URL of the System A` + +In this way, the System B has complete information: the Data Capture Fragment was collected from the Data Subject by System A, and then transferred to it from System A. + +If now System B transfers this data transfers this Data Capture Fragment to System C, then In the System B, this Data Capture Fragment SHOULD be associated with tree Provenance objects: +- one having `provenance-category`:`USER.DATA-SUBJECT`, and `system`: `URL of the System A` +- one having `provenance-category`:`TRANSFERRED`, and `system`: `URL of the System A` +- one having `provenance-category`:`TRANSFERRED`, and `system`: `URL of the System B` + Not to be confused with [Provenance Restriction](#provenance-restriction). ##### Retention Policy @@ -633,9 +648,8 @@ In [here](./examples.md) we provide an overview of various Privacy Requests that ### Remembering Transfers When data about Data Subjects is transmitted from one system to another, in order to be able to process the [Targets property](#targets), and in order to reply to `TRANSPARENCY.WHO` and `TRANSPARENCY.PROVENANCE` demands, Systems MUST keep track of: -- System of destination/origin and addresses where their APIs can be reached -- Categories of data being transferred -- Identifiers (`data-capture-id`s,`fragment-id`s) associated to the data being transferred +- ID of Systesm of origin and destination, in the format of URI according to [RFC3986 of IETF](https://www.rfc-editor.org/rfc/rfc3986) +- Full Data Capture metadata objects - Consents (`consent-id`) associated to the data being transferred - Data Subject Identities (`dsid`,`dsid-schema`) pairs associated to the data being transferred @@ -738,7 +752,7 @@ We need a way to make enums different categories and types more elegant, and reu ### Addressability of System Endpoints -Is there a standard way for representing peer-to-peer System's API endpoints (compatible with our [implications for systems](#exposing-privacy-request-api)) that we can reuse here for representing systems? +System IDs are identified by URIs([RFC3986 of IETF](https://www.rfc-editor.org/rfc/rfc3986)), for compatibility with both [Web3, such as Ethereum](https://ethereum.org/zh/developers/docs/networking-layer/network-addresses), and [OpenID/OAuth/SAML](https://oauth.net/specs/). ### Anonymous Privacy Requests @@ -852,6 +866,7 @@ This document comes with the following support documents: - **[RFC8259]** Bray, T., ["The JavaScript Object Notation (JSON) Data Interchange Format"](https://datatracker.ietf.org/doc/html/rfc8259), STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. - **[RFC2119]** Bradner, S., ["Key words for use in RFCs to Indicate Requirement Levels"](https://datatracker.ietf.org/doc/html/rfc2119), BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, - **[RFC5234]** Crocker, D., Ed. and P. Overell, ["Augmented BNF for Syntax Specifications: ABNF"](https://www.rfc-editor.org/info/rfc5234), STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, +- **[RFC3986]** Berners-Lee, T., Fielding, R., and L. Masinter, ["Uniform Resource Identifier (URI): Generic Syntax"](https://www.rfc-editor.org/rfc/rfc3986), STD 66, RFC 3986, January 2005. diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 4cc50d08..5b21a869 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -1,6 +1,6 @@ *[Privacy Scope Triples](#privacy-scope-triples)# Privacy Request Interchange Vocabulary : Expected Behavior of Implementing Systems -| Status | draft | +| Status | NA / supporting document | | :------------ | :------------------------------------------------------------------------------------- | | **Author(s)** | milstan (milstan@blindnet.io) | | **Updated** | 2022-06-14 | @@ -74,7 +74,7 @@ A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a - *All Captures*: a list of all the [Data Capture](./RFC-PRIV.md#data-capture) objects that the Privacy Compiler is aware of. > Data Captures are not only generated on user input, but may result from user tracking, or from data transfers. All such Data Captures objects are of interest to the Privacy Compiler. - + - *All Requests*: a list of all the [Privacy Request](./RFC-PRIV.md#privacy-request) objects that the Privacy Compiler is aware of - *All Responses*: a list of all the [Privacy Request Response](./RFC-PRIV.md#privacy-request-response) objects that the Privacy Compiler is aware of - Legal Bases: @@ -638,6 +638,8 @@ After having resolved the `target` value to concrete Systems IDs, the Privacy Co ### Normative References - **[RFC8259]** Bray, T., ["The JavaScript Object Notation (JSON) Data Interchange Format"](https://datatracker.ietf.org/doc/html/rfc8259), STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. +- **[RFC3986]** Berners-Lee, T., Fielding, R., and L. Masinter, ["Uniform Resource Identifier (URI): Generic Syntax"](https://www.rfc-editor.org/rfc/rfc3986), STD 66, RFC 3986, January 2005. +- **[RFC2119]** Bradner, S., ["Key words for use in RFCs to Indicate Requirement Levels"](https://datatracker.ietf.org/doc/html/rfc2119), BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, ### Supported Legislation diff --git a/refs/schemas/priv/scenarios.md b/refs/schemas/priv/scenarios.md index 5b2797ef..f4d831da 100644 --- a/refs/schemas/priv/scenarios.md +++ b/refs/schemas/priv/scenarios.md @@ -1,6 +1,6 @@ # Privacy Request Interchange Vocabulary : Scenarios of Use -| Status | draft | +| Status | NA / supporting document | | :------------ | :------------------------------------------------------------------------------------- | | **Author(s)** | milstan (milstan@blindnet.io) | | **Updated** | 2022-06-10 | From 3f8bfb11510ad6688f7739d2350c044ac651f006 Mon Sep 17 00:00:00 2001 From: milstan Date: Fri, 17 Jun 2022 12:58:25 +0200 Subject: [PATCH 180/204] minor error in title --- refs/schemas/priv/expected-behavior.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 5b21a869..a4af3c8c 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -1,4 +1,4 @@ -*[Privacy Scope Triples](#privacy-scope-triples)# Privacy Request Interchange Vocabulary : Expected Behavior of Implementing Systems +# Privacy Request Interchange Vocabulary : Expected Behavior of Implementing Systems | Status | NA / supporting document | | :------------ | :------------------------------------------------------------------------------------- | From 13cabd2207bbb83fdfa2b4d2f45b6b1dffc94e6a Mon Sep 17 00:00:00 2001 From: milstan Date: Fri, 17 Jun 2022 13:01:53 +0200 Subject: [PATCH 181/204] format fix --- refs/schemas/priv/expected-behavior.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index a4af3c8c..c6c3169e 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -59,12 +59,12 @@ A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a Each **Known Selector** MUST be included in the The Intended Privacy Scope. -> **Note** -> -> In addition to `selectors` that are a native mechanism for extending Data Categories with System-specific subcategories, it is necessary to allow Systems to also extend Processing Categories and Purposes, with potentially System-specific terms following PRIV's [Term Dot Notation](./RFC-PRIV.md#term-dot-notation). -> -> This is necessary for interoperability with the specific Processing Categories of the [HL7 Standards](./RFC-PRIV.md#hl7-standards) -> + > **Note** + > + > In addition to `selectors` that are a native mechanism for extending Data Categories with System-specific subcategories, it is necessary to allow Systems to also extend Processing Categories and Purposes, with potentially System-specific terms following PRIV's [Term Dot Notation](./RFC-PRIV.md#term-dot-notation). + > + > This is necessary for interoperability with the specific Processing Categories of the [HL7 Standards](./RFC-PRIV.md#hl7-standards) + > - *Legal Bases*: For each [Privacy Scope Triple](#privacy-scope-triples) from the **Intended Privacy Scope**, one or more [Legal Bases](./RFC-PRIV.md#legal-bases) From c71cf6c9064c3f66e4b82c284a508c3d791d8dd2 Mon Sep 17 00:00:00 2001 From: milstan Date: Fri, 17 Jun 2022 13:04:54 +0200 Subject: [PATCH 182/204] format fix --- refs/schemas/priv/expected-behavior.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index c6c3169e..5a2429e0 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -73,7 +73,9 @@ A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a - **Privacy Metadata Store**, updated at runtime: - *All Captures*: a list of all the [Data Capture](./RFC-PRIV.md#data-capture) objects that the Privacy Compiler is aware of. - > Data Captures are not only generated on user input, but may result from user tracking, or from data transfers. All such Data Captures objects are of interest to the Privacy Compiler. + + > Data Captures are not only generated on user input, but may result from user tracking, or from data transfers. + > All such Data Captures objects are of interest to the Privacy Compiler. - *All Requests*: a list of all the [Privacy Request](./RFC-PRIV.md#privacy-request) objects that the Privacy Compiler is aware of - *All Responses*: a list of all the [Privacy Request Response](./RFC-PRIV.md#privacy-request-response) objects that the Privacy Compiler is aware of @@ -98,7 +100,7 @@ A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a - For each Data Subject, an **Eligible Privacy Scope**, according to [Privacy Algebra](#privacy-algebra). This **Eligible Privacy Scope** is easily resolved at the level of each [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) (or its `selector`) -## [Privacy Scope Triples](#privacy-scope-triples) +## Privacy Scope Triples A **Privacy Scope Triple** is a unit of [Privacy Scope](RFC-PRIV.md#privacy-scope) and it consists of (in that order): From 70eba5305b30075bdfe392a41c712f8ce82727ba Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 22 Jun 2022 10:54:39 +0200 Subject: [PATCH 183/204] Update refs/schemas/priv/expected-behavior.md Co-authored-by: Marko <71560916+m4rk055@users.noreply.github.com> --- refs/schemas/priv/expected-behavior.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 5a2429e0..256542d4 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -14,7 +14,7 @@ It is a first step towards the specification of the [Privacy Compiler](../high-l ## Motivation -While this document is a first step in the definition of the [Privacy Compiler](../high-level-architecture#data-rights-compiler), it is not intended to be its formal specification nor to influence the design choices related to formalization of rules and configurations. +While this document is a first step in the definition of the [Privacy Compiler](../../high-level-architecture#data-rights-compiler), it is not intended to be its formal specification nor to influence the design choices related to formalization of rules and configurations. The purpose of the document is primarily illustrate a possible behavior Systems (And their Privacy Compilers) MAY implement in response to Privacy Requests, in order to test the completeness of the [Privacy Request Interchange Vocabulary](./RFC-PRIV.md). From a7e9c6168ad890944a455e962cb2b194680d2f5e Mon Sep 17 00:00:00 2001 From: Milan Date: Wed, 22 Jun 2022 10:55:00 +0200 Subject: [PATCH 184/204] Update refs/schemas/priv/expected-behavior.md Co-authored-by: Marko <71560916+m4rk055@users.noreply.github.com> --- refs/schemas/priv/expected-behavior.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 256542d4..06000287 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -9,7 +9,7 @@ This document specifies the expected behavior of Systems implementing [Privacy Request Interchange Vocabulary](./RFC-PRIV.md). It defines actions that the systems MAY undertake with regards to particular Privacy Requests and particular situations. -It is a first step towards the specification of the [Privacy Compiler](../high-level-architecture#data-rights-compiler), formerly known as Data Rights Compiler in the [High Level Architecture](../high-level-architecture). +It is a first step towards the specification of the [Privacy Compiler](../../high-level-architecture#data-rights-compiler), formerly known as Data Rights Compiler in the [High Level Architecture](../../high-level-architecture). ## Motivation From 88ccfe42a50fd7e1c8a3b9ea903706dd315b36cf Mon Sep 17 00:00:00 2001 From: Milan Date: Thu, 23 Jun 2022 18:13:00 +0200 Subject: [PATCH 185/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Marko <71560916+m4rk055@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 1 - 1 file changed, 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index e21cca56..39a18d74 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -90,7 +90,6 @@ The Privacy Request Interchange Vocabulary includes the following: [Privacy Request Response](#privacy-request-response), [Privacy Scope](#privacy-scope)(and its dimensions: *Data Category*, *Processing Category* and *Purpose*), [Provenance](#provenance), [Retention Policy](#retention-policy), -[Data Subject Identity](#decentralized-identity-of-data-subjects) - **Properties**: `action`, `after`, `answers`, `capture-id`, `capture-ids`, `consent-id`,`consent-ids`, `data-subject`,`data`, `data-categories`, `data-reference`, `data-subject`, `date`,`demand-id`, `demands`, `dsid`, `dsid-schema`, `duration`, `expires`,`fragment-id`, `fragments`, `from`, `includes`, `in-response-to`,`lang`, `legal-base`, `message`, `motive`, `policy-type`, `processing-categories`, `provenance`, `provenance-category`, `purposes`, `replaces`, `response-id`, `restrictions`, `request-id`, `replaced-by`, `retention`, `requested-action`, `scope`, `selector`, `status`, `system`, `target`, `to`, `vocab` From 88563f19109c7bd860a20ee2688f8c9ffde69d17 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 23 Jun 2022 18:30:43 +0200 Subject: [PATCH 186/204] precision after discussion with Filip --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 39a18d74..5e3304a7 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -649,7 +649,7 @@ In [here](./examples.md) we provide an overview of various Privacy Requests that When data about Data Subjects is transmitted from one system to another, in order to be able to process the [Targets property](#targets), and in order to reply to `TRANSPARENCY.WHO` and `TRANSPARENCY.PROVENANCE` demands, Systems MUST keep track of: - ID of Systesm of origin and destination, in the format of URI according to [RFC3986 of IETF](https://www.rfc-editor.org/rfc/rfc3986) - Full Data Capture metadata objects -- Consents (`consent-id`) associated to the data being transferred +- Full Consents metadata of consents relevant to the data being transferred - Data Subject Identities (`dsid`,`dsid-schema`) pairs associated to the data being transferred > **Note** From 08da1149657b0b526f2d8d2b5626f2299025d46b Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 23 Jun 2022 19:09:11 +0200 Subject: [PATCH 187/204] about UROPA compatibility --- refs/schemas/priv/RFC-PRIV.md | 6 ++++++ refs/schemas/priv/examples.md | 13 +++++++++++++ refs/schemas/priv/expected-behavior.md | 4 ++-- 3 files changed, 21 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 5e3304a7..956c9df5 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -848,6 +848,12 @@ Name, Address (all geographic subdivisions smaller than state, including street We examine, in [examples.md](./examples.md#hippa) how those categories can be mapped to PRIV's Data Categories. +### UROPA + +Alias.dev and Leto.legal have developed [UROPA](https://github.com/uropa-project/uropa) a schema for representing data processing records. Data Processing records are sort of configuration records, covering different general information and settings that PRIV implementing systems MUST configure. UROPA only specifies properties, but almost no particular terms (except for Provenance - the [mapping of which is given un examples.md]((./examples.md#uropa))). + +Full configuration needed to resolve many of the TRANSPARENCY requests can be represented using UROPA, provided that [PRIV Terms](#terms) are used as names of different categories (that are free strings in UROPA). The `data` values of [Privacy Request Responses](#privacy-request-response) MAY also be delivered using UROPA JSON format for better machine readability (the end-user-facing System are then tasked with rendering such information to the User). + diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 13d1455f..20b0ec9c 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -360,6 +360,19 @@ The following correspondence of [data categories](https://www.luc.edu/its/abouti | Photographic image - Photographic images are not limited to images of the face. | `IMAGE` | | Any other characteristic that could uniquely identify the individual | `UID` | +#### UROPA + +[UROPA](https://github.com/uropa-project/uropa) defines the following Collection Means (called Provenance in PRIV) that can be mapped to PRIV Terms: + +| UROPA [collectionMean](https://gdpr.stoplight.io/docs/uropa/922d9e36659fd-data-type) | PRIV [Provenance Terms](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/schemas/priv/RFC-PRIV.md#provenance-categories) | +| -------------- | ------------------ | +| `generated` | `DERIVED` | +| `computed` | `DERIVED`| +| `submitted` | `USER` | +| *not supported* | `TRANSFERRED` | + +It is possible to model subcategory terms `DERIVED.GENERATED` and `DERIVED.COMPUTED` for the purposes of interoperability with UROPA. + ## Questions and Discussion Topics diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 06000287..204fbd41 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -46,7 +46,7 @@ Because of this Systems MUST be able to configure their particular ways of autom A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a particular System MUST have the knowledge of the following key parameters and data structures: -- **Parameters**: a set of parameters defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV) needed to resolve `TRANSPARENCY` requests. +- **Parameters**: a set of parameters defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV) needed to resolve `TRANSPARENCY` requests. Those MAY be received using UROPA format (see [UROPA section of PRIV](./RFC-PRIV.md#uropa)). - **Known Selectors** : exhaustive list of [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) `selector` know by the System, including for every data field that the System is likely to store (either a field of a data collection form, or simply a field in its database) the [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) `selector` corresponding to it @@ -478,7 +478,7 @@ Privacy Requests MAY need to be processed in the context of different [authentic Here is how the Privacy Request Response recommendations are calculated: When no Data Subject ID is provided in the Privacy Request: -- `TRANSPARENCY` Demands: recommend status = `GRANTED`. Provide requested information: Data Categories, Processing Categories, Purposes, and Legal Bases from Intended Privacy Scope, as well as other information from general settings as defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV) and under [Configuration and Prerequisites](#configuration-and-prerequisites). +- `TRANSPARENCY` Demands: recommend status = `GRANTED`. Provide requested information: Data Categories, Processing Categories, Purposes, and Legal Bases from Intended Privacy Scope, as well as other information from general settings as defined under [Implications for Systems](./RFC-PRIV.md#design-implications-for-systems-implementing-PRIV) and under [Configuration and Prerequisites](#configuration-and-prerequisites). The `data` values of Privacy Request Responses MAY be formatted using UROPA format (see [UROPA section of PRIV](./RFC-PRIV.md#uropa)). - `OTHER` Demands: recommend human review and status = `UNDER-REVIEW` - For any other action : recommend status = `DENIED`, motive=`IDENTITY-UNCONFIRMED` From 944edc2d9c9abf5fb11fa1422416dca4c6588da7 Mon Sep 17 00:00:00 2001 From: milstan Date: Thu, 23 Jun 2022 19:40:20 +0200 Subject: [PATCH 188/204] both delete and modify can be unsupported - after comment with Marko --- refs/schemas/priv/expected-behavior.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 204fbd41..b75c1ed8 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -556,6 +556,7 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - Recommend deletion of the **Concerned Fragments**. - `DELETE` Demands: + - If restricted to a Privacy Scope Restriction having a `processing-category` or a `purpose`, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` (A DELETE request can only be relative to a category of data, not to a category of processing or a particular purpose.) - If the **Concerned Fragments** set is empty, recommend status = `DENIED`, motive = `NO-SUCH-DATA` - If it is non-empty: - recommend for deletion the Data Capture Fragments from that set, the `scope` of which only includes [Privacy Scope Triples](#privacy-scope-triples) that are introduced in the Eligible Privacy Scope under Legal Bases belonging to {`LEGITIMATE-INTEREST`, `CONSENT`} @@ -565,7 +566,7 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - when status is one of {`PARTIALLY-GRANTED`, `DENIED`} add one or more motives = `VALID-REASONS` or `IMPOSSIBLE` when **Concerned Fragments** that are not recommended for deletion, have in their `scope` Privacy Scope Triples included in the Eligible Privacy Scope under `CONTRACT` or `NECESSARY` Legal Bases, respectively. - `MODIFY` Demands: - - If restricted to a Privacy Scope Restriction having a `processing-category` or a `purpose`, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` (A Delete request can only be relative to a category of data, not to a category of processing or a particular purpose.) + - If restricted to a Privacy Scope Restriction having a `processing-category` or a `purpose`, recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED` (A MODIFY request can only be relative to a category of data, not to a category of processing or a particular purpose.) - If the **Concerned Fragments** set is empty, recommend status = `DENIED`, motive = `NO-SUCH-DATA` - If it is non-empty, recommend status = `ACCEPT` (potentially upon human validation) From 49740c1bb0c344ce0b5fd59d6d21cafeb733d846 Mon Sep 17 00:00:00 2001 From: Milan Date: Fri, 24 Jun 2022 09:25:56 +0200 Subject: [PATCH 189/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Filip <73657349+filipblnt@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 956c9df5..46fdaa4c 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -647,7 +647,7 @@ In [here](./examples.md) we provide an overview of various Privacy Requests that ### Remembering Transfers When data about Data Subjects is transmitted from one system to another, in order to be able to process the [Targets property](#targets), and in order to reply to `TRANSPARENCY.WHO` and `TRANSPARENCY.PROVENANCE` demands, Systems MUST keep track of: -- ID of Systesm of origin and destination, in the format of URI according to [RFC3986 of IETF](https://www.rfc-editor.org/rfc/rfc3986) +- ID of Systems of origin and destination, in the format of URI according to [RFC3986 of IETF](https://www.rfc-editor.org/rfc/rfc3986) - Full Data Capture metadata objects - Full Consents metadata of consents relevant to the data being transferred - Data Subject Identities (`dsid`,`dsid-schema`) pairs associated to the data being transferred From 3a2bd6742b72699386d977ea90fb7aac65f7914e Mon Sep 17 00:00:00 2001 From: milstan Date: Fri, 24 Jun 2022 09:58:13 +0200 Subject: [PATCH 190/204] adding subcategory terms for UROPA interoperability --- refs/schemas/priv/RFC-PRIV.md | 2 +- .../priv/dictionary/legal-bases/en.legal-bases.json | 3 +++ refs/schemas/priv/examples.md | 12 +++++++++++- refs/schemas/priv/json-schema/priv-terms.schema.json | 3 +++ 4 files changed, 18 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 956c9df5..6ef2adf7 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -115,7 +115,7 @@ The Privacy Request Interchange Vocabulary includes the following: - **Boolean Terms**: {`YES`, `NO`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/boolean](./dictionary/boolean).* - - **Legal Base Terms**: {`CONTRACT`, `CONSENT`, `LEGITIMATE-INTEREST`, `NECESSARY`, `OTHER-LEGAL-BASE`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/legal-bases](./dictionary/legal-bases).* + - **Legal Base Terms**: {`CONTRACT`, `CONSENT`, `LEGITIMATE-INTEREST`, `NECESSARY`, `NECESSARY.LEGAL-OBLIGATION`, `NECESSARY.PUBLIC-INTEREST`, `NECESSARY.VITAL-INTEREST`, `OTHER-LEGAL-BASE`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/legal-bases](./dictionary/legal-bases).* - **Retention Terms**: {`NO-LONGER-THAN`, `NO-LESS-THAN`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/retentions](./dictionary/retentions).* diff --git a/refs/schemas/priv/dictionary/legal-bases/en.legal-bases.json b/refs/schemas/priv/dictionary/legal-bases/en.legal-bases.json index eaf5673b..0787e9b9 100644 --- a/refs/schemas/priv/dictionary/legal-bases/en.legal-bases.json +++ b/refs/schemas/priv/dictionary/legal-bases/en.legal-bases.json @@ -3,5 +3,8 @@ "CONTRACT": "Processing is necessary for providing services to the Data Subject or for the fulfilment of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract", "LEGITIMATE-INTEREST": "Processing is necessary for the purposes of the legitimate interests", "NECESSARY": "Processing is necessary for security reasons, legal reasons or protection of rights", + "NECESSARY.LEGAL-OBLIGATION": "Processing is necessary to comply with legal obligations", + "NECESSARY.PUBLIC-INTEREST": "Processing is necessary for tasks carried out in the public interest or exercise of authority", + "NECESSARY.VITAL-INTEREST": "Processing is necessary to protect an interest which is essential for the life of the data subject or that of another natural person", "OTHER-LEGAL-BASE": "Other legal base", } diff --git a/refs/schemas/priv/examples.md b/refs/schemas/priv/examples.md index 20b0ec9c..37c415df 100644 --- a/refs/schemas/priv/examples.md +++ b/refs/schemas/priv/examples.md @@ -362,7 +362,7 @@ The following correspondence of [data categories](https://www.luc.edu/its/abouti #### UROPA -[UROPA](https://github.com/uropa-project/uropa) defines the following Collection Means (called Provenance in PRIV) that can be mapped to PRIV Terms: +[UROPA](https://github.com/uropa-project/uropa) defines the following JSON enum values that can be mapped to PRIV Terms: | UROPA [collectionMean](https://gdpr.stoplight.io/docs/uropa/922d9e36659fd-data-type) | PRIV [Provenance Terms](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/schemas/priv/RFC-PRIV.md#provenance-categories) | | -------------- | ------------------ | @@ -373,6 +373,16 @@ The following correspondence of [data categories](https://www.luc.edu/its/abouti It is possible to model subcategory terms `DERIVED.GENERATED` and `DERIVED.COMPUTED` for the purposes of interoperability with UROPA. +| UROPA [Legal Bases](https://github.com/uropa-project/uropa/blob/main/src/LegalBasis.json) | PRIV [Legal Base Terms](https://github.com/blindnet-io/product-management/blob/devkit-schemas/refs/schemas/priv/RFC-PRIV.md#legal-bases) | +| -------------- | ------------------ | +| `contract` | `CONTRACT` | +| `consent` | `CONSENT`| +| `legitimate interest` | `LEGITIMATE-INTEREST` | +| `legal obligation` | `NECESSARY.LEGAL-OBLIGATION` | +| `vital interest` | `NECESSARY.VITAL-INTEREST` | +| `public interest task` | `NECESSARY.PUBLIC-INTEREST` | +| *not supported* | `OTHER-LEGAL-BASE` | + ## Questions and Discussion Topics diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json index fcac0d3d..22f9eb79 100644 --- a/refs/schemas/priv/json-schema/priv-terms.schema.json +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -87,6 +87,9 @@ "CONTRACT", "LEGITIMATE-INTEREST", "NECESSARY", + "NECESSARY.LEGAL-OBLIGATION", + "NECESSARY.VITAL-INTEREST", + "NECESSARY.PUBLIC-INTEREST", "OTHER-LEGAL-BASE" ] }, From 072f569e91cc8b843bab02de9d35cb7011b9bf94 Mon Sep 17 00:00:00 2001 From: Milan Date: Fri, 24 Jun 2022 10:12:08 +0200 Subject: [PATCH 191/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Filip <73657349+filipblnt@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index addee868..48acaf0b 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -650,7 +650,7 @@ When data about Data Subjects is transmitted from one system to another, in orde - ID of Systems of origin and destination, in the format of URI according to [RFC3986 of IETF](https://www.rfc-editor.org/rfc/rfc3986) - Full Data Capture metadata objects - Full Consents metadata of consents relevant to the data being transferred -- Data Subject Identities (`dsid`,`dsid-schema`) pairs associated to the data being transferred +- Data Subject Identity pairs (`dsid`,`dsid-schema`) associated to the data being transferred. Note that when Data Capture is transferred from a sending System to a receiving System, it is possible for a receiving System to add Data Subject Identities which are not known by the sending System > **Note** > From 26256ecfb6cae10ac786c4e5c74b6724eb0f2564 Mon Sep 17 00:00:00 2001 From: milstan Date: Fri, 24 Jun 2022 11:00:15 +0200 Subject: [PATCH 192/204] precision on set-theorethic operations (adter discussion with Marko) --- refs/schemas/priv/expected-behavior.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index b75c1ed8..d14eec7d 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -114,6 +114,7 @@ Each [Privacy Scope Triple](#privacy-scope-triples) that includes a `*` or a [Te E.g. `FINANCIAL` x `SHARING` x `SERVICES` is equivalent to the following set: +`FINANCIAL` x `SHARING` x `SERVICES` `FINANCIAL` x `SHARING` x `SERVICES.ADDITIONAL-SERVICES` `FINANCIAL` x `SHARING` x `SERVICES.BASIC-SERVICE` `FINANCIAL.BANK-ACCOUNT` x `SHARING` x `SERVICES` @@ -166,6 +167,14 @@ Yet, the **Eligible Privacy Scope** is independent to [Retention Policy](./RFC-P ### Set Operations over Privacy Scope +#### Set-Theoretic Operations over Privacy Scope + +A Privacy Scope consists of a set of [Privacy Scope Triples](#privacy-scope-triples). +All set operations (union, intersection, inclusion, etc.) are performed over Privacy Scopes taking into account the [Privacy Scope Triples](#privacy-scope-triples) equivalence. + +Privacy Scopes MAY first be resolved to all of their equivalent [Privacy Scope Triples](#privacy-scope-triples), over which simple set-theoretic operations MAY be applied. + + #### Operations over consents The scope of Consents can be modified by Privacy Request that include `OBJECT`, `RESTRICT`, and `REVOKE-CONSENT` actions. From c47544f772fb5741196c98326da96c522f058c66 Mon Sep 17 00:00:00 2001 From: milstan Date: Fri, 24 Jun 2022 13:57:37 +0200 Subject: [PATCH 193/204] precision about scenarios --- refs/schemas/priv/scenarios.md | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/refs/schemas/priv/scenarios.md b/refs/schemas/priv/scenarios.md index f4d831da..5feb835a 100644 --- a/refs/schemas/priv/scenarios.md +++ b/refs/schemas/priv/scenarios.md @@ -11,6 +11,13 @@ This document illustrates different scenarios in which [Privacy Request Intercha The goal of this document is to explore the design implications for implementing systems, that might arise from different situations. +Different scenarios described in this document MAY be combined, i.e. can be imagined any combination of any of the: +- [Local Authentication](#local-authentication) scenarios, +- [Multicast Authentication](#multicast-authentication) scenarios, +- [Automation](#automation) scenarios, +- [Automation](#automation) scenarios, +- [Response](#response) scenarios. + ## Terminology - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) @@ -23,7 +30,10 @@ The goal of this document is to explore the design implications for implementing - All the concepts, properties and terms listed in the [Proposal](./RFC-PRIV.md#proposal) section of PRIV(Privacy Request Interchange Vocabulary are to be interpreted as defined in [Privacy Request Interchange Vocabulary](./RFC-PRIV.md#proposal) ## Authentication -### Anonymous + +### Local Authentication + +#### Anonymous Systems MAY process certain requests without asking the user for their identity. This is especially the case with some of the `TRANSPARENCY` requests, in response to which general information is given. @@ -42,7 +52,7 @@ sequenceDiagram In certain cases, such as with GDPR ([articles 13 and 14](./examples.md#articles-13-and-14)), Systems MAY find themselves in obligation to provide information prior to capturing any data. However, in such cases, Systems are expected to [respond differently to the same requests](./expected-behavior.md#resolving-requests), with regards to the Data Subject being authenticated or not. For example a `TRANSPARENCY.DATA-CATEGORIES` request for an anonymous Data Subject MAY trigger a response listing all the possible data categories that the System is configured to collect. The same request for the authenticated Data Subject MAY trigger a response listing only the categories of data that the System has on this particular Data Subject. -### A Priori Authentication +#### A Priori Authentication The Data Subject formulates a Privacy Request when their identity is already confirmed. @@ -60,7 +70,7 @@ sequenceDiagram ``` -### A Posteriori Authentication +#### A Posteriori Authentication The Data Subject formulates a Privacy Request before their identity is confirmed. @@ -78,8 +88,9 @@ sequenceDiagram system->>subject: Privacy Request GRANTED note left of system: Phone number deleted ``` +### Multicast Authentication -### Signle Point Authentication for Corresponding Systems +#### Signle Point Authentication for Corresponding Systems In a context of multiple corresponding Systems, only one System confirms the identity of the user, and other Systems only process the Privacy Request. @@ -122,7 +133,7 @@ sequenceDiagram note left of systemA: E-mail deleted ``` -### Independent Authentication for Corresponding Systems +#### Independent Authentication for Corresponding Systems In a context of multiple corresponding Systems, every System confirms the identity of the Data Subject in their own way. From a8777b4a9fa62d47032f2397c7b70e0c13ad29e6 Mon Sep 17 00:00:00 2001 From: milstan Date: Sat, 25 Jun 2022 13:46:17 +0200 Subject: [PATCH 194/204] init Prohibited scope --- refs/schemas/priv/RFC-PRIV.md | 5 +- .../data-categories/en.data-categories.json | 1 + .../priv/json-schema/priv-terms.schema.json | 1 + refs/schemas/priv/prohibited-scope-gdpr.md | 91 +++++++++++++++++++ 4 files changed, 96 insertions(+), 2 deletions(-) create mode 100644 refs/schemas/priv/prohibited-scope-gdpr.md diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 48acaf0b..6fa58988 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -91,13 +91,13 @@ The Privacy Request Interchange Vocabulary includes the following: [Privacy Scope](#privacy-scope)(and its dimensions: *Data Category*, *Processing Category* and *Purpose*), [Provenance](#provenance), [Retention Policy](#retention-policy), -- **Properties**: `action`, `after`, `answers`, `capture-id`, `capture-ids`, `consent-id`,`consent-ids`, `data-subject`,`data`, `data-categories`, `data-reference`, `data-subject`, `date`,`demand-id`, `demands`, `dsid`, `dsid-schema`, `duration`, `expires`,`fragment-id`, `fragments`, `from`, `includes`, `in-response-to`,`lang`, `legal-base`, `message`, `motive`, `policy-type`, `processing-categories`, `provenance`, `provenance-category`, `purposes`, `replaces`, `response-id`, `restrictions`, `request-id`, `replaced-by`, `retention`, `requested-action`, `scope`, `selector`, `status`, `system`, `target`, `to`, `vocab` +- **Properties**: `action`, `after`, `answers`, `capture-id`, `capture-ids`, `consent-id`,`consent-ids`, `data-subject`,`data`, `data-categories`, `data-reference`, `data-subject`, `date`,`demand-id`, `demands`, `dsid`, `dsid-schema`, `duration`, `expires`,`fragment-id`, `fragments`, `from`, `includes`, `in-response-to`,`lang`, `legal-base`, `message`, `motive`, `parent`, `policy-type`, `processing-categories`, `provenance`, `provenance-category`, `purposes`, `replaces`, `response-id`, `restrictions`, `request-id`, `replaced-by`, `retention`, `requested-action`, `scope`, `selector`, `status`, `system`, `target`, `to`, `vocab` - **Terms**: all terms included in the [dictionary](./dictionary), and particularly: - **Action Terms**: {`ACCESS`, `DELETE`, `MODIFY`, `OBJECT`, `PORTABILITY`, `RESTRICT`, `REVOKE-CONSENT`, `TRANSPARENCY`, `TRANSPARENCY.DATA-CATEGORIES`, `TRANSPARENCY.DPO`, `TRANSPARENCY.KNOWN`, `TRANSPARENCY.LEGAL-BASES`, `TRANSPARENCY.ORGANIZATION`, `TRANSPARENCY.POLICY`, `TRANSPARENCY.PROCESSING-CATEGORIES`, `TRANSPARENCY.PROVENANCE`, `TRANSPARENCY.PURPOSE`, `TRANSPARENCY.RETENTION`, `TRANSPARENCY.WHERE`, `TRANSPARENCY.WHO`, `OTHER-DEMAND`} or any of their subcategories defined using the [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/actions](./dictionary/actions).* - - **Data Category Terms**: {`AFFILIATION`, `AFFILIATION.MEMBERSHIP`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, `UID.ID`, `UID.IP`, `UID.USER-ACCOUNT` , `UID.SOCIAL-MEDIA` , `OTHER-DATA`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation) including any [Data Capture Fragment](#data-capture-fragments) `selector`s. *See definitions in the [dictionary/data-categories](./dictionary/data-categories).* + - **Data Category Terms**: {`AFFILIATION`, `AFFILIATION.MEMBERSHIP`,`AFFILIATION.MEMBERSHIP.UNION`, `AFFILIATION.SCHOOL`, `AFFILIATION.WORKPLACE`, `BEHAVIOR`, `BEHAVIOR.ACTIVITY`, `BEHAVIOR.CONNECTION`, `BEHAVIOR.PREFERENCE`, `BEHAVIOR.TELEMETRY`, `BIOMETRIC`, `CONTACT`, `CONTACT.EMAIL`, `CONTACT.ADDRESS`, `CONTACT.PHONE`, `DEMOGRAPHIC`, `DEMOGRAPHIC.AGE`, `DEMOGRAPHIC.BELIEFS`, `DEMOGRAPHIC.GENDER`, `DEMOGRAPHIC.ORIGIN`, `DEMOGRAPHIC.RACE`, `DEMOGRAPHIC.SEXUAL-ORIENTATION`, `DEVICE`, `FINANCIAL`, `FINANCIAL.BANK-ACCOUNT`, `GENETIC`, `HEALTH`, `IMAGE`, `LOCATION`, `NAME`, `PROFILING`, `RELATIONSHIPS`, `UID`, `UID.ID`, `UID.IP`, `UID.USER-ACCOUNT` , `UID.SOCIAL-MEDIA` , `OTHER-DATA`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation) including any [Data Capture Fragment](#data-capture-fragments) `selector`s. *See definitions in the [dictionary/data-categories](./dictionary/data-categories).* - **Processing Category Terms**: {`ANONYMIZATION`, `AUTOMATED-INFERENCE`, `AUTOMATED-DECISION-MAKING`, `COLLECTION`, `GENERATING`, `PUBLISHING`, `STORING`, `SHARING`, `USING`, `OTHER-PROCESSING`} or any of their subcategories defined according to [Term Dot Notation](#term-dot-notation). *See definitions in the [dictionary/processing-categories](./dictionary/processing-categories).* @@ -374,6 +374,7 @@ A Consent is given by one Data Subject which can be identified by one or more [D | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | | `data-subject` | 1-* | [Data Subject Identities](#decentralized-identity-of-data-subjects) each containing one `dsid` and one `dsid-schema`| +| `parent` | 0-* | When Data Subject is a child and consent given by a Parent, then [Data Subject Identities](#decentralized-identity-of-data-subjects) of the parent each containing one `dsid` and one `dsid-schema`| | `consent-id` | 1 | a string in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | | `date` | 1 | Date and Time when Consent was given in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | | `expires` | 0-1 | Date and Time when Consent expires in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | diff --git a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json index be5f71b0..07df89d4 100644 --- a/refs/schemas/priv/dictionary/data-categories/en.data-categories.json +++ b/refs/schemas/priv/dictionary/data-categories/en.data-categories.json @@ -1,6 +1,7 @@ { "AFFILIATION": "Groups and Organisations the person is linked to through work, studies, or membership", "AFFILIATION.MEMBERSHIP": "Groups and organisations memberships", + "AFFILIATION.MEMBERSHIP.UNION": "Memberships to trade unions", "AFFILIATION.SCHOOL": "Studies organisation", "AFFILIATION.WORKPLACE": "Work organisation", "BEHAVIOR": "Data about the person's behavior", diff --git a/refs/schemas/priv/json-schema/priv-terms.schema.json b/refs/schemas/priv/json-schema/priv-terms.schema.json index 22f9eb79..94de92b0 100644 --- a/refs/schemas/priv/json-schema/priv-terms.schema.json +++ b/refs/schemas/priv/json-schema/priv-terms.schema.json @@ -40,6 +40,7 @@ "AFFILIATION.WORKPLACE", "AFFILIATION.SCHOOL", "AFFILIATION.MEMBERSHIP", + "AFFILIATION.MEMBERSHIP.UNION", "BEHAVIOR", "BEHAVIOR.ACTIVITY", "BEHAVIOR.CONNECTION", diff --git a/refs/schemas/priv/prohibited-scope-gdpr.md b/refs/schemas/priv/prohibited-scope-gdpr.md new file mode 100644 index 00000000..1085a275 --- /dev/null +++ b/refs/schemas/priv/prohibited-scope-gdpr.md @@ -0,0 +1,91 @@ +# Privacy Request Interchange Vocabulary : Prohibited Privacy Scope under GDPR + +| Status | NA / supporting document | +| :------------ | :------------------------------------------------------------------------------------- | +| **Author(s)** | [milstan](https://github.com/milstan) | +| **Updated** | 2022-06-25 | + +## Introduction + +[Privacy Request Interchange Vocabulary](./RFC-PRIV.md) defines the notion of [Privacy Scope](./RFC-PRIV.md#privacy-scope). [Expected Behavior of Implementing Systems](./expected-behavior.md) document further specifies the Privacy Scope algebra. + +However, [certain **(Privacy Scope)-(Legal Base) pairs** are simply prohibited by legislation](./expected-behavior.md#privacy-algebra) and Systems MAY be configured to reject them. + +This document specifies such **(Privacy Scope)-(Legal Base) pairs** prohibited under GDPR. The list covers most general cases, under assumption that no particular country-specific regulation has specified particular rules. + +Systems working under GDPR MAY be use those lists to facilitate compliance. Rejecting those prohibited scopes is not enough to ensure compliance. Not rejecting them is likely to put the System in a situation of non-compliance. + +## Terminology + +- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) +- The key word "CAN" denotes ability of someone or something, and is interpreted as "MUST be able to" +- The key words "blindnet devkit", "CCPA", "CPRA", "Capture Fragment", "Component", "Data Capture", "Data Capture Fragment", "Data Consumer", "Data Subject", "DPO", "Fragment", "GDPR", "HIPPA", "Internet User", "Organization", "Privateform", "Privacy Request", "System", "Submitter", "User" are to be interpreted as described in [RFC-Lexicon-2](../lexicon/RFC-Lexicon-2.md) +- Any additional precision about the key words defined in [RFC-Lexicon-2](../lexicon/RFC-Lexicon-2.md), as well as additional key words such as "Consent" and "Legal Base", provided in [High Level Conceptualization](../high-level-conceptualization/) is to be considered normative +- All key words denoting components of [blindnet devkit](../lexicon/RFC-Lexicon-2.md#blindnet-devkit), such as "Capture Component", "Encryption and Access Management Engine", "Privacy Computation Engine", "Privacy Compiler", "Privacy Request Capture Interface", "Customization API", "Data Consumer Interface", "Schemas" and "Storage Component" are to be interpreted as defined in [High Level Architecture](../high-level-conceptualization/) +- Privacy Compiler was formerly known as Data Rights Compiler +- Privacy Request was formerly known as Data Rights Request +- All the concepts, properties and [Terms](./RFC-PRIV.md#terms) listed in the [Proposal](./RFC-PRIV.md#proposal) section of PRIV(Privacy Request Interchange Vocabulary are to be interpreted as defined in [Privacy Request Interchange Vocabulary](./RFC-PRIV.md#proposal) + +## Prohibited Scopes + +### Art. 9 of GDPR + +Under `LEGITIMATE-INTEREST` or `CONTRACT` legal bases, (unless data are manifestly made public by the data subject) the following scopes are prohibited: +``` +AFFILIATION.MEMBERSHIP.UNION x * x * +DEMOGRAPHIC.ORIGIN x * x * +DEMOGRAPHIC.RACE x * x * +DEMOGRAPHIC.BELIEFS x * x * +DEMOGRAPHIC.SEXUAL-ORIENTATION x * x * +GENETIC x * x * +HEALTH x * x * +BIOMETRIC x * x * +``` + +Such data categories MAY be processed under `CONSENT` or `NECESSARY` legal bases under certain conditions. + +#### Special Organizations + +##### Not-for-profit + +`LEGITIMATE-INTEREST` can make processing of this data lawful according to Article 9. (d) of GDPR in the special case of not-for-profit body with a political, philosophical, religious or trade union aim and on condition that the processing relates solely to the members or to former members of the body or to persons who have regular contact with it in connection. However the data can't be shared. + +Such Organizations are still subject to the following prohibited scopes when using `LEGITIMATE-INTEREST`: + +``` +DEMOGRAPHIC.ORIGIN x SHARING x * +DEMOGRAPHIC.RACE x SHARING x * +DEMOGRAPHIC.BELIEFS x SHARING x * +DEMOGRAPHIC.SEXUAL-ORIENTATION x SHARING x * +GENETIC x SHARING x * +HEALTH x SHARING x * +BIOMETRIC x SHARING x * +``` + +The following scopes remain prohibited, even for those Organizations, under `CONTRACT`: +``` +AFFILIATION.MEMBERSHIP.UNION x * x * +DEMOGRAPHIC.ORIGIN x * x * +DEMOGRAPHIC.RACE x * x * +DEMOGRAPHIC.BELIEFS x * x * +DEMOGRAPHIC.SEXUAL-ORIENTATION x * x * +GENETIC x * x * +HEALTH x * x * +BIOMETRIC x * x * +``` + +##### Health professional + +`CONTRACT` can make processing of this data lawful according to Article 9. (d) of GDPR in the special case of a health professional subject to the obligation of professional secrecy under Union or Member State law or rules established by national competent bodies or by another person also subject to an obligation of secrecy under Union or Member State law or rules established by national competent bodies. + +The following scopes remain prohibited, even for those Organizations, under `LEGITIMATE-INTEREST`: +``` +AFFILIATION.MEMBERSHIP.UNION x * x * +DEMOGRAPHIC.ORIGIN x * x * +DEMOGRAPHIC.RACE x * x * +DEMOGRAPHIC.BELIEFS x * x * +DEMOGRAPHIC.SEXUAL-ORIENTATION x * x * +GENETIC x * x * +HEALTH x * x * +BIOMETRIC x * x * +``` From 7104af91707e72314ece828b0c29e7b6bbc34167 Mon Sep 17 00:00:00 2001 From: milstan Date: Sat, 25 Jun 2022 14:07:36 +0200 Subject: [PATCH 195/204] link to prohibited scope --- refs/schemas/priv/expected-behavior.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index d14eec7d..c281b208 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -153,7 +153,7 @@ E.g. under GDPR, it is prohibited to process gender and genetic data under any L For convenience, Privacy Compilers MAY also keep track of a set of **Prohibited (Privacy Scope)-(Legal Base) Pairs**, in which they SHOULD include [Privacy Scope Triples](#privacy-scope-triples) made illegal by the legislation that they want to support. It might also be convenient, when Data Subject's `OBJECT` or `RESTRICT` Demands are granted over a particular Privacy Scope, to list that scope under `LEGITIMATE-INTEREST` in the **Prohibited (Privacy Scope)-(Legal Base) Pairs** for making sure not to re-include them in the **Eligible Privacy Scope** unless the user gives explicit consent, signs a contract or becomes subject to mandatory data keeping. -> E.g. under GDPR, as processing of RACE data is only allowed under 'CONSENT' for medical research purposes, examples of **Prohibited (Privacy Scope)-(Legal Base) Pairs** include +> E.g. under GDPR, as processing of RACE data is only allowed under 'CONSENT' for medical research purposes, examples of **[Prohibited (Privacy Scope)-(Legal Base) Pairs](./prohibiter-scope-gdpr.md)** include > > (`data-category`=`DEMOGRAPHIC.RACE`, `purpose`=`ADVERTISING`) - CONSENT > From 4b4d570af6af25ce9436217823c5818b1035e308 Mon Sep 17 00:00:00 2001 From: Milan Date: Mon, 27 Jun 2022 12:20:14 +0200 Subject: [PATCH 196/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Marko <71560916+m4rk055@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 6fa58988..b773e963 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -451,7 +451,7 @@ In the System B, this Data Capture Fragment SHOULD be associated with two Proven In this way, the System B has complete information: the Data Capture Fragment was collected from the Data Subject by System A, and then transferred to it from System A. -If now System B transfers this data transfers this Data Capture Fragment to System C, then In the System B, this Data Capture Fragment SHOULD be associated with tree Provenance objects: +If now System B transfers this data transfers this Data Capture Fragment to System C, then In the System B, this Data Capture Fragment SHOULD be associated with three Provenance objects: - one having `provenance-category`:`USER.DATA-SUBJECT`, and `system`: `URL of the System A` - one having `provenance-category`:`TRANSFERRED`, and `system`: `URL of the System A` - one having `provenance-category`:`TRANSFERRED`, and `system`: `URL of the System B` From 5e97a0d81ef4fcf473dd210f0326d7e50caef96d Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 28 Jun 2022 11:56:02 +0200 Subject: [PATCH 197/204] Update refs/schemas/priv/expected-behavior.md Co-authored-by: Marko <71560916+m4rk055@users.noreply.github.com> --- refs/schemas/priv/expected-behavior.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index c281b208..a31c95ef 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -598,7 +598,7 @@ Systems SHOULD define Retention Policies at the time of configuration, and SHOUL Retention Policies are resolved upon concrete instances of Data Capture Fragments. A particular instance of data, given the Data Capture Fragment `selector` to which it corresponds, is considered `EXPIRED` if all of the following is true: - There is a Retention Policy the `data-categories` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular Data Capture Fragment, that is of type `NO-LONGER-THAN`, such that the date of the event defined under `after` has passed for a more then the time defined under `duration` -- AND There is no Retention Policy the `data-categories` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular Data Capture Fragment, that is of type `NO-LESS-THAN`, such that the event defined under `after` is yet to happen or has happened before a period of time inferior to `duration` +- AND `selector` of the Data Capture Fragment is NOT a part of a Privacy Scope of any of the Data Categories defined under `data-categories` property of the Retention Policy, whose type is `NO-LESS-THAN` and the difference between the current date and the date of the event defined under `after` is less than the value of `duration`, or has already occurred Privacy Compilers SHOULD be able to: - provide lists of active policies, in the context of answering to the `TRANSPARENCY.RETENTION` requests From e23c8a927963f7457c68ec1242fe5970ee9a477b Mon Sep 17 00:00:00 2001 From: Milan Date: Tue, 28 Jun 2022 11:57:35 +0200 Subject: [PATCH 198/204] Update refs/schemas/priv/expected-behavior.md Co-authored-by: Marko <71560916+m4rk055@users.noreply.github.com> --- refs/schemas/priv/expected-behavior.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index a31c95ef..79a0120f 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -597,7 +597,7 @@ When Data Subject ID is provided, the Data Subject is known by the System and au Systems SHOULD define Retention Policies at the time of configuration, and SHOULD cover all Data Categories and Data Capture Fragment `selector`s from the Intended Privacy Scope with at least one Retention Policy. Retention Policies are resolved upon concrete instances of Data Capture Fragments. A particular instance of data, given the Data Capture Fragment `selector` to which it corresponds, is considered `EXPIRED` if all of the following is true: -- There is a Retention Policy the `data-categories` of which is a Privacy Scope that includes Data Capture Fragment `selector` of the particular Data Capture Fragment, that is of type `NO-LONGER-THAN`, such that the date of the event defined under `after` has passed for a more then the time defined under `duration` +- `selector` of the Data Capture Fragment is a part of a Privacy Scope of any of the Data Categories defined under `data-categories` property of the Retention Policy. Retention Policy is of type `NO-LONGER-THAN` and the difference between the current date and the date of the event defined under `after` is larger than the value of `duration` - AND `selector` of the Data Capture Fragment is NOT a part of a Privacy Scope of any of the Data Categories defined under `data-categories` property of the Retention Policy, whose type is `NO-LESS-THAN` and the difference between the current date and the date of the event defined under `after` is less than the value of `duration`, or has already occurred Privacy Compilers SHOULD be able to: From 98b1247cb1607bd63ad811de107db06b540b7289 Mon Sep 17 00:00:00 2001 From: Milan Date: Fri, 1 Jul 2022 15:47:11 +0200 Subject: [PATCH 199/204] Update refs/schemas/priv/RFC-PRIV.md Co-authored-by: Marko <71560916+m4rk055@users.noreply.github.com> --- refs/schemas/priv/RFC-PRIV.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index b773e963..2cf981a0 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -133,6 +133,17 @@ A Privacy Request is made by one and only one Data Subject. A System MAY have multiple ways to identify the Data Subject, especially when data about them came from some other System that uses different identifiers. +> Let us imagine two Systems A and B interoperate, and exchange data about Bob. System A identifies bob with an ID (ID-a), System A sends Bobs data to System B. Systems B uses a different ID (ID-b). + +> If Systems A and B want to interoperate, and be able to interpret Bobs future Privacy Requests, then: + +> - System B MUST (in addition to ID-b, also save ID-a) +> - System that captures Bobs data MUST obtain consent for processing-category:MATCHING, target:PARTNERS +> - When Bob makes Privacy Request at System B but wants the Privacy Request transmitted to System A, System B must include both DSIDs (ID-a & ID-b) in the Privacy Request sent to System A +> - If Bob makes a REVOKE-CONSENT processing-category:MATCHING, then System B MUST delete the correspondence between ID-a and ID-b, and there is no more interoperability of future Privacy Requests. + +> If System A and Systems B use the same ID for Bob, then all this is much simpler. + The System capturing the Privacy Request MAY associate multiple Data Subject Identities to the Privacy Request, especially if the Privacy Request is likely to be transmitted to other systems. An array of one or more [Data Subject Identities](#decentralized-identity-of-data-subjects) MUST be provided in order to match the Data Subject with the data concerning them. From 2645056f4477a93b5a6635129c77a3e7fe4d9a9b Mon Sep 17 00:00:00 2001 From: milstan Date: Fri, 1 Jul 2022 15:48:32 +0200 Subject: [PATCH 200/204] nuance around MUST at revoke-consent matching example --- refs/schemas/priv/RFC-PRIV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 2cf981a0..5c995e16 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -140,7 +140,7 @@ A System MAY have multiple ways to identify the Data Subject, especially when da > - System B MUST (in addition to ID-b, also save ID-a) > - System that captures Bobs data MUST obtain consent for processing-category:MATCHING, target:PARTNERS > - When Bob makes Privacy Request at System B but wants the Privacy Request transmitted to System A, System B must include both DSIDs (ID-a & ID-b) in the Privacy Request sent to System A -> - If Bob makes a REVOKE-CONSENT processing-category:MATCHING, then System B MUST delete the correspondence between ID-a and ID-b, and there is no more interoperability of future Privacy Requests. +> - If Bob makes a REVOKE-CONSENT processing-category:MATCHING, then System B may find itself in a situation to have to delete the correspondence between ID-a and ID-b, and there is no more interoperability of future Privacy Requests. > If System A and Systems B use the same ID for Bob, then all this is much simpler. From 27bc17bfeb145fb28b5eb1b106ca9c1723507bc3 Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 5 Jul 2022 11:14:25 +0200 Subject: [PATCH 201/204] fixed cardinality of data range to/from (0-1, not 0-*) --- refs/schemas/priv/RFC-PRIV.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 5c995e16..3a3bbc82 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -281,8 +281,8 @@ A Demand can be restricted to particular Date Range, for example the Data Subjec | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `from` | 0-* | Date and Time when the Date Range starts in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | -| `to` | 0-* | Date and Time when the Date Range ends in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `from` | 0-1 | Date and Time when the Date Range starts in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | +| `to` | 0-1 | Date and Time when the Date Range ends in JSON Schema [date-time](https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.1) format | A Date Range defined by only one of the {`from`, `to`} properties indicates a period of time after or before a certain date, unbounded on the other end. From dff76dff9c8a0fc892bdbb7a8c85a139ad7b0877 Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 5 Jul 2022 12:11:28 +0200 Subject: [PATCH 202/204] precision on retention policy resolution --- refs/schemas/priv/RFC-PRIV.md | 6 ++++++ refs/schemas/priv/expected-behavior.md | 17 ++++++++++++++--- 2 files changed, 20 insertions(+), 3 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index 3a3bbc82..eb39590d 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -480,6 +480,12 @@ Not to be confused with [Provenance Restriction](#provenance-restriction). When several `data-categories` values are given, they are interpreted as a **union**. +It may happen that two or more Retention Policies conflict, e.g. the same data may be at the same time: +- no longer to be kept (covered by a `NO-LONGER-THAN` Retention Policy, the event of which has happened and the `duration` delay expired), +- AND in mandatory keeping (covered by a `NO-LESS-THAN` Retention Policy, the event of which is yet to happen, or the `duration` of which is yet to expire). + +In such cases, `NO-LESS-THAN` takes priority over `NO-LONGER-THAN`. The data is kept. + ## Detailed Design A separate document gives a list of [examples](examples.md) on how to represent real-life Privacy Requests, as defined in [supported legislation](#supported-legislation), or as modeled in existing systems with which we seek interoperability. diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 79a0120f..9f424fd5 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -51,7 +51,14 @@ A [Privacy Compiler](../high-level-architecture#data-rights-compiler) serving a - **Known Selectors** : exhaustive list of [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) `selector` know by the System, including for every data field that the System is likely to store (either a field of a data collection form, or simply a field in its database) the [Data Capture Fragment](./RFC-PRIV.md#data-capture-fragments) `selector` corresponding to it - **Configuration Maps**, defined at configuration time: - - *Retention Policies*: For each **Known Selector** (or Data Category implying every `selector` used within that Data Category) a data [Retention Policy](./RFC-PRIV.md#retention-policy), + - *Retention Policies*: For each **Known Selector** (or Data Category implying every `selector` used within that Data Category) one or more data [Retention Policies](./RFC-PRIV.md#retention-policy), + + > **Note** + > + > A `selector` MAY be concerned by more than one Retention Policy. Certain Retention Policies are defined at a granular level of the selector (e.g., having `data-categories`:`CONTACT.ADDRESS.SHIPPING`) and others at a more global level of a category (e.g., having `data-categories`:`CONTACT`). + > + > All of those MUST be [resolved](#resolving-retention-policies) i.e. all policies concerning any Data Category in which the `selector` is included MUST be applied to data associated with that `selector`. + > - *Provenance*: For every **Known Selector** keep track of one or more [Provenance](./RFC-PRIV.md#provenance) objects. @@ -597,8 +604,12 @@ When Data Subject ID is provided, the Data Subject is known by the System and au Systems SHOULD define Retention Policies at the time of configuration, and SHOULD cover all Data Categories and Data Capture Fragment `selector`s from the Intended Privacy Scope with at least one Retention Policy. Retention Policies are resolved upon concrete instances of Data Capture Fragments. A particular instance of data, given the Data Capture Fragment `selector` to which it corresponds, is considered `EXPIRED` if all of the following is true: -- `selector` of the Data Capture Fragment is a part of a Privacy Scope of any of the Data Categories defined under `data-categories` property of the Retention Policy. Retention Policy is of type `NO-LONGER-THAN` and the difference between the current date and the date of the event defined under `after` is larger than the value of `duration` -- AND `selector` of the Data Capture Fragment is NOT a part of a Privacy Scope of any of the Data Categories defined under `data-categories` property of the Retention Policy, whose type is `NO-LESS-THAN` and the difference between the current date and the date of the event defined under `after` is less than the value of `duration`, or has already occurred +- `selector` of the Data Capture Fragment is a part of a Privacy Scope of any of the Data Categories defined under `data-categories` property of the Retention Policy. Retention Policy is of type `NO-LONGER-THAN` and the difference between the current date and the date of the event defined under `after` is larger than the value of `duration` +- AND `selector` of the Data Capture Fragment is NOT a part of a Privacy Scope of any of the Data Categories defined under `data-categories` property of the Retention Policy, whose type is `NO-LESS-THAN` and the difference between the current date and the date of the event defined under `after` is less than the value of `duration`, or has already occurred + +In other words, as specified in [PRIV](./RFC-PRIV.md#retention-policy), conflicting policies are resolved by considering `NO-LESS-THAN` to take priority over `NO-LONGER-THAN` policies. + + Privacy Compilers SHOULD be able to: - provide lists of active policies, in the context of answering to the `TRANSPARENCY.RETENTION` requests From 38c97e45f80e0549a537cddb4e1556b8fc40874f Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 5 Jul 2022 15:52:14 +0200 Subject: [PATCH 203/204] removing provenance restriction It can be modeled using Privacy Scope + Data Range. No need for it now, and it would have complicated things for the relational databases. --- refs/schemas/priv/RFC-PRIV.md | 14 ++------------ refs/schemas/priv/expected-behavior.md | 11 ++++------- 2 files changed, 6 insertions(+), 19 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index eb39590d..f9ee063f 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -85,7 +85,7 @@ The Privacy Request Interchange Vocabulary includes the following: [Data Capture Fragment](#data-capture-fragments), [Data Subject Identity](#decentralized-identity-of-data-subjects), [Demand](#demands), -[Demand Restriction](#demand-restrictions) (including [Privacy Scope Restriction](#privacy-scope),[Consent Restriction](#consent-restriction), [Capture Restriction](#capture-restriction), [Date Range](#date-range), [Provenance Restriction](#provenance-restriction), [Data Reference Restriction](#data-reference-restriction)), +[Demand Restriction](#demand-restrictions) (including [Privacy Scope Restriction](#privacy-scope),[Consent Restriction](#consent-restriction), [Date Range](#date-range), [Provenance Restriction](#provenance-restriction), [Data Reference Restriction](#data-reference-restriction)), [Privacy Request](#privacy-request), [Privacy Request Response](#privacy-request-response), [Privacy Scope](#privacy-scope)(and its dimensions: *Data Category*, *Processing Category* and *Purpose*), [Provenance](#provenance), @@ -189,7 +189,7 @@ A Demand MAY refer to only certain Privacy Scope (Data Categories, certain Proce | Property | Expected cardinality | Expected values | | --------------- | ------ | -------------------- | -| `restrictions` | 0-* | An optional array of restriction objects, each being one of [Privacy Scope](#privacy-scope), [Consent Restriction](#consent-restriction), [Capture Restriction](#capture-restriction), [Date Range](#date-range), [Provenance Restriction](#provenance-restriction), [Data Reference Restriction](#data-reference-restriction)| +| `restrictions` | 0-* | An optional array of restriction objects, each being one of [Privacy Scope](#privacy-scope), [Consent Restriction](#consent-restriction), [Date Range](#date-range), [Provenance Restriction](#provenance-restriction), [Data Reference Restriction](#data-reference-restriction)| When more than one restriction is specified, the System MUST interpret the Demand as referring to the **intersection of restrictions**. For example let us consider a `DELETE` demand having two restrictions: `data-category`:`LOCATION` as Privacy Scope, and from 11th to 15th of June 2022 as Date Range. @@ -265,16 +265,6 @@ A Demand can be restricted to particular Consent ID(s). For example, a Data Subj When one or more `consent-ids` are indicated, Systems MUST interpret the Demand as related to all Consents related to indicated `consent-ids`. -###### Capture Restriction - -A Demand can be restricted to particular Capture ID(s). For example, a Data Subject to delete a particular data, they indicate the [Data Capture](#data-capture) concerned by their Demand. - -| Property | Expected cardinality | Expected values | -| --------------- | ------ | -------------------- | -| `capture-ids` | 0-* | Optional array of [Data Capture](#data-capture) IDs to indicate that the Demand (e.g. a `DELETE` Demand) is restricted to data captured within particular Data Captures. Items of the array are strings in the [uuid](https://www.rfc-editor.org/rfc/rfc4122.html) format | - -When one or more `capture-ids` are indicated, Systems MUST interpret the demand all related to (the **union** of) all the data captured as part of those Data Captures. - ###### Date Range A Demand can be restricted to particular Date Range, for example the Data Subject may `OBJECT` to data collection in a particular time period, or they might want to `DELETE` only data collected at certain dates. diff --git a/refs/schemas/priv/expected-behavior.md b/refs/schemas/priv/expected-behavior.md index 9f424fd5..bb7ac2a2 100644 --- a/refs/schemas/priv/expected-behavior.md +++ b/refs/schemas/priv/expected-behavior.md @@ -519,9 +519,7 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - first, check for presence of incompatible restrictions (and if incompatible recommend status = `DENIED`, motive = `REQUEST-UNSUPPORTED`): - [Consent Restriction](./RFC-PRIV.md#consent-restriction) with any other type of Restriction, - [Consent Restriction](./RFC-PRIV.md#consent-restriction) within a Demand other than `REVOKE-CONSENT`, - - More than one [Capture Restriction](./RFC-PRIV.md#capture-restriction), - More than one [Data Reference Restriction](./RFC-PRIV.md#data-reference-restriction) - - A Capture Restriction and any other restriction that is not a Privacy Scope Restriction, or a Data Reference Restriction, - More than one [Date Range](./RFC-PRIV.md#date-range) Restriction. - second, Calculate **Restriction Scope** and **Concerned Fragments**. This is done by processing every Restriction according to the following approach: @@ -531,12 +529,11 @@ When Data Subject ID is provided, the Data Subject is known by the System and au - when processing a [Privacy Scope](./RFC-PRIV.md#privacy-scope) Restriction, set the new **Restriction Scope** to be the intersection of the previous **Restriction Scope** with the Privacy Scope of the Restriction. **Concerned Fragments** is set to all Data Capture Fragments the `scope`s of which are included in the **Restriction Scope**. - - when processing a [Capture Restriction](./RFC-PRIV.md#capture-restriction) set the new **Restriction Scope** to be the intersection of the previous **Restriction Scope** with union of the [Privacy Scope](./RFC-PRIV.md#privacy-scope)s of each Data Capture Fragment of each Data Capture the `capture-id` of which is listed under `capture-ids` of that Capture Restriction + - when processing a [Data Reference Restriction](./RFC-PRIV.md#data-reference-restriction) look for all the Data Capture the `data-reference` of which matches the `data-reference` of the Restriction. Then for each such Data Capture `capture-id` set the new **Restriction Scope** to be the intersection of the previous **Restriction Scope** with union of the [Privacy Scope](./RFC-PRIV.md#privacy-scope)s of each Data Capture Fragment of the Data Capture corresponding to the `capture-id` + **Concerned Fragments** is set to all Data Capture Fragments that satisfy both of the criteria: - their `scope` is included in the **Restriction Scope**, AND - - they are part of one of the Data Captures the `capture-id` of which is listed under `capture-ids` of that Capture Restriction - - - when processing a [Data Reference Restriction](./RFC-PRIV.md#data-reference-restriction) look for all the Data Capture the `data-reference` of which matches the `data-reference` of the Restriction. Then for each such Data Capture `capture-id` proceed as if when processing when processing a [Capture Restriction](./RFC-PRIV.md#capture-restriction). + - they are part of one of the Data Capture corresponding to the `capture-id` - when processing a [Date Range](./RFC-PRIV.md#date-range), look for all the Data Capture Fragments the dates of which are within the given Date Range, and set the new **Restriction Scope** to be the intersection of the previous **Restriction Scope** with union of the [Privacy Scope](./RFC-PRIV.md#privacy-scope)s of each of those Data Capture fragments **Concerned Fragments** is set to all Data Capture Fragments that satisfy both of the criteria: @@ -553,7 +550,7 @@ When Data Subject ID is provided, the Data Subject is known by the System and au > > Data Capture Fragments the scopes of which fall under the **Restriction Scope** are not the same as (but are a superset of) the Data Capture Fragments included in the **Concerned Fragments** scope. > - > This is due to [Date Range](./RFC-PRIV.md#date-range), [Capture Restriction](./RFC-PRIV.md#capture-restriction) and [Provenance Restriction](./RFC-PRIV.md#provenance-restriction), all of which might be used to select particular Data Capture Fragments out of many thay may be captured with the same Data Capture Fragment `selector`. + > This is due to [Date Range](./RFC-PRIV.md#date-range), and [Provenance Restriction](./RFC-PRIV.md#provenance-restriction), all of which might be used to select particular Data Capture Fragments out of many thay may be captured with the same Data Capture Fragment `selector`. > - third, with regards to the `action` of the Demand: From 2502ea3f267f4653ee0d694f31732bea40bd2e25 Mon Sep 17 00:00:00 2001 From: milstan Date: Tue, 5 Jul 2022 20:37:15 +0200 Subject: [PATCH 204/204] removing considerations that are no longer necessary --- refs/schemas/priv/RFC-PRIV.md | 35 +---------------------------------- 1 file changed, 1 insertion(+), 34 deletions(-) diff --git a/refs/schemas/priv/RFC-PRIV.md b/refs/schemas/priv/RFC-PRIV.md index f9ee063f..534a5c89 100644 --- a/refs/schemas/priv/RFC-PRIV.md +++ b/refs/schemas/priv/RFC-PRIV.md @@ -717,42 +717,10 @@ Systems SHOULD keep a log of received [Privacy Requests](#privacy-request), gene ## Questions and Discussion Topics -### Use UUID for identifying Data Subjects - -We could imagine an alternative design, where we would force systems to use an [UUID]([uuid](https://en.wikipedia.org/wiki/Universally_unique_identifier)) (according to the [IETF RFC4122](https://www.rfc-editor.org/rfc/rfc4122.html)), to identify the users. That would require us to provide some way for systems to match UUIDs with their local IDs (usernames, or e-mails), and would potentially limit the ability of 3rd party systems to interpret Privacy Request made at another system. This goal of proposed design is to allow for flexibility. However it is a very important aspect of the proposal, that deserves further debate. - ### Zero-knowledge proof Data Subject authentication PRIV MUST be agnostic of the authentication method, and as such MUST be compatible with Zero-knowledge proof authentication, biometric methods, password-based authentication and any other method. We should check whether this is the case with the current design. -### Mandatory properties and value constrains - -Should we include restrictions in the schema according to the [JSON-schema-validation vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#page-4) in order to make certain properties mandatory and ensure to limit string values to the values we support? - -In the current proposal, this is the case for target, but not for request types, data categories, and user identity schemas. We might want to include more forma constraints there, or deliberately leave flexibility. This is a discussion we need to have. - -### Dot-notation for Terms - -Hierarchies of categories are represented using the "supercategory.subcategory" notation. The idea behind this is to allow developers to use the level of granularity that is adapted to them, yet be able to easily situate the subcategory in supercategory when dealing with more generic requests. - -E.g. We have a data capture associated to "CONTACT.ADDRESS" data category. The Data Subject makes a DELETE request related to all of their data falling under "CONTACT" data category. The developer can easily identify "CONTACT.ADDRESS" as being a subcategory of ""CONTACT.ADDRESS" (either in SQL or in jquery). - -The advantages are: -- It is human-readable -- It is easy to filter and get what you need - -The disadvantages: -- Takes a lot of bites to store (as it is text) and the search operations in it a string operations (also taking time). Those disadvantages can be easily managed on the level of the storage used for the data, and do not have to be managed on the level of this interoperability format, -- this notation (although intuitive) is to the best of my knowledge, non-standard. - -Maybe there are reasons for it (although similar notations are used for packages in programming languages, which are also hierarchical structures). - -*Is there a standard (better) notation we can adopt?* - -A candidate for a standard notation is the [URN](https://datatracker.ietf.org/doc/html/rfc8141). It is - less pretty (still human-readable), + standard, = equally searchable, = equally bad for storage and time. However we would still need to specify our own notation of the part of the URN that we want to customise. So the advantages are limited (if any). - -Disadvantage: using a non-standard notation we expose ourselves to unpredictable risks. - ### Schema elegance and modularity We need a way to make enums different categories and types more elegant, and reusable in the perspective of using them to also represent Data Captures, Consents and responses to Privacy Requests. @@ -771,7 +739,7 @@ This would make sense if the Systems would be responsible for finding a way to r A Data Subject can formulate a request to know about processing generally practiced by the System, or to know about processing being done on Data Subejct's particular data. Those can be different. Yet we have only one category 'TRANSPARENCY.PROCESSING-CATEGORIES'. Same goes for other `TRANSPARENCY` requests. -Currently we don't offer any way to distinguish between those two kinds of demands. We offer instructions for Systems, under [Expected Behavior](expected-behavior.md), on how to interpret them based on context (whether the request is made during capture, or prior to capture where request scope SHOULD be interpreted as general, or in some other context where the request scope SHOULD be interpreted as related to user's particular data). +Currently we don't offer any way to distinguish between those two kinds of demands. We offer instructions for Systems, under [Expected Behavior](./expected-behavior.md), on how to interpret them based on context (whether the request is made during capture, or prior to capture where request scope SHOULD be interpreted as general, or in some other context where the request scope SHOULD be interpreted as related to user's particular data). This design choice MAY be a bad idea. @@ -804,7 +772,6 @@ Should we include a way for systems to sign responses and allow to confirm their Should we implement the Accept-Language logic from HTTP? Or can we assume that the 'lang' of request is the language in which the response is expected? - ### Extending the vocabulary Is the mechanism for extending the vocabulary appropriate?