Where Identity Security Is Heading
There's a lot of activity in the identity community currently. Financial Grade APIs (FAPI), OAuth 2.1, WebAuthn, decentralized identity, and other facets are being actively maintained and updated. In addition, entirely new standards are being proposed to replace existing ones. This is the natural progression of Internet standards.
However, it's easy to forget the stable toolset in place when blinded by shiny new things. Both OAuth 2.1 and FAPI primarily restrict the array of options introduced by OAuth and OpenID Connect to something secure and interoperable. Large standards such as OAuth can be properly implemented in high-security scenarios but can also be misused to provide a false sense of security.
I also see that some new initiatives are trying to solve already solved problems in a more modern way. Appealing (and sometimes handy) as this may be, it does not necessarily provide any useful new security. There are two main drivers for new standards. There is a need for modernization and simplification, essentially adapting the standards to current use cases. On the other hand, there are advanced cases where novel problems are being addressed, such as generalizing out of band authentication, sharing identity information, and building large-scale interoperable identity networks. The latter is often being driven by legislation.
The Evolution of Identity
The identity space has been through many iterations. In many respects, it is a very mature technical area where various problems have been solved many times over. However, we are at the crossroads of a bigger shift. For the first time, many governments have repositioned themselves from the point of indifference to having codified opinions about your digital identity and the data attached to it. There is a contradiction in the need for more oversight and stronger privacy. Thankfully, we can accommodate both if done right. What needs to be done can be broken down into the following three areas.
1. Interoperability
Although OAuth and OpenID Connect were designed to provide interoperable ways to deliver authentication and authorization (really delegation), they have proven even more useful in non-federated scenarios. Commonly, the same organization provides the APIs, the applications, the authentication service, and the token service. Architecturally it makes a lot of sense to extract identity from home-grown applications and centralize it using a single service that combines authentication and token issuance in a single Identity Server. It both reduces cost and time to market while also reducing complexity. In this case, interoperability is not such a significant concern, though it does hasten deployments.
However, in recent years, new legislation has forced entire continents to agree on joint standards to be interoperable. For example, the financial sector has been strictly legislated, forcing banks to open APIs and remove technical obstacles around integration. The list of banking regulations is growing — In Europe, we have PSD2, the UK has UK Open Banking, Australia is working on the CDR, and Brazil has Open Banking Brazil. This growth pushes the limits of what OAuth and OpenID Connect are capable of, and it provides room for innovation while simultaneously refining and restricting certain use cases. The banking industry will most certainly not be the only industry subject to this type of legislation. Energy and health care are prominent candidates for API openness as well.
Interoperability means that we need to heavily restrict, or profile, the usage of the standards. This ensures that the same baseline security is present over all regions.
2. Stronger Identity Assurance
Multi-factor authentication (MFA) is good, but in and of itself, it does not solve the problem around identity assurance. Most often, multiple factors only provide a way to more strongly secure the user's account. It does not tell the end application anything more about who the user really is.
Many countries have already implemented and deployed various E-IDs that provide user authentication with identity assertion. However, this is not what we're talking about. Knowing who a user is important, but for an online service, it's more important to know particular claims associated with them. For example, if I'm selling a car, the dealer must assert that I'm the current owner. Or, when I buy prescription drugs, the pharmacist needs to know that I have a receipt issued for the medicine. Asserting these claims in a general way will lead to more safe transactions on the Internet and lead us to the last point in this blog post.
3. Privacy
The more services we use, the more of our privacy we give away. This has been a great concern in the identity community over the years. Some work has been done to improve the ability to remain anonymous. However, this has primarily been driven by the fact that organizations dislike sharing user details with other organizations for purely commercial reasons.
As we start building large-scale interoperable identity systems, this need is multiplied. The digital footprint left must be reduced to a minimum, and it needs to be controlled by the end-user. I want to assert claims about myself, without sharing my identity.
Combining proper identity assurance with pseudonymous identity information is possible if we trust the issuer of the information. OpenID Connect already provides many of the tools to achieve this, even if some are still in the early stages. Pairwise Pseudonymous Identifiers combined with OpenID Connect Identity Assurance takes us part of the way.
Another fantastic and promising work is Decentralized Identity. This technology and the associated ecosystem allow for sharing only particular claims, such as my age or hometown, in an assertive way without sharing my entire identity. When combined with the ability to manage all applications I have consented to, we are on a good path toward better Internet privacy.
Conclusion
With all the ongoing e-ID work, stronger identity assurance on the Internet is inevitable. To be able to comply with new regulations, we will have to provide a more interoperable framework. If we fail to incorporate privacy in these efforts, we might miss the last chance to protect end-users. Otherwise, the end-user has no choice but to be tracked and mapped wherever it is active. This is close to our hearts at Curity, as our mission is to make the Internet a safer place.