Musings on a global identity ecosystem: January 2023

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:

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