I had cause recently to participate in a workshop considering identity across an enterprise and I wanted to share some of my thinking which was unexpectedly useful.
Identity is a slippery thing, it has real world hooks but in the digital world it can be many-faceted and complex. Both real world and digital identities are heavily context-dependent and in both domains there is a temptation to simplify for ease of administration as well as reuse across contexts without considering the implications both for the subject of the identity and for transactions then conducted with that identity by the organisation.
Creating identities without conscious consideration of the identity’s characteristics will eventually lead to greater uncertainty, greater complexity and ultimately greater risk for the organisation as a whole.
Smaller organisations may only have staff or customer identities, with customer identities being a single consistent thing across a small selection of products and services. Even here though a simple identity based on an unverified email can cause problems when sending sensitive data to customers.
This simplicity is not true of large organisations with large customer bases. Here you may have multiple types of staff (internal, partners, suppliers) as well as very distinct customer bases across different products and services, the same customers may want to exhibit different behaviours interacting with different products. For example, customers likely behave differently on LinkedIn versus tinder and if someone tried to combine those two online identities into one to simplify their customer relationship management the customers may well consider giving up either or both of those identities.
Identity Characteristics
When you create an identity there are several contextual characteristics you need to think about and when reusing an identity created for a different product or service you must consider these characteristics else you might paint yourself into an uncomfortable corner.
| Scope | This describes where an identity is expected to be used, which likely translates to which products or services will rely on this identity. We also need to ask; – Do we need to create it?, – Can we let another organisation create it?, – Can we let other organisations use it? |
| Uses | Different uses of an identity will have different requirements. Knowing your position in a queue is ephemeral and requires no personal data attributes whereas. convicting someone in a court of law requires a different level of strength of positive identification. |
| Strength | The required strength (richness, confidence, validity or verification) of the identity will depend on the uses it is intended to serve. Creating an identity stronger than required may put off potential customers whereas creating a weakly-verified identity may limit future reuse of the identity with an uplift in verification in the user journey to get more risky transactions such as paying money. |
| Legality | The legal basis by which you create an identity is important; both in terms of the uses to which the identity can legally be put as well as the downstream sharing of identity and potential liability from other organisations dependent on the identity created or transmitted by you. |
| Sensitivity | Some identities are more sensitive than others. No-one wants their personal data attributes leaked but for a victim of domestic abuse hiding from their abuser or for an undercover policeman with a family outside of work these identity characteristics, once added to an identity, become hugely sensitive. This would affect both the level of security constraints the organisation should enforce around the storage of identities but also limit the extent to which these identities can be shared. Inference is a great problem here in a world of easy access to powerful data science platforms and open data. |
If you are clear about the use case/s with which you intend to use an identity then the characteristics in the table above should be fairly straightforward to identify.
Where complexity and uncertainty rear their heads is when identities have been reused across a diverse customer journey consisting of multiple products and services. Especially where the transaction risk for the initial identity creation use case was low but the later transaction use cases become increasingly risky. In that case either the user experience must cope with an increase in the strength’ of an identity or the organisation must take greater risk that they do not necessarily know who they are transacting with reliably.
Recommendations
Without recommending that you create identities with characteristics you don’t currently need, and also highlighting you may have no legal basis to do so, it is worth considering the lifecycle of the identity across your enterprise suite of products and services. You should look for opportunities to minimise the risks of reuse as early in the customer journey as possible as well as minimise the number of identity changes customers must go through.
I do strongly recommend you map the characteristics from the table above to each product and service and then map each to their position on the customer journey to make explicit the dependencies and risks in order to make conscious decisions about creating and reusing the customer identities you manage.