COMMENT OUR ARTICLES ON LINKEDIN

How to get rid of hundreds of logins/passwords?

2024-11-09 11:40
How many logins and passwords do you have? A hundred? Two hundred? It’s maddening, yet we’ve come to accept this as a reasonable trade-off for the convenience of accessing hundreds of platforms, services, and online stores.

But let’s take a moment to consider how we might solve this issue. One seemingly obvious solution is a Single Key for all online and even offline systems. The European Commission is heading in this direction with the eIDAS standard. However, this doesn’t actually solve the problem. The real issue with eIDAS isn’t technical, but lies in how the problem is framed. So, what would the right approach look like? Let’s start by exploring that in this article. Prepare for a journey, much like in The Lord of the Rings.
Now, seriously, how many logins and passwords do you have across different systems? I have about 200.

I see this as a huge problem.

And not so much for myself (since I know how to encrypt my password database or use my browser to remember them), but for my mother, who is well over 70. She’s going crazy trying to write everything down in a paper notebook, and almost cries when she can’t find the right password for the electric company’s website. She lives in constant fear of losing or forgetting something.

And this isn’t just my mother’s problem – it’s a global issue.
We understand that this situation arose historically because every platform – from Uber to the electric company that serves my mom – needed a way to identify and authenticate its customers. So, every platform created its own registry with unique logins and passwords. And we, the users, ended up with hundreds of credentials.

But now, even the platforms that gave us these hundreds of logins and passwords recognize that the situation is worsening every day, and that something urgently needs to be done.
The solution is obvious: we need one key for all platforms!
(And if you know the field, you’ll likely think of eIDAS right away.)

“Wait, wait, wait! Even the platforms get this?” you might ask in surprise.

Yes, exactly. At a recent e-commerce platforms conference, I heard how tired they are of managing their own user registries. Not only is customer onboarding (creating an account, entering basic information) costly – especially when someone’s just buying two school notebooks for €3 with delivery – but it also frustrates customers. On top of that, regulators keep imposing new requirements for handling personal data, and e-commerce platforms are losing huge amounts of money on mistargeted advertising.

For instance, if a customer has spent a long time searching for and has just purchased a washing machine, your ad operator (like Facebook) will stubbornly continue wasting your ad budget on showing them more washing machine ads, instead of switching to promoting laundry detergent!

Of course, online stores would love to recognize customers across different platforms. This is also a win for the customer: they don’t want to keep seeing (and effectively paying for) washing machine ads for two months after buying one. Nor do they want to re-enter their shipping address at every store. At the same time, customers still want the option to stay anonymous in some cases.
Indeed, platforms and users need “One Key” for a user for totally different reasons, but for us – users – it is good to know that platforms are ready to move toward this goal.
Now that we see this theoretical readiness from platforms to embrace the One Key concept, it's crucial to clearly define the user experience and set the right requirements – ensuring we don’t get caught up in the limitations imposed by eIDAS.

One Key. User Experience. Defining the Requirements.

Let’s try to outline the ideal user experience we’d want.

First, a single key means no more logins or passwords.

Sounds surprising? In reality, it’s much more intuitive and natural than you might think.

Imagine the ATM recognizing you, the border officer knowing who you are, the car-sharing service in a foreign country greeting you, and even the bartender in Tierra del Fuego serving you by name. You use the same key everywhere, and you’re instantly recognized as a trusted client. With this key, you’d vote, sign a contract to buy a house, or transfer money.
Of course, there’s a crucial detail – you won’t always want to be recognized.
In some stores, you might prefer to remain completely anonymous, with no way to be identified, even through your payment method.

In certain local bars, however, you might want to be known as “John Smith,” without revealing your real identity – like using a pen name.

And naturally, you’d want to avoid any cumbersome onboarding process, whether in online stores or when switching to a new utility provider.

They should recognize you right away and access only the data you choose to share (and the less, the better!). If you move, you certainly shouldn’t have to update your address across every store and service!

What else do we desire? Of course, security!

No one should be able to steal your key without your knowledge, except perhaps by taking your phone where it’s stored. In that case, you’d easily see the absence of the phone, block the key and get a new one, much like a bank card replacement.

Let’s consider an extreme scenario: you’re traveling by boat, it sinks, and you find yourself on the shore of another country with no belongings or documents. Even in such a situation, you should be able to obtain a new Key within a day and re-claim your identity.

And one final requirement: the system’s lifespan should far exceed a person’s lifetime – essentially, we’re talking about centuries. And this isn’t an exaggeration. After a person’s death, their identity still matters: there’s a will to distribute inheritance among heirs, and intellectual property that continues to generate income for many decades.

Now we have a fairly clear set of requirements for our The Key, which would govern all platforms and services, both online and offline.

It’s time to see the Identity architecture which can address it all!

Introducing the Identity Pyramid

First of all, we need to understand the depth of the system for Identity Management we’re aiming to build. It’s like constructing a building: the deeper you drive the piles, the more substantial the structure you can create.

From a technical perspective, we need to link this One Key with a User.

We call it the Identity Pyramid:
It’s obvious that the user cares only about the One Key at the top.

This is where the European Commission steps in with eIDAS to offer support.

  • eIDAS clearly recognizes that at the moment the User gets the Key (actually, a pair of keys, the public and the private keys) the public key of the user needs protection from the notorious man-in-the-middle attack.
  • As this risk is mitigated with the Public Key Infrastructure (PKI), the eIDAS introduces such PKI system, which issues and signs a certificate (for example, in X.509 format) that securely links the Person’s public key to their name or passport.
  • eIDAS also does a great job, ensuring that PKI systems from different countries can trust one another.

(If you’d like a 20-minute crash course on man-in-the-middle attacks, keys, and the role of PKI, this video might help.)
However, the problem is that a person’s name can change. Their passport can be lost. And, if your public Key is linked only to your name and a passport via X.509 certificate, 30 years later, proving that you’re the same person who bought a house three decades ago could become difficult.

And eIDAS won’t help you here. It also won’t help in recognizing a person after a shipwreck, as we demanded in the user requirements section above.

If we draw the depth of the eIDAS approach on the same Identity Pyramid, it won’t even reach the Level 2, as it cannot reliably define a User:
eIDAS also doesn’t solve the problem of preventing your private key from being copied. Its primary mission is to provide a global PKI service, and for that, we are indeed grateful.

Therefore, eIDAS leaves a Terra Incognita below the Level 2 of the ID Pyramid, and we have to dig deeper, if we want to make my mom happy.

The Terra Incognita

Let's agree on names. For if we haven't agreed on names,

what can we even discuss here at all?

–Confucius
Indeed, linking a public key to a person’s name or passport using an X.509 certificate is like building a house on sand. Names, passports, and any other documents can change or be lost. Even a person’s DNA can be altered by modern therapies. In reality, no characteristic of a person remains unchanged throughout their life. Then, what is the persistent (meaning not changing for decades!) anchor we link the public key to?

So, we’ll need to invent the Persistent ID. We will call it an Identifier (level #2 on the diagram). This is a very long (but not very secret) number, something like 92834753825723845560234856320465, assigned to you at birth and lasting for your entire life. You may change your name, passport, nationality or even gender, but the house which you bought for the ID 92834753825723845560234856320465, still belongs to you.

Essentially, the Identifier is the digital equivalent of the phrase "the same customer" in this sentence: "The same customer who bought a Whirlpool washing machine on Amazon yesterday just walked into our store. Let’s sell them some laundry detergent!"

Thus, the Identifier stands as a very stable anchor between the person and their Key, allowing to connect the Key to this anchor, and then linking the anchor to variable and unstable characteristics of the user as their names, passport number, fingerprint, eyes, or friends.
Only with the Persistent Identifier this entire structure becomes sufficiently durable and reliable.
Let’s re-draw this Identity Pyramid, with the Persistent Identifier, which takes the place of the User. It moves user down, to the level 3. And as we would like to accent the physical nature of the user’s body, we will call them the Real Person.

NB! It’s the second layer of relationships (between layer 2 and 3) – between the Identifier and the person’s body – that presents the real challenge . Since no characteristic of a person remains constant throughout their life, we can solve the problem of “the naked person emerging from the sea” only by linking their Identifier to a combination of their characteristics: DNA, retina scans, fingerprints, and even a network of friends who can vouch for their identity. It is done by a set of binding documents.

While every one of the binding documents may be wrong (e.g. the passport is gone or the fingerprints are erased after long time in the water), the combination of several binding documents provides a reliable proof of identity.
In this article, we won't be able to explore the topic of identifiers in depth, so a dedicated article on this will be published later in our Web 3.0 Data Space library. For now, we'll touch on a few unique requirements for identifiers, stemming from the user experience described earlier.

  1. Identifiers will be issued for life – not only to individuals but also to organizations and even objects. They must be unique and preserved for centuries.
  2. Most importantly, the authority to issue identifiers cannot be delegated to any organization (or government) worldwide. A centralized registry, similar to DNS, is not an option. The system must be decentralized.

It is crucial to note right away that all these requirements are achievable, and their solutions naturally lay the groundwork for the future internet, which we refer to as the Web 3.0 Data Space.

In this Web 3.0 Data Space, the absence of hundreds of logins and passwords will be just one feature, alongside many others, such as the elimination of data silos and platform monopolies, as discussed in other articles.

Conclusion

Thus, we examined the Identity Pyramid, beginning at the top, where users have a simple request: to be provided with a single key. Moving downward, we addressed the 1-to-2 relationship, which is reasonably well covered by eIDAS. However, as we continued, we ventured into Terra Incognita, which requires the creation of a Persistent ID and the management of Binding Documents.

Our vision for how this can be implemented within the Web 3.0 Data Space will be detailed in the upcoming articles announced earlier as part of the "Web 3.0 Data Space library."

If we mark the architectural depth of the Web 3.0 Data Space and eIDAS solutions within the familiar framework of the Identity Pyramid it will look like that.
To make this final picture more interesting we have also indicated the depth of the blockchain technology, which fails (or perhaps intentionally avoids) addressing the relationship between keys and identifiers, instead taking the misguided route of equating an Identifier with a Public Key.

We’ll dive into this and other blockchain issues in one of our forthcoming articles.
Join the discussion on this article on LinkedIn!