Open Banking - Global FAPI Ecosystems Roundup [Introductory]

Thank you very much for coming to this session. It's about FAPI and global FAPI, mainly open banking ecosystem roundup. I'm Nat Sakimura, the chairman of the OpenID Foundation and the co-chair of the FAPI Working Group. And I'm Dima Postnikov with multiple hats. I do a lot of work within OpenID Foundation and FAPI Working Group, but I also lead ecosystem architecture for ConnectID in Australia. And you also lead the ecosystem community group.

Yes, and we'll touch on that in a little while. So, doesn't move.

Excuse me, it doesn't seem to move. All right, so it started going.

So, what's FAPI? How many of you know what's FAPI?

So, FAPI used to stand for financial grade or financial API, financial grade API and things like that. But now, FAPI stands for nothing. It's just FAPI. It's because it started off from the financial stuff, securing high APIs, which requires higher security. But then the same technology was actually usable in other industries like healthcare or aerospace and things like that. And these people came to us that having the label financial prohibits us from using it.

So, we decided to remove financial from all the specifications and it now just says FAPI. Although the FAPI 1.0 still says financial grade and there's going to be the errata version coming out. There's a lot of changes in it, but if you look at it, it is actually removing financial grade to FAPI. That's not much more than that. And we should probably rephrase the slogan. FAPI doesn't stand for nothing, but it stands for security and interoperability. I once proposed formally analyze protection interface, but didn't want to. Fortified. There were too many options we couldn't agree on.

It's a secure thing. That's it.

So, who needs secure APIs? Two use cases.

So, there are multiple use cases. I think that will cover a little bit the origins of FAPI. That's Open Data Ecosystems, which has been expanded to Open Finance, Open Insurance and other places and Open Identity. But it's also super useful for large organizations doing partner integration. And it's also useful for the private ecosystems. I've seen some of the large banks in Australia, for example, deploying FAPI for their own partner integration, for their own use cases.

So, this is sort of a classic application. So, it's not just about open banking. It's about high security APIs where you have sensitive data when you have higher requirements. The genesis of this open banking stuff actually started in the white paper by the UK government called Open Banking Standard. And it was talking about the general data sharing practices called MyData, M-I data. And the proposal that they were making back in 2011 was for the users to be able to download their own data onto their PC or onto their phone and then send it over to the relying parties, which didn't really fly.

And partly because it was really difficult to standardize over the data format and things like that, over the general data. So, what that white paper recommended was to concentrate on the open banking, which the data format is kind of well-defined. It's only the figures and structures there, right? And then being able to send the user to be able to instruct the originating bank to send the data over to the relying parties like insurance company or something like that or FinTech.

So, that's the genesis of what it is. But from the beginning, the vision was to be able to provide the data, not only the financial but all sorts of personal data.

So, in the case of Australia, it's like Australian consumer data rights and things like that, right? That's right.

So, it's used in energy, banking, private ecosystems, identity ecosystems. So, there are quite a few applications in Australia. Yeah. And for that, to achieve that, we use OAuth delegated access framework. OAuth was there for some time now, by 2016. I think OAuth was standardized back in 2012 or something like that.

So, we already had some time. And also, we had OpenID Connect standardized back in 2014.

So, we started reusing that secure API patent to transfer the data with instructions or consent of the data principle. Do you want to add something on that?

No, I think that's good. We started off with existing standards, so also OpenID Connect because they're the most applicable to the type of interaction.

And then, the next part is how do we make it more secure, more interoperable? Yeah.

And then, OpenID Connect provides identity overlay of OAuth 2.0. So, we could actually provide who that person is, when that person was authenticated, and so on and so forth.

So, it's not dissimilar to the verifiable credentials, P-data that we are talking about. But it's issued by something called OpenID Provider, right? And it's very, very short-lived. It lives only just like one minute, something like that, which makes it unnecessary to think about revocation, things like that, which simplify the protocol a bit.

So, we picked OAuth 2.0 and OpenID Connect, but just saying OAuth 2.0 and OpenID Connect isn't enough. Both OAuth 2.0 and OpenID Connect are frameworks with many, many options. And some options are not that secure, right? And depending on how you configure the servers and clients, they are not always interoperable. There are different options, and there are also interoperability issues. Everyone was reading the specs in different ways. And when you're trying to create a large ecosystem with a large number of participants, you inevitably have a problem. That's not what we meant.

That doesn't work. That doesn't connect. Lots of issues. That's why where we're heading towards is what FAPI provides for OAuth 2.0 and OpenID Connect is adding security and interoperability. Picking the secure options, making sure that there's a limited number of options people can implement, they become implementable. And there is interpretation of the spec that's locked down that allows people to roll out large ecosystems. Right. And we also provided the certification or test suite as well to which each banks and fintechs could test their implementation against.

And that actually made it considerably easier for each implementation to connect to each other. That's right. So that's security. And one example of the security choice we have chosen is that at the time, the OAuth token type predominantly used is called bearer token. Do you guys know what bearer token means?

Yeah, very little. So the bearer token is the kind of token that whoever got the token can actually use that. That's a bearer token.

Yeah, this is a bearer token. So if I give this to somebody else, they can disguise as me and get into the conference venues. That's a Paris metro ticket. That's the Toronto metro token. That's an example of bearer token. Somebody picks it up, they can use it. That's easy to use but not always good enough for the financial use cases and things like that. So what we have decided is to just allow sender-constrained tokens. Sender-constrained tokens is just like international airline boarding pass. It's got your name on it, right? But when you're using it, you also have to present your passport.

And the airline agent will look at the picture on the passport and look at yourself and compare the names and say, okay, you're allowed to get on board. So that's an example of a sender-constrained token. Do you want to add something?

No, it's okay. So we decided to make all the tokens using FAPI sender-constrained. So that's a big change. Please.

Yeah, right, right. So your question is whether the... What's the mechanism? So is the bearer token with basically signing, is that something you could consider a sender-constrained token because you as you can only sign it. And as a result, you know it's sent by you. And as a result, you know it's identity-proofed in that sense. So it's key-bound basically, right? So only the party who's got the private key can actually use it. In the case of the regular OAuth where a bearer token is used, the resource server who receives the access token can actually replay it to other resources as well.

But in the case of sender-constrained token, because the resource server doesn't have the private key, it can't do that. There are actually two different mechanisms in FAPI how to do that, that we allow for. But I think the example here is... One message here is if you use OAuth 2.0 on its own, it doesn't deal with a stolen tokens type of attack. But we introduced in FAPI additional controls to deal with different types of attacks. And that's just an example.

Yeah, yeah. This is supposed to be an introductory session. So if you want to go into the details, get one of us and we can always get into the details. And FAPI is not only about the security but interoperability, right? That's right. And there were some participants proven, especially in early open banking ecosystems where multiple options had been prescribed to all the participants to support that became unsustainable. And most of them went through the exercise of trimming them down and we are reflecting it in engineering profile here.

And we're talking about the comprehensive conformance testing and certification. That proved to be very, very important. Sometimes we find a bank exposing their own private key. We find that through the conformance test as well. In the case of the UK, when we didn't have the conformance test, it used to take like weeks for a relying party or the fintech to connect to the banks. After we introduced conformance testing, it was cut down to something like 15 minutes when things go well. So FAPI Working Group. All those specifications is done in OpenID Foundation's FAPI Working Group.

At OpenID Foundation, we have many working groups. I don't think they are everything, right? But we assist these active working groups and FAPI is one of them. And the objective of the working group is to create general purpose. General purpose, right? Not only finance. General purpose, high security profile for OpenID Connect and OAuth2. Some notable aspects? In the interest of time, we'll probably need to… You'll get the slides and you can read them. We've got 40 slides in 20 minutes. The working group is making steady progress. We have issued the final version of FAPI 1 back in 2021.

We have done the final version of FAPI 2 this year. So four years later. We are still doing some parts of it. What's important is that in both cases, we require the formal security analysis to be done. So that we know that under the security assumptions, there are always security assumptions. As long as they are fulfilled, the protocol is safe. So one of the things that we'll probably cover a little bit further, but if we don't… So there are two things that we mentioned. And I'm trying to sort of focus on the main message of this presentation.

FAPI is OAuth2 plus security and interoperability. In order for us to ensure that the protocol is secure, we do a formal security analysis with the University of Stuttgart, where they analyze possible theoretical scenarios and produce the report. And a lot of times, pick up certain things to be fixed that require additional controls. And in order for us, for the ecosystem governing bodies and implementers, to understand that their implementation is compatible with the profile.

And thus, because the FAPI profile gives responsibilities to all participants. We need to make sure that those responsibilities are fulfilled. And only then the profile will be secure. The implementation will be secure. Certification is used extensively to guarantee that the actual implementation has implemented the specs correctly and is secure. So that's the focus. These are the two probably bigger sort of differentiators. There's no alternatives in this space in the API security profile.

But in terms of differentiators, formal analysis and certification are key to the point where we started taking it now to all the other specifications and all the other working groups as well. We use that approach in OpenID Foundation. Yeah. And FAPI 1 and FAPI 2. Do you want to go?

Briefly, once again, it's an experience. So FAPI 1 has gone live first with OpenBank in UK in 2018. We've learned a lot since. And a lot of those things made us simplify the profile significantly. And we also redesigned FAPI 2 from scratch based on an attacker model, what we're trying to protect against, and then design the profile around it. So FAPI 2 is the version that is currently best practice in API security space. And it's a bit more modular as well. That's right.

Yeah, and it's much simpler. Like I've had people implementing FAPI 2 and implemented previously FAPI 1. Then they're coming to me and telling me, oh my God, I wish our implementation of CDL, OpenBanking implementation was like that. And there are other FAPI working group specifications as well. It's not really a FAPI working group thing. But for example, JWT, Jout secured authorization request, JAR, that's now in IETF. And we are actually making use of it for authorization request.

And JAR for authorization response, and JWT response for token inspection, and HTTP signature for resource access. So all these belongs to the hardening of the protocols. I think you'll get the slides. I don't know how much time do we have. Five? Nothing. Nothing?

Okay, so maybe we'll go to the couple. I'll give you one more minute, I think. Yeah. So there's a lot to learn about FAPI. I think if you go to the global adoption, it has been extremely successful. Sorry? There's a lot. Yes. Look at the FAPI. It has been extremely successful in terms of implementing it in different jurisdictions. And OpenID Foundation does a lot of work in working with each of those ecosystems. I think one of the counts we did yesterday was we're probably looking at our largest four ecosystems that we are aware of.

We're probably doing about three, four billion monthly calls secured by FAPI. So that just gives you the scale. It's never going to be as much as OpenID Connect out there in the world, but I think it's significant. And the message here is we work with each of the ecosystems globally, trying to make sure that we fit their requirements, and we develop the protocols to fulfill the wider range beyond FAPI. So FAPI is just one part of the set of specs that you need to implement open data.

We recognize that based on experience, and now we're working on fulfilling the other parts that are required, whether it's trust management, whether it's consent management or other parts. Considering that it's been there for like four years now, I think it's a remarkable achievement. And there are new ecosystems considering the use of FAPI as well. And FAPI ecosystem support community group. I think the message here is we work with communities, with ecosystems, to make sure that we feed those requirements back to FAPI and other working groups within OpenID Foundation.

So if you want to adopt FAPI or something like that in your ecosystem, just reach out to us. That's right. We'll stop there. Thank you very much for this presentation. Big applause.