PROPOSAL: Towards the V.Next Framework

[smartopian]

Proposal (in draft mode - from feature request to proposal )

Draft Plan: Consent For Information Sharing & interoperability
Draft 1. Nov20
Draft 2. Nov 30
Draft 3. Draft proposal Update: WIll wait to move to new Information Sharing Interoperability WG - Wiki -

[Note to reader: This proposal, proposes to extend the consent receipt with notice and contract receipt types. This proposal is comprised of an Introduction, the context of the consent standard, and the background for the V. Next in 2020. ]

###Context of this proposal
Privacy and privacy right(s) require notice and consent to cover the use, capture and overall processing of personal data. These laws have evolved through generations, and have become more complex for people to interpret with every common law decision.

Privacy as a tool for regulating surveillance, is a key market driver for consent in digital identity, in fact, for all industries and sectors, the legal codification of explicit consent (real personal data control) for health data began with the Helsinki Declaration in 1964. This is because health data requires the highest standards for data control granularity. The result, is the health industry has defined the highest data transparency, data control requirements to govern the use disclosure and sharing of health data.

###Consent in Identity
Digital technology, and in particular identity management tech, is advanced human attribute and sameness automation technology, traditionally employed for security and access control. Identity Management technology is intentionally designed for human attribute surveillance, at the core it is used for almost all types of surveillance; detection, tracking, aggregation, and all profiling technologies. This means that Identity Management technologies are inherently dangerous for humans and digital identity is implemented to dis-intermediate a personal attributes from a person's physical control (which is much more powerful).

As a result identity management technology (not just digital id tech) represents significant (or high) privacy risks. Risks that were (and are not currently) being considered by most technology developers. For this reason, not only is the consent receipt a critical tool for identity management governance, consent is critical tool for people when engaging with digital identity enabled services.

IdM technology is relatively new in comparison to the very mature human consent considerations encompassed in the existing socio-legal frameworks we have today, which are used to effectively govern the distributed human which we have always been. In the last 20 years, IdM tech has significantly advanced, with only commercial self-governance.

The consent receipt, a decentralised privacy governance standard, is engineered to address critical issues in digital identity management compliance and commercial governance.

###Consent - A human term for interoperability
Consent and the (consent receipt (that capture the state of a specific consent event)) should be interpreted for privacy engineering, first as a social construct, that has been codified legally and then implemented technically.

This proposal takes into context that there has been a tremendous progression in consent receipt works in the last 2 years, along with a dramatic change of market conditions and the enforcement of explicit consent.

Socially, consent as a tool for human interoperability is a concept embed at the core of human interaction and culture. Consent, is represented at all layers of human engagement in static broad policy, but digitally, there is a gap where there isn't strong transparency over data governance. As a result human friction is very high.

Legally, explicit notice and consent is found in all privacy legal instruments around the world. It is a social concept that has evolved over 100's of years in common law to be harmonised formally, from best practice, to standards, to law, to international law.

Today, the GDPR and the first major global enforcement action for notice and consent(1) is the result of significant effort by privacy regulators to address the need for governance, transparency and accountability over personal data processing. (CDP2019-Panel by Regulators calling for implementation of Standards in 2020

####History
The Consent Receipt work is the result of 5 years of specification development.

The consent receipt work was brought to Kantara officially in 2014, by a project called Open Notice. Open Notice, which was a privacy lobby focused on the privacy notice and 'I Agree' problem, challenge. It concluded, that since the core legal privacy requirements for a digital implementation of a Notice is a record of entities in the consent (or identity), that a notice standard was not enough without an identity based consent record standard.

The Open Notice project reported 3 key elements for consent in the context of digital identity management.

1. A NOTICE (privacy statement or policy)
2. A positive OPT-IN feature
3. The IDENTITIES of the parties involved,

Identity, being the legal reason that brought consent to the Kantara Initiative, and why the Kantara community is uniquely suited for this work.

Today, the success of this work is demonstrated with the growing enforcement of notice and consent laws, other (open) standards becoming interoperable with the CR specification, and the use of the Consent Receipt V.1 specification in IdM implementation's, and IdM ecosystem projects.

The V. Next Proposal :

In context of this introduction: (AKA, a specification focused on engineering a human centric transparency - IdM record suitable for managing explicit consent compliance) this proposal encompasses the following 3 feature recommendation for the V. next framework.

1. An update of the Consent Receipt v1.1 related works and interoperable projects
2. Naming a consent receipt a Human Centric(HC) Identity Record, or Identity Rights Record, or even a Decentralised Identity Record or other
3. Proposing micro governance policy modules. For those that resemble a 'Contract' should be separated into another Category of receipt (i.e. personal data processing receipts) and that V. Next work focus on defining "Contract Receipt Types " as a separate than the consent category of receipt, with its own receipt types. Effectively, utilising the consent receipt as a governance module to use with and stack-upon additional agreement based governance services. To enable interoperability and performance testing for : digital consent and contract to be human interoperable. And to enable multi-consent-state contexts + multiple records at once contexts in use cases that might also need + multi party records.

Proposal Breakdown:

This proposal is broken down into these 3 proposed V.Next Features

1. 3 categories of Receipts; Notice, Consent, and Contract Receipts; Expanding the distributed governance of privacy rights law to include a specified Contract type of receipt
2. Proposing 5 Consent Types, to cover the spectrum of consent to complete the scope of consent receipts component of the works
3. Name Consent Receipts works, Human Centric Identity Records
4. Interoperability - (The Open Consent Stack) organise, engage and recruit -Kantara wide + inclusive (as a standards efforts interop liaison for using the CR as open format) aka multi community effort to support the Consent Receipt being apart at ISO during this next 1 year ISO study period

**

1. Receipt Categories

A. Notice Receipt - (Roughly; A Verified Org record which is 90% of the current Consent Receipt header)
B. Consent Receipt - (provides information relevant to the justification and purpose for processing and what is processed)
C. Personal Data Processing Receipt - Captures the governing framework (if any) for the processing of personal data, and should/can be usable to extend the Consent Receipt. The PDPR should have Contract Types and not Consent Types and perhaps Alternative types of distributed (not decentralised) governance privacy identity records.

2. Consent Types

Defined here so as to limit and complete the scope of the consent receipt work and clearly enable people to crisply depict personal data with surveillance by design from processing with consent by design, as this is a key requirement for explicit consent to be compliant.

**Consent Types Proposed **
Objective: cover the full spectrum of consent relative to a human centric experience (or innate understanding) of consent in context. Mapped to legal authority or justification for processing personal data. (For e.g. the GDPR justifications are referenced, mapping coming)
[Note: A metric of the output is effective transparency between Surveillance by Design (SbD) - thank you Shoshana Zuboff, Feb 2019 ] and Consent by Design, AKA GDPR, PIPEDA, HIPPA, etc

Proposed Consent Types Described

1. When Consent is ‘Not Needed’: there is a legal Expectation that surveillance will be notified and privacy will be as reasonably expected. aka protected secure and not based on hidden (or unknown surveillance) ,
   A) meaning; that the controller will manage the burdens of privacy notices and informing people themselves, that an independent governance framework or legal mechanism exists (like a contract, or criminal evidence exemption with seperate oversight ) exists for security (e.g. law enforcement, bank fraud, break glass)
   B) The legal authority, used for authorising this processing covers the justifications of; legitimate interest, processing is in the public interest, legal obligations by controller to process personal data, and the best interests of the data subject (break glass).
2. Implied Consent: Surveillance by Design, (data processing and identity management/profiling) is not as expected, most often used for video surveillance with a sign, or called cookie consent with a banner, and covers from processing like IoT and facial recognition at airports to Google Search and ad tracking based analytics.
3. Public expectation of privacy or Privacy as Expected (PaE) - this is also the basis for Social Consent: which is consent in democratic society, represented in communications and relationship management, in family and community. The baseline is tailored to culture - and can also be extend to social politics and concepts - like sexual consent, elements of life viewable as patterns (AI).
4. Explicit Consent - This is the consent defined in law like GDPR, COPPA, PIPEDA and the Consent Receipt v1.1., GDPR Extension
   A) This prescribes that the human is first aware of the risks to their privacy, and is aware of what they are consenting too, or in legal terms a NOTICE
5. Human Made Consent - or Privacy Agreements: This is when a privacy policy is not needed because the person is setting the consent policy. or Consent Directive themselves, and the laws and best practices of explicit consent are required already.

2. Personal Data Processing Receipts (Category) & Contract Types

Propose to Add to the v1.1 spec A new (V. Next Gen CISWG Work) 'Contract Type' category, to extend the consent receipt work and provide a basic starting receipt type for frameworks

Possible Contract Types/ Alternative

• UMA - Contracts for privacy rights (up-stream) with third parties
• ISA - Information Sharing Agreements with JLinc (down-stream and up-stream)
• CommonAccord, the (Trust Fabric) and Prose- (OpenFlexibleContract for Personal Data Processing Liability)
• Privacy Agreement's (with explicit consent receipts)
• DiD (Distributed Identifier) and SSI Contract Types

3. Interoperable Standards

This section refers to the Consent Receipt Technical Community and the body of standards work that the consent receipt supports for international interoperability. .

1. ISO 29100 Lexicon and ISO 29184 - Online Privacy Notices & Consent - In which the consent receipt is appearing in the appendix (nxt yr?)

2. Personal Data Categories - a set of personal data categories maintained across communities

3. W3C Community Group - Data Privacy Vocabulary Controls (semantic)

• See the Consent Receipt and DPV - GDPR Extension for Explicit Consent and the DPV (used to develop the V.Next)

4.COEL - OASIS Standard, Feb 2019 as Recommend for V.Next CR Ontology; for granular event based - interaction records that can be used to bind at the attribute and data type schema level

5. Kantara Initiative Blinding Identity Taxonomy - for an initial set of identity attributes being match to personal data categories.

[TomCJones]

I thing the following statement is an oxymoron, legal and human-centric are diametrically opposed.
HC Terms - (User Terms) this begins with a human centric glossary that is founded on legal privacy rights usable definitions as a base taxonomy for HCI

[smartopian]

The supposition being made is that consent is first human centric, and this human centricity is codified in privacy rights principles and law over the last 30 years. It is this codification that is required to be implemented technically to be compliant with privacy law, and to replace current dogma like cookie consent with a more accurate HC description - like implied consent. In effect, splitting out contract (disrupting all the lawyers) and moving the lawyers to contract receipt types. (away from the core privacy right controls - that can be implemented with the above standards)

…

On 21 Nov 2019, at 18:26, tom jones ***@***.***> wrote: I thing the following statement is an oxymoron, legal and human-centric are diametrically opposed. HC Terms - (User Terms) this begins with a human centric glossary that is founded on legal privacy rights usable definitions as a base taxonomy for HCI — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#27?email_source=notifications&email_token=ABR6VZ3H6BFMNNGJSU6Q7ETQU3HHHA5CNFSM4JQCRDHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE3GHVI#issuecomment-557212629>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABR6VZ6Y4PCWIYDSCHEWANTQU3HHHANCNFSM4JQCRDHA>.

[smartopian]

FYI - I have put a note on this proposal - that it is in draft - and I have updated with feedback so far. Comments welcome

[coolharsh55]

Regarding the proposal, it could use some editing and clarifications in the text.
Consent and identify management are two separate issues (as of now), and the IMHO the text does not clarify the relationship between the two through consent receipt.
e.g. identity is used in other use-cases where consent is not an option or is not required
Such as digital transactions, where identity management is tied to authentication of individual's identity for financial payment
The contract receipt section does provide this link within the text, but I feel that should come earlier, as the IDM section is too dense (for me) to grasp and is confusing to get around.

'implied consent' is not clear or is ambiguous e.g. when a patient's blood is taken in the emergency ward, the consent is assumed to be implied - this implication is different from 'by continuing to use this site you consent...' which contains an action on the part of the individual. So, there are two types of implied consent - a) where the individual does not have to take any action or react e.g. unconscious patient implies consent for treatment, drunk driving tests b) where the individual must satisfy a condition or event and consent is assumed from that point onwards e.g. by walking in this shop you consent to be recorded

3. Privacy as expected is not clear or is too broad

Are the consent types mutually exclusive? (3) can be implied or explicit as well

4. explicit consent means explicit affirmation of consent by a clear action. ALL consent need a notice at first, the elements differ by requirements, but the minimum that needs to be provided is what the consent is for. Also, in (4), explicit consent does not require information about privacy risks e.g. see GDPR requirements

(5) is unclear, especially the relation to privacy policy

The draft of CR-GDPR shared is quite old, and has lots of highlights (yellow). I think there must be a clean shareable version to link. Also, there are more fields in the latest spreadsheet than in the word document.

[TomCJones]

There are two reasons why the use case "drawing blood in an emergency room" are not applicable to the discussion. The first could be addressed by this committee, the second cannot:
1> Consent (as it exists today) is only about consent for information sharing (CIS). This confusion continues particularly in finance and health care. Extending consent to a wider scope would be a big deal. (Right - the term consent needs a better explanation in the spec.)
2> Consent (and privacy) are not always available to the user and is not always mandated by regulations like GDPR. These are covered by sovereign immunity or conflict of laws issues and are outside the scope of this work. I really do not like the idea of calling this as implicit or any other sort of consent. Just leave it out-of-scope.

[TomCJones]

Notification of such "break-the-glass" issues as emergencies procedure could very well fall into the notification bucket - that is also out-of-scope for the current round, but might be part of future specs.

[smartopian]

Some great comments - this proposal -provides a "consent not needed" mapping.
For example - Emergency Health Care - in which the data subject doesn't provide explicit consent This is a context where - Consent is not needed - because it is in the best interest of the data subject (GDPR legal justification) - which is the legal authority used in-lieu of explicit consent. This is not implied consent (as indicated in the comment)

When consent is not needed - then another mechanism is required - e.g. contract - or an exception. Or a personal data processing receipt for a contract type could be used - (in the context of a V. Next) and attached to the identifier.

For example: financial transaction with a credit card - a person was notified of privacy issues when signing up to the credit card contract - that is then later used in a transaction. Or with PDS2 in the UK - explicit consent is required for a trusted third party to process a transaction.

In the first context, (there are two types of consent being employed) consent for a transaction is implied in the use of the card to pay for something by the Data Subject, and explicit consent is not needed because a contract is in place to govern these relationships. Thus the V.Next can then be used for when multiple justifications and parties are involved (currently a problem without a solution). (Note: Implied in the consent types listed above generally refers to surveillance.)

The use of consent types is intended to simplify and help standardise the notice to people. In this explanation to the data subject, the first consent type is "Consent not needed", but a notice that people can understand relative to context - still is needed. The requirement for a notice, even without explicit consent is universal for legal processing .. (unless there is a specified exemption)

[smartopian]

A notice receipt is used to manage receipt states, when the state changes or is updated (more like an administrative receipt that also fullfills the Controller compliance requirement to present an identity and contact when processing (or administrating) personal data. Since it has the identity info - it's great for notice updates about about a particular consent interaction. it is intended to make it easier for systems and people to maintain a mutual and shared state of understanding.

[smartopian]

In this V. Next proposal - the Consent Receipt should be clarified as Notice for all personal data processing - with the details of the processing - and a standardised notice component is consent types - which translates the processing into something that is meaningful to a human. Extending from the human readable requirement of the consent receipt v1.1 to a human a understandable requirement for all the V. Next receipt standard.

[TomCJones]

I am in general agreement with the direction this thread is going

[smartopian]

ok.. thanks for that great comments, Harsh. With these I have been able to edit this into something more sensible and less dense. (cut a bunch of bits like the intro) and I will work on a Use Case doc with a table for Consent Types mapped to legal justifications. Something that can be used to try them out in use cases. If anyone wants to challenge the consent type framework ? - pls send me a use case and I will add this to the doc..

[vjeuss]

this is very good.
my only thoughts -- but perhaps too early -- is to think of other cases such as sharing with 3rd parties, acceptance of changes, or that (incredibly interesting) break-the-glass. Would these be a a type of receipt?

[TomCJones]

I do not think it is too early to discussion notification after emergency access. I have started a wiki and talked to the chair of another Kantara WG. Here is my start to a spec on this https://wiki.idesg.org/wiki/index.php/Emergency_Access
I will look at US case - can someone else look at other country's solutions?

[HazardJ]

As the "founder" of CommonAccord.org, I greatly welcome this. In our view, consents are the leading edge of document automation. They combine the requirements of signature, proof, automated effects, and ... documents. In this respect they are quite like payments and other receipts. Consents are paradigmatic contract "artifacts". The parties need a log of them.
The text of the consents can be handled in Prose Objects. This permits efficient expression of them, as well as variations, tweaking, forking, etc. It also permits connecting the consents to the broader agreements and frameworks that provide the context for the consents. This process of collaborating on the (legal) texts, once started, can address most of the issues of data governance, and indeed all of contract.
A few examples: http://www.commonaccord.org/index.php?action=list&file=S/Index/DataSharing/