ANCR Notice Records & Consent Receipt

Version: 0.8.8.5

Document Date: Sept 07, 2022

Editor(s): Mark Lizar

Contributors: Sal D’Agostino, Sharon Polsky, Paul Knowles

Contributing Orgs: Zero Public Network (0PN), Human Colossus Foundation

Produced by: ANCR-WG

Status: WG Draft v0.8.7 – 8.9 (completing and polishing)

Editor Notes

This specification is for the PII Principal to create a record of notice. Specified first, to create a single use notice record, before enhancing this record with a digital identifier for repeated use as a proof of notice, for consented data exchanges.

A receipt and record of processing provides transparency over who is accountable and is a pre-condition for processing PII with scalable governance and security. This creates a record of operational transparency that scales providing a human context and understanding to systems. Transparency over data control is used here to regulate online surveillance much like transaction receipts, bank accounts and currency is regulated and tracked today.

Finally, the Anchored Notice Record is a private information record specified here as a separate record. This takes in account security requirements not as considerations, but again as a pre-condition for generating consent records in identity management systems.

In this specification the PII Principal manages consent and identity systems manage a permission grant defined by the notified purpose and in accordance with what the PII Principal expects in context. To this point, this specification focuses on transparency of control, with extensions for extending the transparency of a controller with purpose specification as outlined in Annex.

Abstract:

Currently, when online services are involved, the PII Principal (referred to as the Data Subject or Individual in this proposed standard) is unable to see who is in control of processing their personal data before it is processed, shared or disclosed. There is no way to assert authority upfront, to determine, imply or negotiate the conditions of data processing, identifier generation, its use, and management.

Functionally, people are not able to see (therefore trust and control) the creation use and disclosure of digital identifiers and related meta data, and how it’s (re)purposed. To see this require standardized transparency as a way to provide data governance that scales when decentralized in a meaningful way to people online. Not knowing if PII is kept private to the PII Principal, only exposed locally like physical privacy, or disclosed beyond the region, trans-nationally, or internationally, is essential to trusting the management of surveillance and personal identity technologies.

This Kantara Initiative work effort began when Liberty Alliance became the Kantara Initiative, the Consent and Information Sharing WG formally began in 2015, and its work is carried on in the ANCR WG. This Record specification proposes to standardize digital transparency as an alternative to the one size fits all contracts called ‘terms and conditions’, ‘user licenses’, or sharing agreements, which do not facilitate human centric dynamic data exchanges. This specification provides a methodology to leverage legal and technical standards for transparency to supersede or at least be comparable to the standing of terms and conditions,

The specification introduction begins with (3) transparency performance indicators (TPIs) that an individual can use to assess the transparency before sharing, disclosing or leaking personally identifiable information.

TPI 1 – Notice of Identity of Controller

TPI 2 – Accessibility of Notice

TPI 3 – Security Certificate of Notified Controller

IPR Option:

This specification is open for use for public benefit licensing @ Global Privacy Rights, and @Human Colossus, and is specified under a RAND agreement at the Kantara Initiative for submission to ISO/IEC SC 27 WG 5

Published for use as public infrastructure and/or

Patent & Copyright: Reciprocal Royalty Free with Opt-out to Reasonable and Nondiscriminatory (RAND)

Suggested Citation:

ANCR Specification v0.8.8.5

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 portions of this document for other uses must contact 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 of 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, and 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.

-

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

Contents

Preface

Public international laws and standards now provide an opportunity for digital records and receipts to dramatically improve (at a much lower cost) the security of personal data control to then increase the effectiveness of digital privacy. Here, e.g., the ISO/IEC 29100 Security and privacy framework is the international framework for creating records for trustworthy ‘consented data access’, for Adequate data transfers internationally.

This specification is a contribution to ongoing work at ISO/IEC SC27 WG5, utilizing ISO/IEC 29100 to create a standardized record of processing format for notice records and consent receipts, through engaging with notice.

The record is specified for generating operational transparency with the use of the controls in ISO/IEC 29184 Online privacy notices and consent

Why was this specification was written?

An Internationally standardized notice record information structure provides the standard for a PII Principal to generate records independently of the PII Controller. The PII Principal can trust their own records, and use this record to be included, to set privacy defaults. In turn the PII Controller transfers liability, mitigates risks of data processing by being able to trust the PII Principal. Increasing the effectiveness of data controls for all stakeholders.

Why Operational Transparency?

Standardized digital notice is a steppingstone to digital privacy and is required to scales human to system (electronic) consent online. Here electronic eConsent, is differentiated as it requires a proof of notice record, which the individual must hold, control and manage, separately from the PII Controller. A record that is provided by default using standard digital identifier governance defaults, designed for self-sovereign / human centric transparency and interoperability, between people and systems.

The notice record information structure is specified in this document with ISO/IEC 29100 Security and privacy techniques framework, it is a free and public standard. It is used in this specification to measure the performance of transparency utlizing the controls, and consent notice receipt, specified in ISO/IEC 29184.

What should you expect to find in this document?

In the ‘introduction’ of this specification, an example notice record along with 3 transparency performance indicators (TPI’s) are used to demonstrate how a minimum notice record Information structure can be used to create a record the PII Principal controls and can trust to use, to control personal data with privacy rights.

These TPI’s are;

1. The PII Controller identity and privacy contact point

2. The Accessibility of PII Controller Identity and Contact information,

3. The security and integrity of the controller’s transparency

To operationalize the TPI’s, this specification introduces a concentric notice label field, which is provided by context. It simplifies the understanding and use of rights for people in context of data processing, To present legal justification for processing and rights in order to present a consistent set of notice based controls, fprivacy right defaults and expectations.

Introduction

This specification is proposed to capture, measure and standardize transparency over the security and privacy practices of the PII Controller. Starting with the identity and Controller contact information for operational use by the PII Principal.

This ANCR WG specification introduces a method to capture a Notice and verify its credential. It specifies with what, and how a PII Principal can capture a record of notice with and assess digital transparency and the state of security.

The ANCR Notice Record is specified for PII Principals, using terms, semantics and laws that champion the legal utility of data control and its management. As such, representing a shift in the architecture of digital identity semantics to legal semantics specific to human centric transparency, usability, and control.

For this purpose, the ANCR record is first specified as a single use record, that the Individual controls with 3 transparency performance indicators. First defined as a single use record to generate a record the Individual can own, control and trust. The KPI’s provided here are specified to provide transparency over data control and it’s governance. (Operational Transparency),

A trust protocol of transparency before surveillance. In which a notice or notification is presented to the PII principal that generates a. receipt from an ANCR record. presenting significant security and privacy benefits that assist in distributing and decentralizing stronger security decisions.

Notice Record

The notice record is first specified as a static, one-time use notice record that is created by the PII Principal and used to initiate a state of operational transparency in context measured by access to, and performance of rights.

Diagram 1 Notice Record

Table1: Single Use Notice Record: PII Controller Identity & Contact Transparency Report

Anchoring the Notice Record for Trust

Without a record identifier, added to each record, this initial record is an unanchored notice record. This record can be extended for use as a Trust Anchor for the PII Principal by adding an ANCR Record ID used to track the PII Controller and the data processing relationship over time.

As a trust anchor, it becomes a record the individual can use to verify the digital identity relationship and validated by the person for a digital privacy context in a system that can be expected. In this way an anchored notice record is a gateway to scale consent online and internationally.¹⁰⁵⁷⁴

Notice Record Transparency Performance Indicator's (TPI’s)

Diagram 2: Transparency Performance Indicator’s (TPI’s)

The first 2 performance indicators measure the transparency of the PII Controller identity information that is required to be ‘provided’, as provision of this information on, or before data processing is a condition of Adequacy and compliance for all digital identifier-based processing activities. An ANCR Record is a record if processing activity that demonstrates this compliance,

Referenced to the standards and regulation evolved from Fair Information Privacy Principles to be enforceable in multinational regulation, the GDPR (General Data Protection Regulation and international regulation, Council of Europe, Convention 108+.

Once the capacity for digital privacy is measured to be operational the 3^rd performance indicator can then be used to measure the security certificate or key for its contextual integrity for the specific session or context.

TPI 1: PII Controller Identity & Contact Transparency

Assess if the required information for transparency over who is in control of notice is ‘provided’

The MUST fields identify elements that are required in legislation that MUST be present.

Is there a

TPI 2: Transparency Accessibility

How Accessible is the PII Controller and Privacy Contact information?

For example, in the context of a website, or a mobile device, how difficult was it to access the ‘provided’ information. How many clicks, or screens away is the required information?

TPI 2–Example Accessibility Measurement Rating

This transparency accessibility rating is provided in the context of a browser / mobile device with a mobile application or webpage providing the client user interface.

This rating, a score of; [1,0, -1 or –3] is used to determine the number of steps, screens, or clicks required to find the ‘provided’ information.

Transparency Accessibility Rating description table 2

TPI 3: Certificate & Key Security Transparency

This security performance indicator requires that the notice record session certificate is collected and used to check if the PII Controller identity information is the same or linked to the controlling entity in the associated security certificate. For example, does the SSL (secure software layer) certificate identify the controller and is it secured for the jurisdictional domain and DNS information. (as a required digital privacy measure of Adequacy)

Certificate status and transparency are used to establish session security prior to the collection, use and processing of PII. The security TPI is used to measure the certificate and or cryptographic keys for a specified organizational unit to corroborate and validate the PII Controller’s digital integrity.

Table 2 : Notice Record TPI Report

Notice Record References

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:

— ISO Online browsing platform: available at https://www.iso.org/obp

— IEC Electropedia: available at http://www.electropedia.org/

Normative References

For the international and cross-domain use of the records and receipts here, 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.1¹⁶⁴⁵⁵

• Kantara Initiative: Blinding Identity Taxonomy (Bit)⁶⁵⁷⁴

• 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

Notations and Abbreviations

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “NOT RECOMMENDED”, "MAY", and "OPTIONAL" in this document 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 perosnal information, and who is accountable for enforcement,

ANCR WG; Advanced Notice and Consent Receipt Work Group

ANCR Record: Anchored Notice Record and Consent Receipt Record

Conv. 108+: Council of Europe Convention 108 +

IRM: Identifier Relationship Management

ISO/IEC International Organization for Standardization / International Electrotechnical Commission

FIPP Fair Information Practice Principles

PII Personally Identifiable Information

POMME Privacy operationalization model and method for engineering

Object – a field object

Array – an array of field objects

Terms and definitions

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

If a jurisdiction’s privacy terms are not compatible with this specification, these internationally defined terms can be mapped to jurisdiction 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 Canadian PIPEDA.

Code of Conduct

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 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]

Concentric Notice Label

This field is a new field – normative in this specification.

Used to provide a label that indicates what privacy people can expect by default, determined by legal justification per context for consistent transparency people can trust. This requirement is referenced as:

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

Consent Notice Label Types

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

2. Implied Consent, PII Controller defines the purpose

3. Expressed Consent

4. Explicit Consent

5. ‘Directed Consent’, where in a PII Principle specifies in part, or in whole a purpose. Ensuring a higher quality of understanding.

6. ‘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 prior to 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 processing.

[Source Conv 108+ Rec.20]

Notice

2. Adhering to the openness, transparency and notice principles means:

2. 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;

3. - 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;

4. - 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

   1. - giving notice to the PII principals when major changes in the PII handling procedures occur.

   2. [ISO/IWC 29100]

1. 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, and with references that pro

2. [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 new purposes.

1. [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, visualization 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

(a) 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]

Notice Modalities

The organization may implement the control using different techniques: layered notices, dashboards, just-in-time notices and 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 give in 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]

Notice Record

When organizations should seek consent for changes such as those outlined here, they 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 original consent has been withdrawn.

[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:

(a) 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 of ISO/IEC 29100 originating from the 1973 and have matured into 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]

Proof of Notice

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

1. [Source ISO/IEC 29184 Appendix B]

3. 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.

4. [Source: ANCR Notice Record v1 – Specification]

Personally Identifiable Information (PII)

Any information that (a) can be used to identify the PII Principal to whom such 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’); 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 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]

PII that is in a Sensitive (or Special) Category

what constitutes sensitive PII is also defined explicitly in legislation. Examples 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 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]

Such personal data 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]

PII Principal, Data Subject or Individual

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 exis- tence, 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]

PII Controller

A privacy stakeholder (or privacy stakeholders) that determines the purposes and means for processing personally identifiable information (PII) other than natural persons who use data for personal purposes.

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

SOURCE: ISO 29100]

‘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: it may also be called 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)]

PII Joint Controller

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]

PII Processor

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)]

PII Sub-Processor

Refers to the PII Controller type in the ANCR record specificationl

[ANCR Notice Record Specification v0.9]

An additional field to indicate a delegated PII Processor (rather than 3^rd Party). Used to distinguish between, a legally authorized 3^rd 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 https://w3c.github.io/dpv/dpv/ ]

Processing of PII

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+]

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)]

ISO/IEC 29100 to 27000: Security Framework Mapping

Table Security & Privacy Terminology Mapping

[Source: ISO/IEC 29100: Annex A]

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]

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 and 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.

The notice record is an electronic notice document and is used to initiate electronic consent dialogue using a common, default engagement point that the PII Principal can expect, and trust, per data processing session.

Trust is predicated on operational transparency and security assurances that are inherent to creation and use of records and receipts.

This schema is cumulative, where each layer can be added

1. Layer 1 - Notice Record Schema.

   1. 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.

2. 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

3. 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 linked notice, notification and dislosure records pertinent to the context of notice.

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

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

This is the schema elements that are used to generate a un-anchored notice record and do not contain any PII, or digital identifiers.

Private Notice Record Profile

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

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.

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.

*** PII Controller Consent record must have consent first before making . E.g. Authority to use this for security, -- (non-compliant). ***

Proof of Notice Record

For consented digital identity management, a proof of notice record is used as an alternative to terms and conditions, which refer to the contract-based policy for the governance of identifiers and credentials.

Much like a two-factor authentication (2FA) used for digital identity security, a two factor notice (2fN), presented in here, implements ISO/IEC 27560 the consent record information structure, as summarized in Appendix: ANCR Record Extension 1.

Each 2fN, implements a standardized consent notice dialogue for the use of digital identity management technology, which is the technology used to profile and then automate personal data processing in systems.

Each 2fN requires the presentation of information about data processing using the same content controls, format, ontology, vocabulary, and order of presentation.

1. legal justification,

2. purpose of profiling

3. Localization / Scope of disclosures & 3^rd Parties

4. Privacy/Security Risks

The 2fN, can provides standardized options to engage with the notice, notification, or disclosure, Typically implemented with a software interface in which at a minimum, these 3 options are used by default. (And easily extended with a code of practice)¹⁸⁶¹⁷

1. by default, the notice can be ignored.

2. PII Principal provides an informed consent

3. A privacy rights and controls options is presented

Option C, depending on the age, and accessibility context can be further simplified to the right to be heard and make a complaint, in specific context of processing personal data notified.

[Editors Note; Option C refers to GDPR and Convention 108+ legal instruments which do not require a digital identifier, a user account or any other personally identifying information to access.]

An ANCR Notice Record and a Consent Receipt, referred to as a mirrored record of processing, is generated when the PII Principal engages with the dialogues and completes a notification sequence by selecting one of these options. And, by default, when a notice, or notification is ignored. When an ‘I consent’ option is selected an evidence of consent record and receipt is generated, for eConsent.

Note: ANCR Notice record ID is utilized to create and link new receipts ensuring the providence of the PII Principals control of the ANCR record

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 .

The 2fN produces a network event, presenting information that is needed to produce an evidential record, which a PII Principal can then use independently, as a credential, to aggregate operational transparency information, access privacy state and rights information or to implement personal data controls. (required for more advanced grants to permission record based systems for collection, capture, and access to private data profiles)

• 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 an receipt upon engaging with a standardized notice with access to admin privacy rights from the notice, prior to processing with consent.

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

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

Notice Record Security Architecture

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 consenr

• Rules used to secure, protect and safeguard personal data; .

  • The only identifier is the identifier the PII Principal (optionally provided) to extend the functionality of the anchored record for receipts.

  • Only the PII Principal owns, controls, and delegates technical access to this identifier.

  • Whenever it is exchanged, it must use the blinding identifier taxonomy, cryptographically hashed with PII Principal public key.

  • As a result. Only attributes from the corresponding records can be used with a verified credential.

  • The record MUST not be generated or managed by any other stakeholder or delegate, apart from the PII Principal in order to be a trustworthy id.

3 layers of the notice record Schema is presented in this specification, each layer building on the first.

The first layer, presented in the introduction, is presented as a single use notice record, which is used to assess transparency, accountability and digital security in context.

The second layer scale the use of this record to track and verify PII Controllers additional notice record elements are required. The subsequent schema fields are added for specific purpose of use, specified through induvial action and through the control of personal data.

The 3^rd addition to the record schema is a separate record, used to enable trust, transparency through personal data control.

the PII Principal keeps a personal and private record of the identity relationship metadata.

Security practice: requirements for the privately anchored record

Personal data kept by individual

The ANCR record identifier has specific security requirements and considerations as it can be used by the PII Principal as an Identifier for/by PII Controller’s. The ANCR Notice Record can be extended with 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 protocol requires that the ANCR Record is referenced each time a directed, or altruistic consent is generated. 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 metric: The TPIs provide transparency and security assurance to qualify the PII Controller before the controller processes personal information.

To provide security and safeguard personal data there are multiple methods available for securing the control and transparency of data processing utilizing the personal and private notice record, held by the PII Principal.

1. Blinding identifier taxonomy (BiT)

1. Psudonymous identifier

1. Verified Credential Identifier

1. Differential Transparency

1. Differential Privacy (additive as editorial)

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 authorization required to unencrypt the field for a specified purpose and data 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 principles (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 added to the notice record, it can be used to present the PII Controller identity information by the PII Controller, as a micro-credential.

   2. Conceptually, the ANCR Id works as a reverse cookie, in that it is used by the PII Principle to track the PII Controller through different service environments,

3. Verifiable Private Notice Record used in a 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 (micro-credential)

         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, https://www.w3.org/TR/vc-data-model/#what-is-a-verifiable-credential )

4. Differential Transparency – operational transparency signaling

   1. Operational transparency ‘trust’ protocol for comparing the expected privacy state (purpose and credential) each technical session to authorize an instance of processing, whereby a 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 protocol that uses record serialization in order to sequence data control points. Used to maintain a shared understanding of privacy and conversely securiyt expectations.

   3. Implemented by comparing than anchored notice record with a newly minted eConsent 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. DT 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.

[Editorial Example: Differential Privacy as Data Control Use Case

For discussion with security and privacy community. Like digital identity management, how sovereign data control can be measured is by assessing, 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. Thus indicating which stakeholder can authorise the use of the tool, and for which purpose]

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 can be generated to increase the size of a personal data set, and to employ machine learning systems on behalf of the PII Principal to address and secure the use of PII in machine learning systems to enable the individual address contextual and even adversarial scenarios

Security Code of Conduct

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

• This specification advocates for utilizing international standards for measuring adequacy, mapping the rules, vocabulary and semantics presented in this specification to the national standards and regional privacy regulation.

• eConsent is a security access control (Do Track) in this context that is required to make a record that a PII Principal signs by engaging with a Two factor Notice (2fN)

ISO/IEC Security and Privacy Techniques Framework

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

  • Mutually exclusive an collectively exhaustive framework matured over X years

    • 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 delegated as such specifically 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, 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 un-identified PII Controller, is a 3^rd 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. 3^rd Party

• 3^rd Party Recipients,

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

  • A stakeholder without a controller id, or role in direct purpose of processing. Using a different legal justification, like legal obligation. For automated discovery of security events, like mis-information and fraud detection.

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

  • 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 3^rd Party authority, on behalf of the PII Principal, for use independently of a PII Controller.

• Differential Privacy

  • An editorial use case – in which a recovered is made of who controls the choice to use differential privacy. 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 consent.

    • To address a security gap – dis-empowering 3^rd 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 Compliance

    • without explicit consent for 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.

    • To this over-arching point of providence of authority through consent.

      • The use of digital identity technology requires electronic notice and when required electronic consent,

        • In this regard, ethical use of differential privacy would require a record of consent to identify and profile and personal identity, then, sn 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.

• Bottom Line

  • PII Principal identifying information MUST never be included without being secured at the attribute level. When a consent receipt is provided, all PII Principal identifiers MUST be blinded and, in this way, pseudonymized, in a format in which identifiers can be made portable (data portability) e.g., with a verifiable credential using zero-knowledge proof.

  • Any PII Controller consent records that combine raw personal identifiers with a consent record are therefore insecure and those systems are considered to have non-operational transparency

Notice Record Extensions (for a Consent Record information structure)

The anchored notice record can be extended with the standardized consent record information structure by utilizing 3 extensions.

Extension 1

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

ISO/IEC 27560 is used to generate a standard purpose-specification to then provide a two factor notice which can either confirm or update the PII Principal expectations of privacy, according to the context and legal justification for processing. The 2fN, provides pseudonymous access to privacy rights, controls and services, without requiring the PII Principal to identify themselves.

The Transparency Performance indicator’s can then be used by the PII Principal to validate and negotiate control of personal data processing, with the PII Controller according to the purpose and context of service provisions on or before data processing occurs.

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 )

Extension 2

Extension 2 is focused on data treatment and rights of the purpose specified in Extension1. This extension utilizes 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.

Extension 3

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

specified by industry, trade associations and civil registries (referred to as code of conduct as it references the legal requirements).

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.]

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

References

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

[GDPR] General Data Protection Regulation, http://www.eugdpr.org/article-summaries.html

[ISO 639] ISO 639-1:2002, Codes for the representation of names of languages — Part 1: Alpha-2 code https://www.iso.org/standard/22109.html

[ISO 29100:2011] Information technology -- Security techniques -- Privacy framework. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45123

Click through to no cost license https://standards.iso.org/ittf/PubliclyAvailableStandards/c045123_ISO_IEC_29100_2011.zip

[RFC 2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997 http://www.rfc-editor.org/info/rfc2119

[OECD] OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data. http://www.oecd.org/sti/ieconomy/oecdguidelinesontheprotectionofprivacyandtransborderflowsofpersonaldata.htm

[Kantara Initiative] Blinding Identity Taxonomy [BiT]

[Kantara Initiative] Consent Receipt v1.1

Annex (WiP to v8.9.9)

ANNEX A : ANCR OPERATIONAL SCHEMA

ANCR Record Schema

Note: 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. (ISO/IEC 28184 Annex B: Consent [Notice] Receipt)

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

Terms and Definitions

Attribute Name

data types, for attribute … machine readable element

• 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.

• 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.

• 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.

• 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.

• 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).

• 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.).

Document Reference

Element Reference

Field Label

Field Description

Field Category

ANCR Specification Schema Table [Note : put in Landscape mode to view]

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.

Utilized to extend operational transparency to operational privacy specifying here the right of transparency to include

1. The right for a PII Principal to know what rights they have,

2. The right to be heard, children’s design code of practice

3. The right to start a complaint with a PII Controller and to escalate a complaint to the relevant privacy authority.

To facilitate operationally transparency, concentric notice labels are mapped from legal justifications in table 1, and in table 2, mapped to privacy rights as controls. Utilized in the ANCR record as a concentric notice label in order to set an expectation of privacy, which is attached to a notice record to set an expectation of privacy, and establish a set of digital transparency defaults,

Utilizing ISO/IEC 2910 with reference to GDPR and Convention 108+ to establish a transparency defaults for Adequacy based data transfers,

. 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.

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.

Note: Participatory Consensus, and Concentric data control are two outcome specific conditions that will be added to this specification to include an assessment for operational evidence of these two outcomes.

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.

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.

These are mapped to increase understand of data processing and what rights and obligations the PII Controller have per purpose.

access to privacy rights and information. meaningful through a direct mapping with specific rights, obligations and customs for interaction for data processing, which are enforceable with the references

Appendix

Extension 1: Purpose Specification

(for latest draft of this extension or to get involved in working on it visit ANCR WG-Kantara Wiki ANCR - Extension 1 – 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, utilizing the international ISO/IEC 29100 standard.

In this schema, this record is extended by a service which presents the purpose specification to the ANCR record, to generate a notice, notification or disclosure as required.

• For a person to specify and direct an electronic consent, or by a service to present a grant of consent for a specified purpose.

• As a source of authority for the PII Controller to process personal data.

• Linked, and presented / captured to record the state of security and privacy by default.

• This can then always be used to identify the Controller and link subsequent notifications. The PII Controller details. And by linking it to a notice, the record header is embedded in the notice, in a standard format.

• [Source ISO/IEC 29184 5.3.4][GDPR Art 13&14.1 (a)(b)][Convention 108+,

• This purpose spec schema is specified for the PII Controller, (data protection) but can also be used as record to assess a purpose by a Privacy Stakeholder.

• 7560 Notes

• The ANCR protocol is for generating a record of notice containing controller id and contact, this is always the event, 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 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, 3rd 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 record info structure – was conceived as a record which capture the notice of a PII Controller, or the notice context of the PII Principal.

It is apart of an effort to standardized notice to open consent in order to decentralize data governance in identity management.

In this regard, 27560 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.

1. Schema Interoperability

2. 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 (ref; 27560)

3. To this extent the 27560 ‘event schema’ section is not required.

4. The ANCR record is specified to ISO/IEC 29100 (ref;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, and stakeholder role, relative to the PII Principal,

5. As a result the party_schema is incorporated in the ANCR Record ID, which is specific to a PII Controller, not a service or purpose.

6. A 27560 consent record, which contains the PII Principal identifier in the same record, this would first need a consent receipt, with this purpose as proof of notice – or the record would demonstrate non-compliance with sources referenced in the ANCR record and rendered not interoperable with the ANCR record schema and spec.

7. In this regard, ANCR specification is interoperable for 27560, but 27560 is not interoperable with the ANCR record, as this breaks ANCR Record Security, and contravenes privacy considerations for management of the ANCR Record.

8. To address this we have introduced the missing link, which are the fields for a Proof of Notice ANCR record and receipt required to be blinded, consent to combine the records in such a way is evidenced. Hence providing proof, securing the PII Principals data under the Principal’s control, as well as being compliant with legislation and 29184.

9. 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 Credential - https://wiki.trustoverip.org/pages/viewpage.action?pageId=27722576

Schema Mapping

The following mapping of the ANCR record schema is provide to conform to instructions provided in ISO/IEC 27560. To this extent, and 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.

This schema is intended to support the PII Principal to aggregate purposes per controller, per record. providing technical features to manage multiple legal justifications in a single service context.

Section1 – ANCR Record - Operational Transparnec

Section 2 Purpose Specification is followed by

Section 3: Data Treatment and Rights

Section: 4 Code of practice

Codes of practice can be approved and monitored which are used to 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.

Section 1: Header: Proof of Notice

Section 2: Purpose Specification, (ANNEX C –is also Extension 1)

Section 3: Treatment Specification, W3C DPV

Section 4: Code of Practice Profiles

Section 5: Field Data Sources

These refer to 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 27560 documents.

Extension 2: Data Treatment

In summary, elements from 27560 frame the data treatment elements are found in Extension 3 in addition to

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.

Extension Library

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

Revision history

¹

¹⁰⁵⁷⁴ Lizar, M, Pandit, H, Jesus, V, “Privacy as expected Consent Gateway”, Next Generation Internet (NGI) Grant [Access July 4] https://privacy-as-expected.org/

¹⁸⁶¹⁷ For example the “Age Appropriate Design Code of Practice,” https://ico.org.uk/for-organisations/guide-to-data-protection/ico-codes-of-practice/age-appropriate-design-code/

⁶⁵⁷⁴ Kantara Initiative, ‘Blinding Identity Taxonomy’ [Internet] https://docs.kantarainitiative.org/Blinding-Identity-Taxonomy-Report-Version-1.0.pdf

¹⁶⁴⁵⁵ Kantara Initiative, ‘Consent Receipt v1.1’. [Internet] https://kantarainitiative.org/download/7902/

^I