Construction principles for the information scientist: (6) Disconnect “who you are” from “what you are allowed”
In this series of blogs, I reflect on the still-valid information engineering construction principles that guarantee better “information constructs.” They are sometimes, in the pace of advancing technology, a bit forgotten. Resulting in sometimes shaky or poorly maintainable and extensible “information constructs.” This time about the need to decouple identification/authentication (who you are) and authorization (what you are allowed to do). How many login combinations do you have in use? Probably more than 30. Still every day we struggle with login names and passwords for all those service providers we visit online. In theory, the solution is simple but in practice it is still laborious.
Distinction between who am I, is it really me and what may I
In the physical world, we disclose who we are with our body characteristics (we are recognized) or with a certified document (driver's license, passport, identity card). In the digital world, we do this with a digital attribute associated with us (an email address, mobile number or device with digital certificate).
Unnoticed, we use these means to do multiple things at once. We identify ourselves (I am Jan Jansen), also make it clear that it is really us (authentication) and show that we are also allowed to do something (authorization) for example drive a car or make a payment from an account.Because these three functions often blend together unnoticed, a bunch of key resources are created, for each of our authorizations. Take the driver's license as proof that I can drive a car. You are now required by the Road Traffic Act to carry that with you when you drive a car. But that is not actually necessary during a police check. If I can identify myself and show that it is really me, for example, with the BSN on my passport (my verified identity), a police officer can also request my authorization to drive from a central register. After all, my authorization to drive is separately centrally recorded and retrievable by authorized persons (unfortunately not for that landlord at my vacation address so he does want to see the driver's license).
Another well-known example is the state pass. Passes are still re-issued and collected to give someone access to a building (authorization). This while a pass once issued as an identity is valid for several years. It would suffice to link an authorization to an existing proof of identity.
Identity fraud lurks and what about privacy?
The downside of this simplicity is that if I lose my digital identity or it is hacked, I myself can no longer access anything or someone else can act on my behalf on the Internet. Therefore, additional procedures have been set up such as being able to reset a password via an email address or an additional authentication via another means (2-factor authentication).
Yet in practice, many people have a multitude of username/password combinations. The culprit for this: “lazy” service providers/web stores. They all issue their own authenticated identity instead of reusing an existing one (although increasingly it can be done with DigiD, eIdas or a Facebook or Google identity).Only one digital identity for everything is also a risk because a “single point of failure.” So in the design you must also consider the scenario that things go wrong and devise a procedure in case the externally reusable identity is lost (If I lose my passport abroad I can get a replacement travel document) or the resource is temporarily unavailable (DigiD is down).
Finally, the risk of having one identity for all my digital actions is that my comings and goings in the digital world are technically trackable at one agency in principle. The identity issuer here will have to provide safeguards for my privacy in the terms of use. They don't all do that....It seems incredibly convenient to log in everywhere with your Facebook account but in doing so Facebook collects a lot of data about your behavior on the Internet (where you buy, for example).
Smart authorization management and secure access
One measure to combat identity fraud is to ensure that authorizations have a limited duration. In the end, it's all about authorization or access. As a user, you want to be able to do something or exercise an authority. A passport and driver's license also have limited validity. By attaching a limited validity to an authorization instead of an identity, you can force the user to re-identify after a certain period of time. Possibly with additional safeguards. Only once it has been established that it really is you will have access again. This reduces the chance of abuse. This is why Google or Microsoft or your password manager, for example, regularly asks you to re-identify yourself, with a second factor. But there are more factors to consider in preventing fraud such as making it impossible to log into two geographically distant places in a short period of time.
Decoupling enables multiple uses!
So as a designer, it is important to consider the advantages and disadvantages of issuing a user's own identity or accepting an externally verified identity. The advantage of that multiple use should not lead to a higher risk of identity fraud or privacy violation. Here you have to assume a digi-incompetent user who is not always careful with his digital identity. So with reuse, two-factor authentication is actually a must.
By linking authorization management to the service (gaining access somewhere, processing email, making payments, ordering something) and having identity management handled by a separate service provider, it is possible to use a limited set of identities in the digital world while still dealing securely with a multitude of service providers. So then you are rid of those 30 login combinations. This insight has finally provided ease of use in the secure procurement of government services (with DIGID and eRecognition) even in a European context (eIDAS). Now to get the private service providers to do it!
Read the other information science principles here:
- Meaningless identity designation, read here.
- Decoupling points for complexity reduction and flexibility, maximizing independence of components, read here.
- Language consistency, read here.
- Clear distribution of responsibilities and functional separation for administration, read here.
- Delegating decision-making authority as low as possible, read here.
- Detaching authorization from identification/authentication, read here.
- Single registration of master data, read here.
- Separating data and metadata in storage and processing, read here.
- Applying standard patterns without deviations, read here.
- Separating application function from data storage, read here.
Related Insights
