Extension 1: Purpose Specification (with 27560)
Extension 1 - 27560 Consent record information structure: Purpose Specification
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
The ANCR protocol is for generating a record of notice containing controller id and contact, this is always the schema ‘event’ indicator, in this regard the ancr_id field maps to and replaces the event id field in ISO/IEC 27560 WD 5 consent record information structure (ref; 27560)
To this extent the 27560 ‘event schema’ section is not required.
The ANCR record is specified to ISO/IEC 29100 (ref;29100), in which the ‘privacy and security stakeholders’ are defined, in the context of the ANCR record, this means that any role (other than PII Principal) has a Controller id, and stakeholder role, relative to the PII Principal,
As a result the party_schema is incorporated in the ANCR Record ID, which is specific to a PII Controller, not a service or purpose.
A 27560 consent record, which contains the PII Principal identifier in the same record, this would first need a consent receipt, with this purpose as proof of notice – or the record would demonstrate non-compliance with sources referenced in the ANCR record and rendered not interoperable with the ANCR record schema and spec.
In this regard, ANCR specification is interoperable for 27560, but 27560 is not interoperable with the ANCR record, as this breaks ANCR Record Security, and contravenes privacy considerations for management of the ANCR Record.
To address this we have introduced the missing link, which are the fields for a Proof of Notice ANCR record and receipt required to be blinded, consent to combine the records in such a way is evidenced. Hence providing proof, securing the PII Principals data under the Principal’s control, as well as being compliant with legislation and 29184.
The ANCR record can itself be extended in to a Controller Credential When the ANCR record is used in a consent receipt flow it can also be used to. ToiP-Controller Credential - https://wiki.trustoverip.org/pages/viewpage.action?pageId=27722576
Schema Mapping
The following mapping of the ANCR record schema is provide to conform to instructions provided in ISO/IEC 27560. To this extent, and accordance with ISO/IEC 27560 Art 6.2.3, this annex publishes the ANCR Record Schema’s at Kantara and hosted at the Human Colossus Foundation, for the Global Privacy Rights, public benefit Initiative.
This schema is intended to support the PII Principal to aggregate purposes per controller, per record. providing technical features to manage multiple legal justifications in a single service context.
Section1 – ANCR Record - Operational Transparnec
Section 2 Purpose Specification is followed by
Section 3: Data Treatment and Rights
Section: 4 Code of practice
Codes of practice can be approved and monitored which are used to combine multiple purposes together for an expected code of practice. A “Purpose Bundles” operated with a code practice can be approved and to operationalize privacy.
Anchored Record Schema ‘Structure’ Sections
In addition to the consent receipt schema, the ANCR record schema provides a protocol for its operation.
Section 1: Header: Proof of Notice
Section 2: Purpose Specification, (ANNEX C –is also Extension 1)
Section 3: Treatment Specification, W3C DPV
Section 4: Code of Practice Profiles
Section 5: Field Data Sources
These refer to 27560 line – 362 WD4, where it calls out the need to reference the schema(s) information structure used, in addition to demonstrating the capacity to maintain documentation for its correct technical implementation. - and conformance to the requirements specified in the 27560 documents.
ANCR to 27560 Schema (in draft for v08.6 - 0.9)
ANCR Consent Receipt Section | Label | Variations | Description | 27560 Term | Reference |
| ANCR ID | Specified to be a toot recorded identifier | Notice record id is used as root identifier for linking records about the status of privacy with that controller | Record id |
|
| schema version |
|
|
|
|
| PII Controller Identity Object PII Controller Name PII Controller address correspondence contact email correspondence jurisdiction privacy regulation correspondence phone Correspondence website Correspondence website ssl certificate
| Non-operational privacy contact point |
|
|
|
| Privacy Contact Point Object Object Must have at least one field for the PCP object PCP-Profile Privacy Access Point Profile PCP-InPerson In-person access to privacy contact PCP-Email PCP 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-CoPC code of practice certificate, URI PCP-Social Network:handle PCP-Other Other PCP Policy PCP privacy policy, URI
| ANCR focuses on a KPI – for the transparency performance of privacy contact access point |
|
|
|
| Proof of Notice Object Object labels Description Notice Type Notice, notification, disclosure Notice method Link / URL to the UI that was used to present the notice e.g. website home page -digital-Notice-location Notice location e.g.ip address location Certificate
Notice Language The language notice provided in Notice Text File URL – and or Hashlink for the notice text Notice text The capture of a copy of the notification text Notified legal Justification Implied or explicit notified legal justification based on the text of a notice and its context
PII controller risks
| Uses notice type which would be equivalent to event type in 27560 |
|
|
|
| Concentric Notice Label | Different but incorporates how to fame 27560 defined consent types | Categorizes Notice Labels to indicate protocol for rights access and inherent risks |
|
|
| Purpose ID |
|
|
|
|
| Service Name |
|
|
|
|
| Purpose name |
|
|
|
|
| Purpose Description | Plausible RiSK - *can data control impact assessment) |
|
|
|
| Purpose Type |
|
|
|
|
| Legal justification |
|
| Lawful basis |
|
| Sensitive PII Categpry |
|
|
|
|
| Special PII Category |
|
|
|
|
| PII Principal Category |
|
|
|
|
| PII Processors |
|
|
|
|
| PII Sub-processors | New |
|
|
|
| Risk notice disclosure | ISO-29184 |
|
|
|
| Service Notice Risks |
|
|
|
|
| PII Principal Category |
|
|
|
|
| Attribute Id |
|
|
|
|
| Notified Collection method |
|
| Collection method |
|
| expiration |
|
|
|
|
| Storage location |
|
|
|
|
| Retention period |
|
|
|
|
| Processing location Restrictions |
|
|
|
|
| Duration |
|
|
|
|
| State | Justification for processing (state of privacy) |
|
|
|
| status |
|
|
|
|
| termination |
|
|
|
|
| Inherent to concentric labels - Rights Objects: withdraw, object, restrict, access and rectification, termination of justification, | Regulated practice, approved be regulator or legislated |
|
|
|
| Rights |
|
|
|
|
| Notice Defaults |
|
|
|
|
| Data portability |
|
|
|
|
| FoI-Access & Rectification |
|
|
|
|
4.b)Code of Practice | Cop-ID |
|
|
|
|
| Surveillance Code of practice | Certified practice, |
|
|
|
| Children’s Design Code of Practice |
|
|
|
|
| Operational Privacy Code of Practice |
|
|
|
|
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 (3rd Party)
Approved by Regulator (yes/no)
Certified Body - ? - Certification
SSI – Gov – Principles – Codes of Conduct
Purpose Name
Purpose Label
Ancor Notice Record ID
ANCR Record Protocol
An Anchor record is a PII Controller Relationship Notice Record, very similar to a PII Controller Credential, but instead of being provided by a specific stakeholder, this – micro-credential can be created as an ANCR Notice Record by the PII Principal.
When a record or receipt is generated, it can use either this record, or a PII Controller provided record as the source record, for linking all of the subsequent record and receipts together. This way both the PII Controller and Principal have corresponding (mirrored) records which are not directly linked and separately controlled.