Mistaken identity; the mistakes we make and a lack of understanding about what identity actually is - part 6

Warning: this is part six 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].

https://www.globalidentity.blog/2022/11/mistaken-identity-part1.html

Part Six - If you don’t understand the locus of control problem you will never fix digital identity

Over twenty years ago we wrote the ”Jericho Forum Commandments”. Looking back and reviewing them they are not perfect, but as a set of principles they seem to have stood the test of time.

In particular commandment #8 “Authentication, authorisation and accountability must interoperate / exchange outside of your locus / area of control” heading up the section Identity, Management and Federation.

But what is the “Locus of Control” problem?

This is the “if you give it all to me, I can make it all work for you” conundrum, found in systems and organisations across the globe. Usually implemented with the best intentions by system architects and IT professionals, who are charged with delivering a working system.

Thus, since having to rely on a bunch of systems over which they have no control, they end up building a self-controlled system (that they control) - a locus-of-control!

We repeatedly see it in edicts like “everything must authenticate against Active Directory”, or these days, it must connect to whichever “glue” authentication provider we’ve chosen.

The problems is that this approach, while pragmatic, falls into the remit of the “law of unintended consequences”; (often cited but rarely defined), where you end up in a Catch-22 situation whereby the only way you make this work is to enrol ANYONE needing access into YOUR identity and access management system.

This results in my top-10 list of unintended consequences!

The biggest is (one of IT’s “dirty little secrets”) that there are organisation who have 100,000 staff on payroll (thus reasonably well managed) and 200,000 non-staff; contractors, JV staff, temps, visitors, and even employees of direct-competitors who also have an account on their system; who we can guarantee are not well-managed.

Governments are the same, in the desire to enrol citizens and provide them access to government services (or be able to more directly “control” them) then non-citizens who wish to (for example) work and pay tax need to enrolled as “dummy” citizens, in some cases for only a few weeks or months, potentially creating multiple disparate “identities” as they move from country to country.
You end up collecting attributes for which you are not authoritative, that go stale, as they are either poorly managed or never updated; ending up with silos of identity attributes the majority of which no one has any confidence in.
The loss of trust; where, if we do not have enough trust then we simply revert to starting again. How many times have you gone into a bank only to find that they trust the KYC (know your customer) check done by a rival bank? - never. Note: that the Swedes will point to BankID, a club of eight banks that with government backing have a basic level of interchangeable KYC, but go to Norway (who have a different version of BankID) and you must start from scratch!
“IT solutions” where everything needs to be authenticated against “this” one system (Corporate Active Directory implementations used to be a culprit here), and as a result you are unable to consume attributes from systems you don’t own.
And the counterpoint to that is you have an “IT solution” which cannot share any truly authoritative attributes it contains; and when it does (using SAML for example) it’s on the binary basis of “just trust us”.
As we move to systems each requiring their own identity silo, think Cloud / SaaS / Internal / 3rd Party services, we try to synchronise those multiple disparate identity silos, using one of the various “Glue” identity solutions, almost always sharing “binary” attribute assertions.
Liability, if you maintain non-authoritative attributes in YOUR locus-of-control, then sharing them carries a liability risk if a 3rd party trusts flawed information you provide! As a result your legal department will not want to share attributes that are stale, have variable provenance, or are just plain incorrect for fear of being sued. Conversely, the receiving organisation will rarely want to use these as they have no way of verifying the accuracy of the attributes, and rarely have any insight of your identity proofing process, or its fitness for their purposes.
We fix things for the bit we control (i.e. FIDO2 / W3C), as that’s the part we have some control over. The GSM organisation wants to extend the SIM to encompass better / stronger identification, whereas W3C is bringing stronger authentication to the web browser. Whereas this may be suitable for a subset of applications within that ecosystem, it results in fragmentation of the environment, and users that cannot understand why, for example, that being logged into their computer, (potentially strong) authentication needs to be repeated for each of the browser variants they use on that computer.
You end up with binary authentication everywhere, as most authentication systems pass on a binary “passed authentication” to the application, with no way of understanding the strength of binding between the entity and authentication method.
You end up delivering an “IAM'' system; because you need to control both the entities registered in the system, then “logically” to have a 1:1 match with what those entities can access. Thus we put them in a single system controlling both authorisation (Identification) and access management. [Coincidentally this is what most IAM vendors want to sell you] This leads to building large and complex centralised systems (Government IAM systems for their citizens, Corporate-wide IAM systems such as Active Directory etc.) which not only demands binary trust from any system you connect to it, but provides a single point of attack for the bad-guys.

The Jericho Forum work in this area had a number of insights in this area.

Probably, the best commandment we wrote was “Assume context at your peril”! (if I remember correctly, a contribution from the late Nick Bleach).

# Assume context at your peril!

Any binary assertion, or the reliance on a requirement to blindly trust the organisation / system / entity asserting identity attributes falls into the “assume context at your peril” trap.

Security solutions designed for one environment may not be transferable to work in another. Thus it is important to understand the limitations of any security solution.
Problems, limitations and issues can come from a variety of sources, including geographic, legal, technical, acceptability of risk, etc.
Where there is an attempt to use an identity silo, using federation solution, or SAML, or other glue identity solution this results in BINARY TRUST - the authentication is carried out within that system, and the relying part has to blindly accept (binary one) the authentication result, no idea about how authentication was derived, any additional attributes that may have been used, or even the threshold settings to a pass/fail.

So how should we design this? And what we need to do differently;

The Jericho Forum Commandments, under the section on Identity, Management and Federation gives commandment #8 as:

“Authentication, authorisation and accountability must interoperate / exchange outside of your locus / area of control”
with three relevant sub-clauses of:

There must be capability of trusting an organisation, which can authenticate individuals or groups, thus eliminating the need to create separate identities
Systems must be able to pass on security credentials / assertions
Multiple loci (areas) of control must be supported

To start to achieve this we first we need to separate authentication, entitlement and access management.

We need to understand that (traditional) computer accounts (UserId & Password) are actually only interested in “sameness”.
We need to stop referring to “UserID” as “User Identity”; it’s sameness to an understandable level of confidence - and at best “Unique User Identification”.
We need to design systems to deliver sameness with an understood level of confidence such that the entitlement layer (separating authentication from access) is able to take the decision to grant access based on enough contextual information such that confidence exceeds risk-appetite.
We need to only use “our” systems to contribute the assertions and signals for which we are truly authoritative, and ensure any entitlement layer is able to consume attributes and signals (with a known level of confidence) from other authoritative sources.

And a final thought:

There is a connection with the “passwordless” movement here; as passwordless aims to achieve an acceptable (where confidence level exceeds risk-appetite) level of sameness using a wide range of signals, and attributes from both the entities involved in the transaction chain, plus other sources of intelligence.

References:

Mistaken identity; the mistakes we make and a lack of understanding about what identity actually is - part 5

Warning: this is part five 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].

https://www.globalidentity.blog/2022/11/mistaken-identity-part1.html

Part Five - Why privacy and anonymity must be at the heart of your digital identity ecosystem

There are two famous (prophetic, as they are now over twenty years old,) quotes about tech and privacy:

“The privacy you’re concerned about is largely an illusion. All you have to give up is your illusions, not any of your privacy.” Oracle CEO Larry Ellison in 2001
“You have zero privacy anyway. Get over it.” SUN Microsystems CEO Scott McNealy in 1999.

If you do not already subscribe, then Have I Been Pwned? allows you to search across multiple data breaches to see if your email address or phone number has been compromised. At the last count my personal data has been exposed in seventeen major breaches; everything from date-of-birth, to home address and phone numbers.

And that’s before you perform a dark-web trawl on your name / job / company, and that’s even more scary.

Which leads us to the first (linked) conclusions:

If all your attributes are known, then what you should actually care about is: someone else being able to assert them as “proof” they are you.
When someone/something asserts that they are a particular entity (“hello I’m from your bank”) how can you verify the veracity of said assertion?

However, there are areas of your life where a failure of privacy is hazardous to your life: for example one of our collaborators is an Iraqi Kurd who lived in Iraq during the reign of Saddam Hussain; or that you have a subscription to “Gay Times” if you are living/working in Afghanistan; both attributes (or whole persona) that containing SPI (Sensitive Personal Information).

Which leads us to the first three tenets for privacy;

However, to ensure an ecosystem with privacy at its core; then THE fundamental design principle is the need for 100% anonymity at the root of any identity.

Though counter-intuitive to most identity and security professionals, it’s actually fairly obvious; that if you want to be able to issue linked assertions from disparate personas (see part four), then:

There must be a common root; AND
Only said entity must be in sole control of it; AND THEREFORE
It must be known and accessible only to that entity.

In addition, using this root of trust to make linked assertions, then the relying party (the entity receiving and needing to verify the linked assertion) must also understand the method by which the issuing entity is linked (the level of immutable linkage) to the root of trust; thus, they are able to factor this into their risk-equation for the transaction.

In real-life, you are your own Core Identity, and the immutable linkage between you and the assertion(s) is generally an approved photo ID (Entity:person → photo → name → matched attribute assertions).

Implementing this in the digital realm, there needs to be a known linkage between the entity:person with their “Core Identity” and their “Core Identifier” (their 100% anonymous “cryptographic root of trust”).

In part six, I will look at why understanding the “locus-of-control” problem is fundamental to proposing any solution in the identity ecosystem space.
https://www.globalidentity.blog/2023/02/mistaken-identity-part6.html

References:

Mistaken identity; the mistakes we make and a lack of understanding about what identity actually is - part 4

Warning: this is part four 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].

https://www.globalidentity.blog/2022/11/mistaken-identity-part1.html

Part Four - Making risk-based decisions based on understanding attributes in context

This is the start of the “how do we make it all work” part - and again the problem is, that how we make it work in the real world needs to be totally different from the band-aid “kludges” we cobble together in the computer world; And then we wonder why we can’t make it work, or leverage it everywhere.

So, let’s look at a real-world example of making a risk-based decision. For those that don’t know me, one of my “personas” is that of a white-water kayak instructor, with both Scouting and a local junior Kayaking club.

So, let’s look at what we would call the “entitlement” criteria if I were to offer to take your (precious) 13-year-old on the (London 2012 Olympic) white water course at Lee Valley just outside London.

Of course, in the “good old days” we would just have said “he’s a really good chap, and everyone says he knows what he’s doing”; but that was before 1993, when an outdoor activity centre killed four teenagers, (see: Wiki: “Lyme Bay canoeing disaster”); so in the UK we need to be properly licensed with risk-assessments in place.

Thus, I need to be able to offer a number of attributes, all from their authoritative sources, as a set, immutably linked to me (with a known level of certainty).

Proof I’m over 18, thus legally responsible
A current British Canoeing, Level 3 (or better) Kayak Coach qualification
A current scouting kayaking permit
A UK enhanced DBS Check (proof that I’m not prohibited from working with children)
A Lee Valley user card (proving I’ve passed their test to be able to use the course)

As you can see, each is from a different authoritative source, and that last thing those organisations want to do is maintain attributes for which they are not authoritative, because non-authoritative attributes go stale, and are near impossible to maintain; (and because if there was an accident and an inquest and it turns out that my taking them was based on their incorrect / unmaintained information then they could be liable).

Thus, the other lesson that can be drawn from this example, is that the “entitlement” check should be carried out in real time (or as near real-time as possible) using current attributes.

In addition, as the coach, I need to do a series of risk-assessments;

It's an outdoor course, what’s the weather like?
Each participant's personal capability, are they up to it?
Do we have the correct safety equipment and processes in place if there is an issue.
Have I been briefed by Lee Valley staff on any current issues / changes / new processes.
Dynamic risk: e.g., We start to get freezing hail, do we end the session (hypothermia risk) etc.

Of course, as humans we do variations of that risk assessment continuously and mostly subconsciously, from crossing the street, to walking down a dark alley at night, meeting new people, or deciding to take a new job.

So, this leads us to a series of “principles” on how to process attributes in context, resulting in a risk outcome that meets the risk-appetite of the entity taking the risk; remembering that risk is bidirectional but asymmetric.

As the consumer of the attribute(s)

Risk is temporal, and WILL change over time, thus must be re-evaluated in line with your risk-appetite.
Attributes must be consumed in the full knowledge of the entity that signed them. (Remembering that some attributes could be self-asserted).
Attributes must be consumed in the full knowledge of the entity that is presenting them, and level of immutability between presentee and the attribute they are asserting.
When multiple attributes, from potentially disparate personas, are asserted, then you must have an acceptable level of proof that all the attributes are linked to that single entity.
Only request attributes required to support your risk calculation, or meet a legal obligation (such as KYC).

As the intermediary

(Never turn a variable into a binary) always pass on the attribute, and the provenance of the attribute, so the entity taking the risk can evaluate the whole picture.

As the issuer/signer of the attribute(s)

Only hold, maintain and sign attributes for which you are truly authoritative.

As the presenter of the attributes

(Where possible) only present attributes in a privacy enhancing manner (“I am over 18” rather than “Date-of-Birth”).
Understand why attributes are being requested, and reject requests/transactions that over demand attributes.

Two final thoughts

The evaluation of risk is not just about evaluating the asserted attributes; it also needs to factor in as much supporting information as possible.

Maintaining groups of attributes in a “persona” that is tied to the authoritative source has major security advantages; as all they are doing is maintaining their attributes, thus if they are breached, or their signing key is compromised, then they need to re-issue the key and attributes at their cost. However, as they hold/maintain no others, nothing else is affected.

In part five, I will look at why privacy needs to be at the heart of any identity ecosystem.

https://www.globalidentity.blog/2023/01/mistaken-identity-part5.html

References:

Mistaken identity; the mistakes we make and a lack of understanding about what identity actually is - part 3

Warning: this is part three 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].

https://www.globalidentity.blog/2022/11/mistaken-identity-part1.html

Part Three - Consuming attributes and understanding persona to derive context

Being presented with an attribute of my identity without some form of context is somewhere between meaningless and slightly useful. Let's take the example of buying a bottle of whiskey and asserting my age;

In real life, unlike the computer world, there are few if any absolutes, everything we do, and more importantly the decisions we make are based on context. If I were a social scientist, I would now be making an argument about context being predominantly learnt prejudice, but let's not go there.

In person, grey hair, probably OK, no further attribute required
In person, entering bar, Chicago, grey hair, mandatory photo ID (with date-of-birth) required
In person, UK, look under 25, photo ID with DoB probably required
Over the Internet; some countries, no problems, just buy it!
Over the Internet; in country, with country specific ID, you stand a chance
Over the Internet; without being enrolled in “their” age verification system, probably not
Apart from being a complete lottery when presenting attributes, we need to look at why it sort-of-works face-to-face and generally fails when not face-to-face.

We need to understand who is truly authoritative for the attribute I am asserting. In my case the UK Government, thus there are generally two authoritative documents issued by the UK Government generally acceptable as they have both photo and date-of-birth; namely my UK Driving Licence and my Passport.
Because of international treaties, my passport generally works globally, and my driving licence less so.
I say that because I was at a US conference where a booth was showing their tech that enrolled you into their identity verification system, validating your age via your driving licence, so I gave them my UK licence and was told - “Oh no, this only work on new US ‘strong’ driving licences”.
Had I managed to enrol my UK Driving Licence into their system, then asserting my identity via that US service in the UK is probably a complete waste of time, as a UK supplier will not recognise it at all, and certainly not as authoritative.
In fact, even the big UK banks, which generally are fairly “joined up” and consistent, will not accept each other's assertions for KYC (know your customer) checks.
Our corporate account is with Barclays, obviously with full KYC checks. As a trustee on my late-Father’s trust for his grandchildren would Halifax accept this? - of course not; despite both being British high-street banks, subject to the same UK banking regulations – Halifax required that I turn up in-branch with passport, proof of address etc. - all so a very junior employee could take photo-copies of them.
Bottom line, in real-life we assert an attribute from a persona, often multiple attributes from disparate personas (that are linked at the root - i.e. me), and as long as the entity requiring these attributes is able to validate the entity that signed them, to their level of satisfaction, the transaction is able to proceed.

Why? Because the entity receiving them is able to understand them in context, so for example for my whisky sold over the Internet the contextual decision goes something like this;

Is over 18 AND IF in USA over 21 - signed by relevant government
Will pay for it, signed by VISA OR MasterCard OR Amex OR PayPal
Have valid delivery address signed by relevant Post Office AND not a prohibited country

In reality, we constantly assert attributes from multiple personas, that all need to be provably linked. Easy in real-life (remember that photo linking my personas), however in the digital world we need cryptography and common (single & anonymous) cryptographic roots of trust - but more on that in a later blog.

For now, let's just leave it as Identity (Authentication, Sameness, Personas and Attributes) that all allow the derivation of context, and from context we get into risk-based decision making - but that’s part 4.

https://www.globalidentity.blog/2023/01/mistaken-identity-part4.html

References:

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].
https://www.globalidentity.blog/2022/11/mistaken-identity-part1.html

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.

https://www.globalidentity.blog/2022/12/mistaken-identity-part3.html

References:

Mistaken identity; the mistakes we make and a lack of understanding about what identity actually is - part 1

Identity has a problem!

Not just that we are unable to make digital identity work properly without loads of compromise; no, it’s the fact that IT Architects, Security professionals and (dare I say it) even many claimed identity specialists, do not understand what identity is, misusing the term and even getting the wider aspects of identity fundamentally wrong.

Without properly understanding identity, its facets and nuances, it will be impossible to develop a frictionless global identity ecosystem, or leverage identity for cloud, zero-trust, collaboration, encryption and proof of age, or other essential attributes.

Warning: this is intended to be a nine-part blog looking and expanding on what identity is, starting with this blog!

Part One - Identity fundamentals, or “what is identity?”

Strictly, Entities have Identity, (but that’s going to be part 2!) so first, let's start with people, as that’s what you and I best relate to:

“I am me” - I am a unique entity, we call this Sameness; I am the same entity yesterday, am today and will be tomorrow.

As a unique person I have multiple “facets” of my overall identity, some of which I care to share and some I may never share with anyone, all maintained personally by myself; some attributes we just know (for example family relationships) and some we maintain “pointers” to; references to the authoritative source, such as the assertion that I’m a British Citizen because my passport says so (and is authoritative for this assertion). We refer to this as the “core identity”, all the attributes that make up me as a person.

Those “facets” of my overall identity consist of attributes; some like my height, the colour of my eyes, and a rough approximation of my age which I am unable to keep private if you meet me in real life, but others such as sexual-pursuasion, the football team I support, my favourite colour, my family etc. I may choose to share with you depending on my perceived sensitivity of the attribute, how much I trust you, and your need for that information to process our relationship; in reality I perform a risk-assessment, based on my personal risk-appetite.

In reality; we have sets of attributes that pertain to a particular aspect of our lives, and we call these personas - a group of related attributes that define us in a particular context. Examples would be:

My citizen persona: (in my case as a UK citizen, what is on my state-issued birth certificate) date of birth, place of birth, both of which are immutable, name at birth, sex-at-birth and right to British citizenship - all of which could change.
My family persona; parents, partner, children, aunts, uncles etc.
Employment persona(s)
Sporting persona(s)

You get the idea; and in reality each of us as humans operate with hundreds, if not thousands, of personas, and we assert attributes from multiple disparate personas as required for our day-to-day lives and our interactions with other entities.

What normal humans glibly call “Identity” actually consists of three distinct components.

“Authentication”; the “how do I uniquely prove that I am the same person that you previously met”
“Sameness”; the “I am me, and always will be” part that contains personas, and attributes
“Personas & Attributes”; The parts of my core identity that I decide to share

Authentication is key to interacting with other entities; in real life humans, due to millions of years of evolution, do authentication using faces - in fact we are so good at it that if you meet someone you have not met for ten years there is a good chance you will remember who they are.

Faces are so key to human life that phrases pertaining to this interaction are embedded in our language; “it’s nice to finally see you”, “they are two-faced”, “put on a brave face” or even “put your cards face up”.

When we see someone, we assign the attributes they share (consciously or unconsciously) against an (internalised) unique identifier of their face. In other words, Authentication (by whatever method, and however tenuous) is the key to Sameness.

This is why your driving licence or passport has your face on it; to link the person to the attributes contained on that document with a degree of confidence.

This level to which a person is bound to the authentication is known as the level of Immutable Linkage (or Immutable Binding), and it's important to understand the level as part of your risk-calculation; with what degree of certainty the actual person is linked to the identifier. - I look enough like my brother that if you have not seen us for ten years it’s not unusual for friends of my parents to get us wrong when they meet just one of us (but not I suspect if they met both of us together).

However, the problems start when we cannot interact “face-to-face”, and for many thousands of years civilization has grappled with this problem, accepting a set of compromises, usually based on the bearer holding a set of documents to which some degree of provenance can be given - read the history of the passport!

So, in summary; we as people can derive a model for how identity works in real life. But, as people ourselves, we are fixated on how to extrapolate this to the wider, non-face-to-face, world; which is why we are in the current mess with digital identity.

So in Part 2, we will examine why the identity of people is just a small part of the overall identity picture.

https://www.globalidentity.blog/2022/11/mistaken-identity-part2.html

References:

https://en.wikipedia.org/wiki/Passport
https://www.globalidentityfoundation.org/downloads/Identity_30_Definitions.pdf
https://www.globalidentityfoundation.org/downloads/Authentication_to_Risk_Triangle.pdf