Nat Sakimura delves into Financial-Grade API (FAPI) – Podcast Episode 59

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | Pandora | Email | TuneIn | Deezer | RSS | More

Let’s talk about digital identity with Nat Sakimura, Chairman at the OpenID Foundation.

In episode 59, Nat returns to the podcast to explore Financial-Grade API (FAPI), the base security protocol for UK Open Banking, Australian Consumer Data Standard, and Brazil’s Open Banking. He discusses why and how FAPI was formed; what exactly FAPI is – including technical characteristics; how FAPI is used today; and future plans for the specification – as well as how it connects to GAIN.

[Transcript below]

“The data economy needs a secure and interoperable data network. And we are finally getting there with FAPI and eKYC standards. So, you guys need to get ready for the ride. It’s the time. You need to start acting, start preparing for that.”

Nat Sakimura is a well-known identity and privacy standardisation architect and the representative partner of NAT Consulting. Besides being an author/editor of such widely used standards as OpenID Connect, FAPI, JWT (RFC7519), JWS (RFC7515), OAuth PKCE (RFC7636) ISO/IEC 29184, ISO/IEC 29100 Amd.1, he helps communities to organise themselves to realise the ideas around identity and privacy.

As the chairman of the board of the OpenID Foundation, he streamlined the process, bolstered the IPR management, and greatly expanded the breadth of the Foundation spanning over 10 working groups whose members include large internet services, mobile operators, financial institutions, governments, etc. He is also active in the public policy space. He has been serving in various committees in the Japanese government, including the Study Group on the Platform Services of the Ministry of Internal Affairs and Communications and the Study Group on the competition in Digital Market of the Fair Trade Commission of Japan.

Find Nat on Twitter @_nat_en and LinkedIn.

Nat also appeared in episode 54 of Let’s Talk About Digital Identity, discussing how OpenID Connect took over the world.

We’ll be continuing this conversation on Twitter using #LTADI – join us @ubisecure!

­Go to our YouTube to watch the video transcript for this episode.

 

Podcast transcript

Let’s Talk About Digital Identity, the podcast connecting identity and business. I am your host, Oscar Santolalla.

Oscar Santolalla: Hello and welcome to the first episode of Let’s Talk About Digital Identity for this New Year 2022. And we have a very special guest who has been in very short clips in an episode we had in October, very recently in October. A very special episode, a storytelling episode called How OpenID Connect took over the World, and today’s guest was there. We are talking about our super special guest called Nat Sakimura, one of the creators of the OpenID Connect standard.

Nat Sakimura is a well-known identity and privacy standardisation architect and a representative partner of NAT Consulting. Besides being an author and editor of such widely standards such as the OpenID Connect, FAPI, JWT, OAuth PKCE among others, he helps communities to organise themselves to realise the ideas around identity and privacy. As the chairman of the board of the OpenID Foundation, he streamlined the process, bolstered the IPR management, and greatly expanded the breadth of the Foundation spanning over 10 working groups whose members included large internet services, mobile operators, financial institutions, government, etc. He has been serving in various committees in the Japanese government, including a Study Group on the Platform Services of the Ministry of Internal Affairs and Communications and a Study Group on the competition in Digital Market of the Fair-Trade Commission of Japan.

Hello, Nat.

Nat Sakimura: Hi, Oscar. Thanks for inviting me.

Oscar: Welcome. It’s a great pleasure talking with you, Nat. And well, Happy New Year. And let’s talk about digital identity.

Nat: Likewise, yeah.

Oscar: Fantastic. And I think we know a lot of your involvement, of course, you are leading one of the most important standardisation organisations in the digital space. We’d like to hear a bit about yourself, something personal, of course, how life led you to this world of digital identity.

Nat: OK. So you wanted to know, how was my journey to the world of identity?

Oscar: Yes.

Nat: Yeah. There are three reasons. They all converge to identity. In the middle 1990s, I was working on VPN as an alternative way to secure communications than having dedicated leased lines. And at that time, we were using dedicated leased lines in the financial institutions. And that actually amounts to the identification and the authentication of machines and people as well as integrity protection and encryption of the communication channel. So there you have identity.

Then also, the second reason was that I found in the hard way that access to our personal data is not granted. My daughter had a failed surgery, she was three years old then, and for re-operation I needed to access the medical record quickly but it was not granted. So it was not useful for us. That was a surprise for me. We didn’t have the right nor technology in place to access our own data in a meaningful timeframe. So I started on the combination, the identity and privacy then.

The third one was the research commissioned by the Japanese Postal Agency. It’s been subsequently privatised, but it was still a government agency at the time, on the future of mails. And as part of the research, I got acquainted with Drummond Reed, who dragged me into the standardisation part of the identity arena.

All of these combined paved the way for me to get into the digital identity standardisation work.

Oscar: I see, it’s very interesting you mentioned these three points. One very technical, solving the security problem so that those time- the VPNs in ‘90s, 1990s. Then you needed to access personal data of your daughter, right? And even though I’m sure it was stored somewhere, but you were not able to access it in a timely manner, as you said so.

Nat: Right.

Oscar: Yeah. And then I think the opportunity came, as you mentioned in the Japanese Postal Agency to start working on the standard. So, yeah, super interesting. And we have talked recently and you say you wanted to talk about FAPI, one of the… yeah, one of the main – well children of OpenID Foundation. We have interviewed also Don Thibeau a bit more than one year ago. He a little bit talked about that standard. He has been very enthusiastic about talking that standard and I’m sure you have much more to tell us. But please tell us what is the… what – where is the beginning of that? So what were the challenges that you were working on OpenID Foundation found, led that – led to the, yeah, to start working on the creation of FAPI?

Nat: Yeah. So, right after we have finished OpenID Connect in 2014, I think I have started working on FAPI- preparation for FAPI in 2015. OAuth and OpenID Connect are designed to scale from the point of view of security. If you use only the very basic, you can achieve entry-level security quite simply. Since you’re not using options, it was not that hard to achieve interoperability.

However, when you wanted to achieve more security, you had many options to choose from. And the different combinations not only led to different security properties, but also a lack of interoperability. We needed to bolt the options down so that we have known security properties as well as interoperability.

Oscar: Yeah, indeed, I think interoperability is a word that always come to any standard because there are so many different… yeah, so many possibilities can be done and so many different needs in different, yeah, different industries, different places in the world. Yeah. FAPI is Financial-grade API, correct? And I understand also that from the beginning, it has been, as the name says it’s for financial transactions. Please tell us a bit, what is FAPI in practice?

Nat: Yeah, the FAPI is a general purpose security profile of OAuth and OpenID Connect to protect APIs. It started off from financial use case, from which the letter F comes from. But later, it also made clear that it has general purpose. So we changed the name from Financial API to Financial-grade API. It can be used by for example, healthcare, transportation, and name any.

So there are two notable characteristics of FAPI. Number one is that all the communication is integrity protected, so that it’s tamper-evident. All messages are authenticated. And the second characteristic is that no bearer token is used.

Oscar: OK.

Nat: Yeah. So even if the token was stolen, it cannot be used. You know, the bearer token is like metro ticket or something like that. So if you drop it, and if somebody picks it up, it can be used, right? And instead, in the case of FAPI, we decided to use something called sender constrained tokens. Sender constrained token is much like international airline ticket, I mean the boarding pass. So when you use it, it’s got your name, and you need to show your passport, for example, or travel card so that the person at the entrance can match that you are the rightful user of that boarding pass. So that’s the sender constrained token. And in FAPI, we have stopped using bearer token completely and went all the way to the sender constrained tokens.

So another way to look at it is that it fulfils four authentication properties. In many cases, when we talk about these things, we kind of focus on the user authentication. But there are many other kinds of authentication, which is really important. The number one is strong server authentication. Number two, strong client authentication. Number three, strong message authentication. And these combined with strong user authentication, you will have a pretty complete security picture. So that’s the security part.

And also, we wanted to address the interoperability. So to improve our interoperability, we also needed to provide a testing framework. That is now provided by the OpenID Foundation as FAPI Certification. There are now over 150 implementations that are certified and number is increasing quite rapidly now.

Oscar: And there is some sort of self-certification, correct?

Nat: Yes, it’s a self-certification. So, the test suite is also available as open source. So you can, for example, use it for the continuous development – some banks are actually using it like that. But when you are done with the development, and you have passed all the tests, you can submit the result to OpenID Foundation, and then it will be published from the OpenID Foundation site, and they can be checked by your peers as well so that you know, you have a conformant implementation.

Oscar: Excellent. Yeah. One thing I was not aware now that I said just before asking you is FAPI’s Financial-grade API. And when I read and when I heard for the first time that term, to me sound like yeah, it’s financial, but now you clarified that initially it was Financial API but then now it’s financial-grade, so as secure as the financial transaction, I guess that’s the idea, right? So now it’s more general purpose in a very secure profile from OpenID Connect and OAuth 2, so that’s interesting.

Nat: Yeah, that’s correct. Yeah. I mean, so I think it was by 2017 or ‘18, we had a request from both the healthcare sector as well as the international travel sector, you know airlines, that they wanted to use it. But their request was to change the name because having labelled as financial, it’s going to be harder for them to actually make industry-wide adoption of it. So we kind of searched for the name. By then the acronym FAPI was quite popular so we didn’t want to change the acronym and we wanted to generalise the F part. And we couldn’t come up with anything better than financial-grade. But the intent is that it is for any industry, and it’s secure. That’s what we wanted to communicate.

Oscar: Yeah. Thank you. Thank you for that clarification. I think it’s very important also, for the ones who are not so familiar with the term yet, so yeah. And also, the fact you mentioned in the description that in FAPI, as a profile of OpenID Connect, you don’t – you get rid of the bearer token so that already tells a lot about how much secure it is per se, the bearer token is just – it’s not a possibility in this profile.

Nat: Yeah. So we have removed the bearer token, removed completely to the sender constrained token, as well as other communications even through the browser, is integrity protected. That’s not the case in the usual OAuth or OpenID Connect. So…

Oscar: Yeah, that is correct.

Nat: Yeah.

Oscar: Sounds very interesting. I have to play myself in the browser, what can I see, what I cannot see, so it’s super interesting.

Nat: So unless the sender and the receiver is using the encryption model, you can still see it, but you cannot tamper it.

Oscar: Oh, yes.

Nat: Yeah. Yeah.

Oscar: Exactly.

Nat:  It’s signed. Yeah.

Oscar: Exactly. Exactly. The integrity, you cannot, yeah. You cannot modify it. OK, excellent. Please tell us, yeah, you mentioned that initially it was for financial, then at least healthcare and aviation or transport were interested, what are the – nowadays, let’s say, what are the main use cases? Those are still the main use cases or it’s even broader?

Nat: Yeah, as I’ve said, it’s general-purpose, so it can be used for any use cases that require high level security. Having said that, since we have started off from the financial world, they are leading in the implementation. They had like two years of head start. So the most popular implementation scenario currently is banking. So like accessing banking data, or making payments, and things like that.

Oscar: OK. And I know, I read from some examples from FAPI, the documentation is available. They mentioned some has been already – FAPI has been made part of some, I don’t know standards or regulations in few different countries, including UK, open banking is the most known. Could you tell us about those? How has FAPI being implemented in different countries?

Nat: Yeah, so as you mentioned, the first mainstream usage was the UK Open Banking. Nine biggest banks were mandated by Competitive Market Authority, CMA, to open up the API and FAPI was chosen as the protocol to secure them. And I understand the first reason for that is to make banking data portable. But subsequently, PSD2 kicked in, and now it was expanded into the payment.

And then after that, Australian Consumer Data Standard adopted FAPI. So as the name suggests, it’s much wider than just banking. It’s for any consumer data costs. Again, they have started from banking, and if I remember correctly, they are now expanding into electricity and things like that.

And then Brazil followed the step. I actually had the opportunity to talk with the Vice Governor, I think of the Brazilian Central Bank in London, just before the COVID outbreak. And we agreed that adopting a standardised approach for the testing or certification coming together is going to be really, really vital for widespread adoption and quick adoption. So I think that was taken by Brazilian Central Bank and they are now mandating that to the banks and TPPs, they’re like parties in FinTechs.

And then more recently FDX in the United States announced its adoption, so did the Russian FinTech Association, they have been public. While FDX has made a written statement in the blog post on their website, in the case of the Russian FinTech Association, it’s still verbal, but they’ve been speaking about that in the conferences. So I think it’s, you know, public knowledge now.

Of course, there are a little bit of tweaks that are required for the Russian use cases. In the case of current FAPI, for the purpose of bolting down the options, we have specified a few encryption algorithms and signature algorithms to be used. But in the case of Russia, they need to use their own cost standard for those algorithms. So we need to expand it, modify it and expand it a bit. But that can be done as extension. We are talking about that right now.

And then most recently, we have started joint workshop with the Berlin Group, which is very prominent in continental Europe to seek a way to converge. So, it’s getting good traction now.

Oscar: Berlin Group, I’m not so familiar. It’s also into financial or what it covers, Berlin Group?

Nat: So Berlin Group is mainly… how can I put it? It’s an association of mainly banks. And then there are advisory groups made up which includes FinTechs and other industries as well. But although the name says Berlin, it’s not only Germany. It’s from many other countries as well. So it’s quite widespread in the continent of Europe. And also, I heard some of the Berlin Group banks are now implementing FAPI, or they have already implemented FAPI as well. So that’s an interesting development as well.

Oscar: And it’s also possible that some – in other countries, in different institutions they can implement independently, right, without having a regulation or a main association that – say it force them to use them.

Nat: Sure. Sure. It’s a standard and standards, unless required by regulations like in some other cases, it’s totally optional. It’s totally voluntary. But at the same time, you know, anybody can actually use it. So you don’t have to wait for regulators to come in, and mandating you to use it.

Oscar: So it’s very likely that we will hear in the next, well, in the new year and in the coming months, coming years more associations like this, or banking or even in other industries, more regulations in different other geographies that are embracing FAPI.

Nat: Yeah, so one of the reasons for FDX I understand to adopt FAPI is to move ahead. Well, I don’t know if that’s correct in other countries, but in many countries, if industries or industrial body actually self-regulate themselves, the government regulations do not kick in and you’ll get more freedom. So I think it’s actually better for the industry to adopt something like this without being mandated by the government.

Oscar: And what about GAIN, the project you are heavily involved also, a project that was released a few months ago that also requires GAIN, or – I’m sorry, FAPI. Is FAPI part of GAIN, or could you tell us?

Nat: So GAIN itself is technology neutral, so…

Oscar: OK.

Nat: It’s not mandating any particular technology. It’s open, but FAPI can also be used. And certainly, that is envisaged by some of the participants in GAIN as the first step. So certainly, you can use FAPI and there are people who are using FAPI in the GAIN POC that they’re self-organising right now.

Oscar: Excellent. And could you tell us – leaving a bit outside of the main topic of FAPI, but could you tell us a bit what was also coming from in GAIN, what is happening lately and what is coming in the next months?

Nat: So, there are two distinct paths, at least two, or maybe depending on how you count, it can be three. One is a technical working group, which is hosted by OpenID Foundation and the others are the legal and the business working groups, which are hosted by IIF and Open Identity Exchange. IIF stands for International Institute of Finance, right?

And as to the technical part, we are currently working on the legal agreement, a legal participation agreement so that we can create a safe space for all the participants whose taking part in GAIN POC. We’re in the final phase of drafting such a legal agreement, so that we can participate in POC feeling safe.

Oscar: Excellent. So yes, more… the POCs are coming for GAIN. Excellent. And tell us, core FAPI is the project that has ended, I know you are you’re working on that. So tell us what is coming next for the FAPI Working Group?

Nat: So FAPI Working Group is very far from being done, right? And we have ever more work to do. In the beginning, we didn’t create a profile for dynamic client registration, or consent or intent grant, and every jurisdiction says it slightly differently, but grant management will be core. We had enough work to work then as well. So we kind of postpone the work.

However, after UK, EU, Australia and Brazil went online, it became quite clear, painfully clear, that there are compatibility and security headaches because of no standardised way of doing it. So we decided to start work to address them. So the new technical specification called Grant Management for OAuth is being drafted. And it’s gone through the first implementers draft for OAuth successfully so that it can be implemented by implementers without fear of being sued or something like that. And people are just ironing out the kinks about the draft. We’ll probably need multiple rounds of these things to get to the finalisation but it’s a good start, right.

And then now we’re just starting, just in this, like, a month or so, we’ve been starting dynamic client registration part. It’s been done slightly differently in the UK, Australia and Brazil, as well. And, you know, we are gaining a lot of knowledge from that as well. So we are trying to codify the best practices about those. And hopefully, that’s going to be a very good guidance for other jurisdictions to follow.

Oscar: So that relates to the enrolment of customers or identity for customers.

Nat: Well, actually, no, that’s KYC, right. The dynamic client registration is so the end users uses software to interact with the, for example, banks, in the case of open banking, right? And this software actually needs to be registered to those banks. And we have to exchange the keys and things like that. And that can, of course, be done manually but that doesn’t scale. So we needed to have some kind of programmatical way of doing it. That’s called dynamic client registration. And again, we have a lot of options there. And we need to fold it down for the interoperability purpose and to have predictable security. So that’s what we are doing.

When it comes to the KYC part, KYC is a big field. And it’s a headache for all the financial institutions. It hasn’t been too effective to date, but we’re trying and one of the ways to help the pain there is to create a protocol which would make it easier and more secure to exchange those KYC data among the participants, like GAIN. And that’s not being worked on by FAPI Working Group, but in the adjacent working group called eKYC and IDA Working Group.

Actually, if you join the FAPI Working Group call without dropping off and calling another number or accessing new URL, you will be seamlessly taken to eKYC and IDA Working Group. It’s just happening at the same time, I mean at the same location, just they are connected to each other. And that working group is working on the data and metadata side. That is how to express verified attributes and how they were verified. And these attributes, in the first phase we are sorting out the natural persons, but in the coming days we will also be doing legal entities as well, just passing that this person has been verified as, for example, Nat Sakimura isn’t good enough, you really can’t trust it, right? You need more information and, for example, how it was verified, why it was verified, which evidence you have used, under which legal framework, and so on, so forth, and when.

So, these we call metadata needed to be sent with the data itself. And the specification called OIDC for identity assurance, or OpenID Connect for identity assurance, deals with it. And using that standard, you can get those data and metadata together in a signed format. So the combination of the standard, together with FAPI will be very, very powerful.

Oscar: Yeah, I can see it’s needed definitely. It’s powerful as you said. So yeah, fantastic job that the FAPI Working Group and this other adjacent group is doing together. Nat, just one final question, for all business leaders who are listening to this conversation we had, what is the one actionable idea that you would like them to write on their agendas today?

Nat: OK. So while it’s been talked a lot about – the data economy, that it will be over 5% of GDP, it’s yet to be seen. Why? The data economy needs a secure and interoperable data network. And we are finally getting there with FAPI and eKYC standards. So, you guys need to get ready for the ride. It’s the time. You need to start acting, start preparing for that.

Oscar: Yes. And that will affect all industries.

Nat: Yeah, it’s not only financial institutions. Yeah, it’s for everybody.

Oscar: Yeah, I couldn’t agree more. Thanks a lot Nat for this very interesting conversation. We had knowing a lot more about FAPI and all the great work you do. And please let us know for people who like to continue the conversation with you or know more about the work you are doing, what are the best ways to find you on the net, get in touch?

Nat: OK. So, I’m in LinkedIn. If you search Nat Sakimura, you can get there. I’m on YouTube as well, so you can get to me there as well, so is Twitter. And of course, if you’re technical, I highly recommend you to join FAPI Working Group so we can share the technical ideas in a safe IPR environment.

Oscar: Excellent. Again, thanks a lot Nat for this interview and all the best and Happy New Year!

Nat: Thanks, much obliged and likewise.

Thanks for listening to this episode of Let’s Talk About Digital Identity produced by Ubisecure. Stay up to date with episodes at ubisecure.com/podcast or join us on Twitter @ubisecure and use the #LTADI. Until next time.

[End of transcript]