Anchored Notice and Consent Receipt (ANCR) Record
For Operational Transparency
Version: 0.8.8.2
Document Date: Aug 9, 2022
Editor(s): Mark Lizar
Contributors:
Contributing Orgs: Human Colossus Foundation, Global Privacy Rights
Produced by: ANCR-WG m
Status: WG Draft v0.8.7 – 8.9 (completing and polishing)
Abstract:
Currently, when online service are involved, the PII Principal (referred to as the Data Subject or Individual in this document) is unable to see who is in control of processing their personal data before it is processed, shared or disclosed. No way to assert authority upfront, to determine, imply or negotiate the conditions of data processing.
Functionally, people are not able to see (therefore trust and control) digital identifiers and require standardized transparency to provide data governance that scales what is meaningful 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 identity technologies.
Risk is relative to the stakeholder who controls the processing of personal data. This has a significant impact on the risks to security and privacy and the level of liability exposure for the other privacy stakeholders involved. For example, when the individual controls the personal information source, and specifies consent for its granular access, the safety and security risks drop dramatically for the Individual but can increase for PII Controllers.
Alternatively, privacy risk may be shared amongst stakeholders to lower security and privacy risks overall. (Distributed data governance).
The Anchored Notice Record (ANCR Record) bridges the operational transparency gap by measuring the PII Controller's transparency performance:
This document specifies transparency performance indicators, in order to make transparent risk through a record of the presentation of notice, specifically focus on:
PII Controller Identifying Credential: to see who controls personal data?
PII Controller Privacy Contact: is privacy accessible?
PII Controller Security Transparency Integrity
Measure of the integrity of the security presented (to see if the certificate correlates to the PII Controller and processor)
Included are extensions for the ANCR’s Record (found in Annex) provide to support the extension of operational transparency for operational privacy management.
Providing for a sequenced record extension protocol used to measure PII Controller transparency and accountability with ISO/IEC 29184, online privacy notice and consent controls.
Annex A – Two Factor Notice (2FN) (for differential transparency)
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.
Annex B- Concentric Notice Types
To simplify understanding of what rights and privacy controls are applicable in context, per processing purpose. Label to facilitate transparency autonomy, for independent access to rights to negotiate data controls with the accountable PII-Controller
Annex C – ANCR Record Extensions Protocol
Consent is required for the purpose of digital identity management, as well as any additional purpose(s).
The record is structured according to the protocol of first creating a private record of who is in control and accountable. Before then using this record to track purpose specification, data treatment, and detailed processing practice.
Annex C.1 - Purpose Specification –ANCR Mapped with 27560 Schema.
The ANCR Notice Record Schema, is mapped in accordance to the directions provide by ISO/IEC 27560 WD5. Illustrated in the appendix to help support critical flaws in the security considerations and understanding of the requirements for a human centric schema.
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
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.5.3
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.
...
| Table of Contents |
|---|
...
This ANCR Record specification is the core record for an international and interoperable consented exchange protocol.
The effort here is in parallel to the ongoing work at ISO/IEC 27560, is where the consent record information structure standard is being drafted, and further specifies a protocol for exchange, control and access to PII. This specification is also provided as a contribution to other ISO/IEC 2765x drafts, which might also bein the initial stages of drafting..
This specification completes the framing of the consent notice receipt work @Kantara which appears in Annex b of ISO/IEC 29184. It is used here to first assess if the PII Controller identity is present and acceptable as a proof of notice for distributing evidence of consent. Generating a record utilizing ISO/IEC 29100 security and privacy techniques to assess ‘controls regarding the content and the structure of online privacy notices. (The scope of ISO/IEC 29184 Online privacy notices and consent standard)
...
This ANCR specification introduces the ANCR record used to capture a record of Notice and verify Consented Notice Records and Consent Receipts in the flow and exchange of personal data. It specifies with what, and how a PII Principal can capture a record of notice with and assess digital transparency for the state of security and status of consent. The goal to measure if transparency is operational for the PII Principal transparency, requires knowing who the PII Controller is and if PII Controller contact information can be used to query status of privacy and consent.
This work effort creates an alternative to terms and conditions/contract-based process which is the default online today. The approach is to leverage legal and technical standards to supersede the use of terms and conditions, and contract-based privacy with operational privacy. This is done here by generating a record that can be used as a ‘Proof of Notice’ (eNotice) for evidence of consent (eConsent). The capture of security status and privacy state provide an anchor for decentralized transparency, accountability, and access to privacy rights.
The ANCR Record is specified for PII Principals, using terms, semantics and laws that champion the legal utility of data control and it’s management. As such, representing a shift in the architecture of digital identity semantics to legal semantics specific to human centric transparency, usability, and control.
To this point, the ANCR record is first specified as a record an Individual controls with 3 KPI’s specified to enable people to see the security and operational transparency, before its extension to a proof of notice object (a receipt) for linking service’s purpose and associated risks .
Before data processing a notice or notification is presented and ANCR record provides the individual with a choice, a chance to mitigate risks prior to, and post processing. Presenting significant security and privacy benefits that assist in making stronger security decisions.
...
To capture and measure transparency and security of the PII Controller identity and Controller contact information for operational use.
Correspondingly it presents two legal requirements for implementing privacy and security, which are universally found in standards, laws, and principles. One, to provide a notice prior to processing and, two, the PII Controller Identity and Contact information for querying the status of consent.
2 uses presented:
The PII Principal makes an ANCR record and assesses if the PII Controller identity is present so as to be accountable and secure
The PII Principal makes an ANCR record of contact information to ensure the notice is operationally viable for privacy access.
This specification, references ISO, GDPR and Convention 108+, to provide authoritative protocol for an international transparency baseline of default notice requirements for adequacy of a data transfer with evidence of consent.
...
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
...
For the purposes of this document, the following terms and definitions apply.
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/
...
For the international and cross-domain use of the records and receipts here, this document refers to the following:
1980/2013 OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data [OECD]
ISO/IEC 29100:2011 Security and privacy techniques
ISO/IEC 29184 Online privacy notices and consent,
Fair Information Practice Principles (FTC) foundational principles
...
General Data Protection Regulation (GDPR)
Council of Europe Convention 108+ (Conv. 108+)
Kantara Initiative Consent Receipt v1.1
ISO/IEC 27561:2022 POMME
ISO/IEC 27560: WD5 2022
...
PIPEDA -
...
Normative to Non-Normative
...
ISO
...
GDPR
...
Conv 108
...
PII Controller Identity
...
PII Controller Contact
...
The definitions reference terms that are used in this specification to indicates what is normative, non-normative, and additive. Adding human centric equivalents to the authoritative lexicon for operational transparency.
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.
...
[Source ISO/IEC 29184 5.2.7]
...
A record of a notice utilizing 29100 and 29184 for schema structure, and controls regarding notice content. It is used to demonstrate conformance to regulation, local and/or contextual, to practice surveillance in the processing of personally identifiable information
...
Broadly refers to any surveillance or privacy notice, notification, disclosure, statement, policy, sign or signal used to indicate personal data processing.
...
[Source ISO/IEC 29184
...
[Source ISO/IEC 29184
...
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 29100]
Personal data
[Source GDPR}
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: Con. 108+)
...
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.”
...
[GDPR Art X, Rec. 1(a)]
[Con 108: X.X.X]
Individual
[Additive: PIPEDA]
...
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]
Note: it may also be called data controller.
...
Covers multiple joint controller relationships including co-controllers, hierarchical, fiducial, and code. Likely a type.
...
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]
...
An additional field to indicate a delegated processor.
...
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+]
...
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]
[GDPR
[Conv
...
The legitimate interests of a controller, including those of a controller to which the personal data may be disclosed, or of a third party, may provide a legal basis for processing, provided that the interests or the fundamental rights and freedoms of the data subject are not overriding, taking into consideration the reasonable expectations of data subjects based on their relationship with the controller....
At any rate the existence of a legitimate interest would need careful assessment including whether a data subject can reasonably expect at the time and in the context of the collection of the personal data that processing for that purpose may take place. The interests and fundamental rights of the data subject could in particular override the interest of the data controller where personal data are processed in circumstances where data subjects do not reasonably expect further processing
The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned. The processing of personal data for direct marketing purposes may be regarded as carried out for a legitimate interest.
(GDPR Rec 47
...
reference the expected processing for a specified purpose in reference to common law (
...
The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned. The processing of personal data for direct marketing purposes may be regarded as carried out for a legitimate interest.
Processing is ‘as expected’ Notification
...
unverified
...
As expected,
...
not as expected,
...
minor change in state,
...
material change in state ,
...
Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including, inter alia, as appropriate:
(Conv. 108+ Art 33.1)
...
Not-Available
In-Active
Active
Active & Operational
Active & Dynamic
...
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]
‘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]
...
The corresponding field names, description and conformance criteria. Utilizing “named object” data types to define the principal requirements within the ANCR Record to verify operational transparency, prior to processing and disclosing of PII.
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
...
These fields are required
...
Field Cat Name
...
Object Label
...
Object Format
...
Object Description
...
Presence Requirement
...
ANCR Record ID
...
ancr_id
...
string
...
Blinded identifier secret to the PII Principal
...
Required
...
Schema version
...
V x.xx.x
...
string
...
PII Controller Identity
...
Object
...
array (strings)
...
_
...
Required
...
Presented Name of Service Provider
array (strings)
...
name of service. E.g. Microsoft
...
May
...
PII Controller Name
array (strings)
...
Company / organization name
...
MUST
...
PII Controller address
array (strings)
...
_
...
MUST
...
PII Controller contact email
\ array of strings
...
correspondence email
...
MUST
...
PII Controller jurisdiction legal reference
...
string
...
PII Controller Operating Privacy Law
...
MUST
...
PII Controller Phone
...
string
...
The general correspondence phone number
...
SHOULD
...
PII Controller Website
...
string
...
URL of website (or link to controller application)
...
MUST
...
PII Controller Certificate
...
Attache file
...
A capture Website SSL
...
OPTIONAL
...
Privacy Contact Point Location
...
pcpL
...
Privacy Contact Point Types (pcpT)
...
Object
...
array of strings
...
Must have at least one field for the PCP object
...
MUST
...
PCP-Profile
...
string
...
Privacy Access Point Profile
...
**
...
PCP-InPerson
...
string
...
In-person access to privacy contact
...
**
...
PCP-Email
...
string
...
PAP email
...
**
...
PCP-Phone
...
string
...
Privacy access phone
...
**
...
PCP -PIP- URI
...
string
...
privacy info access point, URI
...
**
...
PCP-Form
...
string
Privacy access form URI
...
**
...
PCP-Bot
...
string
privacy bot, URI
...
**
...
PCP-CoP
...
string
code of practice certificate, URI of public directory with pub-key
...
**
...
PCP-Other
...
string
...
Other
...
**
...
PCP Policy
...
pcpp
...
string
...
privacy policy, URI with standard consent label clauses
...
MUST
Legal Justification
...
ljust
...
Legal justification expected prior to notice
Concentric Notice Label
...
cnl
...
string
...
a label that is mapped to legal justifications, rights and controls that can be provided by default, for a specified purpose
...
SHALL
...
Event information required to demonstrate conformance and compliance.
Notice Record: Personal Data (Proof of Notice) Fields required to be included for the exchange of consent records, as consent receipts.
The following field data MUST be provided for the exchange of ANCR (as consent receipts) to evidence proof of notice, consent receipts.
...
Field Object
...
Label
...
Type
...
Description
...
Presence
...
ANCR Record ID
...
ancr_id
...
string
...
An identifier provided by the PII Principle
...
MUST
...
Schema Version
...
v x.xx
...
String
...
ANCR Record Schema version #
...
Required
...
Timestamp
...
iat
...
_the time and date when the ANCR record was created
...
Required
...
Legal Justification
...
string
...
One of six legal justifications used for processing personal data
...
Notice Record
...
Object labels
...
Notice Type
...
string
...
Notice, notification, disclosure
...
Required
...
Notice method
...
string
...
Link / URL to the UI that was used to present the notice e.g. website home page
...
MUST
...
-digital-Notice-location
...
dig-notice
...
Notice location e.g.ip address
...
MUST
...
location Certificate
...
MAY
...
Notice Language
...
The language notice provided in
...
MUST
...
Notice Text File
...
URL – and or Hashlink for the notice text
...
MUST
...
Notice text
...
The capture of a copy of the notification text
...
MUST
...
Notified legal Justification
...
Implied or explicit notified legal justification based on the text of a notice and its context
...
MUST
...
Risk notice disclosure
...
risk
...
PII controller risks
...
MUST
...
These fields can be asserted by the PII Principle to extend the functionality beyond the transparency KPI’s specified. to generate records and receipts with providence the PII Principal can trust.
...
ANCR Record Field Name
...
Field Label
...
Description
...
Required/Optional
schema version
...
V
...
A number used by the PII Principal to track the PII Controller Record
...
Optional (unless shared or used further)
...
Anchor Notice Record id #
...
Ancr_id
...
MUST
...
Date/Time
...
Required
...
Notice Collection method
...
Notice presentation UI Type
...
optional
...
Notice Collection Location
...
URL or digital address and location of the notice UI
...
required
...
Notice Legal Justification
...
One of the six legal justifications(ISO, GDPR, C108)
...
PII Principal Legal Location
...
ploc
...
optional
...
Device Type
...
May
...
PII Principal Public Key
...
These are the key performance indicator, ANCR fields required and used to assess the provided transparency of the PII Controller.
...
ANCR Record Fields
...
Field Description
...
Must, Shall, May
...
Field Data. E.G.
Record of Transparency Accessibility
Rate: -3, –1, 0, +1, +2
...
PII Controller Name
...
Name of presented business
...
MUST
...
Walmart
...
1
...
Controller Address
...
MUST
...
1940 Argentina Road Mississauga, Ontario L5N 1P9.
...
0
...
PII Controller Contact Type
...
Contact method for correspondence with PII Controller
...
MUST
...
Email, phone
...
-1
...
PII Controller-Correspondence Contact
...
General contact point
...
SHALL
...
Privacy@org.com
...
1
...
Privacy Contact Type
...
The
Contact method provided for access to privacy contact
...
MUST
...
...
0
...
Privacy Contact location
...
Location/address of Contact Point
...
MUST
...
Org.com/privacy.html
...
1
...
Session Certificate
...
A certificate for monitored practice
...
Optional
...
E.g., SSL Certificate Security (TLS) and Transparency
...
2
...
The first 2 Key Performance Indicators measure the transparency of the required PII Controller Identity information is ‘provided’, as provision of this information on, or before data processing is a condition of compliance for all data processing activities. In addition, to the standards referenced maintained by ISO/IEC and the GDPR and Convention 108+, which are references for enforceable multi-national (or international) privacy laws.
Once qualified as operational there is an optional 3rd KPI
The 3rd KPI, which is optional, is used to assess the contextual integrity of the security of the transparency assessed in KPI 1 &2, but only if the transparency ‘provided’ is operational.
The security KPI requires that the ANCR notice record is compared to a session certificate, to see if the PII Controller Identity information is the same, or mutually linked to the controlling entity in the associated security certificate e.g., SSL Certificate and domain DNS information match the PII Controller Identity.
...
Assess if the required information is ‘provided’ - Transparency over who is in control of notice and personal information. MUST fields, is there enough information to verify the controller identity and contact the PII controller to access and use privacy rights?
...
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?
...
This example is provided in the context of a browser / mobile device with a mobile application or webpage providing the client user interface.
This scale, a score of; [2,1,0, -1 or –3] is used to determine the number of steps, screens, or clicks required to find the ‘provided’ information.
Scale;
2 – is automatically or dynamically discoverable
1 - is one click away with a notification signal on the first page of viewing –question would be – privacy policy link at bottom of home page.
0 – is two clicks away
-1 – is 3 clicks away from signal (fail)
- 3 Information was Not found or more than 3 clicks
...
Certificate status and transparency are further indicators to the security and appropriateness of processing. This KPI uses standards to measure the certification. This includes checking things such as the SSL certificate, cryptography, organizational unit (e.g., for corroboration), object identifier, Common Name, and Jurisdiction -
...
Do these align
...
Currently online PII Principals are unable to see who is processing there personal data before personal data is processed, and what’’s more, people are not able to see who it is shared with, if it is exposed locally, or internationally, and are not able to have a say it what it is used for.
This presents critical security challenges for people, privacy and trust. To address this, the ANCR Record specifies Transparency KPI’s that generate a baseline transparency measure of PII Controller’s identity and contact information, before data processing and consent occurs.
‘Anchoring’ the digital identity relationship with a record that establishes an initial state of security and privacy defaults to provide notices that record to capture and maintain a shared understanding for purpose and risks.
An ANCR record stores this ‘session’ information for the PII Principal to be albe to remember the state of security and status of privacy for the next session. Re-used (like a cookie) on an ongoing basis to secure personal data processing, and distribute decentralized data controls for the use of rights.
The raw data in the record is only for the use/viewing by the PII Principal. It can only be made accessible with a proof o notice record and a receipt, which is used to verify data in the record, not transfer it – into data protection.
n doing so this addresses the critical security threat surrequirement of knowing to some baseline level who you are dealing with.
The ANCR Record supports PII Principal rights to self-verify the identity management relationship, to negotiate control over personal information and to be able to assert the legal authority to do so.
The ANCR Record adheres to the following security and privacy requirements:
Non-national standard used to Specified and design in the context of ISO/IEC 29100 - Security and Privacy schema, information structure protocol
Consent is a security access control in this context that is required to make a record with a PII Principal. In the baseline case the PII Principal makes the record by their own implied and explicit consent. This condition is then maintained for any other interaction that holds the context of the consent (e.g., purpose, codes and other governing parameters, e.g., locations (people, data) and implicit legal jurisdiction.
The ANCR Record represents the online privacy notice control record that is used to assess conformant to and with ISO/IEC 29184 controls.
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 technically 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.
PII Controller uses privacy stakeholders as a mutually inclusive and collectively exhaustive framework for extensions to the record for transferring liability and risk (e.g., internationally). This refers to any exchanges between/among PII Controllers and PII Principals collectively.
The ANCR record is specified here, in a method, to secure records that can be self-asserted by people to control, use, and trust. 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.
Every non-person entity touching data here is considered a PII Controller. The PII Controller can have many roles, according to context of processing. E.g., Joint Controller, PII Processor, and PII-Sub-processor.
The 3rd Party, and Recipient, here are extendable for example to Holder, Verifier, and Issuer in Self Sovereign Identifiers (SSIs) and Distributed Identifiers (DIDs) have direct mappings to the ANCR framework, its schema as well as traditional identity management (e.g., OAuth and SAML identifiers).
All data processing and every instance of processing requires the ANCR Record fields as a minimum. This can first qualify the record fields for compliant data processing as well as establishing the security capacity for digital privacy protocols and zero knowledge assurances.
Importantly the specification establishes a protocol in which the ANCR record is first created (by any stakeholder) and can be done so independently of a service provider.
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.
The KPIs provide transparency and security assurance to qualify the PII Controller before the controller processes personal information.
...
PII Principal identifying information MUST never be included in this specified ANCR Record. When a consent receipt is provided, all PII Principal identifiers MUST be either blinded or pseudonymized, 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 non-operational and insecure.
This categorizes most of the current internet and identity infrastructure as non-operational from a security perspective. As a result nearly all digital identifiers in an identifier management relationship produce raw PII for all parties that require security considerations. Access and use of this record as a data source in these cases are achieved through extensions. Annex A
...
ISO/IEC 27560 is used to generate a standard purpose-based notice and consent information and identifier structure. This is utilized by the ANCR Record schema and protocol to specify or audit a purpose for any legal justification.
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 Annex C)
...
Once specified, the W3C Data Privacy Vocabulary is used to specify the treatment of personal data.
...
Extending the ANCR Notice record, purpose specification and data treatment sections with a code of conduct (transparency practices) 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.]
...
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
...
[Conv 108+] Council of Europe, Convention 108 +
...
[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
...
Click through to no cost license https://standards.iso.org/ittf/PubliclyAvailableStandards/c045123_ISO_IEC_29100_2011.zip
...
Annex (WiP to v8.9.9)
...
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)
...
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
The right for a PII Principal to know what rights they have,
The right to be heard, children’s design code of practice
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.
...
Legal Justification
...
Description
Concentric Notice Type
...
Privacy Rights / PII Controls
...
Reference
...
Vital Interest
...
refers to processing ‘which is essential for the life of the data subject or that of another natural person. Processing of personal data
...
Implied/implicit
Transparency, Access, Rectify, Forget/Erase, Withdraw, Restrict,
ISO/IEC 29184, 5.4.2
Conv.108+ 10.2(c)
...
Explicit Consent Notice
...
Explicit consent to processing one or more specified2 purpose
...
Explicit , Directed, Altruistic Consent
Access, Rectify, Forget/Erase, Object, / Withdraw, Restrict, Portability
...
29184, 5.4.2
Conv.108+ 10.2(a)
GDPR art 6.1(a)
...
Implicit consent notice
...
And where manifestly published by the PII Principal
...
Implicit Consent
Con 108 + 10.2(e)
...
Implied consent notice
By Controller or Principal in the field of employment and social security and social protection law
...
Implied Consent
...
CoE 108+ 10.2(b)
...
Contractual Necessity
...
Implied consent
...
Restrict Processing, Object to
...
29184, 5.4.2
Con. 108+(43)
...
Legitimate Interest
...
Implied consent
...
Object and restrict processing
...
29184, 5.4.2
GDPR Recital 47
Con.108+ 10.2(d)
...
Public Interest
...
Democratically framed
...
Implied Consent/Consensus
...
29184, 5.4.2
Con. 108+ 10.2(I,g,j)
...
Legal Obligation
...
ISO/IEC 29184, 5.4.2
Processing is necessary for the establishment, exercise or defense of legal claims
...
Con.108+ (f)
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 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
Concentric Notice Type
...
Description
...
Legal Justification
...
Privacy Rights
(GDPR)
...
Legal Ref
...
Non-Operational Notice
N/O
...
Not enough 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
...
The anchor record is captured or generated for the explicit control of the PII Principal. This record, standardized with ISO/IEC 29100 security and privacy technique framework, can then be used for transparency interoperability.
The Anchor record and linked consent ledger is used by the PII Principal to track the state of privacy and status of consent for dynamic data controls for bilateral (peer to peer) interaction. The anchor record is minted with the PII Controller ANCR record and in this way extended by a product or service purpose specification.
...
Anchored Notice and Consent Receipt (ANCR) Record
For Operational Transparency
Version: 0.8.8.3
Document Date: Aug 17, 2022
Editor(s): Mark Lizar
Contributors:
Contributing Orgs: Global Privacy Rights, Human Colossus Foundation,
Produced by: ANCR-WG
Status: WG Draft v0.8.7 – 8.9 (completing and polishing)
Editor Note:
A Record of processing provides transparency over who is accountable and is a pre-condition for processing PII with scalable governance and security. Operational transparency scales into systems human context and understanding. Transparency over data control is used here to regulate online surveillance much like transaction receipts, bank accounts and currency is regulated and tracked today.
This specification is designed from the PII Principle perspective and primary use is for creating a record of notice. Specifying to start, a single use record, then enhancing this record for repeated use, and then again as a proof of notice, for it’s exchange.
Finally, the Anchored Notice Record, private information records is specified here as a separate record. Requiring security considerations for generating consent records for identity management systems.
In this specification PII Principles manage consent and identity systems manage a permission grant defined by the notified purpose and what people expect in context. This specification focuses on transparency of control, with extensions for extending this transparency to services with a purpose specification protocol as outlined in Annex
Abstract:
Currently, when online service 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. No way to assert authority upfront, to determine, imply or negotiate the conditions of data processing, identifier generation, its management or to even establish a trust protocol to engage with.
Functionally, people are not able to see (therefore trust and control) the creation use and disclosure of digital identifiers (meta data). The use of which, require standardized transparency to provide data governance that scales from centralized to decentralized is meaningful 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, becoming the Consent and Information Sharing WG in 2015. Creates to standardize transparency as an alternate to custom terms and conditions, user license, contracts. This standard recommends a methodology to leverage legal and technical standards for transparency to supersede or at least be comparative too, the use of terms and conditions,
Security breach + lack of Transparency + dual records and receipt system for a common landscape for data control interoperability.
KPI 1 – Notice of Identity of Controller
KPI 2 – Accessibility of Notice
KPI 3 – Security 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.5.3
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.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Table of Contents |
|---|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
Public international laws and standards for digital record and receipts promise to dramatically lower the cost of security and increase the effectiveness of privacy. The use of ISO 29100 privacy framework for consented data access, control and transfer proposed a low cost, or free notice record framework for PII Principles (and Controllers). To facilitate the governance and regulation by all privacy stakeholders, by regulating authorities.
Key perspective: An Internationally standard notice record information structure to enable the PII Principal to generate records independently of the PII Controller. Greatly decreasing the cost of security and the effectiveness of privacy for all stakeholders.
This ANCR WG – Notice Record specification is introduced with a operational assessment of transparency over who is in control, and how accessible is access to privacy rights information prior to processing personal data and before generating identifiers. A record to access the authority before authentication, and the authorizations created to processing personal data.
This specification is a contribution to ongoing work at ISO/IEC SC27 WG5, Utilizing 29100 Security and privacy techniques to create a standardized record of processing for personal data control through engaging with notice. Generating a dual Notice record, for use with ISO/IEC 29184 Online privacy notices and consent structure and controls. For example, operational transparency measurements are introduced in the introduction, while the Notice records is specified in the body pf the document.
This specification has been developed in parallel with the work on ISO/IEC 27560 Consent record information structure to operationalize transparency with Consent Notice Receipts, (Annex b of ISO/IEC 29184) and presentation in September –2022 to complete the contribution made by Kantara of the Consent Receipt in 2018.
**
Operational Transparency
A stepping stone to digital privacy, in which human consent scales on line –(is interoperable) with rights to control data processing in multiple systems based on context.
In the ‘introduction’ the aim is to operationalize this specification by providing an example notice record, along with 3 transparency performance indicators, which are used to provide context for the Notice Record Information Structure contribution.
This notice record is specified with the freely available ISO/IEC 29100 security and privacy techniques framework to measure the performance of transparency with the controls in ISO/IEC 29184. Specifically,
The PII Controller identity and privacy contact point
The Accessibility of PII Controller Identity and Contact information,
The security and integrity of the controller’s transparency
Notic Record Specification
elements and acceptable as a ‘Proof of Notice’ for distributing evidence of consent. Generating a record utilizing ISO/IEC 29100 security and privacy techniques to assess ‘controls regarding the content and the structure of online privacy notices. (The scope of ISO/IEC 29184 Online privacy notices and consent standard)
The terms specified are referenced first to ISO, then to enforced trans-national regulation, GDPR, and Convention 108, which are used to set an international Adequacy baseline for performance related measurements for data controls
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
2 things to Preface
This specification is being created to standardize, the capture and measure transparency and security of the PII Controller identity and Controller contact information for operational use by the PII Principal.
Correspondingly it presents two legal requirements for implementing privacy and security, which are found in standards, laws, and principles. One, to provide a notice prior to processing with PII Controller Identity and 2. privacy Contact information.
This ANCR specification introduces the Notice Record used to capture a record of Notice and verify Consented Notice Records and Consent Receipts in the flow and exchange of personal data. It specifies with what, and how a PII Principal can capture a record of notice with and assess digital transparency for the state of security and status of consent. to measure if transparency is operational for the PII Principal transparency, requires knowing who the PII Controller is and if PII Controller contact information can be used to query status of privacy and consent.
The ANCR 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.
To this point, 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.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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.
| Anchor | ||||
|---|---|---|---|---|
|
Field Name | Field Description | Requirement: Must, Shall, May | Field Data Example |
Notice Location | Location the notice was read/observed | MUST | |
PII Controller Name | Name of presented business | MUST | Walmart |
Controller Address | The physical address of controller and/or accountable person | MUST | 1940 Argentina Road Mississauga, Ontario L5N 1P9. |
PII Controller Contact Type | Contact method for correspondence with PII Controller | MUST | Email, phone |
PII Controller-Correspondence Contact | General contact point | SHALL | |
Privacy Contact Type | The Contact method provided for access to privacy contact | MUST | |
Privacy Contact Point | Location/address of Contact Point | MUST | |
Session Certificate | A certificate for monitored practice | Optional | E.g., SSL Certificate Security (TLS) and Transparency |
Anchoring the Notice Record for Trust
Without a record identifier, added to each record, this initial record is un-anchored 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 to secure a privacy context in a system.
| Anchor | ||||
|---|---|---|---|---|
|
The first 2 Key Performance Indicators measure the transparency of the required PII Controller Identity information is ‘provided’, as provision of this information on, or before data processing is a condition of compliance for all data processing activities. In addition, to the standards referenced maintained by ISO/IEC and the GDPR and Convention 108+, which are references for enforceable multi-national (or international) privacy laws.
Once qualified as operational there is an optional 3rd KPI
The 3rd KPI, which is optional, is used to assess the contextual integrity of the security of the transparency assessed in KPI 1 &2, but only if the transparency ‘provided’ is operational.
The security KPI requires that the ANCR notice record is compared to a session certificate, to see if the PII Controller Identity information is the same, or mutually linked to the controlling entity in the associated security certificate e.g., SSL Certificate and domain DNS information match the PII Controller Identity.
| Anchor | ||||
|---|---|---|---|---|
|
Assess if the required information is ‘provided’ - Transparency over who is in control of notice and personal information. MUST fields, is there enough information to verify the controller identity and contact the PII controller to access and use privacy rights?
| Anchor | ||||
|---|---|---|---|---|
|
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?
KPI 2 – Example Accessibility Measurement Scale
This example is provided in the context of a browser / mobile device with a mobile application or webpage providing the client user interface.
This scale, a score of; [2,1,0, -1 or –3] is used to determine the number of steps, screens, or clicks required to find the ‘provided’ information.
Scale;
2 – is automatically or dynamically discoverable
1 - is one click away with a notification signal on the first page of viewing, the assessment question would be, is the privacy policy link at bottom of home page?
0 – is identity or contact info two clicks away
-1 – is 3 clicks away from signal (fail)
- 3 Information was Not found or more than 3 clicks
| Anchor | ||||
|---|---|---|---|---|
|
Certificate status and transparency are further indicators to the security and appropriateness of processing. This KPI uses standards to measure the certification. This includes checking things such as the SSL certificate, cryptography, organizational unit (e.g., for corroboration and integrity), object identifier, Common Name, and Jurisdiction -
Do these align
Field Name | Field Description | Requirement: Must, Shall, May | KPI 1 Available Not-Available | KPI 2 Rate: -3, –1, 0, +1, +2 | KPI 3 CN-Matches |
Notice Location | Location the notice was read/observed | MUST | present | +2 | |
PII Controller Name | Name of presented organization | MUST | present | 1 | Match |
PII Controller Address | Physical organization Address | MUST | present | 0 | Not match |
Privacy Contact Point | Location/address of Contact Point | MUST | Present | 1 | Not match |
Privacy Contact Method | Contact method for correspondence with PII Controller | MUST | Present | -1 | No Match |
Correspondence Contact Method | General contact point | SHALL | present | 1 | Not match |
Session key or Certificate | A certificate for monitored practice | MUST | Not-found | 2 |
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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/
| Anchor | ||||
|---|---|---|---|---|
|
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
| Anchor | ||||
|---|---|---|---|---|
|
1980/2013 OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data [OECD]
Kantara Initiative Consent Receipt v1.1
ISO/IEC 27561:2022 POMME
ISO/IEC 27560: WD5 2022
| Anchor | ||||
|---|---|---|---|---|
|
General Data Protection Regulation (GDPR)
Council of Europe Convention 108+ (Conv. 108+)
PIPEDA – Individual, Meaningful Consent,
| Anchor | ||||
|---|---|---|---|---|
|
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
| Anchor | ||||
|---|---|---|---|---|
|
The definitions reference terms that are used in this specification to indicates 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.
| Anchor | ||||
|---|---|---|---|---|
|
For Individual participation and access
The concentric notice type, refers to a notice label that is provided by or to the PII Principal according to data processing default legal context. The labela act as a short code to quickly see. or signal, the legal context of data processing and what digital privacy rights are typically accessible for the context.
Note: Should link to notice modality risks, derogations and obligations
[Source: ANCR Notice Record Annex C]
References for Concentric Notice Types
Establishing procedures to enable PII principals to exercise these rights in a simple, fast and efficient way, which does not entail undue delay or cost. 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
[29184: Art 5.2.1]
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. The controller should be obliged to respond to requests from the data subject without undue delay and at the latest within one month and to give reasons where the controller does not intend to comply with any such requests.
[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.
Personal data should be processed in a manner that ensures appropriate security and confidentiality of the personal data, including for preventing unauthorised access to or use of personal data and the equipment used for the processing and for preventing its unauthorised disclosure when it is transmitted.
[Source Conv 108+ Rec.20]
| Anchor | ||||
|---|---|---|---|---|
|
Adhering to the openness, transparency and notice principle 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.
[ISO/IWC 29100]
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.
[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
(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 ]
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.
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.
Machine-readable notices may be provided in a standardized XML or JSON format. By so doing, becomes possible for devices to select items appropriately and display graphics and icons where applicable.
[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]
| Anchor | ||||
|---|---|---|---|---|
|
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
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]
A record of a notice utilizing 29100 and 29184 for schema structure, and controls regarding notice content. It is used to implement operational defaults to demonstrate conformance to regulation, local and/or contextual, to practice surveillance in the processing of personally identifiable information
[Source ANCR Notice Record]
Privacy Principles
The privacy principles of ISO/IEC 29100
Consent and choice
Purpose legitimacy and specification
Collection limitation
Data minimization
Use, retention and disclosure limitation
Accuracy and quality
Openness, transparency and notice
Individual participation and access
Accountability
Information security
Privacy compliance
| Anchor | ||||
|---|---|---|---|---|
|
[Source ISO/IEC 29184
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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 29100]
Personal data
[Source GDPR}
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: Con. 108+)
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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]
[GDPR Art X, Rec. 1(a)]
[Con 108: X.X.X]
Individual
[Additive: PIPEDA]
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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]
Note: it may also be called data controller.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
Covers multiple joint controller relationships including co-controllers, hierarchical, fiducial, and code. Likely a type.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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]
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
An additional field to indicate a delegated processor.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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+]
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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]
[GDPR
[Conv
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
Table A.1 — Matching ISO/IEC 29100 concepts to ISO/IEC 27000 concepts | |
ISO/IEC 29100 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]
Third 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]
| Anchor | ||||
|---|---|---|---|---|
|
The ANCR Record is essentially a layered record schema, the first record is the minimum viable consent receipt record, This record collects no additional data, except what the PII Principal would require to see in order to initiate electronic notice and consent dialogue with some operational security assurance.
Base Notice Record Schema. This is a private Un-Anchored Notice Access Record
Personal Notice Data is added to the private record
PII Principal private record is extended with personal data specific to use of notice
A Proof of Notice (PoN) credential is generated.
which is used to determine if the PII Controller identity information and privacy contact point is operationally transparent
The corresponding field names, description, and conformance criteria. Utilizing “named object” data types to define the principal requirements within the ANCR.
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
| Anchor | ||||
|---|---|---|---|---|
|
This is the schema elements that are used to generate a un-anchored notice record and do 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 |
|
|
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 | ||||
|---|---|---|---|---|
|
Proof of Notice record, builds on the PII Controller Identity and Contact field base to generate a proof of notice record with PII fields to a corresponding private proof of notice record.
This legally required information for proof of notice. This event information is needed for legal chain of evidence, in which PII is added to the record but blinded, and secure. Starting with the Private ANCR Record ID which the PII Principal can use to aggregate operational transparency information for more advanced use in context.
Field Cat | Field Name | Description | Presence |
ANCR Record ID | Blinded identifier secret to the PII Principal | Required | |
Schema version |
|
| |
Timestamp |
| _the time and date when the ANCR record was created | Required |
Legal Justification |
| One of six legal justifications used for processing personal data |
|
Notice Record | Object labels |
|
|
| Notice Type | Notice, notification, disclosure | Required |
Notice legal location | The location ore region that the PII Principal read the information., | ||
| Notice presentation method | Website | MUST |
| online notice -location | Notice location e.g.ip address | MUST |
| location Certificate |
| MAY |
| Notice Language | The language notice provided in | MUST |
| Notice Text File | URL – and or Hashlink for the notice text | MUST |
| Notice text | The capture of a copy of the notification text | MUST |
| Notified legal Justification | Implied or explicit notified legal justification based on the text of a notice and its context | MUST |
Concentric Notice Label | cnl | a label that is mapped to legal justifications, rights and controls that can be provided by default, for a specified purpose | SHALL |
| Anchor | ||||
|---|---|---|---|---|
|
These fields can be asserted by the PII Principle to extend the functionality beyond the transparency KPI’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.
*** PII COntroller Consent record must have consent first before making . E.g. Authority to use this for security, -- (non-compliant). ***
ANCR Record Field Name | Description | Required/Optional | Security Consideration |
schema version | A number used by the PII Principal to track the PII Controller Record | Optional (unless shared or used further) | Blinded Pseudonymized Anonymized Verified Credential Attribute |
Anchor Notice Record id # | MUST | ||
Date/Time | Required | ||
Notice Collection method | Notice presentation UI Type | optional | |
Notice Collection Location | URL or digital address and location of the notice UI | required | |
Notice Legal Justification | One of the six legal justifications(ISO, GDPR, C108) | ||
PII Principal Legal Location | optional | ||
Device Type | May | ||
PII Principal Private- Key | |||
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
Notice Record is first a tool of transparency, a private record with this minimal purpose. It is then extended into two records, 1. being a private proof of notice record proof of notice record, which provides assurance that the PII Principal has read the notice. Impl
Currently online PII Principals are unable to see who is processing there personal data before personal data is processed, and what’’s more, people are not able to see who it is shared with, if it is exposed locally, or internationally, and are not able to have a say it what it is used for.
This presents critical security challenges for people, privacy and trust. To address this, the ANCR Record specifies Transparency KPI’s that generate a baseline transparency measure of PII Controller’s identity and contact information, before a proof of notice is required for consent to process personal data. This is an initial securtiy check that does not require digital identifiers, prior to notice and the presentation of a service purpose, for any legal basis, at which point consent defaults can be applied to automate purpose notification,
‘Anchoring’ the digital identity relationship with a record that establishes an initial state of security and privacy defaults to provide notices that record, capture and maintain a shared understanding for purpose and risks.
An ANCR record stores this ‘session’ information for the PII Principal to be albe to remember the state of security and status of privacy for the next session. Re-used (like a cookie) on an ongoing basis to secure personal data processing, and distribute decentralized data controls for the use of rights.
The raw data in the record is only for the use/viewing by the PII Principal. It can only be made accessible with a proof o notice record and a receipt, which is used to verify data in the record, not transfer it – into data protection.
n doing so this addresses the critical security threat sur requirement of knowing to some baseline level who you are dealing with.
The ANCR Record supports PII Principal rights to self-verify the identity management relationship, to negotiate control over personal information and to be able to assert the legal authority to do so.
The ANCR Record adheres to the following security and privacy requirements:
Non-national standard used to Specified and design in the context of ISO/IEC 29100 - Security and Privacy schema, information structure protocol
Consent is a security access control in this context that is required to make a record with a PII Principal. In the baseline case the PII Principal makes the record by their own implied and explicit consent. This condition is then maintained for any other interaction that holds the context of the consent (e.g., purpose, codes and other governing parameters, e.g., locations (people, data) and implicit legal jurisdiction.
The ANCR Record represents the online privacy notice control record that is used to assess conformant to and with ISO/IEC 29184 controls.
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 technically 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.
PII Controller uses privacy stakeholders as a mutually inclusive and collectively exhaustive framework for extensions to the record for transferring liability and risk (e.g., internationally). This refers to any exchanges between/among PII Controllers and PII Principals collectively.
The ANCR record is specified here, in a method, to secure records that can be self-asserted by people to control, use, and trust. 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.
Every non-person entity touching data here is considered a PII Controller. The PII Controller can have many roles, according to context of processing. E.g., Joint Controller, PII Processor, and PII-Sub-processor.
The 3rd Party, and Recipient, here are extendable for example to Holder, Verifier, and Issuer in Self Sovereign Identifiers (SSIs) and Distributed Identifiers (DIDs) have direct mappings to the ANCR framework, its schema as well as traditional identity management (e.g., OAuth and SAML identifiers).
All data processing and every instance of processing requires the ANCR Record fields as a minimum. This can first qualify the record fields for compliant data processing as well as establishing the security capacity for digital privacy protocols and zero knowledge assurances.
Importantly the specification establishes a protocol in which the ANCR record is first created (by any stakeholder) and can be done so independently of a service provider.
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.
The KPIs provide transparency and security assurance to qualify the PII Controller before the controller processes personal information.
| Anchor | ||||
|---|---|---|---|---|
|
Towards Privacy
PII Principal identifying information MUST never be included in this specified ANCR Record. When a consent receipt is provided, all PII Principal identifiers MUST be either blinded or pseudonymized, 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 non-operational and insecure.
This categorizes most of the current internet and identity infrastructure as non-operational from a security perspective. As a result nearly all digital identifiers in an identifier management relationship produce raw PII for all parties that require security considerations. Access and use of this record as a data source in these cases are achieved through extensions. Annex A
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
ISO/IEC 27560 is used to generate a standard purpose-based notice and consent information and identifier structure. This is utilized by the ANCR Record schema and protocol to specify or audit a purpose for any legal justification.
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 Annex C)
| Anchor | ||||
|---|---|---|---|---|
|
Once specified, the W3C Data Privacy Vocabulary is used to specify the treatment of personal data.
| Anchor | ||||
|---|---|---|---|---|
|
Extending the ANCR Notice record, purpose specification and data treatment sections with a code of conduct (transparency practices) 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.]
| Anchor | ||||
|---|---|---|---|---|
|
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 | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
[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
Annex (WiP to v8.9.9)
| Anchor | ||||
|---|---|---|---|---|
|
ANCR Record, with these annex show the human centric transparency ontology, This annex focuses on the data technical semantics of the ontology from a Human (label), for legal reference, to a machine readable attribute, for an operational transparency schema.
Field Label (or Name)
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.).
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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)
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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
The right for a PII Principal to know what rights they have,
The right to be heard, children’s design code of practice
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.
| Anchor | ||||
|---|---|---|---|---|
|
These are mapped here
| Anchor | ||||
|---|---|---|---|---|
|
Legal Justification | Description | Concentric Notice Type | Privacy Rights / PII Controls | Reference |
Vital Interest | refers to processing ‘which is essential for the life of the data subject or that of another natural person. Processing of personal data | Implied/implicit | Transparency, Access, Rectify, Forget/Erase, Withdraw, Restrict, | ISO/IEC 29184, 5.4.2 Conv.108+ 10.2(c) GDPR art 6.1(d) art 49(f) |
Explicit Consent Notice | Explicit consent to processing one or more specified2 purpose | Explicit , Directed, Altruistic Consent | Access, Rectify, Forget/Erase, Object, / Withdraw, Restrict, Portability | 29184, 5.4.2 Conv.108+ 10.2(a) GDPR art 6.1(a) |
Implicit consent notice | And where manifestly published by the PII Principal | Implicit Consent | Con 108 + 10.2(e) | |
Implied consent notice | By Controller or Principal in the field of employment and social security and social protection law | Implied Consent | CoE 108+ 10.2(b) | |
Contractual Necessity | Implied consent | Restrict Processing, Object to | 29184, 5.4.2 Con. 108+(43) | |
Legitimate Interest | Implied consent | Object and restrict processing | 29184, 5.4.2 GDPR Recital 47 Con.108+ 10.2(d) | |
Public Interest | Democratically framed | Implied Consent/Consensus | 29184, 5.4.2 Con. 108+ 10.2(I,g,j) | |
Legal Obligation | ISO/IEC 29184, 5.4.2 | |||
Processing is necessary for the establishment, exercise or defense of legal claims | Con.108+ (f) |
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.
| Anchor | ||||
|---|---|---|---|---|
|
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
Concentric Notice Type | Description | Legal Justification | Privacy Rights | Legal Ref |
Non-Operational Notice N/O | Not enough notice/security information for digital privacy | Not compliant with any if unable to determine or confirm Controller, or contact | Withdraw, Object, Restrict, | 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. | 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 | ||||
|---|---|---|---|---|
|
The anchor record is captured or generated for the explicit control of the PII Principal. This record, standardized with ISO/IEC 29100 security and privacy technique framework, can then be used for transparency interoperability.
The Anchor record and linked consent ledger is used by the PII Principal to track the state of privacy and status of consent for dynamic data controls for bilateral (peer to peer) interaction. The anchor record is minted with the PII Controller ANCR record and in this way extended by a product or service purpose specification.
| Anchor | ||||
|---|---|---|---|---|
|
The legitimate interests of a controller, including those of a controller to which the personal data may be disclosed, or of a third party, may provide a legal basis for processing, provided that the interests or the fundamental rights and freedoms of the data subject are not overriding, taking into consideration the reasonable expectations of data subjects based on their relationship with the controller....
At any rate the existence of a legitimate interest would need careful assessment including whether a data subject can reasonably expect at the time and in the context of the collection of the personal data that processing for that purpose may take place. The interests and fundamental rights of the data subject could in particular override the interest of the data controller where personal data are processed in circumstances where data subjects do not reasonably expect further processing
The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned. The processing of personal data for direct marketing purposes may be regarded as carried out for a legitimate interest.
(GDPR Rec 47
| Anchor | ||||
|---|---|---|---|---|
|
reference the expected processing for a specified purpose in reference to common law (
The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned. The processing of personal data for direct marketing purposes may be regarded as carried out for a legitimate interest.
Processing is ‘as expected’ Notification
unverified
As expected,
not as expected,
minor change in state,
material change in state ,
PII Principal
| Anchor | ||||
|---|---|---|---|---|
|
Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including, inter alia, as appropriate:
(Conv. 108+ Art 33.1)
| Anchor | ||||
|---|---|---|---|---|
|
Not-Available
In-Active
Active
Active & Operational
Active & Dynamic
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||
|---|---|---|
|
...
|
...
|
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.
...
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.
| Anchor | ||
|---|---|---|
|
...
|
...
|
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.
...
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.
| Anchor | ||
|---|---|---|
|
...
|
...
|
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)
To this extent the 27560 ‘event schema’ section is not required.
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,
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.
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.
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.
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.
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
| Anchor | ||
|---|---|---|
|
...
|
...
|
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.
...
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.
| Anchor | ||
|---|---|---|
|
...
|
...
|
In addition to the consent receipt schema, the ANCR record schema provides a protocol for its operation.
...
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.
| Anchor | ||
|---|---|---|
|
...
|
...
|
ANCR Consent Receipt Section | Label | Variations | Description | 27560 Term | Reference |
| ANCR ID | Specified to be a toot recorded identifier | Notice record id is used as root identifier for linking records about the status of privacy with that controller | Record id | |||||||||||||||||||||||||
schema version | same | ||||||||||||||||||||||||||||
PII Controller Identity Object
| Non-operational privacy contact point | ||||||||||||||||||||||||||||
Privacy Contact Point Object
| ANCR focuses on a KPI – for the transparency performance of privacy contact access point | ||||||||||||||||||||||||||||
Proof of Notice Object
| Uses notice type which would be equivalent to event type in 27560 | ||||||||||||||||||||||||||||
Concentric Notice Label | Different but incorporates how to fame 27560 defined consent types | Categorizes Notice Labels to indicate protocol for rights access and inherent risks | 29184 – purpose specification |
| Purpose ID | ||||
Service Name | |||||
Purpose name | |||||
Purpose Description | Plausible RiSK - *can data control impact assessment) | ||||
Purpose Type | |||||
Legal justification | Lawful basis | ||||
Sensitive PII Categpry | |||||
Special PII Category | |||||
PII Principal Category | |||||
PII Processors | |||||
PII Sub-processors | New | ||||
Risk notice disclosure | ISO-29184 | ||||
Service Notice Risks | |||||
PII Principal Category |
| Attribute Id | ||||
Notified Collection method | Collection method | ||||
expiration | |||||
Storage location | |||||
Retention period | |||||
Processing location Restrictions | |||||
Duration | |||||
State | Justification for processing (state of privacy) | ||||
status | |||||
termination |
| Inherent to concentric labels - Rights Objects: withdraw, object, restrict, access and rectification, termination of justification, | Regulated practice, approved be regulator or legislated | |||
Rights | |||||
Notice Defaults | |||||
Data portability | |||||
FoI-Access & Rectification | |||||
4.b)Code of Practice | Cop-ID | ||||
Surveillance Code of practice | Certified practice, | ||||
Children’s Design Code of Practice | |||||
Operational Privacy Code of Practice |
| Anchor | ||
|---|---|---|
|
...
|
...
|
Purpose Bundle
Code of Practice Certification -
Badge -
Pre-Consent Notice Lable Type
Notify to confirm or change -
Then start -
Purpose Description – medical
Vital interest
Legal obligation
Operational personal data handle (3rd Party)
Approved by Regulator (yes/no)
Certified Body - ? - Certification
SSI – Gov – Principles – Codes of Conduct
Purpose Name
Purpose Label
Ancor Notice Record ID
ANCR Record Protocol
An Anchor record is a PII Controller Relationship Notice Record, very similar to a PII Controller Credential, but instead of being provided by a specific stakeholder, this – micro-credential can be created as an ANCR Notice Record by the PII Principal.
When a record or receipt is generated, it can use either this record, or a PII Controller provided record as the source record, for linking all of the subsequent record and receipts together. This way both the PII Controller and Principal have corresponding (mirrored) records which are not directly linked and separately controlled.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||
|---|---|---|
|
...
|
...
|
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 – focusing on spec structurally for human centricity I focus | ||
8.8.5 | updated terms and references | ||
1
I