Think about how permissions work in everyday digital life.
- You download an app.
- You create an account.
- You accept the terms.
- You enable a feature.
And somewhere along the way, a relatively simple decision becomes permission for an organisation to access, retain or connect far more information than you originally intended.
We have become accustomed to permissions being broad because the systems behind them are broad.
But consider how differently we behave in the physical world.
- I might give a hotel my payment details without giving the hotel access to my medical history.
- I might show someone my driving licence without giving them access to my bank account.
- I might give a colleague my professional contact details without giving them access to my family life.
We instinctively understand that permission has context.
Yet digital identity has often struggled to preserve those boundaries.
One Person Does Not Mean One Permission
This becomes particularly important when organisations think about identity.
A person is not a single, indivisible collection of information.
The information relevant to one interaction may be completely irrelevant to another.
So perhaps permission should not begin with:
What can this organisation access about me?
Perhaps it should begin with:
What am I permitting for this particular interaction?
That is a very different relationship.
For Greenfield Services
For a new platform, this creates an opportunity to make boundaries part of the design from the beginning.
Instead of building one large customer identity and then creating increasingly complicated rules governing access to it, different contexts can remain deliberately separated.
Permission becomes specific rather than assumed.
That can create a simpler proposition for the person using the service:
You are not giving permission to “you”. You are giving permission to this particular part of your digital life, for this particular purpose.
For Existing Organisations
For established organisations, the challenge is more significant.
Customer information may already cross products, departments, platforms and technology systems.
The adoption question therefore becomes:
Are the boundaries in our systems the same boundaries our customers believe they are agreeing to?
That is not simply a privacy question.
It touches customer experience, governance, risk, organisational design and trust.
An organisation might technically have permission to use information.
The more important question may increasingly become:
Would the customer reasonably expect it to?
Permission Should Have Boundaries
This is where Identity Containers as the Unit of Permission becomes interesting from an adoption perspective.
Instead of treating the individual as one large permission surface, the principle creates boundaries around different contexts of identity.
That changes the conversation.
The objective is no longer simply managing access to data.
It is preserving the boundaries within which permission was given.
And that is something we already understand intuitively in everyday life.
We don’t give everyone access to everything.
Why should digital life be different?
A Question for Leaders
Look at how permission works across your organisation.
When a customer says yes to one interaction:
What else are they unknowingly saying yes to?
That is the adoption question behind ICCA Design Principles: Identity Containers as the Unit of Permission.
The underlying ICCA work is being openly shared under a Creative Commons Attribution-ShareAlike 4.0 licence, encouraging discussion, challenge, adaptation and further development.
The paper describes the architectural principle. This article asks what adopting that principle could mean for people and organisations.
#ICCA #DigitalIdentity #DigitalTrust #PrivacyByDesign #CustomerExperience #DataGovernance #Leadership #DigitalTransformation #DataPrivacy #CreativeCommons