AuthC Protocol

Authorization from Consent

Version: 0.8.9.3

Document Updated: Nov 22

Status:

The ANCR record objective is to provide operational transparency for 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) 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 record 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 digital 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.

In this specification and proposed standard the term “PII Principal” is used interchangeably with Data Subject and “Individual”.

 

IPR Option:

This ANCR Record Specification is available for use for public benefit licensing @0PN C.I.C and the open schema available @Human Colossus, and is specified under a Reasonable and Non‑Discriminatory (RAND) agreement at the Kantara Initiative for submission to ISO/IEC SC 27 WG 5

Published for use as public infrastructure through code of conduct and practice in industry and trade certification bodies.

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

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.

Kantara is known around the world for incubating innovative concepts, operating Trust Frameworks to assure digital identity and privacy service providers, and developing community-led best practices and specifications. Its efforts are acknowledged by OECD ITAC, UNCITRAL, ISO SC27, other consortia and governments around the world. 'Nurture, Develop, Operate' captures the rhythm of Kantara in consolidating an inclusive, equitable digital economy offering value and benefit to all.

Every publication, in every domain, is capable of improvement. Kantara welcomes and values your contribution through membership, sponsorship and active participation in the working group that produced this and participation in all our endeavors so that Kantara can reflect its value back to you and your organization.

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

Contents

 

Introduction

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.

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

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

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

3 Layers to the ANCR Record Schema

Layer 1 - Notice Record Schema.

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

Layer 2 – Private Notice Record Micro-Data

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

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

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

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

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

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

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

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

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

 

Field Cat Name

Name

Object Description

Presence Requirement

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

 

Private Notice Record Profile

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

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

Private Notice Record Schema

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

Record Field Name

Field Description

Verifier/Validator

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

 

Proof of Notice Record

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

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

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

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

  1. Legal justification,

  2. Purpose of profiling

  3. Localization/Scope of disclosures & identification of 3rd Party Controllers

  4. Privacy/Security and Surveillance Risks

The 2FN can provides standardized options to engage with the notice, notification, or disclosure. 2FN is typically implemented with a software interface in which, at a minimum, these three options are used by default (and easily extended with a code of practice):3

  1. By default, the notice can be ignored.

  2. PII Principal provides an informed consent

  3. Privacy rights and control options are presented and, depending on the Individual’s age, an accessibility context can be further simplified to the right to be heard and make a complaint, in specific context of processing personal data notified.

Note: Option C refers to GDPR and Convention 108+ legal instruments, neither of which requires a digital identifier, a user account, or any other personally identifying information to access.

An ANCR Notice Record and a Consent Receipt, referred to as a mirrored (or twinned) record of a processing activity, is generated when the PII Principal engages with a notice dialogue and completes a notification sequence by selecting one of the 2FN options; and, by default, when a notice or notification is ignored. When an ‘I consent’ option is selected an electronic notice record and evidence of consent receipt is generated, for the corresponding eConsent.

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.

Proof of Notice Record Schema

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

The 2FN produces a network event, presenting information that is needed to produce an evidential record, which a PII Principal can then use independently. A micro-credential used to aggregate operational transparency information, access privacy state and rights information, or to implement personal data controls (that are required for a grant of consent grants to a system to implement controls and permissions in systems for collection, capture, portability and access to private data profiles)

Field Cat

Field Name

Description

Presence

Field Cat

Field Name

Description

Presence

ANCR Record ID

 

Blinded identifier secret to the PII Principal

Required

Schema version

 

The notice record

Required

Timestamp

_the time and date when the ANCR record was created

Required

Legal Justification

One of six legal justifications used for processing personal data

Required

Notice Record

Object labels

Notice Type

Notice, notification, disclosure

Required

 

Notice legal location

The physical location or region that the PII Principal read the information.,

MUST

Notice presentation method

Website

SHALL

online notice -location

Notice location e.g., IP address

MUST

location Certificate

An SSL certificate or key

MAY

Notice Language

The language notice provided in

MUST

Notice Text File

URL and/or link to the notice text

SHALL

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

 

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

Notice Record Security Architecture

Overview

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

  • The only identifier is the identifier the PII Principal chooses to provide to extend the functionality of the anchored record for receipts.

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

  • Whenever an identifier is exchanged, it must use the blinding identifier taxonomy, cryptographically hashed with PII Principal public/private key pair in which the private key is in the notice record and the public key is applied according to it’s purpose

  • Only attributes from the corresponding records can be verified for a 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.

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.

Security practice: requirements for the privately anchored record

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

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

Security Assurance

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

Numerous methods available to provide security and to safeguard personal data, and for securing the control and transparency of data processing using the personal and private notice record, held by the PII Principal.

  1. Blinding identifier taxonomy (BiT)

  1. Pseudonymous identifier

  1. Verified Credential Identifier

  1. Differential Transparency

  1. Differential Privacy (additive as editorial)

 

In this table, suggestions for what method can be applied on a per attribute level are provided as an example.

Record Field Name

Field Description

Security

Trust Consideration

Record Field Name

Field Description

Security

Trust Consideration

schema version

The version of this layered notice record schema

Differential Transparency

Can be required for technical assurance by the system that the record is correctly interpreted and used to compare record versions

Anchor Notice Record id #

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

BiT & Differential Transparency, (Required)

Only the PII Principal can unencrypt and use this identifier to aggregate records and receipt specific to that PII Controller relationship, Must be used for Differential Transparency, to compare one record against another to enable people to see if privacy is what people expect.

Date/Time

The date and time a notice was read by PII Principal

Differential Privacy

Noise put in this data field so that it is not usable for evidence without legal justification

Notice presentation method

Notice presentation medium/context in a user interface

 

Notice presentation vehicle

Notice Location

URL or address location the notice was presented to the PII Principal from

Verifiable Controller Credential

Used to monitor validate and monitor the controller

PII Principal Legal Location

Refers the privacy rules in the local context of where PII Principal read the notice

BiT

BIT, regionally localized, – codes of practice/by laws and the like

Device Identifier

The device identifier refers to type of device (e.g., sign, mobile phone, desktop computer) and its unique identifier(s)

BiT

Notice Medium

Software Identifier

An identifier can be a software configuration fingerprint

Differential Privacy

Ads noise to this fingerprint

PII Principal Pub Key

The cryptographic key used to sign consent receipts

Differential Transparency

Used to help determine if the record is secure and not fake

 

  1. Blinded Identity Taxonomy (BiT)

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

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

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

  2. Pseudonymized Identifier

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

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

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

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

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

      1. signing a copy of the notice-record

        1. (transforms record into a micro-credential)

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

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

  4. Differential Transparency – operational transparency signaling

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

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

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

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

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

    5.  

Notice Record Extensions (for a Consent Record information structure)

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

Extension 1: Purpose Specification

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

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

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

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

Extension 2: Data treatment & RIghts based controls

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

Extension 3:bundled cod of transparency practices

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

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, www.eugdpr.org/article-summaries.html

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

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

[Kantara Initiative] Blinding Identity Taxonomy [BiT]

[Kantara Initiative] Consent Receipt v1.1

[OECD] OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data.

[RFC 2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997

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

 

Annex (WiP to v8.9.9)

ANNEX A : ANCR OPERATIONAL SCHEMA

ANCR Record Schema

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

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

Terms and Definitions

Attribute Name

data types, for attribute … machine readable element

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

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

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

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

  • Document Reference

  • Element Reference

  • Field Category

  • Field Description

  • Field Label

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

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

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

 

 

ANCR Specification Schema Table

Notice Record Example Field Category

Label

Data Type

Attribute name

Field Description

Presence Requirement

TPI 1 Cntrl Id Present

TPI 2 Accessibility Example

Security TPI 3: Digital Context Integrity

ISO/IEC 29100-Ref

ISO/IEC 29184-Ref

GDPR Ref

Conv 108 Ref

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)

 

 

 

 

 

 

 

 

 

ANNEX B: Concentric Notice Label Types

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

The ANCR record is intended to extend operational transparency to a Privacy Operationalization Model and provide for a scalable Method for Engineering.

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

  3. The right to a children’s design code of practice

  4. 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; and are used 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.

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.

Legal Justification

Description

Concentric Notice Type

Privacy Rights/PII Controls

Reference

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.

Concentric Notice Labels to Privacy Rights

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

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

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

Concentric Notice Type

Description

Legal Justification

Privacy Rights
(GDPR)

Legal Ref

Concentric Notice Type

Description

Legal Justification

Privacy Rights
(GDPR)

Legal Ref

Non-Operational Notice

N/O

Insufficient notice/security information for digital privacy

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

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

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

Consensus Notice

Notice of Legitimate Processing. Surveillance Notification

 

Legitimate interest

 

Implied Consent Notice

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

Consent

 

ISO/IEC

GDPR Art 50 1 c

Con 108+

-Supplement- IPC, Canada3

Implicit consent notice

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

Legitimate interest, Contract,

Legal obligation

Object , Restrict

 

Expressed Consent notice

Expressed through the implicit action of a Notified individual.

Informed Consent

Withdraw

 

Explicit Consent Notice

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

Consent witch is knowledgeable of risk

Withdraw

Con 108+.1(4)1b

GDPR Art 7.1

Directed Consent

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

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

 

GDPR 9.1(h)

Altruistic Consent

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

Consent

 

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

 

Appendix — EXTENSIONS

Extension 1: 27560 for Purpose Specification

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

SUMMARY

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

In this schema, this record is extended by a service that 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. Wrapping

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

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

A consent receipt is part of an effort to standardized notice to open consent in order to decentralize data governance in identity management.

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.

To this extent the ISO/IEC 27560 ‘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, 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.

An ISO/IEC 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 ISO/IEC 27560, but ISO/IEC 27560 is not interoperable with the ANCR record, since that would break 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 Credentialwiki.trustoverip.org/pages/viewpage.action?pageId=27722576

Schema Mapping

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

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

Section1 – ANCR Record — Operational Transparency

Section 2 Purpose Specification – generating a notice record and consent receipt

Section 3: Data Treatment and Rights

Section: 4 Code of Practice

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.

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

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.

Extension 2: Data Treatment

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

Extension 3: Code of Practice

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

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

Extension Library

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

Revision history

 

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

 

1 Kantara Initiative, ‘Consent Receipt v1.1’. [Internet]

2 Kantara Initiative, ‘Blinding Identity Taxonomy’ [Internet] docs.kantarainitiative.org/Blinding-Identity-Taxonomy-Report-Version-1.0.pdf

3 For example the “Age Appropriate Design Code of Practice,”

4 Lizar M, Ortalda, A” “Report on the Adequacy of Identity Governance Transparency – DIACC Special Group Insights” Digital Identity and Authentication Council of Canada [Online]