On-Behalf: Co-Regulation & Delegation for Privacy Risk and Liability -CR v1.1 Review Summary

The key challenge in addressing the biggest lie on the internet is in standardizing the identification of the supply chain of identifiers collected when processing personal data and uncovering what was really behind the terms and conditions and the fake privacy policies subject to them (rather than people and expectations.

The GDPR has been instrumental in the update to the CR v1.1, (with multiple definitions of on-behalf used) providing missing terms and legal infrastructure to progress and finished the notice and consent receipt work so it can address illegal data processing and out perform usability.

The Google/IAB ad-tech ecosystem is a service architecture where the Data Controller uses Google analytics which is an info-mediary which acts as a proxy service for apply rules for advertising.  This  dis intermediates the identity supply chain without legal safeguards commonly referred to as privacy in the analogue brick and motor law without the digital extension of standard schema and term which would open analogue notice for its digital twin equivalent.  

Weak Transparency:

The identity of the controller, and any subsequent personal data processor is not legally required to have a digital identity - just a physical one. The law does require fairness, and reciprocity, which means legal identity, also requires a digital identity to be fair. Although the law doesnt specify how. This is where standards come in. Standards evolved from best practices.

But, standards are new, an up until now we see how personal data is collected by organisations with a physical address and an email posted on a website. With no requirement for the digital identification of processors, revealing the cyber-security gap, and weak transparency. This is further compounded by the law not requiring the identification of legal entity who have access to personal data. And that a legal entity can have many legal owners, and then again many beneficial owners. Known as shell’s companies or LEI’s

  • which is why, for extremely high privacy risk, we advocate for greater transparency requirements for organisations that have multiple beneficial owners - and complex microprocessing services (e.g. IAB cookie auctions) declarations of operating jurisdiction for high assurance dynamic data access in consent by design frameworks.

    • suggesting policies that create greater friction for the controller and the data subject - like requiring the registration, and log for processing for each processor with the identification of every beneficial owner and their interests in the processing. (whic

Solutions Space

Transparency over delegation - and with it the delegation of liability and risk via delegated authority to processing with model contact clauses. For the entire supply chain, the privacy rights are contracted. Including and sub-processing, (term now added to the DPV v0.02)

providing active digital transparency with delegating authority  - i.e. acting or processing  on behalf of a processor.

Even now with the latest data governance laws and enforcement the legal requirement for sub-processor transparency is also weak and is the biggest cyber-security/war issue. 

Exposing a critical identity and cyber security flaw hidden deep behind the terms and conditions that do not legally apply, a challenged that can only be addressed with International (inter-domain) standards.

How?

  Even though this has been illegal - there was no other legal framework mechanism that was performative for the internet service and identity relying party to use.  The ISO 29100 and subsequent works especially ISO 29184 address this gap, still in a legal analogue way.  The legal data ontology (or  semantics) - required to address this gap and govern digital identity management at scale across the Internet.  

Some trans-national federated identity systems have addressed this by developing legal data shaing ontologies like the GA4GH federation, in which semantic onltolgoy is combined into data categories labels and then applied through access controls and permission.  A non federated legal ontology for semantic web and linked data is the W3C Data Privacy Vocabulary CG, in  we supported it launch, with the ODI and MIT Media Labs to celebrated the GDPR May 23,2018.  As of writing this v0.2 is now available and includes the data categories and standard semantics for purpose specification and with it computational privacy law.

Through the work we discovered that there are multiple context for delegation, represented in legal language ‘on-behalf’ and ‘third-party’, the ambiguity in the law directly relatate to digital lack of transparency corresponding to the intent of the law e.g. GDPR article 13/14 identity of controller.

In the process of engineering the notice and consent receipt we reviewed the analogue legal definitions defined in the CR vc1.1 in Line 331 - as outlined by the legal use case of a ‘third-party analytics service required to be transparent over the legal identity  a) parental consent b) educational data trust.  Pulling these apart through the use case a  closely related field issue and reveals the gap in the CR v1.1 specification, where there is a missing standard ontology for delegation, delegation of authority - from its source in law, the regulator for the interaction, the controller, the processor, and each privacy stakeholder including ’sub-processor’, 

(Note: this can be even more confusing as marketing has made the legal case with the IAB Privacy Framework for their sub-processing to be understood as a  joint controller instead.  Making the requirement to add sub-processing explicitly even more clear at this time. 

Solution  in the CR V1.2, Delegated Authority

First developed for data subject, a field for delegate authority, e.g. parental consent, and the parental consent credential, or in its absence an approved (by a regulator) legal entity identifier for the parent or guardian.

To further specify the above - the on-behalf field has been replaced by the delegated authority and identifier field which is used to identify the authority for delegated processing as well as the legal identities in the data governance supply chain.

Data Subject - Parental or Guardian Delegation

Controller - Joint Controller Or Processor delegation 

Processor - sub-processor or in some context 3rd party delegation

The requirement for approval by regulators reveals the regulatory delegation of authority, which is also recognised in approved/standardised codes of conduct and practice. 

To this end Regulatory authority can also be transferred with  delegation of authority.  A key component for recognising credentials, for witnessing identifiers to generate credentials and for notarising identifiers and credential attributes to generate credentials.

CR v1.1  Report- Delegation of Authority 

The On Behalf field was first written in as Consent on behalf of the PII Principle, in v0.05, which covered explicit consent by a parent or guardian for children, but the v1.1 was frozen on the decision to not defined the explicit consent type, and wait for legal standards to do this.  It was unclear at the time (MVCR v0.07) – and resulted in the only non-consensus vote in the history of the work at Kantara.   To this end,  we decided to wait until GDPR came into effect, with many people on the mailing list.     

  • The on-behalf field has been one of a handful of long standing action items as in th CR v1.1. comments have been received asking for clarification, they have been accepted, and the have been responded t with the fields present for delegation in this specification. 

As is in the CR V1.1 it is an optional field for acting on behalf of-  but, in the spec earlier it refers to - acting on behalf of the data controller as a  data representative, and has carried with it 3 contravening references in the CR v1.1, that are reconciled with the v1.2 update to delegated authority.  A delegation format for co-regulation and the transfer of liability and risk.   The use of standards provides for greater extension of interoperable data governance signaling.

Great deal of work on this was with liaison and event activities with multiple stakeholders.  Open Consent, with the support of Kantara hosted 5 Real Consent Workshops at Digital Catapult in London UK, through this work and review of V1.1 we made these revisions to the on-behald field.

In addition,  in reference to the GDPR leaked draft. and the GDPR receipt profile,

  1. On-Behalf field in the CR v1.1 shows an example that defines a sub-rpocess and processor – which is already defined as a 3rd party in the spec – which means this field is redundant in the CRv1.1 – once a sub-processor field is defined. 

  2. The aforementioned - consent on behalf of PII Principle

  3. Line 212 - in the CR v1.1. spec (or the spec) referring to  PII Controller  having someone (or a 3rd party org) act on their behalf as a data representative -  which arguably could also be required of a Data Processor 

  4. Then in multiple loctions, on-behalf is referred to as a delegated processor -

    1. Line 264 — Use - includes  in its description to processing on behalf of a processor  on be-half of a 

    2. Line 331 - OPTIONAL: A PII Processor acting on behalf of a PII Controller or PII Processor. For example, a third-party analytics service would be a PII Processor on behalf of the PII Controller, or a site operator acting on behalf of the PII Controller.

Specifying 

  1. a term that maps ‘on behalf’ to Sub-Processor for use in the GDPR

  2. Adding the Term On-Behalf as a new term in GDPR term Section

    1. As ‘a party acting on, or consenting on the behalf of; a PII Principle, controller, processor or regulator.  And should be used as such.  

  3. Adding fields for specifying who the -on-behalf- party is- 

    1. name, address, contact, role and authority  

On-Behalf - CRv1.1 : GDPR extension – conformance program inputs 

  • Map on-behalf from CR v1.1 to GDRP extension as sup

    • The on-behalf field in the CR is mapped to Sub-Processor in the Extension

  • And in the GDPR Fields section 



  • The On-Behalf Field 

    • is further defined in this extension to represent 

      • Consent or Acting On-behalf of  the PII Subject, controller, processor or Regulator

    • The representing party

      • Name, address, contact, 

      • role, For 

        • PII Subject

          • A Parent, Guardian, Advocate or Agent

        • Controller

          • Data Protection Officer, Data Controller Representative

        • Regulator

          • Approved Auditing and Certification frameworks

      • Authority

        • A URL link (or inclusion of) a certificate of authority or approved verification

Applied in the Extension

(A Conformance field is added to Extend the PII Controller  section: ) Note to implementer’s, the delegation format can be used in the receipt information structure for any guardianship, for consent directives, for  PII Controller to Processor contract delegation, for Regulator to Code of Practice –certification and monitoring authority, for the Privacy Assurance Framework as established by ISO 29184. Specified here as: 

  • If Children’s Data is being processed = Yes

    • Consent On Behalf, field is used

      • Consent on behalf 

        • With the selected role of parent or guardian

  • If a 3rd party representative is provisioning or administering explicit consent on behalf of  controller, processor, then 

    • Acting on behalf, to process consent with the role of

      • Data Protection Officer, Data Protection Representative

  • if Regulator 

    • Acting on behalf, is with the role with approved code of conduct with controls for Online Privacy Notices and Consent

      • Approved Trusted 3rd party that is accredited by the regulator



Note: although, un apparent, the