Re: Proposed additions/changes to Purpose taxonomy based on ROPA templates

Hi DPV  CG,  (and Harsh of course)

I would like to propose a secondary purpose specification form the Open Consent Group, which is also being proposed to the ANCR WG at the Kantara Initiative.

To ths enda,

Is it also possible to include a bottom up formula for purpose formulation using the DPV?  Dichotomizing purpoase specification so that it suits a bottom up specification of consent using ISO terms ?

In the latest ‘proposed” iteration of the consent receipt framework, in which the consent receipt is focused on the specification of purpose.     The initial iteration and energy of the consent receipt was not that it was specified the top down, but, that it was specified form there bottom up.  Which translates today to a public and open privacy infrastructure advocacy.

In the consent receipt specification, purpose is specified in the consent of any technical systems that harvests personally identifiable identifiers, aka, technical surveillance. It is specified this way so that a consent receipt can b3 used as proof of consented surveillance by a service provider, including the service providers identifiers and notice.   In this way, it is top down, and can be used for evidence of the metal state of consent by both parties.

What this would look like as a specification

The Prefix of the Consent Receipt  would contain  the data controller digital policy information in ISO standardized fields. Controller contact, and DPO legal identifier is required for a compliant identity management system,  Which we call a consent gateway that registers the controller information and notartizezs rights claims,   This start with a  record that is kept by the Data Subject (or on the data subject behalf as a fiduciary) regardless, the prefix presents the security requirements for a valid consent, and are used to provide a privacy risk score.

This prefix, which we call the anchor record is generated and kept by the data subject.
Through the use of client software, or a User Agent, (aka a Web browser extension) a record of the data controller is generated and this record is used to generate consent notice  receipts automatically for each identifier and disclosure relationship.  Initiated at theby first reading of a privacy notice (by the PII Principal) and then through data subject interaction, generate a consent notice  receipt.  AN authoritative online record used to assert permissions and preferences independent of service providers.

Long story short,

The purpose specification is generate from the bottom up, by
a) creating an anchored record of the data controller, address, contact info, privacy jurisdiction/agreements / certifications
b) the notice presented by the data controller is then used to make a consent receipt (aka purpose specification, using the anchored record ID).
c) this looks a bit like a session cookie online, the controller ancor record information is use with
c.1 - a legal justification, (field objective)  other than consent (includes the  consent type) which is added onto the legal justification of consent receipt
c.2)_ then the purpose context is added by the data subject agent/ or preference.  This is what is called a service in 27560.3, or a brand name by an Individual, or a generic context by a parent - e.g. a website
c.3 then there is the update to the purpose category to; Purpose Type -  type of person generalized for the data subject / individual from the bottom. e.g. Marketing
c.4 then the purpose field, which describes the purpose using the Data Privacy Vocabulary, in order to standardized the semantics of a consent receipt.

To this end,  I ask this to the group, and those deeply involved, is  it possible/viable  to make another category of purpose definition, defined at the end of the data subject context?   Rathe than the enterprise ?

Best Regards,

Mark

PS. I have attached the ANCR Framework receipt spec, drafted to purpose specification, in hopes this can be innovated with , \







The rec

 that is used to generate consent receipt for each session, or interaction with the Data Controller.

purpose specific u and consent receipt framework, purpose there is a proposal that

On Aug 12, 2021, at 1:50 PM, Harshvardhan J. Pandit <me@harshp.com<mailto:me@harshp.com>> wrote:

Hello.
Sharing the working document for reference and comments (see attached).
Paul and Beatriz (mostly) and myself went through the DPA ROPA templates and other sources (see: https://github.com/w3c/dpv/issues/22) to see how we can enrich DPV purpose taxonomy. Result of this is the proposed list of additions and changes. We will be discussing these in the coming meeting calls. Please provide any comments/views you have in reply to this email or on the GitHub issue.

For other proposed concepts we have already discussed, e.g. legal bases, data transfers, we have a few resolutions, and they will be included in the next iteration alongside the purpose concepts.

I'm hoping for first week September to have the next iteration published, so whatever is accepted up to the next ~two meeting calls.

Regards,
--
---
Harshvardhan J. Pandit, Ph.D
Research Fellow
ADAPT Centre, Trinity College Dublin
https://harshp.com/

<DPV_Purposes.xlsx>