Table of Contents
In this Help Net Security interview, Gail Hodges, Executive Director at the OpenID Foundation, discusses how the Foundation ensures global consistency in FAPI 2.0 implementations and helps different industries, including healthcare, adopt secure and interoperable identity standards.
Hodges also explains how conformance testing and strategic partnerships help maintain security and interoperability across sectors.
What role does the OpenID Foundation play in ensuring global consistency in FAPI 2.0 implementations, especially in sectors like healthcare that haven’t historically used open identity standards at this scale?
1. Standards
As a non-profit technical standards body, the OpenID Foundation’s primary role is to lead the global community in creating identity standards that are secure, interoperable, privacy-preserving, and openly available. In the case of the FAPI 2.0 security profile, we support ecosystems across various sectors that share private and sensitive data. We seek to ensure that implementers are realizing the benefits of these mature and proven specifications to achieve their goals.
The FAPI 2.0 specification is a secure and interoperable profile of OAuth 2.0. It provides secure ‘rails’ between ecosystem participants for data sharing and other functionalities. This standard can be selected and deployed within a single company, a single ecosystem, or across ecosystems and borders. The protocol itself is agnostic to the data being exchanged between parties. While it has been most commonly selected for financial, insurance, or identity data sharing, FAPI 2.0 can be used in any sector to share high-risk data or ‘cargo’ on those rails.
2. Implementation testing and certification
Our second responsibility is to help ecosystems ensure that their implementations are completed in accordance with FAPI 2.0 specifications, ultimately guaranteeing that these implementations are secure and interoperable. The OpenID Foundation operates a comprehensive conformance testing program available to vendors, ecosystem governing bodies, and individual implementations.
In our experience, the most successful ecosystems have implemented clean profiles of our specifications and have mandated mandatory conformance testing for all participants.
3. General ecosystem support
The OpenID Foundation has supported many ecosystems over the years as they’ve moved from concept through to deployment phases. Our support extends past due diligence into strategic relationships where we help with profiling specifications, providing tests that support implementation, offering security insights and best practices for deployment configuration, conformance testing, self-certification support, and roadmap and governance advice.
Countries with live FAPI implementations include the UK, Brazil, Saudi Arabia, Germany, UAE and Australia. The OpenID Foundation is also actively supporting the development and deployment of FAPI for the first time in five other countries on four continents.
Norway is the first country to use FAPI at scale in the health sector, allowing the exchange of health data across the entire Norwegian Health Network while mitigating security and interoperability risks. The OpenID Foundation and FAPI Work Group are delighted to see NHN take the lead as the largest ecosystem to deploy FAPI 2.0 yet. This means NHN has more entities deploying FAPI and delivering interoperability than any other network we have worked with to date. Their accomplishments are impressive, and we’re partnering with NHN to exchange best practices and scope any additional support that might help them scale, maintain, and develop their ecosystem.
The use of OpenID Foundation specs for the health sector isn’t novel. Our first standard, OpenID Connect, is actively used by the UK National Health Service and in the FAST FHIR protocol for US health data. One interesting observation is that while OpenID Connect implementers often take the standard and modify it in-house for their own purposes, FAPI ecosystem implementers tend to stay more closely connected to the OpenID Foundation. They maintain a two-way exchange of implementation experiences, and most use our ongoing conformance testing and self-certification. This ensures the security, interoperability, and operational benefits can be sustained over time.
FAPI 2.0 includes measures like DPoP and JWT-secured authorization requests. For security leaders unfamiliar with the protocol suite, how would you describe the key innovations from a threat mitigation perspective?
Broadly speaking, these mechanisms are used to mitigate security risks. The first innovation was that FAPI 2.0 profile development was done with a corresponding ‘attacker model’ that describes the risks and scenarios FAPI 2.0 is intended to provide protection from. These security goals can be summarized as:
- No attacker can access protected resources
- No attacker is able to log in at a client under the identity of another user
- No attacker is able to force a user to be logged in under the identity of the attacker
- And no attacker is able to force a user to use resources of the attacker.
The second innovation is that the FAPI security profiles are academically assessed for security by University of Stuttgart Cyber Security researchers. They formally model the internet, the protocol, and the required security features as described in the Attacker Model, and are able to prove that the protocol and profile meet its stated security objectives. There are peer-reviewed academic papers available that back this up.
DPoP (RFC 9449) is one of the two methods FAPI 2.0 uses for creating and validating ‘sender-constrained access tokens.’ The other option uses MTLS to a similar effect. These are used to mitigate the risks associated with access token leakage or theft. Access tokens without sender constraining can be taken and used by any other party to interact with protected data and services. This isn’t possible with a sender-constrained access token as it’s bound to a private key, and a signing mechanism using that bound key is required when the sender-constrained access token is presented.
JWT-secured authorization requests (RFC 9101) are utilized in the FAPI 2.0 message signing extension to provide additional non-repudiation features. Some ecosystems require assurance about the origin and integrity of the authorisation request.
Norwegian Health Network’s (NHN) rollout of FAPI 2.0 across its national health infrastructure is the first of its kind. What technical or organizational factors made this deployment possible at such a scale?
From the OpenID Foundation’s point of view, this was simple. It was the selection of FAPI 2.0 and the requirement for all implementers in their ecosystem that needed to exchange data to implement to the same specification.
The ultimate success and recognition rests with NHN and all the participating health service providers. They’re the ones who did the hard work analyzing options, deciding to use FAPI 2.0, integrating it into their deployments, testing interoperability, and then moving each implementation into production. These are hard projects to manage, but as we understand it from the NHN team, FAPI 2.0 and the supporting elements from the OpenID Foundation result in mitigation of various risks.
The OpenID Foundation believes the following categories of risk mitigation helped NHN conclude they would adopt FAPI 2.0:
- Clear security risk mitigation backed up by very wide review and implementation experience around the world
- Interoperability risk mitigation through a very specific and clearly defined security profile
- Support of the security profile by software vendors and service providers
- And confidence that any future issues will be addressed in a consensus-based fashion with the OpenID Foundation community of members, contributors, and implementers.
NHN reported a reduction in token theft risk after deploying DPoP and other FAPI 2.0 mechanisms. Are these results consistent with what you’re seeing in other deployments, and how do you think this will influence regulators and CISOs?
Mitigation of token theft has been one of the key design goals for FAPI WG from the very beginning of FAPI 1.0. Security analysis has proven that we have achieved this goal and conformance testing proves that implementations have been deployed correctly and the goals of the protocol have been accomplished.
We haven’t heard of any compromises related to the FAPI 1.0 or FAPI 2.0 protocol itself from any of our ecosystem partners. We have heard about issues related to phishing attacks on end users leading to fraud, but those are unrelated to protocol security and more consistent with consumer awareness and education needs to avert manipulation by bad actors. We’ve also heard of errors in managing consent that led to ecosystem disruption, but that was an operational issue, in other words a human error.
Most commonly, security issues are detected by our ecosystem partners through the certification and conformance process, and ongoing real-time testing against the OpenID Foundation open source test suites, which are freely available. Any part of their implementation that fails to pass our tests is flagged to the developer to triage and remediate until it passes.
The OpenID Foundation itself also detected a potential security issue within one of the upstream specifications. It was a vulnerability discovered during a formal security analysis unrelated to FAPI 2.0. When this potential vulnerability was identified, we were able to leverage our relationship with ecosystems like NHN to inform them so they could take mitigating actions if needed. This exemplifies the benefits of ecosystems working in partnership with the OpenID Foundation and each other. We can collectively ensure the security of this critical infrastructure.
We’re certainly seeing more regulators and CISOs favoring FAPI 2.0, as they’ve been selecting it even before it went to final. Many of our ecosystem partners are either already pursuing or seriously considering upgrading from FAPI 1.0 to FAPI 2.0 to benefit from its improvements. We’re also starting to see implementers with in-house, pre-existing, or proprietary APIs switching over to FAPI 2.0, which indicates others may follow their lead.
The OpenID Foundation is a small team, so with 90+ countries pursuing Open Banking and Open Data, we’re not able to proactively identify every decision maker and support every ecosystem that should or will consider FAPI 2.0.
The OpenID Foundation Board is working to scale our capacity, such as exploring the accreditation of third-party test houses, but we’ll remain reliant on a range of channels to reach and inform the community of decision makers. In practice, this includes OpenID Foundation standards experts and members, FAPI certified vendors, conferences, and word-of-mouth between regulators.
Progressively, we’re also engaging with experts on the needs of developing and lesser developed countries through organizations such as the World Bank, UNDP, and open source NGOs. We also hope that expert reporting like Help Net Security can help amplify awareness and consideration of the standard across sectors and stakeholders.
Healthcare systems often struggle with legacy integration. What lessons from NHN’s phased migration strategy could be useful for other sectors considering a move to FAPI 2.0?
While this is really a question best answered by the NHN team, what I can say is that we, the OpenID Foundation, have seen implementers of FAPI 1.0 and FAPI 2.0 transition from years of work to deploy at scale, like in the UK. Also to months of work to deploy at scale in Saudi Arabia and UAE.
When all implementers in an ecosystem are building to the same tests, and the standard allows interoperability by default, implementers can eliminate the vast majority of errors in their own implementation well before they get to multi-party integration and testing. This allows the ecosystem to focus on other governance decisions and integration challenges specific to their needs.
Having worked in networked business for over 25 years, I’ve seen how private entities can drive ecosystem scale through common rules, like Visa and MasterCard, and common APIs like Apple Pay.
The beauty of FAPI 2.0 is that public and private ecosystems alike can benefit from the security, scale, interoperability, and operational benefits of FAPI 2.0 specs and tests, allowing them to focus less of their resources on integration and more on the value they can uniquely bring to their ecosystems.
