Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Anchored Notice and Consent Receipt (ANCR) Credential Transparency

...

Framework

Version: 0.8.9.3

Document Date: Oct 8, 2022

Editor(s): Mark Lizar, Sharon Polsky

Contributors: Sal D’Agostino, Paul Knowles

Contributing Orgs: Open Consent Group/0PN C.I.C, Privacy & Access Council of Canada, Human Colossus

Produced by: ANCR-WG

Status: WG Draft v0.8.9 (WG Review)Updated: Nov 22

Status:

The ANCR record objective is to provide operational transparency over data control and processing that works to regulate surveillance from offline and online activities, in much the same way as financial transactions are now regulated and tracked.

...

Finally, an active technical record of processing activities provides for the PII Principal in context transparency over who is accountable for — and is a pre-condition of — processing Personally Identifiable Information (PII) for human interoperable governance and security.

NOTES TO READER

This Kantara Initiative work effort began when Liberty Alliance became the Kantara Initiative, and the Consent and Information Sharing Working Group formally began in 2015. That Working Group’s activities carried on through the ANCR Working Group.

...

Suggested Citation: (upon WG approval)

ANCR Specification v0.9

NOTICE

This document has been prepared by Participants of Kantara Initiative Inc. Permission is hereby granted to use the document solely for the purpose of implementing the Specification. No rights are granted to prepare derivative works of this Specification. Entities seeking permission to reproduce this document, in whole or in part, for other uses must contact the Kantara Initiative to determine whether an appropriate license for such use is available.

Implementation or use of certain elements of this document may require licenses under third party intellectual property rights, including without limitation, patent rights. The Participants and any other contributors to the Specification are not and shall not be held responsible in any manner for identifying or failing to identify any or all such third-party intellectual property rights. This Specification is provided "AS IS," and no Participant in Kantara Initiative makes any warranty of any kind, expressed or implied, including any implied warranties of merchantability, non-infringement of third-party intellectual property rights, or fitness for a particular purpose. Implementers of this Specification are advised to review Kantara Initiative’s website (http://www.kantarainitiative.org ) for information concerning any Necessary Claims Disclosure Notices that have been received by the Kantara Initiative Board of Directors.

Dear reader

Thank you for downloading this publication prepared by the international community of experts that comprise the Kantara Initiative. Kantara is a global non-profit ‘commons’ dedicated to improving trustworthy use of digital identity and personal data through innovation, standardization and good practice.

...

Copyright: The content of this document is copyright of Kantara Initiative, Inc.
© 2022 Kantara Initiative, Inc.

Anchor
_gjdgxs
_gjdgxs
Anchor
_Toc243379787
_Toc243379787
Anchor
_Toc244482062
_Toc244482062
Anchor
_Toc260291045
_Toc260291045

Contents

Table of Contents

Anchor
_30j0zll
_30j0zll
Anchor
_Toc114372086
_Toc114372086
Anchor
_Toc114373590
_Toc114373590
Anchor
_Toc114373688
_Toc114373688
Anchor
_Toc114397892
_Toc114397892
Anchor
_Toc114372087
_Toc114372087
Anchor
_Toc114373591
_Toc114373591
Anchor
_Toc114373689
_Toc114373689
Anchor
_Toc114397893
_Toc114397893
Anchor
_Toc114372088
_Toc114372088
Anchor
_Toc114373592
_Toc114373592
Anchor
_Toc114373690
_Toc114373690
Anchor
_Toc114397894
_Toc114397894
Anchor
_Toc114372089
_Toc114372089
Anchor
_Toc114373593
_Toc114373593
Anchor
_Toc114373691
_Toc114373691
Anchor
_Toc114397895
_Toc114397895
Anchor
_Toc114372090
_Toc114372090
Anchor
_Toc114373594
_Toc114373594
Anchor
_Toc114373692
_Toc114373692
Anchor
_Toc114397896
_Toc114397896
Anchor
_Toc114372091
_Toc114372091
Anchor
_Toc114373595
_Toc114373595
Anchor
_Toc114373693
_Toc114373693
Anchor
_Toc114397897
_Toc114397897
Anchor
_Toc114372092
_Toc114372092
Anchor
_Toc114373596
_Toc114373596
Anchor
_Toc114373694
_Toc114373694
Anchor
_Toc114397898
_Toc114397898
Anchor
_Toc114372093
_Toc114372093
Anchor
_Toc114373597
_Toc114373597
Anchor
_Toc114373695
_Toc114373695
Anchor
_Toc114397899
_Toc114397899
Anchor
_Toc114372094
_Toc114372094
Anchor
_Toc114373598
_Toc114373598
Anchor
_Toc114373696
_Toc114373696
Anchor
_Toc114397900
_Toc114397900
Anchor
_Toc114372095
_Toc114372095
Anchor
_Toc114373599
_Toc114373599
Anchor
_Toc114373697
_Toc114373697
Anchor
_Toc114397901
_Toc114397901
Anchor
_Toc114372096
_Toc114372096
Anchor
_Toc114373600
_Toc114373600
Anchor
_Toc114373698
_Toc114373698
Anchor
_Toc114397902
_Toc114397902
Anchor
_Toc114372097
_Toc114372097
Anchor
_Toc114373601
_Toc114373601
Anchor
_Toc114373699
_Toc114373699
Anchor
_Toc114397903
_Toc114397903
Anchor
_Toc114372098
_Toc114372098
Anchor
_Toc114373602
_Toc114373602
Anchor
_Toc114373700
_Toc114373700
Anchor
_Toc114397904
_Toc114397904
Anchor
_Toc114372099
_Toc114372099
Anchor
_Toc114373603
_Toc114373603
Anchor
_Toc114373701
_Toc114373701
Anchor
_Toc114397905
_Toc114397905
Anchor
_Toc114372100
_Toc114372100
Anchor
_Toc114373604
_Toc114373604
Anchor
_Toc114373702
_Toc114373702
Anchor
_Toc114397906
_Toc114397906
Anchor
_1fob9te
_1fob9te
Anchor
_Toc108928869
_Toc108928869
Anchor
_Ref114328224
_Ref114328224
Anchor
_Ref114328225
_Ref114328225
Anchor
_Toc114497429
_Toc114497429
Introduction

...

For the purposes of this specification, the following terms and definitions apply as normative; non-normative to be used per context; and additive, in that they aid human understanding and data control.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

Normative References

For the international and cross-domain use of the records and receipts reflected in this specification, this document refers to the following:

  • ISO/IEC 29100:2011 Security and privacy techniques

  • ISO/IEC 29184 Online privacy notices and consent

  • Fair Information Practice Principles (FTC) foundational principles

Non-Normative References

  • 1980/2013 OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data [OECD]

  • Kantara Initiative Consent Receipt v1.11

  • Kantara Initiative: Blinding Identity Taxonomy (Bit)2

  • For input to ISO/IEC 27561:2022 POMME (Privacy operationalization model and method for engineering)

Additive Reference

  • General Data Protection Regulation (GDPR)

  • Council of Europe Convention 108+ (Conv. 108+)

  • PIPEDA – Individual, Meaningful Consent

...

The definitions and reference terms that are used in this specification to indicate what is normative, non-normative, and additive.

If this specification is not compatible with a jurisdiction’s privacy laws, the internationally‑defined terms reflected in this specification can be mapped to jurisdiction’s laws and context specific terms. For example, PII Principal in this document maps to the term ‘Data Subject’ in European GDPR legislation and the term ‘individual’ in Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA).

...

In this document the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “NOT RECOMMENDED”, "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119].

...

The following abbreviations and set of stakeholders are used to frame a mutually exclusive and collectively exhaustive set of terms for providing transparency over what organization controls the processing of personal information, and who is accountable for enforcement.

  • ANCR Record — means the Anchored Notice Record and Consent Receipt Record

  • ANCR WG — means the Advanced Notice and Consent Receipt Work Group

  • Array — means an array of field objects

  • Conv. 108+ — means the Council of Europe Convention 108+

  • FIPP — means Fair Information Practice Principles

  • IRM — means Identifier Relationship Management

  • ISO/IEC — means International Organization for Standardization/International Electrotechnical Commission

  • Object — means a field object

  • PII — means Personally Identifiable Information

  • POMME — means Privacy Operationalization Model and Method for Engineering

  • ZPN – Zero Public Network – a network in which each processor of personal information has a controller credential and the PII Principal has a private record of the credential

...

A code of conduct referred to in paragraph 2 of this Article shall contain mechanisms which enable the body referred to in Article 41(1) to carry out the mandatory monitoring of compliance with its provisions by the controllers or processors which undertake to apply it, without prejudice to the tasks and powers of supervisory authorities competent pursuant to Article 55 or 56.

[Source: GDPR Art 40.4]

When a Processor is not a European Union institution or body, its adherence to an approved code of conduct referred to in Article 40(5) of Regulation (EU) 2016/679 or an approved certification mechanism referred to in Article 42 of Regulation (EU) 2016/679 may be used as an element by which to demonstrate sufficient guarantees as referred to in paragraphs 1 and 4 of this Article.

[Source: Conv. 108+ Art 29.5]

...

This a new field – normative in this specification.

Used to provide a label that indicates what privacy an individual can expect by default, determined by legal justification per context for consistent transparency that an Individual can trust.

The types of Concentric Notice Label are specified in Annex B, which spans the spectrum of legally defined consent types, defined from for the individual’s context and perspective.

...

Not Concentric: Legal obligation or legitimate interest independent of PII Principal

Implied Consent: The PII Controller defines the purpose

Express Consent: The Individual actions indicate purpose

Explicit & Informed Consent:

Meaningful and/or Directed Consent, where in a PII Principal specifies the purpose for the collection, use, and/or disclosure of PII. Requires and ensures a higher degree of understanding.

Altruistic Consent, which requires a certified code of practice (in this framework – for a directed consent in which the legal obligation to identify the controller before processing is derogated.

[Source: ANCR Notice Record Annex B]

The organization shall provide information about the PII Principal's rights (e.g., access, rectification, deletion, objection, restriction, data portability, withdrawal of consent)

[Source: 29184: 5.3.1.2 — PII Principal Participation]

Modalities should be provided for facilitating the exercise of the Data Subject's rights under this Regulation, including mechanisms to request and, if applicable, obtain, free of charge, in particular, access to and rectification or erasure of personal data and the exercise of the right to object. The controller should also provide means for requests to be made electronically, especially where personal data are processed by electronic means.

[GDPR Rec 59]

Any processing of personal data should be lawful and fair. It should be transparent to natural persons that personal data concerning them are collected, used, consulted or otherwise processed and to what extent the personal data are or will be processed.

The principle of transparency requires that any information and communication relating to the processing of those personal data be easily accessible and easy to understand, and that clear and plain language be used.

That principle concerns, in particular, information to the Data Subjects on the identity of the Controller and the purposes of the processing and further information to ensure fair and transparent processing in respect of the natural persons concerned and their right to obtain confirmation, and communication of personal data concerning them, which are being processed.

Natural persons should be made aware of risks, rules, safeguards and rights in relation to the processing of personal data and how to exercise their rights in relation to such [rules of] processing.

[Source: Conv 108+ Rec.20]

...

Adhering to the openness, transparency and notice principles means providing PII Principals with clear and easily accessible information about the PII Controller’s policies, procedures and practices with respect to the processing of PII;

  • including in notices the fact that PII is being processed, the purpose for which this is done, the types of privacy stakeholders to whom the PII might be disclosed, and the identity of the PII Controller including information on how to contact the PII Controller;

  • disclosing the choices and means offered by the PII Controller to PII Principals for the purposes of limiting the processing of, and for accessing, correcting and removing their information; and

  • giving notice to the PII Principals when major changes in the PII handling procedures occur.

[Source: ISO/IEC 29100]

To provide notice where it is required, in a language appropriate to PII Principals, at a time that permits PII Principals to meaningfully exercise consent, at places where it is easy for PII Principals to recognize.

[Source: ISO/IEC 29184: Art 5.2.1]

Notice may be required, among other situations, when the organization plans to collect new PII (from the PII Principal or from another source) or when it plans to use PII already collected for a new purpose.

[Source: ISO/IEC 29184]

The principle of transparency requires that any information addressed to the public or to the data subject be concise, easily accessible and easy to understand, and that clear and plain language and, additionally, where appropriate, visualisation be used. Such information could be provided in electronic form, for example, when addressed to the public, through a website. This is of particular relevance in situations where the proliferation of actors and the technological complexity of practice make it difficult for the data subject to know and understand whether, by whom and for what purpose personal data relating to him or her are being collected, such as in the case of online advertising. Given that children merit specific protection, any information and communication, where processing is addressed to a child, should be in such a clear and plain language that the child can easily understand.

[GDPR Rec.58]

Principles relating to processing of personal data

Personally identifiable information must be processed lawfully, fairly, and in a transparent manner in relation to the Data Subject (‘lawfulness, fairness and transparency’);

[Conv 108+: Art.4(a)]

Broadly refers to any surveillance or privacy notice, notification, disclosure, statement, policy, sign, or signal used to indicate personal data processing.

[ANCR Notice Record Annex B]

...

The organization may implement the control using different techniques: layered notices, dashboards, just-in-time notices, or icons, and may provide notices in a machine-readable format so that the software which is presenting it to the PII Principal can parse it to optimize the user interface and help PII Principals make decisions

[Source: ISO/IEC 29184 5.2.7]

Transparency, including general information on the logic underlying the PII processing, can be required, particularly, if the processing involves a decision impacting the PII Principal. Privacy stakeholders that process PII should make specific information about their policies and practices relating to the management of PII readily available to the public. All contractual obligations that impact PII processing should be documented and communicated internally as appropriate. They should also be communicated externally to the extent those obligations are not confidential.

[Source: ISO/IEC 29100 5.8]

That information may be provided in combination with standardised icons in order to better provide an easily visible, intelligible and clearly legible manner, a meaningful overview of the intended processing. Where the icons are presented electronically, they should be machine-readable.

[Conv 108+ Rec 35]

...

Organizations should seek consent for changes such as those outlined here, and should consider whether the PII Principal has access to a record (of some kind) of their original consent, as well as how much time has elapsed between the original consent and the present. If the PII Principal is able to access a record of their prior consent readily and if the elapsed time is not significant, organizations may provide notice of the changes and seek consent for same. Otherwise, the organization should seek reconfirmation of the original consent in addition to consent to the notified changes.

Where re-consent is requested, and no response is received, it should be assumed that the request for consent for the new/additional purpose is not granted; and the purposes for which the original consent has been provided remains unchanged.

[Source: 29184: 5.3]

Each controller and, where applicable, the controller's representative, shall maintain a record of processing activities under its responsibility. That record shall contain all of the following information:

(a) the name and contact details of the controller and, where applicable, the joint controller, the controller's representative and the data protection officer;

[Source: GDPR Art 30]`

Records of processing activities: 1. Each controller shall maintain a record of processing activities under its responsibility. That record shall contain all of the following information: the name and contact details of the controller, the data protection officer and, where applicable, the processor and the joint controller;

[Source: Conv 108+ Art 31]

Privacy Principles

The privacy principles articulated in ISO/IEC 29100 are now embodied in international standards and laws.

  1. Consent and choice

  2. Purpose legitimacy and specification

  3. Collection limitation

  4. Data minimization

  5. Use, retention, and disclosure limitation

  6. Accuracy and quality

  7. Openness, transparency, and notice

  8. Individual participation, and access

  9. Accountability

  10. Information security

  11. Privacy compliance

[Source: ISO/IEC 29100 Table 3]

...

A Consent Notice Receipt, for a proof of notice, used as evidence of consent and to ...demonstrate compliant records of processing activities.

[Source: ISO/IEC 29184 Appendix B]

A Record of Notice that is generated to provide proof of an informed individual supersedes terms and conditions (contract), to implement overarching privacy rights‑based control.

[Source: ANCR Notice Record v1 – Specification]

...

Any information that (a) can be used to identify the PII Principal to whom Personally Identifiable Information relates, or (b) is or might be directly or indirectly linked to a PII Principal.

NOTE: To determine whether or not an individual should be considered identifiable, several factors need to be taken into account. (Equivalent with personal data)

[Source: ISO/IEC 29100]

Descriptor for a type of Personally Identifiable Information, or a set of types of Personally Identifiable Information

[Source: ISO/IEC 29184 3.3]

Personal Data means any information relating to an identified or identifiable natural person.

Data Subject means an identifiable natural person who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

[Source: Conv. 108+ Rec 16]

...

What constitutes Sensitive PII is defined explicitly in legislation; however, the definition might vary across jurisdictions. Sensitive PII might include information revealing race, ethnic origin, religious or philosophical beliefs, political opinions, trade union membership, sexual lifestyle or orientation, and the physical or mental health of the PII Principal. In other jurisdictions, sensitive PII might include information that could facilitate identity theft or otherwise result in significant emotional, psychological, or financial harm to the natural person (e.g., credit card numbers, bank account information, or government-issued identifiers such as passport numbers, social security numbers or drivers’ license numbers), and information that could be used to determine the PII Principal’s real time location.

[Source: ISO/IEC 29100 4.4.7]

Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person's sex life or sexual orientation shall be prohibited.

[Source: GDPR Art 9.1]

Sensitive PII should not be processed unless the specific conditions set out in this Regulation are met. Those personal data should include personal data revealing racial or ethnic origin, whereby the use of the term ‘racial origin’ in this Regulation does not imply an acceptance by the Union of theories which attempt to determine the existence of separate human races. The processing of photographs should not systematically be considered to be processing of special categories of personal data as they are covered by the definition of biometric data only when processed through a specific technical means allowing the unique identification or authentication of a natural person. In addition to the specific requirements for processing of sensitive data, the general principles and other rules of this Regulation should apply, in particular as regards the conditions for lawful processing. Derogations from the general prohibition for processing such special categories of personal data should be explicitly provided, inter alia, where the Data Subject gives his or her explicit consent or in respect of specific needs, in particular where the processing is carried out in the course of legitimate activities by certain associations or foundations the purpose of which is to permit the exercise of fundamental freedoms.

[Source: Conv. 108+ Rec, 29]

...

The natural person to whom the personally identifiable information (PII) relates.

NOTE: Depending on the jurisdiction and the particular data protection and privacy legislation, the synonym “Data Subject” can also be used instead of the term “PII Principal.”

[Source: ISO 29100 2.11]

PII Principals provide their PII for processing to PII Controllers and PII processors and, when it is not otherwise provided by applicable law, they give consent and determine their privacy preferences for how their PII should be processed. PII Principals can include, for example, an employee listed in the human resources system of a company, the consumer mentioned in a credit report, and a patient listed in an electronic health record. It is not always necessary that the respective natural person is identified directly by name in order to be considered a PII Principal. If the natural person to whom the PII relates can be identified indirectly (e.g., through an account identifier, social security number, or even through the combination of available attributes), he or she is considered to be the PII Principal for that PII set.

[Source: ISO 29100 4.2.1]

Personal Data means any information relating to an identified or identifiable natural person (‘Data Subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

[Source: GDPR: Article 4.1]

Individual: Upon request, an individual shall be informed of the existence, use, and disclosure of his or her personal information and shall be given access to that information. An individual shall be able to challenge the accuracy and completeness of the information and have it amended as appropriate.

[Additive: PIPEDA 4.9]

...

A PII controller determines why (purpose) and how (means) the processing of PII takes place. The PII controller should ensure adherence to the privacy principles in this framework during the processing of PII under its control (e.g., by implementing the necessary privacy controls). There might be more than one PII controller for the same PII set or set of operations performed upon PII (for the same or different legitimate purposes). In this case the different PII controllers shall work together and make the necessary arrangements to ensure the privacy principles are adhered to during the processing of PII. A PII controller can also decide to have all or part of the processing operations carried out by a different privacy stakeholder on its behalf. PII controllers should carefully assess whether or not they are processing sensitive PII and implement reasonable and appropriate privacy and security controls based on the requirements set forth in the relevant jurisdiction as well as any potential adverse effects for PII principals as identified during a privacy risk assessment.

NOTE: A PII Controller sometimes instructs others (e.g., PII processors) to process PII on its behalf while the responsibility for the processing remains with the PII Controller.

[Source: ISO 29100 4.2.2]

‘Controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law;

Note: Also known as a Data Controller.

[Source: GDPR Art. 4(7)]

‘Controller’ means the Union institution or body or the directorate-general or any other organisational entity which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by a specific Union act, the controller or the specific criteria for its nomination can be provided for by Union law;

[Source: Conv 108+ Art 3(8)]

...

Covers multiple joint controller relationships including co-controllers, hierarchical, fiducial, and code.

Where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers. They shall in a transparent manner determine their respective responsibilities for compliance with the obligations under this Regulation, in particular as regards the exercising of the rights of the Data Subject and their respective duties to provide the information referred to in Articles 13 and 14, by means of an arrangement between them unless, and in so far as, the respective responsibilities of the controllers are determined by Union or Member State law to which the controllers are subject. The arrangement may designate a contact point for Data Subjects.

[Source: GDPR Art 26.1]

Where two or more controllers or one or more controllers together with one or more controllers other than Union institutions and bodies jointly determine the purposes and means of processing, they shall be joint controllers. They shall in a transparent manner determine their respective responsibilities for compliance with their data protection obligations, in particular as regards the exercise of the rights of the Data Subject and their respective duties to provide the information referred to in Article 79, by means of an arrangement between them, unless and in so far as the respective responsibilities of the joint controllers are determined by Union or Member State law to which the joint controllers are subject. The arrangement may designate a contact point for Data Subjects.

[Source: Conv 108+ Art 86.1]

...

A privacy stakeholder that processes personally identifiable information (PII) on behalf of and in accordance with the instructions of a PII Controller.

[Source: ISO 29100]

'processor’ means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller;

[Source: GDPR Art 4(8)]

‘processor’ means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller;

[Source: Conv. 108+ Art 3(12)]

...

Refers to the PII Controller type in the ANCR record specification.

[ANCR Notice Record Specification v0.9]

An additional field to indicate a delegated PII Processor (rather than 3rd Party). Used to distinguish between, a legally authorized 3rd Party, like a public health authority, who would themselves be a PII Controller, for that legal justification. Also found in the W3C Data Privacy Vocabulary.

[Additive: W3C DPV 2.3.1.6 http://w3c.github.io/dpv/dpv/ ]

...

An operation or set of operations performed on personally identifiable information (PII).

NOTE: Examples of processing operations of PII include, but are not limited to, the collection, storage, alteration, retrieval, consultation, disclosure, anonymization, pseudonymization, dissemination or otherwise making available, deletion or destruction of PII.

[Source: ISO 29100]

‘Processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;

[Source: GDPR Art 4.2]

‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;

[Source. Convention 108+]

...

Refers to a government authority responsible for the enforcement of privacy and data protection regulation. Referred to also as a Data Governance Authority, a Data Protection Authority (DPA) or simply Privacy Regulator.

Privacy Stakeholder

A natural or legal person, public authority, agency or any other body that can affect, be affected by, or perceive themselves to be affected by a decision or activity related to personally identifiable information (PII) processing.

[Source: ISO 29100]

Engage relevant stakeholders in discussion and activities aimed at furthering international cooperation in the enforcement of legislation for the protection of personal data;

[Source: GDPR Art. 50(c)]

Engage relevant stakeholders in discussion and activities aimed at furthering international cooperation in the enforcement of legislation for the protection of personal data;

[Source: Conv.108+ Art 51(c)]

...

Table A.1 — Mapping ISO/IEC 29100 concepts to ISO/IEC 27000 concepts

...

Correspondence with ISO/IEC 27000 concepts

...

Privacy stakeholder

...

Stakeholder

...

PII

...

Information asset Information security incident Control

...

Privacy breach Privacy control Privacy risk

...

Risk

...

Privacy risk management

...

Risk management

...

Privacy safeguarding requirements

...

Control objectives

[Source: ISO/IEC 29100: Annex A]

...

Standard Concentric Clauses implement 29184 compliance controls and Privacy Service Agreements [ISO/IEC TS 27570: 3.22]

These clauses are used to implement the PII Principals expectations of privacy, data control, localization and security according to context and notified purpose. These clauses are introduced in contracts, terms and conditions and refer to the concentric notice label controls and requirements as specified in this document Annex X.

These clauses MUST be employed in a manner to scale the expectations of the PII Principal online, to facilitate data governance interoperability and transborder adequacy of electronic consent.

Third Party (or 3rd Party)

A privacy stakeholder other than the personally identifiable information (PII) principal, the PII Controller and the PII processor, and the natural persons who are authorized to process the data under the direct authority of the PII Controller or the PII processor.

[Source: ISO 29100 2.27]

Third party means a natural or legal person, public authority, agency or body other than the Data Subject, controller, processor and persons who, under the direct authority of the controller or processor, are authorised to process personal data;

[Source: GDPR Art 4.10]

Third party means a natural or legal person, public authority, agency or body other than the Data Subject, controller, processor and persons who, under the direct authority of the controller or processor, are authorised to process personal data;

[Source: Convention 108 Art 3.14]

ANCR Notice Record Schema Specification

...

ANCR Notice Record Schema Specification

The ANCR notice record is fundamentally a layered record schema, the first record layer is the minimum viable notice record (MVNR) a PII Principal can make to capture the organisation/institution that controls their personal data as well as the accountable person liable for that legal entity. This record collects no additional data, except what the PII Principal is required to see and understand in order to be legally informed of the risks of generating a digital identifier.

...

This schema is cumulative, where each schema layer can be added upon the previous layer.

3

...

Layers to the ANCR

...

Record Schema

Layer 1 - Notice Record Schema.

The PII Principal's private record of a notice without digital identifiers, also called a ‘minimum viable record notice’. This record is un-anchored and used for contextual purposes when it does not contain an ANCR Record ID, in the ancr record id field.

Layer 2 – Private Notice Record Micro-Data

  1. The meta data that can, and must be collected with the notice record to make a digital record of the notice record

  2. Is kept private and not directly accessible, exposed or made public.

  3. The PII Principal private record collects personal data specific to the use of the notice

Layer 3 - A Proof of Notice (PoN) record is generated

  1. A secured Anchored Notice Record generated upon engagement with a notice to demonstrate that the PII Principal is informed. Not an opt-in or opt-out check box – which is linked to a notice. But check-box to confirm a notice clause is read, with a button on the notice dialogue that generates a record and receipt when used by the PII Principal

  2. A proof of notice record can then be used by processing stakeholders to generate subsequent (serialized) linked notice, notification and disclosure records pertinent to the context of notice.

    1. Personal identifiers and attributes are encrypted, secured, verified and validated by linking to the private notice record.

Anchor
_Toc114497459
_Toc114497459
Notice Record Schema: PII Controller Identity & Privacy Contact Point Schema

These are the schema elements that are used to generate a static Notice Record and does not contain any PII, or digital identifiers.

...

Field Cat Name

Name

Object Description

Presence Requirement

PII Controller Identity

Object

_

Required

Presented Name of Service Provider

name of service. E.g. Microsoft

May

PII Controller Name

Company/organization name

MUST

PII Controller address

_

MUST

PII Controller contact email

correspondence email

MUST

PII Controller jurisdiction legal reference

PII Controller Operating Privacy Law

MUST

PII Controller Phone

The general correspondence phone number

SHOULD

PII Controller Website

URL of website (or link to controller application)

MUST

PII Controller Certificate

A capture Website SSL

OPTIONAL

Privacy Contact Point Location

pcpL

Direct link to security and/or privacy contact point

MUST

Privacy Contact Point Types (pcpT)

Object

Must have at least one field for the PCP object

MUST

PCP_Profile

Privacy Access Point Profile

**

PCP_InPerson

In-person access to privacy contact

**

PCP_Email

PAP email

**

PCP_Phone

Privacy access phone

**

PCP _PIP_URI

privacy info access point, URI

**

PCP_Form

Privacy access form URI

**

PCP_Bot

privacy bot, URI

**

PCP_CoP

code of practice certificate, URI of public directory with pub-key

**

PCP_Other

Other

**

PCP Policy

pcpp

privacy policy, URI with standard consent label clauses

MUST

Anchor
_Toc114497460
_Toc114497460
Private Notice Record Profile

These fields can be asserted by the PII Principle to extend the functionality beyond the transparency TPI’s specified, on the PII Principal’s behalf.

These private record fields are separated from the Proof of Notice schema, as these are kept and controlled by the PII Principal and are used to provide defaults.

Anchor
_Toc114497461
_Toc114497461
Private Notice Record Schema

This is the data source for consented records of processing that is directed (and securely) verified by the PII Principal, with secure localized data source and device.

Record Field Name

Field Description

Verifier/Validator

Schema version

A number used by the PII Principal to track the PII Controller Record

Verifier

Anchor Notice Record id #

An identifier unique to the controller, used to identify the legal entity accountable for relying parties and affiliated services

Verifier

Date/Time

The date and time a notice was read by PII Principal

Validator

Notice Presentation method

Notice presentation delivery method is also known as a user-interface presentation_Type

Validator

Notice Location

URL, physical address, or regional location, the notice was presented to the PII Principal

Verifier

Notice Legal Justification

One of the six legal justifications(PII Cntrl’r, ISO/IEC, GDPR, C108+)

Validator

PII Principal Legal Location

Refers the privacy rules in the local context

Validator

Device Type Identifier

device identifier or fingerprint used to verify the physical method of delivery -.e.g. sign, mobile phone number, desktop computer

Verifier

PII Principal Private/Public - Key Pair

The cryptographic key pair used to sign and encrypt fields in a consent record

Verifier

Anchor
_Toc114497462
_Toc114497462
Proof of Notice Record

For consented digital identity management, a proof of Notice Record is used as an alternative to terms and conditions, to mitigate high privacy risks associated with digital identifier surveillance and profiling. Terms of use refer to a contract-based policies for the governance of identifiers and credentials.

...

Note: The ANCR Notice Record ID is used to create and link new receipts, thereby ensuring the providence of the PII Principal’s control of the ANCR Record.

Anchor
_Toc114497463
_Toc114497463
Proof of Notice Record Schema

The Proof of Notice Record builds upon the PII Controller Identity fields and contact fields, with PII Controller Identifiers used to digitally track the state of privacy .

...

  • A notice that is used to generate granular consent receipts using standards that specify purpose in the same way. Those generated with the same schema based can be compared to automate notice for operational transparency over changes to privacy state.

  • A 2FN is used to produce a dual record and receipt upon engaging with a standardized notice with access to administrator-level privacy rights from the notice, prior to processing with consent.

  • The consent receipts produced from a 2FN can be compared independently to measure the difference in the active state and status of privacy, to automatically produce a notification based on the difference in state.

  • Differential Transparency, produced with a tactile signal, or layer1 notice indicator, standardized with machine readable data privacy vocabulary (i.e., concentric and synchronic transparency).

...

Anchor
_Toc114497464
_Toc114497464
Anchor
_Toc498675771
_Toc498675771
Anchor
_Toc108928904
_Toc108928904
Notice Record Security Architecture

Anchor
_Toc114497465
_Toc114497465
Overview

The ANCR Record represents the online privacy notice control record that is used to assess conformance with privacy expectations using controls and structure for consent from ISO/IEC 29184 Online Privacy Notice and Consent, which sets out the rules used to secure, protect and safeguard personal data:

...

Three (3) layers of the notice record schema is presented in this specification, with each layer building on the first as described in the Introduction.

Anchor
_Toc114372161
_Toc114372161
Anchor
_Toc114373661
_Toc114373661
Anchor
_Toc114373757
_Toc114373757
Anchor
_Toc114397950
_Toc114397950
Anchor
_Toc114372162
_Toc114372162
Anchor
_Toc114373662
_Toc114373662
Anchor
_Toc114373758
_Toc114373758
Anchor
_Toc114397951
_Toc114397951
Anchor
_Toc114372163
_Toc114372163
Anchor
_Toc114373663
_Toc114373663
Anchor
_Toc114373759
_Toc114373759
Anchor
_Toc114397952
_Toc114397952
Anchor
_Toc114372164
_Toc114372164
Anchor
_Toc114373664
_Toc114373664
Anchor
_Toc114373760
_Toc114373760
Anchor
_Toc114397953
_Toc114397953
Anchor
_Toc114497466
_Toc114497466
Security practice: requirements for the privately anchored record

The ANCR record identifier has specific security requirements and considerations since it can be used by the PII Principal as an identifier for and by a PII Controller. The ANCR Notice Record can be extended to additional stakeholders with a public key. Consent records and receipts created by the PII Principal are sensitive, confidential, and secured for PII Principal ownership and control. Evidence of consent is required to access these attributes for producing or using verifiable (micro) credentials the PII Principal can validate.

The protocol requires that the ANCR Record be referenced each time a directed, or altruistic consent is generated, or when decentralized data governance is required. This is done in order to verify the PII Controller Identity and ensure sufficient (any) security for the privacy state that is, and can then be, expected by the PII Principal.

Trustworthy Compliance Metrics

The transparency performance indicators (TPIs) provide transparency and security assurance to the PII Controller before the Controller processes personal information.

...

  1. Blinded Identity Taxonomy (BiT)

    1. PII field security measure that is used to blind attributes that are identifiable, for example, the attributes presented in ISO/IEC 29100 section 4.4.2

    2. A BiT attribute is encrypted with the PII Principals private key- so as not be usable in any data set without the corresponding authority required to unencrypt the field for a specified purpose and treatment.

    3. In this specification BIT is used by the PII Principle to encrypt and blind the ANCR record ID field. Which is in the private notice record, the pseudonymized identifier generated/provided by the PII Principals (client security protocol)

  2. Pseudonymized Identifier

    1. The ANCR record id refers to the PII Controller legal identity captured with a notice record, and once a notice record is collected it can be signed to become added to digital wallet (or pod), it can be signed to become a micro-credential, and used to communicate to the PII Controller, to manage rights and control processing of digital identifiers and associated information.

    2. Conceptually, the ANCR Id is a reverse use cookie, in that it is used by the PII Principle to remember the privacy state and track the PII Controller through different service environments, domains and jurisdictions.

  3. Verifiable Private Notice Record signed to be a micro-credential

    1. The PII Principal as the holder of the notice record can use it to a verify the presentation a PII Controller Identity

    2. Holders of a signed notice record (proof of notice) can generate a verifiable presentation of this proof by;

      1. signing a copy of the notice-record

        1. (transforms record into a micro-credential)

      2. exchanging this with the other stakeholder (PII Principle or Controller) as a signed consent receipt in order to tokenize the exchange of attribute level private record data on a per processing session basis.

        1. (W3C Verified Credential Data Model, www.w3.org/TR/vc-data-model/#what-is-a-verifiable-credential)

  4. Differential Transparency – operational transparency signaling

    1. Operational transparency – notice record ‘trust’ protocol for active state technical object. Achieved by comparing the expected privacy state (purpose and credential) each technical session to authorize an instance of processing, whereby a notification signal is generated only if there has been a change in the expected, and known active state of privacy.

    2. Differential Transparency (DT) is a contextual transparency enhancing notification protocol that uses record serialization in order to sequence data control points. Used to maintain a shared understanding of privacy and conversely security expectations.

    3. Implemented by comparing than Anchored Notice Record with a newly minted anchored consent notice receipt. To detect if there has been a change in this expected state. Achieved through self-asserted changes, or through monitoring authoritative public data sources.

    4. Differential Transparency is used by the PII Principal to automate the verification of trust, monitoring the active state of the PII Controller Legal identity and technical security performance. Prior to authorizing data processing activities by signing a consent notice receipt.

      1. Utilizing the Transparency Performance Indicator’s in the introduction of this specification to transform a consent receipt into a consent token. (Individual authority and providence default controls to implement rights)

    5. Automating Operational Transparency

      1. Human centric notice protocol to keep a record of controllers and context of processing, for each session/interaction, so that these contextual records, controlled owned and secured by the PII Principal, can remember the active state of privacy and verify the PII Control and Privacy state without interrupting the service-user flow.

      2. Notice Signal Layer: For operational transparency at a glance using digital signaling to indicate with concentric labeling what is expected, and what is not.

Case Study: Differential Privacy as a mechanism for Data Control

For discussion with security and privacy community. Like digital identity management, how sovereign data control can be measured is by identifying which PII Stakeholder is in control of the personal data and personal data process; who benefits from processing personal data; and how dynamic are the personal data controls? The analysis results indicate which stakeholder can authorise the use of the tool, and for which purpose(s)

  1. Differential Privacy [ not to be confused with Differential Transparency]

    1. A method to produce noise in a personal data profile, and data sets so that the output cannot be used as conclusive evidence, or used to attack systems. A safeguard that is described as a way to provide a ‘buffer’ to protect the PII Principal from harms.

      1. A relevant topic defined in the ANCR Record used in a different context, not as a tool used by a PII Controller, but as a control for PII Principal to use when engaging with PII Controller Services,

    2. Synthetic personal data can be generated from the Anchored Private Notice record and linked eConsent receipts with the use of verified micro-credentialing

    3. These records and receipts can be used to provide safe environments to model future personal data, anonymize PII Principles own data before use, provide statistical data to services and trusts, safeguard Altruistic Consent (see concentric data types) can be employed to open certain data types for a specific purpose to help people and society.

    4. Differential privacy can be used to evaluate structural deficiencies in existing data models (online profiles), and invalidate data sets through access rights which are near universal.

    5. Differential privacy tools can generate synthetic personal data to increase the size of a personal data set, to employ machine learning systems on behalf of the PII Principal to diffuse data in order to address privacy harms which exists with use of big data, with out transparency or consent. Like any other tool it can be used in good and bad ways.

Anchor
_Toc114497467
_Toc114497467
Security Code of Conduct

Non-national standards are used in this specification to mediate transborder data controls and policies and provide extra-territorial governance. National standards are limited in terms of governance policy.

...

A code of conduct in this specification refers to regulation and/or Regulator approved set of rules, which are enforceable. As oppose to a transparency code of practice, which refers to a certifiable best practice used to implement a code of conduct, for example, requiring the use of two factor notice.

ISO/IEC Security and Privacy Techniques Framework

  • ISO/IEC 29100 - Security and Privacy schema, information structure

    • Mature, mutually exclusive, and collectively exhaustive framework used to identify security and privacy stakeholder roles in data governance

    • The ANCR record is specified to propose a standard method, to secure records that can be self-asserted by people to control, use, and trust online.

    • It is envisioned that the only data ever seen by the PII Principal and accessible only via verification are those specifically delegated as such by the PII Principal.

  • PII Controller uses privacy stakeholders as a mutually inclusive and collectively exhaustive technology governance framework for cross-border identifier exchanges

  • All data processing is required to be transparent by default and provide notice, notifications, and disclosures, all of which can be automated with this specification.

    • Transparency defaults are provided in relation to adequacy with international best practice in order to be interoperable with EU-GDPR and Convention 108 to operationalize transparency with enforcement.

  • Every non-person entity, or delegate, processing personal data is a PII Controller. An unidentified PII Controller, is a 3rd Party, and requires PII Controller Category with a scope of authority for the context of processing personal data.

    • The PII Controller can have many roles, according to context of processing (e.g., Joint Controller, PII Processor, and PII-Sub-processor. 3rd Party

  • 3rd Party Recipients,

    • All 3rd parties MUST be identified as a PII Controller

    • A stakeholder without a Controller ID, or role in direct purpose of processing is required to provide the legitimate legal justification and specified purpose.

    • Monitoring of non-identified controllers should include using a different legal justification, without authority could further be analyzed for mis-information and fraud detection.

    • Assurances that 3rd parties, can also be identified as a PII Controller.

    • Assurances that all PII Joint Controllers, Processors or Sub-Processors, are accountable and identifiable as a PII Controller.

    • PII Controller Identity credential (is required to produce a consent notice receipt for verification, validation and authorisation by the PII Principle.

    • There are interoperable with IAM system roles 0 Holder, Verifier, and Issuer in Self Sovereign Identifiers (SSIs) and Distributed Identifiers (DIDs) can be directly mapped to PII Controller roles.

  • ANCR notice records can be generated by the PII Principal and notarized by a 3rd Party authority, on behalf of the PII Principal, for use independently of a PII Controller.

  • Differential Privacy

    • An editorial use case – in which the questions is asked? who controls the choice to use differential privacy? Is it the PII Principal or the PII Controller, or both? Presented in the context that the PII Principal is in control of record and the choice to use the method. As opposed to the PII Controller being in control and deciding when to use this without proof in the form of electronic notice and consent.

    • To address a security gap – dis-empowering 3rd Party data processing without consent, the creation of an identifier for system access and management, any type of tracking, is referred to as profiling, which constitutes a high-risk privacy activity.

    • To mitigate the substantial risks of digital identifier management technologies, any secondary use of the data – including ‘Differential Privacy’ must a) be transparent (specified with the consent information structure) and b) consented with a proof of notice receipt for evidence of consent,

    • This means processing is specific to purpose of the consent (Note: unless derogated in law which is also provided in notice and a represented in a code of practice, for the service.

    • Best Practice - Consent for the service to re-use a PII Principal profile for a secondary purpose, is a specific explicit consent, not an opt-in, or out governance control.

Trustworthy ID

  • Trustworthy identity requires notice and transparency defaults, or else it is very difficult for people trust the use of digital identity technology. As oppose to every jurisdiction and organisation deciding what is transparent, with T&C’s services just change without notice.

    • The defaults for operational transparency are presented in this industry publication “Adequacy of Identity Governance Transparency” with 23 default transparency for notice, notification and disclosures, which are required for a ZPN code of conduct.4

  • eConsent is a critical and missing component in the generation of identifiers the use of PII for big-data, machine learning, including differential privacy is arguably a breach of PII and clearly un-ethical as it violates the privacy expectations of the Individual, creating records people don’t control, and can’t see when they are used.

  • In this regard, ethical use of differential privacy would require a record of consent to identify and profile and personal identity, then, an explicit consent for the purpose of use.

    • In this way PII Principals can be secure, safeguarded, and empower their choices through the control of who benefits from their personal and why.

  • For an anchored notice record, it is recommended that PII Principal identifying information never be included in a record without being secured at the attribute level in the record. When a eConsent receipt is provided, all PII Principal identifiers MUST be blinded except for the legitimate required stakeholders.

  • Any PII Controller consent record that combine raw personal identifiers, is not secure enough to be a consent record, which in this specification is self-sovereign anchor record. Trust is understood to be relative to each stakeholder but represented in this specification with a PII Controller consent.

Anchor
_Toc114497468
_Toc114497468
Notice Record Extensions (for a Consent Record information structure)

The Anchored Notice record can be extended with the standardized consent record information structure by using three (3) extensions.

Anchor
_Toc114497469
_Toc114497469
Extension 1: Purpose Specification

The concentric notice label is used to identify the default legal justification for processing which is used for the default data processing practices.

...

The extension is written for the PII Controller, to enable the anchored record to be used as a verifiable data source for operationalizing a channel (exchange) where PII Principals can advertise a consent grant to the controller. (see Appendix 1 )

Anchor
_Toc114497470
_Toc114497470
Extension 2: Data treatment & RIghts based controls

Extension 2 is focused on data treatment and rights of the purpose specified in Extension1. This extension uses some of the ISO/IEC 27560 schema, as well as the W3C Data Privacy Vocabulary, and some additional elements regarding delegation, cross-border adequacy, definition of data privacy rights data controls.

Anchor
_Toc114497471
_Toc114497471
Extension 3:bundled cod of transparency practices

Extending the security code of conduct, purpose specification (Extension 1) and data treatment sections (Extension2) with a transparency code of practice.

...

This can be further extended (Internationally) where the filed data, categories, vocabulary, ontology and record formats are specified (to be hosted by a non-national regulatory body) to enable decentralized data exchange governance at a global scale.
[Note: The appendices introduce the new elements found in this specification, as well as a schema map for interoperability with ISO/IEC 27560 for contribution.]

Anchor
_Toc114497472
_Toc114497472
Acknowledgements

  • Kantara Community, DIACC, ToiP, W3C DPV and Consent

  • The ISO/IEC 27560 committee

  • Standards Council of Canada

  • PasE; Consent Gateway Team and the NGI – Next Generation Internet Grant contribution

Anchor
_1v1yuxt
_1v1yuxt
Anchor
_Toc498675772
_Toc498675772
Anchor
_Toc108928905
_Toc108928905
Anchor
_Toc114497473
_Toc114497473
References

[Conv 108+] Council of Europe, Convention 108 +

...

Click through to no cost license standards.iso.org/ittf/PubliclyAvailableStandards/c045123_ ISO_IEC_29100_2011.zip

Annex (WiP to v8.9.9)

Anchor
_Toc114497474
_Toc114497474
ANNEX A : ANCR OPERATIONAL SCHEMA

Anchor
_Toc114497475
_Toc114497475
ANCR Record Schema

This ANCR Record uses a record data type for MySQL as the example data type for records, unlike consent notice receipt tokens, which use jason-ld web-token data types. (PII ConISO/IEC 28184 Annex B: Consent [Notice] Receipt)

The Notice Record uses data types for a record in a database, this maps to MySQL, unlike the consent receipt which uses JSON token data types.

Anchor
_Toc114497476
_Toc114497476
Terms and Definitions

Attribute Name

data types, for attribute … machine readable element

  • Array [attribute type]: a data type that defines a structure that holds several data items or elements of the same data type. When you want to store many pieces of data that are related and have the same data type, it is often better to use an array instead of many separate variables (e.g. array[text], array[numeric], etc.).

  • Binary:a data type that defines a binary code signal, a series of electrical pulses representing numbers, characters, and performed operations. Based on a binary number system, each digit position represents a power of two (e.g., 4, 8, 16, etc.). In binary code, a set of four binary digits or bits represents each decimal number (0 to 9). Each digit only has two possible states: off and on (usually symbolised by 0 and 1). Combining basic Boolean algebraic operations on binary numbers makes it possible to represent each of the four fundamental arithmetic operations of addition, subtraction, multiplication, and division.

  • Boolean:a data type where the data only has two possible variables: true or false. In computer science, Boolean is an identification classifier for working out logical truth values and algebraic variables.

  • DateTime: a data type that defines the number of seconds or clock ticks that have elapsed since the defined epoch for that computer or platform. Common formats (see 'Format Overlay') include dates (e.g., YYYY-MM-DD), times (e.g., hh:mm:ss), dates and times concatenated (e.g., YYYY-MM-DDThh:mm:ss.sss+zz:zz), and durations (e.g., PnYnMnD).

  • Document Reference

  • Element Reference

  • Field Category

  • Field Description

  • Field Label

  • Numeric: a data type that defines anything of, relating to, or containing numbers. The numbering system consists of ten different digits: 0, 1, 2, 3, 4, 5, 6, 7, 8,and 9.

  • Reference: a data type that defines a self-addressing identifier (SAID) that references a set of attributes through its associated parent. SAID is an identifier that is deterministically generated from and embedded in the content it identifies, making it and its data mutually tamper-evident.

  • Text: a data type that defines a human-readable sequence of characters and the words they form, subsequently encoded into computer-readable formats such as ASCII.

Anchor
_Toc114497477
_Toc114497477
ANCR Specification Schema Table

Notice Record Example Field Category

Label

Data Type

Attribute name

Field Description

Presence Requirement

TPI 1 Cntrl Id Present

TPI 2 Accessibility Example

Security TPI 3: Digital Context Integrity

ISO/IEC 29100-Ref

ISO/IEC 29184-Ref

GDPR Ref

Conv 108 Ref

PII Controller Identity

Controller ID Object

String

controller_id_object

_

Required

Security key or Cert

4.2.2

5.3.4

Presented Name of Service Provider

String

presented_name_of_service_provider

name of service, e.g. Microsoft

May

PII Controller Name

String

piiController_name

Company/organization name

MUST

PII Controller address

String

piiController_address

_

MUST

PII Controller contact email

Varchar(n)

piiController_contact_email

correspondence email

MUST

PII Controller legal location

String

piiController_legal_loc

PII Controller Operating Privacy Law

MUST

PII Controller Phone

Char

piiController_phone

The general correspondence phone number

SHOULD

Issuer Statement

PII Controller Website

Varchar

piiController_www

URL of website (or link to controller application)

MUST

PII Controller Certificate

BLOB

piiController_certificate

A capture Website SSL

OPTIONAL

Privacy Contact Point Location

VarChar(max)

pcpL

MUST

Public Key base64 (human readable - kind of...)

Privacy Contact Point Types (pcpT)

Object

pcpType

Must have at least one field for the PCP object

MUST

PCP-Profile

String

pcpProfile

Privacy Access Point Profile

**

PCP-InPerson

String

pcpInperson

In-person access to privacy contact

**

CRL and OSCP endpoints

PCP-Email

Varchar

pcpEmail

PAP email

**

PCP-Phone

char

pcpPhone

Privacy access phone

**

PCP -PIP- URI

Varchar

pcpPip_uri

privacy info access point, URI

**

PCP-Form

Varchar

pcpForm

Privacy access form URI

**

PCP-Bot

String

pcpBot

privacy bot, URI

**

PCP-CoP

String

pcpCop-loc

code of practice certificate, URI of public directory with pub-key

**

PCP-Other

string

pcp_other

Other

**

PCP Policy

pcpp

string

pcpp

privacy policy, URI with standard consent label clauses

MUST

Anchored Notice Record Field Categories

Name

Type

Attribute Name

Description

Presence

ANCR Record ID

string

ancr_id

Blinded identifier secret to the PII Principal

Required

Schema version

string

V x.xx.x schema_version

Timestamp

DATETIME

time_stamp

_the time and date when the ANCR record was created

Required

Legal Justification

string

legal_justiication

One of six legal justifications used for processing personal data

Notice Record

Object labels

VarChar(max)

notice_record

Notice Type

string

notice_type

Notice, notification, disclosure

Required

Notice method

string

notice_method

Link/URL to the UI that was used to present the notice e.g. website home page

MUST

-digital-Notice-location

string

digital_notice_location

Notice location e.g. IP address

MUST

location Certificate

BLOB

location_certificate

MAY

Notice Language

string

notice_language

The language notice provided in

MUST

Notice Text File

string

notice_text_file

URL and/or Hashlink for the notice text

MUST

Notice text

string

notice_text

The capture of a copy of the notification text

MUST

Notified legal Justification

string

notice_legal_justification

Implied or explicit notified legal justification based on the text of a notice and its context

MUST

Concentric Notice Label Type

string

cnl

a label that is mapped to legal justifications, rights and controls that can be provided by default, for a specified purpose

SHALL

5.3.12

Not-Consent

Refers to laws and democratic consensus (legitimate Interest, Legal Obligation, Public Interest & Vital Interest)

Private Anchored Notice Record Field Category

Label

Type

Attribute name

Field Name

Required/Optional

Private Record

schema version #

V

Optional (unless shared or used further)

Anchor Notice Record id #

Int

Ancr_id

MUST

Date/Time

DEATETIME

Required

Notice Collection method

optional

Notice Collection Location

VarChar(max)

required

Notice Legal Justification

VarChar(max)

PII Principal Legal Location

VarChar(max)

ploc

Device ID

NVarChar (max)

PII Principal Private- Key

VarChar(max)

Anchor
_Toc114497478
_Toc114497478
ANNEX B: Concentric Notice Label Types

The object of the ANCR record is to enable operational transparency. A concentric notice type is used to provide a human centric label to a record or a receipt.

...

Referencing the corresponding ISO/IEC 29184 control to enhance interoperability of operational transparency. Interoperability that is realized through the extension of transparency with records of processing to establish and maintain a shared understanding of security and privacy risks. Affording people choice which mitigate risks and transfer liability.

Anchor
_Toc114497479
_Toc114497479
Mapping Legal Justifications to Concentric Notice Types

These are mapped here to provide a set of operational transparency defaults to set and support privacy as expected by the PII Principal. Expectations that provide a privacy notice starting point, where PII Principal and PII Controller can gain a shared understanding, or where a PII Principal can assert a legal justification for processing to access privacy rights.

...

Concentric digital transparency is a design principle of electronic Notice and evidence of consent. The outcomes are for a shared/concentric understanding of a relationship and the purpose of digital interaction, the data control impact, and associated risks centric to the PII Principal.

Anchor
_Toc114497480
_Toc114497480
Concentric Notice Labels to Privacy Rights

Concentric Notice Types are you to create a digital notice label to enable that can be applied to digital processing context which are understood from a human centric perspective.

...

Concentric Notice Type

Description

Legal Justification

Privacy Rights
(GDPR)

Legal Ref

Non-Operational Notice

N/O

Insufficient notice/security information for digital privacy

Not compliant with any if unable to determine or confirm Controller, or contact

Withdraw, Object, Restrict,
Access/Edit, Forget,

Con.108+ 79.1(a) GDPR Art 13/14 1a,b,

Consensus Notice

Notice of Legitimate Processing. Surveillance Notification

Legitimate interest

Implied Consent Notice

Implied through PII Principals participation in a specific context.
Or through a notice from PII Controller for a specific purpose context. Can also refer to an existing state of privacy and its established status. aka ‘applied consent’ to data processing.

Consent

ISO/IEC

GDPR Art 50 1 c

Con 108+

-Supplement- IPC, Canada3

Implicit consent notice

Refers to governance that is implicit to the action of the PII Principal.

Legitimate interest, Contract,

Legal obligation

Object , Restrict

Expressed Consent notice

Expressed through the implicit action of a Notified individual.

Informed Consent

Withdraw

Explicit Consent Notice

Provided in such a way that the is Informed, freely given, knowledgeable consent,.

Consent witch is knowledgeable of risk

Withdraw

Con 108+.1(4)1b

GDPR Art 7.1

Directed Consent

A consent directive is consent explicitly defined by the PII Principal for specific purposes, according to disclosures of risks that are notified.

meaningful consent, in which the individual has specified the consented purpose

GDPR 9.1(h)

Altruistic Consent

Not knowing who the Controller of PII will be. Consent to a purpose and public benefit governance framework, without knowing who is the beneficiary

Consent

DGA, Recital 1,2,4,36,39

Anchor
_Toc114497481
_Toc114497481
Appendix — EXTENSIONS

Anchor
_Toc114497482
_Toc114497482
Extension 1: 27560 for Purpose Specification

(For the latest draft of this Extension, or to get involved in working on it, visit ANCR WG‑Kantara Wiki ANCR - Extension 1 – ISO/IEC 27560 - Consent record information structure)

SUMMARY

An Anchored Notice Record is specified to capture the data control relationship between the PII Principal and the PII Controller, using the international ISO/IEC 29100 standard.

...

  • This purpose schema is specified for the PII Controller, and can also be used by a Privacy Stakeholder as a record to assess a purpose

  • The ANCR protocol is for generating a Record of Notice containing Controller ID and contact. This is always the event, and in this regard, the ancr_id maps to event id. To this extend event schema section is not required.

  • The ANCR record is specified to ISO/IEC 29100, in which the ‘privacy and security stakeholders’ are defined. In the context of the ANCR record, this means that any role (other than PII Principal) has a Controller ID, relative to the PII Principal, in addition to the role for the specific context of processing (e.g., processor, recipient, third party, which represent the processing role and activity relative to the ANCR record). This enables liability and risks to be delegated and transferred amongst the stakeholders specified to a per‑process instance. As a result, the party_ID schema is incorporated in the ANCR Record ID, which is specific to a PII Controller, not a service or purpose.

Introduction

Consent receipt, and the associated record information structure, were conceived as a record that captures the notice of a PII Controller, or the notice context of the PII Principal.

...

In this regard, ISO/IEC27560 is specified with the utility of the consent receipt in mind, which is to specify the purpose of personal data use and risks so that people can make informed choices and control personal data.

Schema Interoperability

The ANCR protocol is for generating a Record of Notice containing Controller ID and contact. This is always the schema ‘event’ indicator, in this regard the ancr_id field maps to and replaces the event id field in ISO/IEC 27560 WD 5 consent record information structure.

...

The ANCR record can itself be extended in to a Controller Credential When the ANCR record is used in a consent receipt flow it can also be used to. ToiP-Controller Credentialwiki.trustoverip.org/pages/viewpage.action?pageId=27722576

Schema Mapping

The following mapping of the ANCR record schema conforms to instructions provided in ISO/IEC 27560. To this extent, and in accordance with ISO/IEC 27560 Art 6.2.3, this annex publishes the ANCR Record Schema’s at Kantara and hosted at the Human Colossus Foundation, for the Global Privacy Rights, public benefit Initiative.

...

Codes of practice can be approved and monitored, and can combine multiple purposes together for an expected code of practice. A “Purpose Bundles” operated with a code practice can be approved and to operationalize privacy.

Anchored Record Schema ‘Structure’ Sections

In addition to the consent receipt schema, the ANCR record schema provides a protocol for its operation.

...

The Anchored Record Schema ‘Structure’ Sections refer to ISO/IEC 27560 line – 362 WD4, where it calls out the need to reference the schema(s) information structure used, in addition to demonstrating the capacity to maintain documentation for its correct technical implementation. - and conformance to the requirements specified in the ISO/IEC 27560 documents.

Anchor
_Toc114497483
_Toc114497483
Extension 2: Data Treatment

In summary, elements from ISO/IEC 27560 frame the data treatment elements are found in Extension 3 in addition to [ ]

Anchor
_Toc114497484
_Toc114497484
Extension 3: Code of Practice

The ANCR record is specified in this information structure according to legally defined code of conduct, each element that is required is referenced to standards and legislation which constitute the code of conduct for operational transparency trustworthy id protocol.

The legal code of conduct is extended by codes of practice which are often recognized as certifications and represented by certificates and certifications.

Anchor
_Toc114497485
_Toc114497485
Extension Library

Terms, definitions, filed data, record examples, machine readable privacy vocabulary, used to generate notice, notifications, and disclosures are provided here.

Anchor
_4f1mdlm
_4f1mdlm
Anchor
_Toc498675774
_Toc498675774
Anchor
_Toc108928906
_Toc108928906
Anchor
_Toc114497486
_Toc114497486
Revision history

Version

Date

Summary of Substantive Changes

0.1 DRAFT

2021-02-28

Initial v1.1 draft

0.5

2022-02-02

Draft – updating scope to Notice and eConsent

0.8

2022-07-04

Full outline/70% drafted

0.8.5

2022-08-04

Outline 100% Draft - Posted to Kantara Wiki

8.8.2

Annex Updates

8.8.3

Restructured Sections and schema, cleaned schema up a little – practice what preaching by making spec structural human centric

8.8.4.0.1

2022-09-18

Content edited for grammar, consistency, clarity

...