Consent Management allows customers to define policies that an end user wants to agree upon, typically to share their personal information. What is configured here is what shows up for end users, to Agree or Disagree, based on which, appropriate data sharing can be done.
It allows user to approve and withdraw consent and then create personal experiences from that. Identity management has traditionally been more focused on data protection than granting individuals control.
Once a consent group is created and enabled, it is a required field in your site schema as a condition for login. A new user cannot register to your site without at least viewing this policy.
Consent can be defined in many ways but let us focus on the digital world. In simple words, consent is an expressed “green light” that allows an organization to do something with your personal data. Without your explicit consent, an organisation can’t legally collect, store or process your personal data.
The problem with consent In real life, we’re giving consent at all times. The biggest lie on Internet is that tick-box we’ve all checked: “I have read and I agree to the terms and conditions.” The phrase depicts how lightly we take consent. Even if we put in the effort, today’s systems and procedures are not designed to protect people’s data. The problem with consent is not one but many:
Terms and conditions are usually lengthy and written in a language that only lawyers can understand.
Consent is usually bundled giving the user only two choices: all or nothing, take it or leave it. The typical case is a mobile app that asks you access to your location even though it’s clearly not needed. Why does a torch app need access to my location or microphone?
A person can’t keep a record of what personal data was given, to whom, and for which purposes (the boxes that ticked and what was written in the terms and conditions that specific day). Such a record is stored only in the organisations’ database.
Due to a increased awareness on these problems, in recent years we have seen more stricter data protection regulations, such as European Union’s GDPR (General Data Protection Regulation). However, the third and last point requires a more technical approach, and the concept that is emerging to fill this gap is “consent receipt.”
A consent receipt is a proof document that you receive every time you give consent to process your personal data.
A Consent Receipt is record of authority granted by a Personally Identifiable Information (PII) Principal to a PII Controller for processing of the Principal's PII. The record of consent is human-readable and can be represented as standard JSON. This specification defines the requirements for the creation of a consent record and the provision of a human-readable receipt. The standard includes requirements for links to existing privacy notices & policies as well as a description of what information has been or will be collected, the purposes for that collection as well as relevant information about how that information will be used or disclosed. This specification is based on current privacy and data protection principles as set out in various data protection laws, regulations and international standards.
As of today, there are almost no implementations and the most promising standard is Kantara Initiative Consent Receipt. Mostly based on Kantara’s approach,
I will use a simplified explanation to show you how a consent receipt would be in practice. You can find three main building blocks in a consent receipt:
Receipt and transaction information (date, time, place, purpose of collecting data, receipt number, language)
Individual’s details (name)
How to use that kantara consent management features in my portal.
Go to cidaas administrator dashboard->Settings-> Consent Management
The Consent Management systems follows the kantara standard
Consent Receipt Header:
- This header contains receipt and transaction information (consent name, place, purpose of collecting data, method of collection, language, type)
Note: There are two types of consent here 1) Login: During login ask consent from users. 2) Action: while downloading or any situations ask for consent from the user.
An Administrator can specify the purpose of consent specifications and those must be fulfilled. The below mentioned specification information is maintained by kantara standard.
Service Name: Give the name for purpose of consent.
Description: Administrator can describe the privacy and terms and condition information are mentioned here.
Purpose of category: kantara standard provide categories the consent, for example (core functions, contract service, marketing ect..).
Personal Identity Category: we can get consent details users in the following. Example: ( Biographical, Biomatric, Contact, Social_Contact)
Terminiation: An Administrator can specifiy the consent page expiry date after which the data that was mentioned is not shown on the page.
Only after all mandatory fields are filled, one can click save button to successfully create consent. Consent details can be updated later on.
Once the consent group is added, it is used during the create App. For more information refer Advance Settings.
When User logs in to user self-service portal, the below Consent Management screen gets displayed,
Select the checkbox next it and click “Agree” button (this is a one-time agreement to sign in).