...
Authorization from Consent
Version: 0.8.9.3
Document Updated: Nov 22
...
The ANCR record objective is to provide operational transparency over data control and processing that works to regulate surveillance from offline and online activities, in much the same way as financial transactions are now regulated and trackedfor people so they are able to have a choice to control personal data and it’s processing to co-regulate digital surveillance technologies.
The Anchored Notice and Consent Receipt (ANCR) is a Record of processing specification that can be used for any data processing activity. Used to provide individuals with transparency (i.e., a PII Principal) to employ a 3-layer notice record schema to indicate as a digitally twinned record provides active state transparency features with the use of a technique called Differential Transparency. A processing model driven with the authority of the individual. The specification is intended to be used for with or in addition to any legal data processing activity. AuthC employs a 3-layer notice record schema to indicate knowledge of processing, and in this context indicate consent and or permissions as appropriate.
Required for a specific data exchange. PII Principals can enhance the single use record schema with a layer 2 schema that incorporates a digital identifier to serve a ‘proof of notice’ record for repeated use in concentric data exchanges.
The 3rd notice record schema is the private, anchored notice records is a private information (identity relationship) recordrecord which contains sensitive information to validate the digital identity relationship. This schema is' a self-sovereign security' schema, which considers security transparency requirements as a mandatory pre-condition for generating records and receipts in identifier management systemsdigital consent receipt tokens validation.
Finally, an active technical record of processing activities provides for the PII Principal in context transparency over who is accountable for — and is a pre-condition of — processing Personally Identifiable Information (PII) for human interoperable governance and security.
AuthC contribution are from the Digital Transparency Lab Canada.
NOTES TO READER
This Kantara Initiative work effort began when Liberty Alliance became the Kantara Initiative, and the Consent and Information Sharing Working Group formally began in 2015. That Working Group’s activities carried on through the ANCR Working Group.
...
Suggested Citation: (upon WG approval)
ANCR Specification v0.9
NOTICE
This document has been prepared by Participants of Kantara Initiative Inc. Permission is hereby granted to use the document solely for the purpose of implementing the Specification. No rights are granted to prepare derivative works of this Specification. Entities seeking permission to reproduce this document, in whole or in part, for other uses must contact the Kantara Initiative to determine whether an appropriate license for such use is available.
Implementation or use of certain elements of this document may require licenses under third party intellectual property rights, including without limitation, patent rights. The Participants and any other contributors to the Specification are not and shall not be held responsible in any manner for identifying or failing to identify any or all such third-party intellectual property rights. This Specification is provided "AS IS," and no Participant in Kantara Initiative makes any warranty of any kind, expressed or implied, including any implied warranties of merchantability, non-infringement of third-party intellectual property rights, or fitness for a particular purpose. Implementers of this Specification are advised to review Kantara Initiative’s website (http://www.kantarainitiative.org ) for information concerning any Necessary Claims Disclosure Notices that have been received by the Kantara Initiative Board of Directors.
Dear reader
Thank you for downloading this publication prepared by the international community of experts that comprise the Kantara Initiative. Kantara is a global non-profit ‘commons’ dedicated to improving trustworthy use of digital identity and personal data through innovation, standardization and good practice.
...
Copyright: The content of this document is copyright of Kantara Initiative, Inc.
© 2022 Kantara Initiative, Inc.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Contents
Table of Contents |
---|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
ANCR Notice Record Schema Specification
The ANCR notice record is fundamentally a layered record schema, the first record layer is the minimum viable notice record (MVNR) a PII Principal can make to capture the organisation/institution that controls their personal data as well as the accountable person liable for that legal entity. This record collects no additional data, except what the PII Principal is required to see and understand in order to be legally informed of the risks of generating a digital identifier.
...
This schema is cumulative, where each schema layer can be added upon the previous layer.
3 Layers to the ANCR Record Schema
Layer 1 - Notice Record Schema.
The PII Principal's private record of a notice without digital identifiers, also called a ‘minimum viable record notice’. This record is un-anchored and used for contextual purposes when it does not contain an ANCR Record ID, in the ancr record id field.
Layer 2 – Private Notice Record Micro-Data
The meta data that can, and must be collected with the notice record to make a digital record of the notice record
Is kept private and not directly accessible, exposed or made public.
The PII Principal private record collects personal data specific to the use of the notice
Layer 3 - A Proof of Notice (PoN) record is generated
A secured Anchored Notice Record generated upon engagement with a notice to demonstrate that the PII Principal is informed. Not an opt-in or opt-out check box – which is linked to a notice. But check-box to confirm a notice clause is read, with a button on the notice dialogue that generates a record and receipt when used by the PII Principal
A proof of notice record can then be used by processing stakeholders to generate subsequent (serialized) linked notice, notification and disclosure records pertinent to the context of notice.
Personal identifiers and attributes are encrypted, secured, verified and validated by linking to the private notice record.
Anchor | ||||
---|---|---|---|---|
|
These are the schema elements that are used to generate a static Notice Record and does not contain any PII, or digital identifiers.
...
Field Cat Name | Name | Object Description | Presence Requirement |
---|---|---|---|
PII Controller Identity | Object | _ | Required |
Presented Name of Service Provider | name of service. E.g. Microsoft | May | |
PII Controller Name | Company/organization name | MUST | |
PII Controller address | _ | MUST | |
PII Controller contact email | correspondence email | MUST | |
PII Controller jurisdiction legal reference | PII Controller Operating Privacy Law | MUST | |
PII Controller Phone | The general correspondence phone number | SHOULD | |
PII Controller Website | URL of website (or link to controller application) | MUST | |
PII Controller Certificate | A capture Website SSL | OPTIONAL | |
Privacy Contact Point Location | pcpL | Direct link to security and/or privacy contact point | MUST |
Privacy Contact Point Types (pcpT) | Object | Must have at least one field for the PCP object | MUST |
PCP_Profile | Privacy Access Point Profile | ** | |
PCP_InPerson | In-person access to privacy contact | ** | |
PCP_Email | PAP email | ** | |
PCP_Phone | Privacy access phone | ** | |
PCP _PIP_URI | privacy info access point, URI | ** | |
PCP_Form | Privacy access form URI | ** | |
PCP_Bot | privacy bot, URI | ** | |
PCP_CoP | code of practice certificate, URI of public directory with pub-key | ** | |
PCP_Other | Other | ** | |
PCP Policy | pcpp | privacy policy, URI with standard consent label clauses | MUST |
Anchor | ||||
---|---|---|---|---|
|
These fields can be asserted by the PII Principle to extend the functionality beyond the transparency TPI’s specified, on the PII Principal’s behalf.
These private record fields are separated from the Proof of Notice schema, as these are kept and controlled by the PII Principal and are used to provide defaults.
Anchor | ||||
---|---|---|---|---|
|
This is the data source for consented records of processing that is directed (and securely) verified by the PII Principal, with secure localized data source and device.
Record Field Name | Field Description | Verifier/Validator |
---|---|---|
Schema version | A number used by the PII Principal to track the PII Controller Record | Verifier |
Anchor Notice Record id # | An identifier unique to the controller, used to identify the legal entity accountable for relying parties and affiliated services | Verifier |
Date/Time | The date and time a notice was read by PII Principal | Validator |
Notice Presentation method | Notice presentation delivery method is also known as a user-interface presentation_Type | Validator |
Notice Location | URL, physical address, or regional location, the notice was presented to the PII Principal | Verifier |
Notice Legal Justification | One of the six legal justifications(PII Cntrl’r, ISO/IEC, GDPR, C108+) | Validator |
PII Principal Legal Location | Refers the privacy rules in the local context | Validator |
Device Type Identifier | device identifier or fingerprint used to verify the physical method of delivery -.e.g. sign, mobile phone number, desktop computer | Verifier |
PII Principal Private/Public - Key Pair | The cryptographic key pair used to sign and encrypt fields in a consent record | Verifier |
Anchor | ||||
---|---|---|---|---|
|
For consented digital identity management, a proof of Notice Record is used as an alternative to terms and conditions, to mitigate high privacy risks associated with digital identifier surveillance and profiling. Terms of use refer to a contract-based policies for the governance of identifiers and credentials.
...
Note: The ANCR Notice Record ID is used to create and link new receipts, thereby ensuring the providence of the PII Principal’s control of the ANCR Record.
Anchor | ||||
---|---|---|---|---|
|
The Proof of Notice Record builds upon the PII Controller Identity fields and contact fields, with PII Controller Identifiers used to digitally track the state of privacy .
...
A notice that is used to generate granular consent receipts using standards that specify purpose in the same way. Those generated with the same schema based can be compared to automate notice for operational transparency over changes to privacy state.
A 2FN is used to produce a dual record and receipt upon engaging with a standardized notice with access to administrator-level privacy rights from the notice, prior to processing with consent.
The consent receipts produced from a 2FN can be compared independently to measure the difference in the active state and status of privacy, to automatically produce a notification based on the difference in state.
Differential Transparency, produced with a tactile signal, or layer1 notice indicator, standardized with machine readable data privacy vocabulary (i.e., concentric and synchronic transparency).
...
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The ANCR Record represents the online privacy notice control record that is used to assess conformance with privacy expectations using controls and structure for consent from ISO/IEC 29184 Online Privacy Notice and Consent, which sets out the rules used to secure, protect and safeguard personal data:
...
Three (3) layers of the notice record schema is presented in this specification, with each layer building on the first as described in the Introduction.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The ANCR record identifier has specific security requirements and considerations since it can be used by the PII Principal as an identifier for and by a PII Controller. The ANCR Notice Record can be extended to additional stakeholders with a public key. Consent records and receipts created by the PII Principal are sensitive, confidential, and secured for PII Principal ownership and control. Evidence of consent is required to access these attributes for producing or using verifiable (micro) credentials the PII Principal can validate.
The protocol requires that the ANCR Record be referenced each time a directed, or altruistic consent is generated, or when decentralized data governance is required. This is done in order to verify the PII Controller Identity and ensure sufficient (any) security for the privacy state that is, and can then be, expected by the PII Principal.
...
Security Assurance
The transparency performance indicators (TPIs) provide transparency and security assurance to the PII Controller before the Controller processes personal information.
...
Blinded Identity Taxonomy (BiT)
PII field security measure that is used to blind attributes that are identifiable, for example, the attributes presented in ISO/IEC 29100 section 4.4.2
A BiT attribute is encrypted with the PII Principals private key- so as not be usable in any data set without the corresponding authority required to unencrypt the field for a specified purpose and treatment.
In this specification BIT is used by the PII Principle to encrypt and blind the ANCR record ID field. Which is in the private notice record, the pseudonymized identifier generated/provided by the PII Principals (client security protocol)
Pseudonymized Identifier
The ANCR record id refers to the PII Controller legal identity captured with a notice record, and once a notice record is collected it can be signed to become added to digital wallet (or pod), it can be signed to become a micro-credential, and used to communicate to the PII Controller, to manage rights and control processing of digital identifiers and associated information.
Conceptually, the ANCR Id is a reverse use cookie, in that it is used by the PII Principle to remember the privacy state and track the PII Controller through different service environments, domains and jurisdictions.
Verifiable Private Notice Record signed to be a micro-credential
The PII Principal as the holder of the notice record can use it to a verify the presentation a PII Controller Identity
Holders of a signed notice record (proof of notice) can generate a verifiable presentation of this proof by;
signing a copy of the notice-record
(transforms record into a micro-credential)
exchanging this with the other stakeholder (PII Principle or Controller) as a signed consent receipt in order to tokenize the exchange of attribute level private record data on a per processing session basis.
(W3C Verified Credential Data Model, www.w3.org/TR/vc-data-model/#what-is-a-verifiable-credential)
Differential Transparency – operational transparency signaling
Operational transparency – notice record ‘trust’ protocol for active state technical object. Achieved by comparing the expected privacy state (purpose and credential) each technical session to authorize an instance of processing, whereby a notification signal is generated only if there has been a change in the expected, and known active state of privacy.
Differential Transparency (DT) is a contextual transparency enhancing notification protocol that uses record serialization in order to sequence data control points. Used to maintain a shared understanding of privacy and conversely security expectations.
Implemented by comparing than Anchored Notice Record with a newly minted anchored consent notice receipt. To detect if there has been a change in this expected state. Achieved through self-asserted changes, or through monitoring authoritative public data sources.
Differential Transparency is used by the PII Principal to automate the verification of trust, monitoring the active state of the PII Controller Legal identity and technical security performance. Prior to authorizing data processing activities by signing a consent notice receipt.
Utilizing the Transparency Performance Indicator’s in the introduction of this specification to transform a consent receipt into a consent token. (Individual authority and providence default controls to implement rights)
Automating Operational Transparency
Human centric notice protocol to keep a record of controllers and context of processing, for each session/interaction, so that these contextual records, controlled owned and secured by the PII Principal, can remember the active state of privacy and verify the PII Control and Privacy state without interrupting the service-user flow.
Notice Signal Layer: For operational transparency at a glance using digital signaling to indicate with concentric labeling what is expected, and what is not.
Case Study: Differential Privacy as a mechanism for Data Control
For discussion with security and privacy community. Like digital identity management, how sovereign data control can be measured is by identifying which PII Stakeholder is in control of the personal data and personal data process; who benefits from processing personal data; and how dynamic are the personal data controls? The analysis results indicate which stakeholder can authorise the use of the tool, and for which purpose(s)
Differential Privacy [ not to be confused with Differential Transparency]
A method to produce noise in a personal data profile, and data sets so that the output cannot be used as conclusive evidence, or used to attack systems. A safeguard that is described as a way to provide a ‘buffer’ to protect the PII Principal from harms.
A relevant topic defined in the ANCR Record used in a different context, not as a tool used by a PII Controller, but as a control for PII Principal to use when engaging with PII Controller Services,
Synthetic personal data can be generated from the Anchored Private Notice record and linked eConsent receipts with the use of verified micro-credentialing
These records and receipts can be used to provide safe environments to model future personal data, anonymize PII Principles own data before use, provide statistical data to services and trusts, safeguard Altruistic Consent (see concentric data types) can be employed to open certain data types for a specific purpose to help people and society.
Differential privacy can be used to evaluate structural deficiencies in existing data models (online profiles), and invalidate data sets through access rights which are near universal.
Differential privacy tools can generate synthetic personal data to increase the size of a personal data set, to employ machine learning systems on behalf of the PII Principal to diffuse data in order to address privacy harms which exists with use of big data, with out transparency or consent. Like any other tool it can be used in good and bad ways.
...
Non-national standards are used in this specification to mediate transborder data controls and policies and provide extra-territorial governance. National standards are limited in terms of governance policy.
This specification advocates for using international standards for measuring adequacy, mapping the rules, vocabulary and semantics presented in this specification to the national standards and regional privacy regulation.
eConsent is a security access control that is required to make a record that a PII Principal signs by engaging with a Two Factor Notice (2FN)
A code of conduct in this specification refers to regulation and/or Regulator approved set of rules, which are enforceable. As oppose to a transparency code of practice, which refers to a certifiable best practice used to implement a code of conduct, for example, requiring the use of two factor notice.
ISO/IEC Security and Privacy Techniques Framework
ISO/IEC 29100 - Security and Privacy schema, information structure
Mature, mutually exclusive, and collectively exhaustive framework used to identify security and privacy stakeholder roles in data governance
The ANCR record is specified to propose a standard method, to secure records that can be self-asserted by people to control, use, and trust online.
It is envisioned that the only data ever seen by the PII Principal and accessible only via verification are those specifically delegated as such by the PII Principal.
PII Controller uses privacy stakeholders as a mutually inclusive and collectively exhaustive technology governance framework for cross-border identifier exchanges
All data processing is required to be transparent by default and provide notice, notifications, and disclosures, all of which can be automated with this specification.
Transparency defaults are provided in relation to adequacy with international best practice in order to be interoperable with EU-GDPR and Convention 108 to operationalize transparency with enforcement.
Every non-person entity, or delegate, processing personal data is a PII Controller. An unidentified PII Controller, is a 3rd Party, and requires PII Controller Category with a scope of authority for the context of processing personal data.
The PII Controller can have many roles, according to context of processing (e.g., Joint Controller, PII Processor, and PII-Sub-processor. 3rd Party
3rd Party Recipients,
All 3rd parties MUST be identified as a PII Controller
A stakeholder without a Controller ID, or role in direct purpose of processing is required to provide the legitimate legal justification and specified purpose.
Monitoring of non-identified controllers should include using a different legal justification, without authority could further be analyzed for mis-information and fraud detection.
Assurances that 3rd parties, can also be identified as a PII Controller.
Assurances that all PII Joint Controllers, Processors or Sub-Processors, are accountable and identifiable as a PII Controller.
PII Controller Identity credential (is required to produce a consent notice receipt for verification, validation and authorisation by the PII Principle.
There are interoperable with IAM system roles 0 Holder, Verifier, and Issuer in Self Sovereign Identifiers (SSIs) and Distributed Identifiers (DIDs) can be directly mapped to PII Controller roles.
ANCR notice records can be generated by the PII Principal and notarized by a 3rd Party authority, on behalf of the PII Principal, for use independently of a PII Controller.
Differential Privacy
An editorial use case – in which the questions is asked? who controls the choice to use differential privacy? Is it the PII Principal or the PII Controller, or both? Presented in the context that the PII Principal is in control of record and the choice to use the method. As opposed to the PII Controller being in control and deciding when to use this without proof in the form of electronic notice and consent.
To address a security gap – dis-empowering 3rd Party data processing without consent, the creation of an identifier for system access and management, any type of tracking, is referred to as profiling, which constitutes a high-risk privacy activity.
To mitigate the substantial risks of digital identifier management technologies, any secondary use of the data – including ‘Differential Privacy’ must a) be transparent (specified with the consent information structure) and b) consented with a proof of notice receipt for evidence of consent,
This means processing is specific to purpose of the consent (Note: unless derogated in law which is also provided in notice and a represented in a code of practice, for the service.
Best Practice - Consent for the service to re-use a PII Principal profile for a secondary purpose, is a specific explicit consent, not an opt-in, or out governance control.
Trustworthy ID
...
Trustworthy identity requires notice and transparency defaults, or else it is very difficult for people trust the use of digital identity technology. As oppose to every jurisdiction and organisation deciding what is transparent, with T&C’s services just change without notice.
The defaults for operational transparency are presented in this industry publication “Adequacy of Identity Governance Transparency” with 23 default transparency for notice, notification and disclosures, which are required for a ZPN code of conduct.4
...
eConsent is a critical and missing component in the generation of identifiers the use of PII for big-data, machine learning, including differential privacy is arguably a breach of PII and clearly un-ethical as it violates the privacy expectations of the Individual, creating records people don’t control, and can’t see when they are used.
...
In this regard, ethical use of differential privacy would require a record of consent to identify and profile and personal identity, then, an explicit consent for the purpose of use.
In this way PII Principals can be secure, safeguarded, and empower their choices through the control of who benefits from their personal and why.
...
For an anchored notice record, it is recommended that PII Principal identifying information never be included in a record without being secured at the attribute level in the record. When a eConsent receipt is provided, all PII Principal identifiers MUST be blinded except for the legitimate required stakeholders.
...
Anchor | ||||
---|---|---|---|---|
|
The Anchored Notice record can be extended with the standardized consent record information structure by using three (3) extensions.
Anchor | ||||
---|---|---|---|---|
|
The concentric notice label is used to identify the default legal justification for processing which is used for the default data processing practices.
...
The extension is written for the PII Controller, to enable the anchored record to be used as a verifiable data source for operationalizing a channel (exchange) where PII Principals can advertise a consent grant to the controller. (see Appendix 1 )
Anchor | ||||
---|---|---|---|---|
|
Extension 2 is focused on data treatment and rights of the purpose specified in Extension1. This extension uses some of the ISO/IEC 27560 schema, as well as the W3C Data Privacy Vocabulary, and some additional elements regarding delegation, cross-border adequacy, definition of data privacy rights data controls.
Anchor | ||||
---|---|---|---|---|
|
Extending the security code of conduct, purpose specification (Extension 1) and data treatment sections (Extension2) with a transparency code of practice.
...
This can be further extended (Internationally) where the filed data, categories, vocabulary, ontology and record formats are specified (to be hosted by a non-national regulatory body) to enable decentralized data exchange governance at a global scale.
[Note: The appendices introduce the new elements found in this specification, as well as a schema map for interoperability with ISO/IEC 27560 for contribution.]
Anchor | ||||
---|---|---|---|---|
|
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 +
...
Click through to no cost license standards.iso.org/ittf/PubliclyAvailableStandards/c045123_ ISO_IEC_29100_2011.zip
Annex (WiP to v8.9.9)
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
This ANCR Record uses a record data type for MySQL as the example data type for records, unlike consent notice receipt tokens, which use jason-ld web-token data types. (PII ConISO/IEC 28184 Annex B: Consent [Notice] Receipt)
The Notice Record uses data types for a record in a database, this maps to MySQL, unlike the consent receipt which uses JSON token data types.
Anchor | ||||
---|---|---|---|---|
|
Attribute Name
data types, for attribute … machine readable element
Array [attribute type]: a data type that defines a structure that holds several data items or elements of the same data type. When you want to store many pieces of data that are related and have the same data type, it is often better to use an array instead of many separate variables (e.g. array[text], array[numeric], etc.).
Binary:a data type that defines a binary code signal, a series of electrical pulses representing numbers, characters, and performed operations. Based on a binary number system, each digit position represents a power of two (e.g., 4, 8, 16, etc.). In binary code, a set of four binary digits or bits represents each decimal number (0 to 9). Each digit only has two possible states: off and on (usually symbolised by 0 and 1). Combining basic Boolean algebraic operations on binary numbers makes it possible to represent each of the four fundamental arithmetic operations of addition, subtraction, multiplication, and division.
Boolean:a data type where the data only has two possible variables: true or false. In computer science, Boolean is an identification classifier for working out logical truth values and algebraic variables.
DateTime: a data type that defines the number of seconds or clock ticks that have elapsed since the defined epoch for that computer or platform. Common formats (see 'Format Overlay') include dates (e.g., YYYY-MM-DD), times (e.g., hh:mm:ss), dates and times concatenated (e.g., YYYY-MM-DDThh:mm:ss.sss+zz:zz), and durations (e.g., PnYnMnD).
Document Reference
Element Reference
Field Category
Field Description
Field Label
Numeric: a data type that defines anything of, relating to, or containing numbers. The numbering system consists of ten different digits: 0, 1, 2, 3, 4, 5, 6, 7, 8,and 9.
Reference: a data type that defines a self-addressing identifier (SAID) that references a set of attributes through its associated parent. SAID is an identifier that is deterministically generated from and embedded in the content it identifies, making it and its data mutually tamper-evident.
Text: a data type that defines a human-readable sequence of characters and the words they form, subsequently encoded into computer-readable formats such as ASCII.
Anchor | ||||
---|---|---|---|---|
|
Notice Record Example Field Category | Label | Data Type | Attribute name | Field Description | Presence Requirement | TPI 1 Cntrl Id Present | TPI 2 Accessibility Example | Security TPI 3: Digital Context Integrity | ISO/IEC 29100-Ref | ISO/IEC 29184-Ref | GDPR Ref | Conv 108 Ref |
---|---|---|---|---|---|---|---|---|---|---|---|---|
PII Controller Identity | Controller ID Object | String | controller_id_object | _ | Required | Security key or Cert | 4.2.2 | 5.3.4 | ||||
Presented Name of Service Provider | String | presented_name_of_service_provider | name of service, e.g. Microsoft | May | ||||||||
PII Controller Name | String | piiController_name | Company/organization name | MUST | ||||||||
PII Controller address | String | piiController_address | _ | MUST | ||||||||
PII Controller contact email | Varchar(n) | piiController_contact_email | correspondence email | MUST | ||||||||
PII Controller legal location | String | piiController_legal_loc | PII Controller Operating Privacy Law | MUST | ||||||||
PII Controller Phone | Char | piiController_phone | The general correspondence phone number | SHOULD | Issuer Statement | |||||||
PII Controller Website | Varchar | piiController_www | URL of website (or link to controller application) | MUST | ||||||||
PII Controller Certificate | BLOB | piiController_certificate | A capture Website SSL | OPTIONAL | ||||||||
Privacy Contact Point Location | VarChar(max) | pcpL | MUST | Public Key base64 (human readable - kind of...) | ||||||||
Privacy Contact Point Types (pcpT) | Object | pcpType | ||||||||||
Must have at least one field for the PCP object | MUST | |||||||||||
PCP-Profile | String | pcpProfile | Privacy Access Point Profile | ** | ||||||||
PCP-InPerson | String | pcpInperson | In-person access to privacy contact | ** | CRL and OSCP endpoints | |||||||
PCP-Email | Varchar | pcpEmail | PAP email | ** | ||||||||
PCP-Phone | char | pcpPhone | Privacy access phone | ** | ||||||||
PCP -PIP- URI | Varchar | pcpPip_uri | privacy info access point, URI | ** | ||||||||
PCP-Form | Varchar | pcpForm | Privacy access form URI | ** | ||||||||
PCP-Bot | String | pcpBot | privacy bot, URI | ** | ||||||||
PCP-CoP | String | pcpCop-loc | code of practice certificate, URI of public directory with pub-key | ** | ||||||||
PCP-Other | string | pcp_other | Other | ** | ||||||||
PCP Policy | pcpp | string | pcpp | privacy policy, URI with standard consent label clauses | MUST | |||||||
Anchored Notice Record Field Categories | Name | Type | Attribute Name | Description | Presence | |||||||
ANCR Record ID | string | ancr_id | Blinded identifier secret to the PII Principal | Required | ||||||||
Schema version | string | V x.xx.x schema_version | ||||||||||
Timestamp | DATETIME | time_stamp | _the time and date when the ANCR record was created | Required | ||||||||
Legal Justification | string | legal_justiication | One of six legal justifications used for processing personal data | |||||||||
Notice Record | Object labels | VarChar(max) | notice_record | |||||||||
Notice Type | string | notice_type | Notice, notification, disclosure | Required | ||||||||
Notice method | string | notice_method | Link/URL to the UI that was used to present the notice e.g. website home page | MUST | ||||||||
-digital-Notice-location | string | digital_notice_location | Notice location e.g. IP address | MUST | ||||||||
location Certificate | BLOB | location_certificate | MAY | |||||||||
Notice Language | string | notice_language | The language notice provided in | MUST | ||||||||
Notice Text File | string | notice_text_file | URL and/or Hashlink for the notice text | MUST | ||||||||
Notice text | string | notice_text | The capture of a copy of the notification text | MUST | ||||||||
Notified legal Justification | string | notice_legal_justification | Implied or explicit notified legal justification based on the text of a notice and its context | MUST | ||||||||
Concentric Notice Label Type | string | cnl | a label that is mapped to legal justifications, rights and controls that can be provided by default, for a specified purpose | SHALL | 5.3.12 | |||||||
Not-Consent | Refers to laws and democratic consensus (legitimate Interest, Legal Obligation, Public Interest & Vital Interest) | |||||||||||
Private Anchored Notice Record Field Category | Label | Type | Attribute name | Field Name | Required/Optional | |||||||
Private Record | schema version # | V | Optional (unless shared or used further) | |||||||||
Anchor Notice Record id # | Int | Ancr_id | MUST | |||||||||
Date/Time | DEATETIME | Required | ||||||||||
Notice Collection method | optional | |||||||||||
Notice Collection Location | VarChar(max) | required | ||||||||||
Notice Legal Justification | VarChar(max) | |||||||||||
PII Principal Legal Location | VarChar(max) | ploc | ||||||||||
Device ID | NVarChar (max) | |||||||||||
PII Principal Private- Key | VarChar(max) |
Anchor | ||||
---|---|---|---|---|
|
The object of the ANCR record is to enable operational transparency. A concentric notice type is used to provide a human centric label to a record or a receipt.
...
Referencing the corresponding ISO/IEC 29184 control to enhance interoperability of operational transparency. Interoperability that is realized through the extension of transparency with records of processing to establish and maintain a shared understanding of security and privacy risks. Affording people choice which mitigate risks and transfer liability.
Anchor | ||||
---|---|---|---|---|
|
These are mapped here to provide a set of operational transparency defaults to set and support privacy as expected by the PII Principal. Expectations that provide a privacy notice starting point, where PII Principal and PII Controller can gain a shared understanding, or where a PII Principal can assert a legal justification for processing to access privacy rights.
...
Concentric digital transparency is a design principle of electronic Notice and evidence of consent. The outcomes are for a shared/concentric understanding of a relationship and the purpose of digital interaction, the data control impact, and associated risks centric to the PII Principal.
Anchor | ||||
---|---|---|---|---|
|
Concentric Notice Types are you to create a digital notice label to enable that can be applied to digital processing context which are understood from a human centric perspective.
...
Concentric Notice Type | Description | Legal Justification | Privacy Rights | Legal Ref |
---|---|---|---|---|
Non-Operational Notice N/O | Insufficient notice/security information for digital privacy | Not compliant with any if unable to determine or confirm Controller, or contact | Withdraw, Object, Restrict, | 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 | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
(For the latest draft of this Extension, or to get involved in working on it, visit ANCR WG‑Kantara Wiki ANCR - Extension 1 – ISO/IEC 27560 - Consent record information structure)
SUMMARY
An Anchored Notice Record is specified to capture the data control relationship between the PII Principal and the PII Controller, using the international ISO/IEC 29100 standard.
...
This purpose schema is specified for the PII Controller, and can also be used by a Privacy Stakeholder as a record to assess a purpose
The ANCR protocol is for generating a Record of Notice containing Controller ID and contact. This is always the event, and in this regard, the ancr_id maps to event id. To this extend event schema section is not required.
The ANCR record is specified to ISO/IEC 29100, in which the ‘privacy and security stakeholders’ are defined. In the context of the ANCR record, this means that any role (other than PII Principal) has a Controller ID, relative to the PII Principal, in addition to the role for the specific context of processing (e.g., processor, recipient, third party, which represent the processing role and activity relative to the ANCR record). This enables liability and risks to be delegated and transferred amongst the stakeholders specified to a per‑process instance. As a result, the party_ID schema is incorporated in the ANCR Record ID, which is specific to a PII Controller, not a service or purpose.
Introduction
Consent receipt, and the associated record information structure, were conceived as a record that captures the notice of a PII Controller, or the notice context of the PII Principal.
...
In this regard, ISO/IEC27560 is specified with the utility of the consent receipt in mind, which is to specify the purpose of personal data use and risks so that people can make informed choices and control personal data.
Schema Interoperability
The ANCR protocol is for generating a Record of Notice containing Controller ID and contact. This is always the schema ‘event’ indicator, in this regard the ancr_id field maps to and replaces the event id field in ISO/IEC 27560 WD 5 consent record information structure.
...
The ANCR record can itself be extended in to a Controller Credential When the ANCR record is used in a consent receipt flow it can also be used to. ToiP-Controller Credential — wiki.trustoverip.org/pages/viewpage.action?pageId=27722576
Schema Mapping
The following mapping of the ANCR record schema conforms to instructions provided in ISO/IEC 27560. To this extent, and in accordance with ISO/IEC 27560 Art 6.2.3, this annex publishes the ANCR Record Schema’s at Kantara and hosted at the Human Colossus Foundation, for the Global Privacy Rights, public benefit Initiative.
...
Codes of practice can be approved and monitored, and can combine multiple purposes together for an expected code of practice. A “Purpose Bundles” operated with a code practice can be approved and to operationalize privacy.
Anchored Record Schema ‘Structure’ Sections
In addition to the consent receipt schema, the ANCR record schema provides a protocol for its operation.
...
The Anchored Record Schema ‘Structure’ Sections refer to ISO/IEC 27560 line – 362 WD4, where it calls out the need to reference the schema(s) information structure used, in addition to demonstrating the capacity to maintain documentation for its correct technical implementation. - and conformance to the requirements specified in the ISO/IEC 27560 documents.
Anchor | ||||
---|---|---|---|---|
|
In summary, elements from ISO/IEC 27560 frame the data treatment elements are found in Extension 3 in addition to [ ]
Anchor | ||||
---|---|---|---|---|
|
The ANCR record is specified in this information structure according to legally defined code of conduct, each element that is required is referenced to standards and legislation which constitute the code of conduct for operational transparency trustworthy id protocol.
The legal code of conduct is extended by codes of practice which are often recognized as certifications and represented by certificates and certifications.
Anchor | ||||
---|---|---|---|---|
|
Terms, definitions, filed data, record examples, machine readable privacy vocabulary, used to generate notice, notifications, and disclosures are provided here.
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 – practice what preaching by making spec structural human centric | ||
8.8.4.0.1 | 2022-09-18 | Content edited for grammar, consistency, clarity |
...