Musings on a global identity ecosystem: February 2023

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.

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