The DPDPA Rules on Consent Manager (Rule no 4 with Schedule 1) is disappointing since it indicates that the ministry is stuck with its concept of account aggregator and has failed to go beyond the myopic view that the consent manager should be an intermediary without any visibility on the data being submitted by the data principal to the data fiduciary.
It is strange that the Consent Manager is expected to be a platform to “Provide”, “Manage”, “Review” and “Withdraw Consent”, retain the consent information for 7 years, provide access to the consent all without having any visibility to the data exchanged.
Consent Manager is envisaged as a glorified log manager and the only personal data maintained is about the log account of the data principal. The log itself will have the information on the notice issued but not what the data principal has furnished.
For example, if the notice says, please give your name, address and e-mail, the data principal may give some name, some address and some email and the consent manager will not know what is the information given. He just keeps the log record that a notice was received and was responded to.
If the Consent Manager account is kept in the name of Vijayashankar Nagaraja Rao and I submit Vijay as a response to the notice, the consent manager has no way to know. If all the information required to be submitted to a notice is to be validated by the consent manager then he needs visibility to the data. If not, he cannot have any control.
Further, the consent manager may only have a few fields of data with him which can be automatically uploaded as a response to the notice and additional information may be either directly provided by the data principal directly on the data fiduciary website or through another data fiduciary (as indicated in the illustration). This means that the consent manager has to aggregate data elements available with him and the data elements collected from the second data fiduciary and populate the notice response in a “Data Blind Environment”.
The “Consent” in DPDPA environment is not a consent given by a data principal X to a data fiduciary B. It is a consent for a specified purpose of processing by B. It is possible that today I give a consent to B for Process 1 and next week I give a consent to process 2. Each notice is therefore distinct and the consent manager will not have the information with him for all the purposes for which I may like to provide consent at different points of time.
Hence his services are only useful to share information that either he himself has or what he can fetch at the instance of the data principal from another data fiduciary which may be the Digi Locker or another Bank etc.
Hence the replication of the Account Aggregator model to this “Consent Manager” was a mistake.
Having prescribed that the consent manager shall not have any visibility to the data exchanged by the data principal to the data fiduciary, or by one data fiduciary to another at the instance of the data principal, there is no need for stringent credentials for the consent manager and the capital criteria etc.
The rule as proposed has killed the potential of the Consent Manager who could have been used to assist in overcoming the language barrier and the tendency of data fiduciaries to ask for and obtain permissions which are not required.
Instead, the system envisaged duplicates the flow of data in the loop, data principal to data fiduciary-consent manager- data principal-back to consent manager- data fiduciary, where as presently the data principal while being on the data fiduciary’s web site provides all the information himself.
May be a “Form completion assistant” with a cookie could be a better option for the data principal to reduce his consent fatigue and fill up the forms faster than what he does not without reading and evaluating the permissions.
There is an urgent need to change the rule regarding the consent manager. …..
Naavi
