Image for post
Image for post

Theo walks into his favourite store. He looks at a pair of shoes that he has wanted for a while and finally has enough saved to buy them. He tries the shoes on, finds the best fit, walks up to the cashier and pays cash for the shoes. The cashier gives him a receipt so he has some sort of proof that he bought it.

Seems normal right? How about we replay that transaction in the online world.

Theo tries to walk into a store, except he is not allowed in until he tells the security guard his name, date of birth, address and agrees to a secret hand shake. The guard also tells him that he now owns this information and might sell it to others that want it. Theo understandably says no thanks and leaves. He goes to another store that lets him look and try on the shoes without security bothering him. When he walks up to pay however, the cashier asks similar personal questions to the guard at the previous store. He can’t buy the shoes if he doesn’t answer the questions, but at least this store doesn’t sell his personal information. He looks at the other people in the line, sees that they are all doing it, shrugs his shoulders and reluctantly agrees.

Hopefully you can see the thread here. A basic economic trade is occurring whereby an individual is parting with money in exchange for goods or services. Why then do we consider the second scenario normal online, when it clearly is not? A vendor doesn’t force you to buy something so the power is in the hands of the consumer, as illustrated by the very existence of receipts for essentially anonymous cash purchases. Currently accepted online processes however do not reflect this fact, but this is not to say that companies are doing all of this on purpose, far from it.

It’s just that the various frameworks that govern a person’s identity on the global Internet are fundamentally broken, and they aren’t being fixed correctly.

Even a cursory look at the way in which people have been trained to accept insecure, antiquated and frankly scary modern identity practices reveals a mountain of good (and not so good) intent turned into unmanageable chaos. What follows is a brief look into the various tactical solutions that are being used at this point in history, as well as a proposed solution that is both manageable and scalable.

You have read the introductory narrative so now ask yourself these questions. How many sites on the Internet have you visited that ask for information about you? Can you give me a list right now of all the sites that know your personal details, store your private passwords and require you to repeatedly agree to their terms of service? Wait a minute, do they really need this information? Why do they now own it? Shouldn’t you be the owner of your own personal information? The answer is undoubtedly yes, however it doesn’t necessarily mean online merchants are wrong to collect some information. How can you send an item to someone without knowing their address and how can you streamline their experience so they don’t have to enter it every time they visit your store?

The fallacy of strong passwords.

We have all been to websites that ask for your new password to have the dreaded “combination of letters, numbers and special symbols”. Oh and my favourite, the maximum password length of ten characters. In fact, these so-called rules do surprisingly little to protect you from malicious intent. Time and time again it has been shown that length is the only true differentiator in this cryptographic equation, so it is far more secure to have a sentence as your password than a short complicated string of characters. Not to mention the fact that there is no standard around this, so each site’s rules are invariably, and infuriatingly, different. Perhaps there are some people who find joy in managing the ever growing number of passwords with their varying complexity rules, but they are few and far between. Granted, in the absence of a better solution, password managers have stepped in to save us from ourselves, but they are merely band-aids masking the underlying problem.

So much for the man, now for the monster.

Speaking of band-aids, a particularly elaborate one has emerged in recent years promising to help make all of this identity pain go away; the use of social media logins. This option allows you to forego the creation of credentials and entering personal information if you allow the merchant access to your social media account. They can get all they need to fulfil your order from there so it seems like a win-win situation. Scratching the surface slightly reveals a far more troubling reality to this solution. Not only do people rarely read the information that is actually being requested but you still don’t have control of your personal information. Furthermore what is the end game in this paradigm? It seems to be the beginnings of a monopoly on identity, which is not helpful to anyone.

At this point I could go into all the myriad technologies I have worked with in the past that currently support identity such as CAS, Active Directories, LDAP domains, Kerberos tickets, SAML circles of trust, IdPs, HMAC headers, HTTP basic auth, OAuth 2.0 access tokens, JSON web tokens etc., but the truth is that they are all propagating the same problem; identity ownership or the lack thereof. I shall therefore try to build on the shoulders of giants, explain what is useful and discard what is not.

Authentication versus authorisation.

Put simply, authentication is about who you are, authorisation is about what you can do. When a website asks you for a username and password, it is really asking for authentication; credentials that are deemed sufficient to show that this is the same person who visited before. Increasingly the trend to use an email address as a username has gained popularity for a number or reasons. Firstly it allows the merchant to prove that the user owns the provided email address by sending a confirmation link. Secondly it streamlines the password reset workflow. The downside is however that all of your passwords are only as strong as the password of your email account, because they can be reset with a few clicks.

So do your really need all these passwords when you can reset most of them with your email address anyway?

Whatever the answer, once you are logged in to a website, the actions you are allowed to do are based on your level of authorisation. A good example of this is a regular user versus say an admin user. They may see very different screens and be able to do different things based on their permissions. Because authorisation relates to the actions you are able to perform in another system, it is entirely up to the merchant what they want to allow and disallow on their site. As long as they know who you are, it is their prerogative to decide your level of access.

Something you know, something you have, something you are.

Otherwise known as multi-factor authentication, this refers to the ways in which you can provide enough information to show that you are the same person visiting as last time. The trusty password, pin or secret questions are all examples of something you know. Something you have can take the form of a physical token, credit card or mobile phone; while fingerprints, voice or facial recognition can be used as something you are. Obviously the best authentication combines all three, and thankfully now with the proliferation of mobile devices, the process is becoming far more seamless. Think about a person touching the fingerprint reader (are) on their phone (have) and being prompted to enter a pin (know). An age old problem, now simple and accessible, all without needing a password at all.

Hiding in plain sight.

Just because you are the same person as last time, doesn’t mean the merchant knows, or needs to know, anything about you. Personal details such as your name, date of birth, address or phone number are all attributes of a person’s identity; that is, they are merely details linked to particular credentials. When a set of credentials have no identity attributes associated with them, the entity is effectively pseudo-anonymous. Think about the first paragraph of this article. If I pay cash at a bricks and mortar store, there is no need for me to hand over these details at all.

This is utterly analogous to online goods and services, where all that is really required is a method of payment linked to a particular pseudo-anonymous user to subscribe to a streaming service. Taking this line of reasoning one step further, there are use cases where not even credentials are required. Think of an electricity bill or once-off software download. In these cases does it really matter who pays the bill as long as it is paid? If I want to buy my kid the latest FIFA game online, why do I need to log in at all?

Assurance of attributes and the choice.

Conversely, there will be cases where attributes are absolutely required in order to fulfill an online transaction. The physical delivery of goods requires an address while a driver license renewal requires a name and date of birth for example. In the former use case it would suffice to have the user provide these details, however the latter is far more tricky. The provided attributes need to be verified somehow in order to provide a level of assurance to the merchant that they are dealing with a real person.

Assurance and evidence of identity have taken many forms in the past. Think of the classic hundred point check where you provide some photo identification and a bank card. This is a crude form of assurance, verifying that you are who you say you are. The online version of this can be far more advanced, where a set of attributes linked to an identity can verified by trusted entities. SSL certificates are a good example of the manifestation of this process, and there is no reason the same principles could not be applied to online identity attributes.

Whatever the nature of the transaction; anonymous, pseudo-anonymous with verified or unverified attributes etc., the key point is that the management of personal information and the choice of how much to disclose to what parties should be in the hands of the data owners, i.e. the users.

Across the world baby steps are being taken to address some of the growing information privacy and ownership concerns that are the result of these broken identity processes. A good example of this is the recent introduction of the General Data Protection Regulation (GDPR) in the EU that, amongst other things, describes data subjects and the lifecycle of their associated personal information. Of particular interest is the assertion that parties must delete personal data held when requested to do so by the owner. Still more examples of similar legislation can be found elsewhere in various stages of maturity and this is a good starting point from an awareness point of view, however the most effective way to address these problems is to combine these legislations with a simple, robust identity framework including supporting business processes and protocols.

Occam’s razor.

Reverse the paradigm. At the moment when we go to a website that requires authentication, we are either redirected or directed to a place where we can enter our infamous username and password. This is where we enter details that are stored by the merchant to verify who we are. In short, we are logging on to the website, and this is where the whole problem lies. Knowing what you know now, take a step back and think about the problem then.

Websites should be logging on to you, not the other way around. They should be agreeing to your terms of service.

When you go to a website, if they have decided that they want to know your first name and if you have visited before, they should request that information from you. You then get a notification asking if you agree to provide this information to them automatically and ideally temporarily. You approve their access request and move on with your life. Whenever necessary you can access a management dashboard, again ideally with multi-factor authentication, that contains the latest version of your personal information that you can manage. It also contains a revokable list of the websites that are currently using your information, along with those that have accessed it in the past.

If you build it, will they come?

The actual technical solution would be made up of three parts; a management dashboard, your personal data and a reliable way to find it. The first part is a simple web application that can be deployed wherever the identity owner sees fit, be it on personal hardware, trusted cloud services or on blockchain smart contracts. A similar pattern applies to personal data, whereby it can be stored as a file on your phone, on a cloud object store or distributed storage such as IPFS. The third part is the secret sauce; a unique, Internet accessible URL that is used as a pointer to the previous two components, sent with an original HTTP request. This would be built on top of HTTP but would be for identities only. Sharing and management of attributes can be handled in a similar way to the OAUTH 2.0 workflow, just as attribute verification can be handled using the well trodden SSL certification process.

To summarise the previous paragraph let’s examine a standard workflow for two use cases, firstly that of the user and merchant.

Verifying your attributes would be relatively simple as well.

To conclude, the benefits of this proposed reversal of identity solution in terms of privacy, ownership, robustness and scalability are more numerous than can be fit into a brief overview such as this one. Moreover because an individual now has the ability to cancel logins and revoke access to their own information at any time, perhaps more forethought will be put into what information is requested in the first place. Perhaps a new type of identity economy will emerge, whereby websites that require less information than others are valued more highly that the ones that require more.

Unfortunately to make this change would require significant buy in from the general public, human rights bodies, the technical community and major Internet companies. Traditionally coordinated support like that is very hard to come by, however perhaps we can apply the same reverse philosophy as the solution itself. Perhaps we should be asking each and every one of these interested parties what is stopping them from supporting such a simple solution to an irrefutably broken system. Let them explain themselves.

Written by

Historian and Architect. These articles represent my own view points and not those of my employer, Amazon Web Services.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store