EPISODE 1733

[INTRO]

[0:00:00] ANNOUNCER: FAPI is a refinement of the OAuth standard developed by the OpenID Foundation. It was conceived to solve a core problem of providing a consistent approach to API security across a financial industry, with the goal of enhancing interoperability of financial data exchange. It has now been adopted across many different industries and applications where there is an API that requires a heightened authorization security implementation.

Authlete is a service that provides a set of APIs to implement OAuth authorization servers and OpenID connect identity providers, allowing either to be easily made FAPI compliant.

Joseph Heenan is the CTO at Authlete, and he also leads the certification program at the OpenID Foundation. He joins the podcast with Gregor Vand to talk about the origins of FAPI, the motivations for its creation, the status of FAPI development, and more.

Gregor Vand is a security-focused technologist and is the founder and CTO of Mailpass. Previously, Gregor was a CTO across cybersecurity, cyber insurance, and general software engineering companies. He has been based in Asia Pacific for almost a decade and can be found via his profile at vand.hk.

[EPISODE]

[0:01:23] GV: Hi, Joseph. Welcome to Software Engineering Daily.

[0:01:26] JH: Thanks, Gregor. Great to be here.

[0:01:27] GV: Yes, Joseph. It's great to be speaking today. We did have Authlete on the podcast. I think it was back in April. We learned a really good amount of things really around the OAuth spec and the way that Authlete implements that specifically. But today, we're going to be focusing on kind of a different piece of the Authlete stack, if we could call it that, which is FAPI. Obviously, we can get on to what on earth it is FAPI and what does it even stand for, et cetera. You're the CTO of Authlete. Maybe if you could just give us a quick, sort of, what's your background and like how did you find yourself as the CTO of Authlete?

[0:02:03] JH: Yes, sure. So, my actual kind of long-term background is actually as a mobile app developer. I always quip that I started doing mobile apps before mobile apps actually existed because I actually started back in 2000 when this was more like PalmPilots and things like that. If some of your readers are of the older nature. But yes, after I kind of ended that engagement, I went into doing independent consulting for a bit. And then some people that I'd worked with at the previous company doing mobile apps, reached out to me and said, "Hey, we've started this new thing called Authlete. Are you interested to come and see what we're doing and talk to us about helping out?"

So, yes, kind of went from there. That was my first kind of venture, really, into this whole authorization space. I'd obviously consumed OAuth before, but never really got into the details of how it all worked and how you secure it and what's good and bad practices.

[0:02:58] GV: Yes. You're also, you're quite involved. Is it with the OpenID Connect, like spec? Is that the best way to so describe it?

[0:03:05] JH: Yes. Particularly, with the Open ID Foundation, I get quite involved with a bunch of specs they do. So, as well as my CTO role at Authlete to actually lead the certification programs over at the OpenID Foundation. So, yes, I get involved with quite a lot of different specs, including the most famous one, OpenID Connect that I think everybody's heard of as you kind of log in with Google and so on options. But also get involved with a lot of the other specs as well. So, some of the shared signal specs that are used for these modern ecosystems where the identity providers share signals about fraud with each other.

Some of FAPI is another OpenID Foundation spec, obviously. And then there's some others like AuthZEN Federation and a few others. Probably shouldn't get into those today.

[0:03:51] GV: Yes. I mean, it all sounds very complementary. Yes, I think may be different to some other kind of aspects of technology and the industry, just that being involved with foundations and spec creation often go kind of hand in hand with platforms that are rolling it out. Having some huge separation there doesn't really benefit anyone. So, it really helps to sort of be able to be on the spec creation side as much as the industry side.

[0:04:21] JH: Yes, exactly, definitely. I mean, I think from the very early days of Authlete, it's been very important to the company that all the kind of specifications are open, interoperable standards that don't favor any particular player and that everybody can get involved with and implement without any fear of things being pated until locked into one vendor or anything like that.

[0:04:41] GV: Yes. Let's kind of dive straight in. Today we're here to talk about FAPI. I'm aware FAPI has gone through a few naming changes, conventions, because I think if I guess if I was to Google FAPI or whatever, there could be a few different potential things pop up for sort of what that - still in this context, but yes, I'll let you maybe just talk us through the history of the naming.

[0:05:07] JH: Yes. It is quite interesting and a long history. As you say, there's been a few different names over the years. I mean, originally, the working group at the OpenID Foundation actually started out with the aim of making essentially an open banking API that will be global and international. They kind of relatively quickly realized that was actually a really complicated task, but what they had produced was a security profile for how you do OAuth in these kind of open banking spaces.

So, at this point, it was FAPI stood for financial API, and it had this goal to be this wide-ranging thing that covered everything to do with open banking. As I say, they specialize then into just the security part, but at that point the kind of FAPI acronym was already locked in. So, we've been trying to figure out different ways to use that acronym but still have some underlying sense.

Firstly, it evolved into financial API security profile. But then we started getting approached by people that were actually outside of these traditional open banking spaces because the FAPI standard is very much, it's how you do OAuth in a high security and interoperable modern way. So, it's completely applicable to pretty much any open data ecosystem that's transmitting any kind of personal information. So certainly, we've got a lot of information from health ecosystems. The privacy is very important to people. Also, things like open energy ecosystems or open insurance. There's quite a few. With that financial label on it, we were getting pushback from those ecosystems. We don't think this is suitable for us because you're aiming for banks. We then changed the name to instead of financial API to financial grade API security profile.

Actually, it's continued to be a thing that the financial in there was confusing people somehow and they just didn't feel that this was a general-purpose thing that they should adopt. Essentially, the latest changes that's it now FAPI and it doesn't stand for anything in the same way OAuth 2.0. 

It did originally stand for something, but now it's just OAuth. Nobody talks about what it stood for. So, we're doing the same thing with FAPI.

[0:07:10] GV: Yes. Then, I think, we know we see this throughout history in this sort of tech world. I believe MS DOS started as QDOS, which I think actually technically stood for a quick and dirty operating system. So, they dropped the Q and added MS on the front. Obviously, they don't want to sort of remember the fact that started as quick and dirty OS. When technologies start out, they always have a name that sort of helps everyone just get behind a concept. And I think I find this one particularly interesting because even I, thought there was maybe more specifically around the financial side today, whereas actually, it's a standard and it can be used for many things.

I think it might also be just helpful. I'm very familiar with, when we talk about open banking, for example. I'm very familiar with that. Although I live in Asia, I'm quite familiar with so the UK banking system. There was a big thing around open banking. But there, I think there would be quite a few listeners out there who actually don't maybe have a concept of what that sort of means. So, maybe could we just sort of cover that one off?

[0:08:12] JH: Yes. It's a good point. So, as you say, the UK was very much the leaders in this space. Back in, it was 2018, that open banking started to become a thing in the UK. The idea was very much using more acronyms now. It came out of part of GDPR coming out of the European general data privacy regulations, which is very much this concept that a user's data is their own. If they want to be able to share it with other people in a way that benefits their lives, they should be able to. In particular, the whole open banking aspect is that the regulators didn't want the banks to be choosing who the consumers could and couldn't share their data with and wanted it to be easy for the consumers to do this data sharing.

So, that's where open banking comes from. A few actual use cases I can name like when I'm doing my accounts, the transactions from all my UK bank accounts just automatically appear in my accounting package. That's just using open banking. At some point in history, I authorized my accounting software to access my bank account, said I was quite happy for that to be ongoing access, and they just automatically come in several times a day, and it saves a lot of manual entry and reduces the number of errors.

Prior to open banking, this was actually done via FTP if the listeners actually are old enough to remember FTP, and It wasn't reliable. It was a paper-based form to set it up. Quite often, you'd miss a day's transactions or a day's transactions would get uploaded twice or something, and open banking is very much solved that. The setup's much easier. It's much more reliable.

[0:09:49] GV: Yes. I didn't maybe appreciate, if I'm understanding right, that it was actually FTP behind the scenes. But when I first started a company in 20, I think, it was 12 at this point, and Barclays, the bank in the UK had a sort of relationship with an accounting provider and they talked about bank feeds. As a consumer this was pretty great. I didn't need to do much but I do remember signing forms and there was data problems at times like, "Oh, the same day has appeared twice or that kind of thing." Then there was a clear point when we were told, we are moving to this new standard called open banking and you need to click a button and that's fine. Equally, another use case, I guess, for me is I'm sure people in the US, for example, Robin Hood or these sort of trading platforms, if you want to top up that account similar concepts in the UK and you can just say, "Hey, top up." And then your bank app pops up and says, "Are you okay about transferring this money?" "Yes, I am." And you don't have to do any kind of other real logins other than your, in this case, sort of touch ID or that kind of thing.

[0:10:51] JH: Yes, exactly. I mean, one of the biggest use cases in the UK now actually is for paying your taxes with open banking and it's actually saved the government a fortune because the thing about paying your taxes is you always have to get the exact right account number and there's also some kind of ID that actually means that the payment can be tracked to what you are trying to pay. And people were just getting these IDs wrong all the time and HMRC after then manually trace the payment, try and figure out what you were trying to pay and so on. That took up a lot of time for them. So, they enabled open banking. You just go on your phone and say, "Hey, you owe this much. I want to pay it." Launches your bank app and you say, "Yes, go ahead and pay it."

So yes, I can't remember the latest figures, but I think they reckoned it'd save them millions of pounds, basically just implementing this open banking ecosystem. One of the best payoffs, I think, in a recent government tech project.

[0:11:42] GV: Yes. Actually, just to back up for a second, HMRC. I think because we're both quite UK-aware, we know what that is. Maybe if you could just give a quick explanation of what is HRMC.

[0:11:53] JH: Yes, sure. So, Her Majesty's Revenue & Customs which is a very British term, obviously. Yes, in the USA, the equivalent would be the in-line revenue service, the dreaded IRS. The people that are responsible for collecting taxes from individuals and businesses.

[0:12:10] GV: I sit in Singapore and I don't maybe think they're using open banking as such, but within Singapore is a very sort of closed ecosystem where effectively the same thing is going on. I feel quite spoiled at this point between the two systems. I'm quite just used to kind of be able to do things very fast and easily. I think, obviously, the elephant in the room is North America, where you have all these sort of differing banking systems and, is it ACH? Is it wire, fed wire, blah, blah, blah?

So, I think, we've probably got a fairly good feeling of where this can be useful. Maybe sort of towards the end, we can also come back on, you mentioned things like open insurance. I'm really curious to hear about that, having personally worked in cyber insurance. We'd love to go there. But let's talk actually just about the technology side. Obviously, Authlete very much helps implement FAPI. We can talk about the exact Authlete piece to this, shortly. But let's actually, just talk about FAPI and emulation and OAuth and OpenID Connect generally. Those are the two standards or OAuth 2.0, if we're talking auth, probably. How would you sort of in semi-layman terms describe how FAPI differs from these other two standards and works potentially with them, which I think it does?

[0:13:30] JH: Yes. So, I mean, I think the first and most important thing is that all these things are built on top of OAuth 2.0. So, there is a common underlying base there with common terminology and so on. We're not trying to completely reinvent wheels. OAuth 2.0, it's very much a framework. It's got lots of optionality even in the base spec, and then there's all kinds of bolt-on specs you can have as well. There's different documents that cover security best practices for OAuth itself or for the underlying JWTs, things like that.

It's a very comprehensive spec, and if you just say I'm using OAuth 2.0, then you can't really expect any level of interoperability, and it's very unknown what kind of security it you're hitting. And OpenID Connect is just, again, that builds on top of OAuth 2.0. OpenID Connect very much adds on the identity layer so that as well as getting access to an external resource like your Google Drive contents or whatever, you also get information about who you are sent to the third party so they know your verified email address, for example. That's the part that OpenID Connect solves.

So FAPI, very much builds on top of those underlying OAuth 2.0 standards. But FAPI is based on an attacker model that these are the kinds of things that we want to prevent happening by improving the security of OAuth 2.0. It uses standard OAuth 2.0 specs. Again, there's all this optionality around. So, FAPI really narrows it down to, when you're doing client authentication, I think a lot of people that have done OAuth 2.0 in the past will be familiar with client secrets. And secret is a bit of a misnomer here because that secret is known to many people. It's known to the authorization server that issued it. It's obviously hard-coded into your client software that you then uses it to actually authenticate at the authorization server. It's known by your client developers, maybe some of who aren't even with your company anymore and that kind of thing. So, it's not really a secret because of that. It doesn't really give you proof that if this secret's presented, that you actually know who the entity presenting it is.

So, what FAPI does in this case is it says you must use one of two particular standards, one of which is called MTLS, one of which is called Private Key JWT Client Authentication. The common thing between both of those standards is that they're based on cryptography, so public and private keys. They're based on the assumption that the third party has a private key and can keep it secure, and then it just passes objects signed with that private key to the authorization server. The authorization server knows the public key it's expecting for the client and can then verify the message.

That's one example of the kind of way FAPI 2.0. It builds upon OAuth 2.0, but it makes it more interoperable, it makes it more secure.

[0:16:13] GV: Yes, I think, yes, this is a very good way to sort of introduce and explain it, is the fact that under the hood is still OAuth 2.0. However, what is, was one of the problems of OAuth 2.0 that there are still many ways to implement OAuth 2.0. Unless you can get everybody on the same page about our role agreeing to that, then exactly the call of different APIs, I mean, that's a very basic way of explaining it. But even though it's the same spec, you're kind of working off two different systems.

So, FAPI has added this, effectively, an agreement layer, if we want to call it. So, here's a question. When it came to, I guess, open banking with FAPI, I'm sure there's a long process, so maybe just a condensed version. What was the process for actually getting the major banks to agree to a spec? I mean, how does that work?

[0:17:04] JH: Yes. That was a long journey. I think we could say. It's a journey that repeats every time open banking expands to new ecosystems. So actually, exactly this conversation is currently ongoing in the USA and in Canada. The USA has, what, their Consumer Finance Protection Bureau has started saying actually open banking is going to be a thing. They're probably some rules. Now, banks are talking, "How do we actually do this?"

Yes, as you're hinting at there, getting a country-wide set of banks to actually agree to doing something in similar ways is not the easiest task. I think, at the end of the day, a lot of the actual roots of agreements is from regulators, actually, saying that you have to do something that's secure and interoperable, which means it has to be pretty similar across everything you're doing. So, you do need to agree to do something that's the same through all of you.

[0:17:55] GV: Yes. If those listening today, the reason why they might need to implement FAPI, either they work for someone where they are in a regulatory environment that says just that, you need to implement FAPI. Or is it also fair to say that it could be there are a small number of parties in a certain industry or area that all much faster agree to needing to or wanting to pass data between themselves, because they would all benefit and FAPI happens to now be probably the most realistic agreement structure to do that under?

[0:18:33] JH: Yes. Definitely. I guess, one interesting example is, in Australia. Australia actually has a regulated ecosystem called the Consumer Data Right which deals with a lot of the open banking of things. But what's happened recently is that the bank's industry body, Australia Payments Plus, has decided that they want to start the banks sharing identity information with each other and with people that want to pay to access it. So, yes, they got the banks together and they decided, "Yes, we should do this using FAPI. This is the obvious choice."

[0:19:06] GV: Out of curiosity, are there any other standards, like at the moment that could be sort of competitors to FAPI, so to speak?

[0:19:13] JH: Yes, the kind of, I mean, the big one you'll hear about within Europe is the Berlin Group standards, which they define open banking APIs, but they've also defined some security profiles. But I think it's fair to say that open banking in Europe is not as advanced and not as usable for consumers as it is in the UK. A lot of people, including myself attribute that difference to those Berlin Group standards. They're firstly not mandatory for all banks and they're not as prescriptive about interoperability as FAPI is. They don't, for example, have certification suites like the ones the Open ID Foundation has that actually check, "Yes, okay, this bank has actually implemented the standard correctly, which is a really important thing because everything we've discovered from doing certification is that unless you have that kind of test and that assurance, then the banks just don't implement things correctly.

They do something they works. Then, if somebody complains it doesn't work, they just say, "Sorry. But you can around it like this." When you have to do that for 400 banks, it becomes a significant impediment to actually integrating with banks when you do that. 

The other standard that people often talk about which is not mentioned yet is OAuth 2.1, which is an upcoming standard from the same working group in the Internet Engineering Task Force that produced OAuth 2.0 originally. People do say, "Well, can't I just use OAuth 2.1 instead of FAPI?" I mean, OAuth 2.1, it does fix some of the worst security problems in OAuth 2.0, and it has the recommendations kind of built into the spec instead of external, best-current practice documents. It's a much easy aspect to read and actually implement, but it's still just a framework exactly like OAuth 2.0. It's not prescriptive about exactly how you do things. It says, yes, we recommend you use send a constrained access tokens, for example, which prevents stolen access tokens being used by an attacker to access the data.

So, it recommends that, but it doesn't say you must do this in a particular way, so you don't have the interoperability. It's only a recommendation, so a bank can quite happily say, "Hey, I'm compliant with OAuth 2.1, but not implement this very important security feature." 

[0:21:26] GV: Yes. I think this is a really good point just to touch on where often the problem, at least from where I sit with a lot of implementations of anything when it comes to security generally is the lack of, whether you want to just call them defaults or kind of lack of quite frankly opinionated forcing, actually, of whether it's a user or a, in these cases, it's more sort of companies and how they talk to each other. But actually, saying you don't have a choice. This is, yes okay, the underlying spec had this sort of all these areas you could have gone with, but the only way we're going to do this in probably the best possible way and what we're talking about is the safest and more secure possible way is you cannot use all the bits of the spec. You have to actually use certain bits of the spec in this specific way. Actually, the challenge, of course, is getting people to come and agree on that.

So, I think this is really just a really interesting sort of move forwards where actually something like FAPI has come along and put in place clearly a whole series of more than just suggestions. But let's do this. let's use the same thing. Maybe we could even dive into just some of those in a little bit more detail now, some things that, yes, I guess, come to mind, the concepts of things like message signing, client-initiated, back channel authentication, grant consent, pushed authorization requests, and then you did touch on it just briefly there, sender constrained access tokens. Could you maybe just talk through kind of these concepts and like how they actually make FAPI work?

[0:22:56] JH: Yes, definitely. Let's talk about Client-Initiated Backchannel Authentication. I guess, that's usually abbreviated to CIBA which is much less of a mouthful. So, it's not actually got huge adoption at the moment, but it has got some niche use cases where it's working very well. What that specification really does is when you want to authorize someone to do something, if you say doing it over a phone call, then it's very difficult to do that whole identity proofing. I'm going to - you can't read out an access token over the phone or something.

What CIBA does, you can call into a call center. The call center probably knows who you are because they've got your phone number. Then you tell the operator what you want to do. They need access to your account. So, you get a push notification on your mobile phone that says, "Hey, do you want to allow this call center operative you're talking to, access to your account?" Obviously, you can put some kind of codes in there so you know it's the person you're actually talking to. And then the user authenticates that and does the usual face ID. Says, "Yes, I want to consent to this." And then the call center operator gets access to the user's account and is able to complete whatever the user wants done.

So, that's the kind of use case as CIBA solves. As you mentioned, there's a separate message signing spec as well. The way FAPI was developed, there was an attacker model developed. Then we tried to develop a security profile that then protected against that attacker model. We actually did a formal mathematical analysis that was done by the University of Stuttgart that actually proves that, yes, what we put in the specification does actually protect against the attacker model that was defined there, and what message signing does this. It's not necessary to actually protect against that attacker model, but it's sometimes necessary to retain messages and prove later in time that, yes, I did actually receive a request to make a payment from this account to this account from this third party.

The message signatures gives you the way to actually have that signed message that says, "Yes, someone that has access to that private key that only this third party fintech should have access to, did actually sign this message and ask for that payment to be made." So, it's not technically security, but people call it non-remediation which is a phrase that people often understand, but it's just that ability to say that, "Yes, to the best of our knowledge of current cryptography, this person did actually produce that message and send it to the bank."

[0:25:23] GV: Matching of identities, basically, and not necessarily within a very specific time frame, if I'm understanding it. There could be a lag.

[0:25:31] JH: Yes, exactly. Yes, it could end up being produced in court or something.

[0:25:37] GV: Yes. Then, maybe just touch on pushed authorization request, something I think I'm fairly aware of receiving. So, I think that could be an interesting one. How does that operate?

[0:25:48] JH: Yes. So, pushed authorization request, actually, it's a great simplification to the specs because in the first version of FAPI, we actually always require people to send signed messages because these messages were actually getting passed via the browser in what you'd call the front channel, which means they're kind of exposed and the user potentially, or plugins the user has installed in their browser could modify those messages. So, yes, potentially you end up with a situation where that plugin could be changing the destination account number or something like that, which is obviously undesirable.

FAPI 1.0 said you have to sign the message to avoid that because that then makes it untamparable. But then this concept called pushed authorization requests came up. And what that allows is that it allows the fintech or the third party to actually ahead of time sent to the bank's authorization server.
I want to make this payment from this account to this account. It's passed over TLS, as you'd expect, and it's an authenticated message, so it uses MTLS or a signed job just to say, "Yes, this is coming from this third party. You can check that and know that." Then basically, the bank gives back a handle to the third party, and then it's only that handle that's actually passed into the user's browser. Then, you can't tamper with it because it's not got any of that payment information and it's either a valid handle or it's not. So, the only thing you can do by tampering with it is break the whole thing.

That just means that the developers at the fintechs can just avoid having to do this whole thing with signed messages and it just makes the spec much simpler and it helps with security and with privacy. Because even if the message is signed, the contents is still there. So, you'd have to add encryption on top to prevent the contents being leaked to browser plugins and potentially recorded in browser history and who knows what else. But again, it neatly solves that problem, because that information never flows through the browser anymore.

[0:27:40] GV: I think that's a really good example where it's not as if developers from two different bank couldn't have ultimately come up with this system. That's not the problem here. Yes, it's still very complex and still requires people to really understand, especially, things like cryptography to know what they're doing. But this sort of overarching problem here was getting everyone to agree to use spec that we all know what these different bits are and how to handle them.

Before we maybe talk about some maybe potentially non-financial, we talked a lot about open banking and we can move on to maybe just a couple of other examples. But I'm aware that FAPI does have, I think it's two different profiles, baseline and advanced. How does that differ effectively?

[0:28:27] JH: Yes. So, it's actually slightly more complex than that because there is a version one of FAPI and a version two. So, in FAPI version one, there's a baseline profile and an advanced profile. Again, they've been through several name changes. So, you'll sometimes see the baseline profile actually referred to as a read-only profile and the advanced one referred to as a read-write profile.

The thought was at the time that security of payment transactions would need to be higher than the security of just getting access to account transactions. But once these open banking ecosystems started spinning up and the lawyers started getting involved and the banks as well, they actually quickly said, "Well, hang on, we don't actually care that much about losing little bits of money. It happens all the time. We just give the customer the money back. It's not a big issue. But if the user's data leaks, that's actually a big problem, because you can't close the barn door after the horse has bolted." So, it actually came out, yes, we need this higher security all the time. Actually, the baseline profile really isn't used. Everybody uses that advanced profile in FAPI 1.0.

Then what happened, as a result of a lot of the feedback we got from ecosystems implementing FAPI 1.0 advanced, it became clear that it could be simplified a bit and made easier. And we started on a second version of FAPI called FAPI 2.0, that just has a security profile. It doesn't have baseline and advanced. And that security profile is sufficient to meet everything in the attacker model. Then, as we talked about earlier, there's extra bolt-ons like message signing and so on that you can add on top of that.

[0:30:01] GV: Got it.

[0:30:01] JH: So, we have talked quite a bit about sort of open banking at the start of the episode. You touched on some other areas, things like open insurance. But you just speak to a couple, maybe you'll assume almost seen every area or implementation of FAPI so far, or been aware of it probably. What else has been happening with FAPI?

[0:30:21] GV: Yes. I mean, it's interesting you say we're aware of them all. But even with that kind of role I'm doing at the OpenID Foundation, we occasionally get people pop up and say, "Oh, yes, we get contact from a new country and they say, 'Yes, we implemented a law two years ago that says people have to use FAPI. The first we're hearing of it is two years later." Often, we don't find out about these things as they're actually happening. Particularly with OpenID Connect, we have absolutely no idea how many implementations there out there. We reckon it's thousands, tens of thousands, but people just - it's open standards. It gets used and you never find out about it a lot of the time.

So, in terms of other ecosystems that we actually know about that are using it, I mean, Brazil went, they bought into FAPI and open data in a big way. They put open banking live. They extended that to open finance pretty quickly. Open banking, obviously, it's usually just your transactions and stuff, and then once you expand into open finance, you're talking about your investments, potentially credit cards, that kind of thing that might not be part of the traditional bank. Then they very quickly after that expanded into open insurance as well. Then, it's perhaps still slightly early days for open insurance. I don't think we've got the data yet on where the kind of biggest benefits for users are coming in.

Obviously, it's letting brokers retrieve information about the policies a user has from the insurance companies. They can then use that to get quotes from other insurance companies that have the same equivalent cover. It avoids this problem with the user needing to reenter all the information into each insurance site to try and get competitive quotes. There are alternative solutions around to that. I think in the UK and I think the US compare the market is a big one, but that's obviously all based off kind of proprietary APIs and open insurance is very much that same very open, the user owns the data type ethos where everything's based on open standards.

If a new player wants to enter the market, they can very easily do so. They don't have to sign agreements with each insurance company to get access to the data before they can actually usefully serve users. So, it's just very much about flattening that barrier to entry, and allowing innovation and things where there's, otherwise, market incumbents that just have essentially not creating a proper competitive market.

[0:32:44] GV: Yes. That's a really good example. Compare the market, I'm very, I guess, familiar with that. Finding my insurance for a house or a car. If you could give a quick explanation and we can talk about why it's even so famous in the UK, but what is compared the market?

[0:33:01] JH: Yes. It's one of these portals that you can try and find the best deal as consumers. It covers insurance, credit cards, things like that. But, yes, they do a lot of data scraping, essentially, to get the data and potentially they ask questions about what insurance policy you would like and then provide it out to a bunch of different companies. I'm sure some of them are using APIs, but I would suspect some are probably using screen scraping and those kinds of headless browsers. 

Perhaps, I don't know if money supermarket is more better known in some of the other geographies, but it's this kind of comparison site paradigm.

[0:33:37] GV: Yes. I think it was probably one of the sort of first that came on the scene for consumers. But yes, very much popularized by their advertising of compare the meerkat and having a puppet meerkat. Once they did it, I think it's all animated now. But yes, good advertising. But unfortunately, it means that everybody in the UK, I think, knows exactly what compare the market is.

[0:33:57] JH: Yes. I think, at one point, if you talk a policy out through them, they did actually send you a soft toy, cuddly meerkat in the post.

[0:34:05] GV: Yes. That sounds about right. Is this in any way in the right direction where something like FAPI is then going to actually make it safer, better than I feel like something like compare the market? I don't know what they do today, but someone like them or in another industry basically sort of scraping data and using RPL, I think is the acronym, basically using kind of headless browser, et cetera, et cetera. Terrible ways to kind of do official things that feels like where FAPI can come in and as you say, the level the playing field a bit and just say, "Look, we're all an agreement that it should be helpful to both sides that we can swap this information, but please don't come and use bots on our website."

[0:34:46] JH: Yes. Exactly. I mean, the big problem with that kind of screen scraping approach and the bots is that it's not really visible to the bank or necessarily to the user what's going on. So, if you give your online banking username and password to one of these screen scraping sites so they can pull their account transactions down. You're actually also giving them the ability to make payments on your behalf, which is not really what you wanted to do. FAPI just avoids that because it's an OAuth-based and the user is actually involved in authorizing the bank. The fintech gets specific permissions that might even be limited by the regulator or something. So, yes, the user knows that that person they're going to be able to see their account transaction data, but they're not going to be able to do anything else with their bank account.

[0:35:35] GV: Yes. Overall, just a huge step in the right direction given how many accounts, things that we basically manage online today whether it's insurance for a car or a house, it feels like all my banking is online at this point in time. But insurance is also getting there. I think they finally just implemented the ability to update my credit card on their account, which feels kind of ridiculous. But I'm aware insurance moves much slower than other industries. But if something like FAPI can come along and, as you say, level that a bit and speed that up, that sounds pretty exciting.

Let's maybe just talk about Authlete and how Authlete helps implement FAPI. So, if I'm a developer and I'm wanting to implement FAPI, what does Authlete can do to help with that?

[0:36:23] JH: Yes. Good question. So, I mean, Authlete specialty is providing these backend APIs that let you build your authorization server how you want. Obviously, you probably start by building a basic OAuth 2.0 authorization server. But then once you've built that with Authlete, if you decide you want to enable FAPI, which obviously I think most people should, then it's just a case of switching on a few configuration options, creating a few keys, and that kind of thing. Authlete hides any complexity of all that extra security that's going on from you. You just have to interact with it in the same way. You basically get that FAPI side without any development effort on your side.

[0:37:02] GV: We may have covered it in our last episode back in April, but in terms of, does it matter at all, like what stack? I'm already using, or am I already using OAuth 2.0 or OpenID Connect, how does that look in terms of I'm getting fresh at this? Fresh at this, but let's talk about both greenfield and maybe brownfield projects as well.

[0:37:23] JH: Yes, sure. Greenfield is obviously a great place to just buy straight Authlete. There are, obviously, other solutions out there, but we would say they don't give you that same level of flexibility. For example, when you're using Authlete, you get a completely free choice of which programming language, which web frameworks you used to actually develop your authorization server. Because we're not providing the actual authorization server. We're just providing those APIs that enable you to create an authorization server easily. 

You want to do it in Go, Scala, Node.js, whatever you want to do it in, you can do it in. It's just you have to call the API. So, it means that it's really loved by developers because they get the freedom to do exactly what they want in the languages they're comfortable with, which is quite different to perhaps some of our competitors that might insist you use Java and a particular web framework. You kind of get a bit locked into the decisions they made for you and having to get developers familiar with that, that are necessary, that same developers you would have for other parts of your product.

[0:38:30] GV: Yes, awesome. Yes, what's the day zero for a developer with Authlete? I mean, does it tend to be a developer that makes that for sort of signs up and gets the account running? Or is it somebody else in the org? Or how does that work?

[0:38:41] JH: I mean, I think, in general we see our customers being developer-driven. A developer just, they need to solve a problem. They sign up for an Authlete trial account. They get immediate access. And they can then put the authorization server together very simply. We've had people spin one up in a few hours. Then once they've done that, obviously, they've got their proof of concept and they can then go and build out the full proper project and get the other people involved and say, "Hey, I found this solution. This looks good to me. Go and buy this, please."

[0:39:12] GV: Yes, nice. Well, I mean, yeah, you have it listeners. Pretty easy in the end of things to actually get going with FAPI, whether it's something that's being asked of you. Depending on your role and the company you're in, or if it's actually now, just something that sounds like it, it makes a lot of sense.

I'm curious, Joseph, what are you - you're so involved with the spec. Whilst, as you say, you haven't seen, you don't know every single implementation so far, but what are you kind of excited about potentially seeing FAPI unlock that maybe hasn't actually happened yet?

[0:39:47] JH: Certainly, one big problem that we see in the UK and a lot of other countries is that people's medical records are locked into a particular system and can't be exposed. So, we have seen some of the European countries actually adopting FAPI for healthcare use cases. I think that's really exciting to let users consent to sharing their data from the provider that's holding it with other people that need it in a nice and easy way.

I mean, I can't tell you how many times I've heard from people that their GPs meant to have sent the data to a specialist and quite often involves letters sent in the post or via email with scans of PDFs and who knows. But it often seems to fail. Just by having that direct, okay, the users in control of their data, they can actually just share it directly with the specialist just means you avoid a whole area of the system that can go wrong and slow down people actually getting access to the healthcare they need.

[0:40:45] GV: Yes. That's really interesting. I lived in Hong Kong for a long time and something that stuck out there was if you got an X-ray then they just give you your X-rays like in an old packet, and then you take them physically to whoever they need to go to. It became this kind of thing that you noticed as you realized, "Oh, there's someone with their X-rays today." In other countries, that just doesn't happen. But equally, the way that data like that gets transmitted, who knows, maybe, is actually just literally posted or is it slightly sort of not okay ways of who knows emailing X-rays or something along these lines? So yes, something like FAPI could definitely, I feel, clean that up. 

So, yes, thank you so much for coming on today, Joseph. I mean, I think, I love just learning, I guess, a bit more behind the scenes of the system that I've obviously benefited from hugely having access you know, I'd say to the UK banking system and kind of having watched it. I guess, in some ways, almost take the lead a little bit on the open banking sort of stage to recap. Where's the best place for a developer to go from a website perspective to get running with FAPI on Authlete?

[0:41:53] JH: Yes. We actually have a special offer for Software Engineering Daily podcast subscribers. So, we usually have a kind of limited free trial, but that's been extended to 90 days for subscribers. If you just go to authlete.com/SED, then you'll get that.

[0:42:10] GV: Awesome. So, that's authlete.com/SED?

[0:42:14] JH: Yes.

[0:42:15] GV: Perfect. Wow. I feel like that's almost the first. We must be hitting the big leagues if we're getting the special offers just for our listeners. This is exciting. Again, thank you so much, Joseph, for coming on. Yes, I look forward to catch up in the future and all things FAPI.

[0:42:32] JH: Yes. It's awesome. Thank you very much for having me, Gregor.

[END]