Consumers are increasingly demanding companies become more thoughtful with their privacy and data. The fact that companies like Facebook have failed to put proper safeguards on “who sees what when” has created an increase in consumer data protection laws driven by the very subjects of that data – people.
Of course, it’s almost impossible for consumers to understand what they have granted access to -- data sharing agreements are nested within current agreements that are already impossible to interpret. These issues are driving consumer data privacy to the forefront of every business conversation.
In fact, Garnter says that the concept of “Privacy-First” is becoming as important as other socially responsible labels such as organic or animal cruelty labeling.
Regulations such as GDPR, Open Banking and CPAA all require a level of dynamic data sharing critical to companies use. That is, a single click (like friending someone on Facebook) can no longer grant broad access to other people and organizations in perpetuity. Consumers, and the regulations that enforce these consumer desires, need to be able to know explicitly who gets to see their data, how it will be used, and for how long.
Dynamic privacy involves consent and enforcement – a third-party application needs to be granted consent by the consumer managed by the CIAM system and that consent needs to be consumed and enforced.
Let’s say the consumer wants to share data from their bank with our fictional “Financroo” finance application. The consumer grants this permission in the trusted CIAM system – it’s not simply a matter of handing over all access to the consumer’s account, but letting the consumer choose what data will be made available to the application and for how long.
Note that the consumer is given options for fine-grained access, the app can see the profile and account information for a credit card, for example, but it cannot initiate payments. Even more importantly, the consent has an expiration date – access shouldn’t be granted forever (as we often forget we even granted it), and the consumer should be able to specify when that access will be revoked automatically.
Then even finer grained consent for individual accounts can be applied, creating finer and finer grained access based on the intent of the consumer’s interaction with the application.
The Banking API administrator should be able to interact with the available permissions, not only adding required and optional data that can be shared but adding and describing the risk in certain kinds of grants to help the consumer understand the risks before granting access to third parties.
Now the app gets a new token and is able to connect to the banking API within the constraints provided by the CIAM Privacy service. Rather than giving an app broad access, this separation of responsibilities (the 3rd party application, CIAM service, and secure banking services) limits exposure to specific data that the consumer has explicitly granted access, limits for how long that access is granted and consolidates control in the consumer’s hands.
And it’s not just that the consumer has granted access – we also have to take into account when consumers revoke consent. Because the enforcement is aware of the changes in realtime, the revocation is as simple and seamless as granting access.
At the end of the day, consent isn’t just a yes/no gate, it’s a series of interactions that consider the intent of the application, the privacy of the consumer, and the changing nature of the relationship that can be easily enforced in distributed environments and multi-cloud ecosystems. We live in a dynamic, changing world and the tools we use to interact with that world need to be able to keep up with that change.