2FN for Data Governance 2FC for Data Controls

This specification aims to separate the requirement for notice for processing and extend a more robust notification and proof of notice protocol for people to provide a stronger/compliant form of eConsent for operational identifier privacy transparency.   This presents a new authorization flow, Auth from Consent in which a PII Controller broadcasts surveillance  presented provides for compliance with a data processing notice for processing, before processing or at the outset of processing, with privacy rights and controls, for any type of data control processing with a standardized data processing notice for citizen trust.

Authorization (and security) (Notice) before surveillance and Authentication.  A  human centred specification in that consent is the default context for notice, so that a notice is human understandable and meaningful. (regardless of legal authorization for data processing).   This specification relies upon standards for the generation of a record that can be used as a  proof of notice and a gateway for using a proof of notice as evidence for eConsent.  Addressing many compliance and usability requirements for data governance, which is a task this specification is being drafted for mapping to.

In Focus

Decentralized Data Governance Systems for Human Understandable Notice, re digital identity interoperability. AuthC presents an alternative, more performative,  policy agreement starting point and format (Consent by Default) for enabling authorized and more dynamic data control. Implemented for the exchange of personal surveillance data; identifiers, preferences, and  policy though notice records. 

An 'Operational Privacy' alternative to: 


Online when interacting with service providers there is often a checkbox to policy and terms that people have not read, and if they did read, the information is not standard, or relevant to the individual and their context. 

Policy and technical permissions for access and data control are divorced and not connected revealing a lack of contextual integrity between what people expected and the surveillance that occurs.   This has a been a long time challenge and is the output to research development and iteration from over a decade of input into  notice and consent standards to address the original use case which the Consent Receipt specification was specified for.  

Generating a Consent Receipt

2FN is a recommended best practice for presenting an alternative to the checkbox online and for opting into, or out of privacy controls. 

A 2FN notice is presented and the interaction with the notice is captured by generating a record of the notice (by either party) which can be kept a proof of notice and as evidence of consent, which can be used outside the context of the interaction to manage the processing permissions with privacy rights.

The ANCR record is comprised of the PII Controller Credential specific information, which is used as a context (relationship) anchor for data governance (regulatory policy).  The ANCR record is the prefix of the Consent Receipt, containing the notified PII Controller context information, this sets the security baseline  and parameters which safeguard the use of identifiers, the digital service relationship and the transparency of processing of personal data in a supply chain.  

The options for a 2FN Must include access to privacy rights information and children's right to be heard, adults right to complain (not a link to privacy policy).  Terms and Conditions can then be entered into to scale the AuthC in identity management for a consistent and interoperable rights management and exchange protocol.  (like PaECG)

Preference and Permission Exchange

In some context both parties can exchange receipts, in which the PII Principal can provide a-receipt with consent preferences, and the controller with required permissions and terms.   

A signed receipt by both parties can be used as a token which is linked to the 'active and valid state of consent' as negotiated or legally authorized. 

This consent token can then be used to streamline the PII Principals experience and help administrate the relationship.  Capturing the preferences, monitoring the valid state of the consented or informed identifier and data processing surveillance. 

Proof (legal evidence) of Notice

As an alternative to the checkbox (opt in and out) policy links found in software, defined by contract, a 2FN provides a notice which contains the legally required notice information presented from a standardized record format, using standardized privacy legal semantics, and data control vocabulary. 

These standards when combined provide high assurance that the notice does not contain dark patterns, mis-information, and can be used for operational surveillance and privacy applications that require a proof of notice for legitimately authorized  data processing. 

These include all sensitive or special data categories and especially for high risk and sensitive contexts when dealing with legal and evidentiary evidence across borders, e.g. the surveillance of children and vulnerable people. 

Two forms of 2FN 

The first is a notice for any type of personal data processing, surveillance.  The second is consent, in which data rights are used to control who benefits form personal data, and to collect this data in an interoperable standard format called a consent receipt. 

2 Factor Notice (2FN)

(two factor notice for proof of notice)  

2 Factor Consent (2FC)

(two factor notice for proof of Notice and evidence of eConsent) 

2 Factor Notice is used to enhance existing notice formats to provide enhanced notice, notification and disclosures.  

The core notice credential is ue record format is the ANCR Section 1 receipt. 

The receipt is generated with an ANCR WG conformance assessment, in which required identity information is provided in a standardized format prior to processing personal information is used to show a notice of control for consent to the Individual. 

This identity information is found in the first part of the 2 factor Consent receipt, which is comprised of the  Notice of Controller (PII_Controller Object) Receipt fields (with or without the legal justification).  This is a key component that provides the notice for the proof of Notice component provided in a Consent Receipt.

For legal compliance with any identity management system, the identity of the controller is universally required  in every privacy law/ jurisdiction.  See the original research for the consent receipt from the ISTPA - International Security, Trust Privacy Alliance, which is the research that ended up turning into ISO/IEC 29100. (link) The international security and privacy framework used as a basis for the notice, control and portability of personal information. 

 If the information is not provided, the identity management system/tech,  is not in compliance with privacy legal requirements like the GDPR and why proof of notice for consent is so important. 

How it works

The anchor receipt is created when a proof of online notice is generated  from the page (and context) to include legally required elements of notice, this is captured in the receipt. This ANCR receipt then can be measured for its conformance to this v1,2 for ISO + legal requirements (and is a separate sub-use case) 

The anchor receipt is used to provide an active state of relationship for the human, conceptually a reverse cookie, required to start a digital identity relationship.

The second factor

The second factor of the receipt contains the legal justification and purpose of the service.  Once added this completes the anchor consent receipt, which is then linked to all future receipts to be able to generate a Consent Lifecycle to frame the governance of the relationship. 

PaE:CG - Website Use Case Example

In the use case example from the Privacy as Expected project, A Consent Receipt wallet is added as a browser feature or add-on, for website.

  1. a 2FN is presented for the existing privacy state as indicated by the implied action which resulted in calling the website to the browser
  2. if this is the first time (with 2FN active) an anchor record is automatically created and the ANCR ID and URL is stored in the add-on
  3. the add-on to generate ANCR records is used to generate a 2FN independent of the website (and technology), for the individual to confirm controller credential and purpose / consent type for this context. and uses this record to generate a receipt to capture the notice upon use.
  4. if both parties use 2FN, a 2FN-C receipt exchange occurs and a Privacy as Expected Signal is generated to indicate if consensus and consent is valid.
  5. A dual signed consent receipt becomes a micro-credential which can then be used as factor for Authentication, further streamlining the digital privacy experience to what people expect from the purpose of use and their own physical context. 
  6. The receipt from the add-on, captures the notice provide by the controller, and up on first use, with a non-participating (unknown) controller - a capture of all the relevant policy information, and operational privacy elements are captured as evidence or proof of the notice.  So the PII Principal can use it for evidence for applying rights or changing preferences.
    1.  This capture includes the meta-data for extending (or combining) the digital identity service relationship(s) that are also present at the time Into the lifecycle. All of this can be  attached as apart of the  receipt payload (and even be made into a requirement for the capture of active relationship state to extend a consent lifecycle. 

A Short History of Work Leading to 2FN (&C)