ANCR Consent Token: Mirrored Record Information Structure v0.7

Version: 0.7

Document Date: Dec 6, 2023

Editor(s): Mark Lizar

Produced by: ANCR-WG

Status: WG Draft v0.7 (updated from Sept 2022-Archive-Next version Feb-March 2024)

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 requires that the identity of the controller, the legal justification, governance framework and jurisdiction be presented prior to data processing. The AuthC Protocol utilises this mirrored record and receipt standard record information structure, now standardized in tprocessing scales human context and understanding into systems. Transparency over data control ensures a consent by default methodology enabling individuals to regulate surveillance. Brining together two very mature regulatory instruments, standard for records, and compliance for receipts, with a new technical standard of digital credentials.

much like a transaction receipts, bank accounts and currency is regulated and tracked today.

Abstract:

Currently, when online service are involved, the PII Principal (referred to as the Data Subject or Individual in regulation) is unable to see who is in control of processing their personal data before it is processed, shared or disclosed. As a result consent online is not valid.

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

IPR Option:

This specification is open under Kantara Initiative Patent & Copyright: Reciprocal Royalty Free with Opt-out to Reasonable And Nondiscriminatory (RAND).

Suggested Citation:

ANCR Specification v0.7

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.

Open

-

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

Contents

Preface

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 security and privacy framework for consented data access, control and transfer adequacy proposes 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.

The Legal Rules Codified

In this framework, the privacy, notice and consent, transparency code of conduct is the law that is developed into open source code, and required to access un-linked data silo’s, across jurisdictional and technically -networked disparate systems.

   digital privacy transparency with

[Anonymous] Consent by Default: the common mode of governance

• Digital Consent is required by default, an individual is notified if PII is needed, for what purpose, and what permissions are required.

• Privacy law as derived and matured from principle, in civil and common law is in the context of the legitimate interests of the individual, it’s most primary tenant being that of openness, proportionate and fair transparency, required to secure ones self and the autonomy to make choices.

• An easy way to understand, develop and deploy digital privacy is with consent by default, code as law, digital transparency

• Digital privacy – as a universal standard requires a common digital transparency standard, and in this way human consent, understanding, control and choice can be used to govern the flows of information,  

o   Concentric Transparency

§  From the context of consent, a notice, notification or disclosure is presented to the individual, to inform them if there is surveillance which uses a different legal justification, other than consent.

§  Interaction with this transparency gateway, is what is recorded, and what is provided to the individual as a knowledge receipt

Purpose Defined

6 Legal Categories of Authority

Consent

Contract

Public Interest

Best Interest

Legal Obligation

Legitimate Interest

Types of Consent

a.     Types of Consent

Expressed

Implicit

Explicit

Directed

Altruistic

Concentric Notice Labels

It is very difficult for stakeholders to know what law, rules and obligations apply in any given context, to address this, Concentric Notice Labels map the legal justification, and the type of consent to rights, and digital rights controls that reduce liability and mitigate risks.

ANCR Record

An ANCR Record, is the initial digital identity rep relationship record in a linked chain of records, in which a record of a processing activity captures a; notice, notification or disclosure, in a standard record, using data privacy vocabulary. The record is a snapshot of the state of digital privacy transparency provided by a PII Controller, or a PII Controller’s delegate processor.

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.

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

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.

Notice Record References

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

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

Normative References

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

• ISO/IEC 29100:2011 Security and privacy techniques

• ISO/IEC 29184 Online privacy notices and consent,

• Fair Information Practice Principles (FTC) foundational principles

Non-Normative References

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

Kantara Initiative Consent Receipt v1.1

Additive Reference

• General Data Protection Regulation (GDPR)

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

  • PIPEDA – Individual, Meaningful Consent,

Notations and Abbreviations

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

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

ANCR WG; Advanced Notice and Consent Receipt Work Group

ANCR Record: Anchored Notice Record and Consent Receipt Record

Conv. 108+: Council of Europe Convention 108 +

IRM: Identifier Relationship Management

ISO/IEC International Organization for Standardization / International Electrotechnical Commission

FIPP Fair Information Practice Principles

PII Personally Identifiable Information

Object – a field object

Array – an array of field objects

Terms and definitions

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.

Concentric Notice Types

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

Notice

Adhering to the openness, transparency and notice principle means:

1.  

2. Providing PII principals with clear and easily accessible information about the PII controller’s policies, procedures and practices with respect to the processing of PII;

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

4.  

5. - disclosing the choices and means offered by the PII controller to PII principals for the purposes of limiting the processing of, and for accessing, correcting and removing their information; and

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

   2. [ISO/IWC 29100]

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

1. [Source ISO/IEC 29184]

2.  

[GDPR Rec.58]

[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

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]

Notice Record

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

Privacy Principles

1. Consent and choice

2. Purpose legitimacy and specification

3. Collection limitation

4. Data minimization

5. Use, retention and disclosure limitation

6. Accuracy and quality

7. Openness, transparency and notice

8. Individual participation and access

9. Accountability

10. Information security

11. Privacy compliance

Proof of Notice

1.  

   1. [Source ISO/IEC 29184

Personally Identifiable Information (PII)

PII Principal, Data Subject or (Individual)

PII Controller

PII Joint Controller

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

PII Processor

PII Sub-Processor

An additional field to indicate a delegated processor.

Processing of PII

Privacy Stakeholder

Security

Third Party

Notice Record Information Structure

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.

1. Base Notice Record Schema. This is a private Un-Anchored Notice Access Record

2. Personal Notice Data is added to the private record

   1. PII Principal private record is extended with personal data specific to use of notice

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

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

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

Proof of Notice Record Schema

A consent receipt, when provisioned with is 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.

Private Notice Record Schema

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

Notice Record Security

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

Conclusion –

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

Notice Record Extensions

Extension 1

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)

Extension 2

Once specified, the W3C Data Privacy Vocabulary is used to specify the treatment of personal data.

Extension 3

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

Acknowledgements

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

• The ISO/IEC 27560 committee

• Standards Council of Canada

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

References

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

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

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

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

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

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

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

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

Two Factor Notice (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.

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

Open

Concentric Notice Types

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

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

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

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

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

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

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

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

Mapping Legal Justifications to Concentric Notice Types

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

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

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

Concentric Notice Types mapped to Privacy Rights

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

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

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

Annex C: ANCR Record Extension Protocol

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. 

Privacy State (tentative)

• 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

Privacy State Notification Types (tentative)

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

    •  

Transparency Status

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

Transparency Status Types

• Not-Available

• In-Active

• Active

• Active & Operational

• Active & Dynamic

Annex C.1 Purpose Specification with 27560 Consent Record Information Structure

SUMMARY

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

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

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

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

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

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

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

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

• 7560 Notes
  
  

• The ANCR protocol is for generating a record of notice containing controller id and contact, this is always the event, in this regard the ancr_id maps to event id. To this extend event schema section is not required

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

•  

Introduction

Consent receipt – and record info structure – was conceived as a record which capture the notice of a PII Controller, or the notice context of the PII Principal.

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

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

Schema Interoperability

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

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

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

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

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

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

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

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

Schema Mapping

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

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

Section1

Section 2 Purpose Specification is followed by

Section 3: Data Treatment and

Section: 4 Code of practice

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

Anchored Record Schema ‘Structure’ Sections

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

Section 1: Header: Proof of Notice

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

Section 3: Treatment Specification, W3C DPV

Section 4: Code of Practice Profiles

Section 5: Field Data Sources

These refer to 27560 line – 362 WD4, where it calls out the need to reference the schema(s) information structure used, in addition to demonstrating the capacity to maintain documentation for its correct technical implementation. - and conformance to the requirements specified in the 27560 documents.

ANCR to 27560 Schema (in draft for v08.6 - 0.9)

Terms (wip)

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 (3^rd 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.

Revision history

¹

^I