Mistaken identity; the mistakes we make and a lack of understanding about what identity actually is - part 2
Warning: this is part two of what is intended to be a nine-part blog looking and expanding on what identity is!
If you have arrived here directly, then please go back and start at part 1 - after all, in the Identity world context is everything! [sorry for the identity in-joke].
Part Two - Entities have identity, not just people
Back in Part One of this blog, I talked about computer professionals being fixated with digital identity for “people”. If you think about where we have come as an industry, we started with computers (which when they were only mainframes were god-like and implicitly trusted) and we then introduced the concept of “users” - people who, if they were lucky enough, were granted the privilege of being able to interact with these entities.
From there, we went to multiple computers which needed a central computer managing user authentication, which (sort of) worked, but ONLY if all the users were managed in our “Locus-of-Control” [See: Ref 1, command #8] (a system that we own, manage, and of course vet the users prior to giving them a user account) - historically for most organisations this ended up being Active Directory. But the instant we need to involve users or systems outside of our locus-of-control then things start to get difficult and compromises start to occur (a topic for a different blog).
So let's go back to first principles and look at how identity operates in-real-life, and what we are doing wrong.
We, as humans, need to interact with a wide variety of entities; from organisations to devices and of course to other humans. Back over ten years ago this led us to explain this in terms of five basic entity types that explain the breadth of what we are describing; People, Devices, Organisations, Code and Agents. But in fact it’s wider than that; and you could generalise an Entity as being “any unique instance of a ‘thing’”.
Why are entities so important? #1 Because they enable personas
If you generalise how identity and attributes work: then the join of two entities forms a unique persona, populated with some (hopefully) authoritative attributes.
Let's think about this with a few examples;
The join between Entity:Me and Entity:UK Government creates my unique “Citizen Persona”
The join between Entity:Me and Entity:Simmonds Family creates my unique “Family Persona”
The join between Entity:Me and Entity:UK DVLA creates my unique “Driving Licence Persona”
The join between Entity:Me and Entity:ACME Plc. creates my unique “ACME Plc. Staff Persona”
In the first example above, my citizen persona (in my case as a UK citizen, what is on my state-issued birth certificate) contains attributes issued by the authoritative source for children born in the UK, which are:
Date of birth (immutable)
Place of birth (immutable)
Name [at birth] (could change)
Sex [at birth] (could change)
Right to British citizenship (could change)
If you’ve been into any financial institution for a KYC (know-your-customer) check then you will know that they insist on original documents from (mainly) authoritative entities, one of which must be photographic (passport or driving licence etc.) so that they can tie the name on the other paperwork to your face, thus having an acceptable level of Immutable Linkage between yourself and all the attribute assertions you are making, as a linked-set (i.e., they all have the same name).
Effectively you are asserting different attributes, each “signed” by a source that the bank recognises as authoritative, as a linked set with you at the root of that assertion.
Why are entities so important? #2 Because over a network you can’t (easily) distinguish a person from any other entity type.
In reality, you don't actually know whether it's a person, an AI, an IoT device, a system or a hacker at the end of the conversation. It's a bit like a modern Turing Test, only more difficult, because not only are you trying to determine whether is a particular type of entity, you are also trying to determine that the credentials match the actual entity claimed - just because the password matches, or even the API says “biometric match” does not make it 100% the entity claimed.
It’s a bit like being robocalled by an AI, or a hacker using a deep-fake - and they are getting better day-by-day - so it takes a while to understand (and test) whether it’s actually a person. We should be validating the person randomly calling; does the Caller-ID match? Can they provide evidence of the organisation they are calling from? Can they prove who they are? - Of course, if it is someone we know personally, or even intimately, then it’s easier to check for “shared secrets”, but otherwise, as numerous politicians who have been prank-called by radio-stations have found out, it can be very difficult.
So, when communicating remotely, we should care about the fidelity of an entities assertions of who/what they claim to be, as well as the level of immutability between the entity and the claim.
In Part 3, we will examine why consuming attributes and understanding personas is key to deriving context.