So yeah, I'm Joseph Heenan, I'm the CTO or athlete. We're a an authorization server vendor. We had a different session explaining a bit more about what we do, which I'm sure you can look at the recording of if you're interested. But a lot of the last five plus years I've been really helping make ecosystems interoperable and secure. So I'm gonna talk a bit about that with my colleague Daniel.
Hi everybody. Thanks for joining us So late here today. My name's Daniel Fed and I'm today here also for Athlete and Justice Joseph. I've worked in a different thing, but same goal making things interoperable on a large scale. And this talk will in, in this talk we will present what we learned and what we did over the last years. And it all starts with orth two of course. So say you want to create an eHealth API or you want to your, your technical body writing an open insurance specification, of course you need API authorization, you might need authentication based on open ID connect. So what do you do? What do you write in your specification? Do you just say, and I've seen that in practice just use or two, that is not enough because as it turns out, in any larger ecosystem, you need more than what or two gives you, for example, you want real interpretability or two says in the first paragraph that it is not interoperable, it will create non interoperable protocols.
So it's a framework giving you a lot of flexibility, but you really need to tie that down. Obviously you need to do something about security. I've seen specifications where it says use or two and then cater for the OS top 10 security issues. That's obviously not enough. What is with the or OS top 11 security issue, right? So or two really just gives you authorization. You need more than that. We learned a lot about author to security and so we, some of that you already find it open and deconnect where you obviously get the authentication part. You also get conformance tests that we'll talk about later, but you don't get what is, for example, written in the OR two security bcp, which, which really captures a lot of the, the security stuff that we learned you can use or 2.1 which is great, which is essentially or two plus the security BCP best current practice. So that's great, but it still doesn't give you interpretability. If you want all of that, then your best choice is probably to use fpi. So what is fpi?
All right, so let's start a little bit by talking about the naming. So the naming has evolved a little bit over the years, so there we go. So FPI started out as financial API and there was a, a goal in the working group to provide a all singing or dancing globally compatible open banking api. Turned out that wasn't quite so easy, but we did do a security profile so we started to, to use that in the name. But then we realized that this wasn't just for banking. You need high security for all the use cases. Daniel mentioned, you know, when you're sharing your health records, you probably want that to be at least as secure as your access to your bank. But we wanted to keep the FPI name. So we moved to financial grades API security profile to try and imply that yes, you can use this in other places.
But then as we talked to more ecosystems, they said, well it's still got financial in the name. We don't really like that we'd, we think it's focus for banks. We don't really think it's for us. So now we are just fpi, we, we don't stand for anything. Although Nat, if you're at the session on Monday, the chairman of the FPI working group, Nat has an idea on turning it back into an acronym again. So this may not be the end of the story. I think we were going for formally analyzed protection interfaces latest idea. So we'll, we'll update you on that at EIC next year.
Yep. So FPI is, FPI is a security interoperability and feature profile for all two. That gives you all the things that I mentioned in the beginning. It's usable for all high security APIs, whether it's an E-sign application, e-government, health, financial obviously insurance, whatever. You can use it. And yeah, so, so it's really agnostic to what you're actually do doing with it. FPI two is the latest here. So we have FPI one which is already also rolled out in some applications, but there's also FPI two, which is an evolution of FPI one based on the industry experience. So the things that we learned about the best security mechanisms, the best interoperability, the things that you should do and shouldn't do in such a profile, we put all of that into far P two. It's easier to use than FPI one, it has better interoperability and it's more secure in the sense that it's easier to analyze whether it's actually secure or not.
So there's a couple of specifications that you should know. So at the bottom you find the attacker model. That's a more theoretical document that outlines what we want to protect against and what we don't want to protect against in this profile. Of course you still have attacks that, that you need to consider, but some of those are outside of what provides you. You need other measures to do that. Then there's a security profile on top that really tries to protect against all these attacks outlined in the attacker models or against the attackers, not the specific attacks. So we really talk in attacker capabilities. That's probably the most important document. That's the one where you want to start reading that tells you what exactly you need to do to get secure and interpretable or an almighty connect. And then for special use cases or special requirements, there are a couple of add-on documents that you can or cannot use.
So there's message signing obviously for signing messages for non-repudiation client initial initiated back channel authentication for special flows grant management if you want to have an API to, to talk about, like to manage grants or to to talk about authorizations that happened in the past and to modify them and so on. And let's talk about the security profile for moment. As I said, this is the most important document here, just to give you an idea of what's happening in that document. A few examples. For example, we took all the things from the orth best current practice RFC draft if you want. If you don't want to read that document it ha, I think it has 60 plus pages. It's a good idea to use FPI two because we incorporated all the measures from there into FPI two. Obviously we have paragraphs telling to you what algorithms to use, what algorithms not to use TLS recommendations and so on.
There are recommendations for example, for sender constraint access tokens, super important to keep access token safe. Even if they get stoned they cannot be misused. Asmatic client authentication is a learning to improve security. We don't have enough time to go into all the details here, but the message here is there's really a lot in there, but still it's a relatively brief document that you can read and is really actionable. The security recommendations they, so we didn't just like invent them. We had a formal security analysis to to underpin this to really say okay, this actually protects against the attacker model. So this is also formally verified. Then regarding interoperability of course the main point is reduce the optionality or two gives you a lot of optionality, different grant types, different mechanisms for almost everything so far. P two selects the best mechanisms for you and also tells you which mechanism not to use, which mechanisms might be insecure to give you an A protocol that is on the wire interoperable. So two far P compliant implementations will actually be able to talk to each other. One thing that we added for various reasons actually push authorization requests. They increase interoperability, they replaced bespoke solutions that were, that we saw for example in the banking sector and they improved security as well. So great mechanism and that's actually, that touches on security interoperability and all the other areas as well. And then there's another part that's conformance tests.
Thank you Daniel. So yeah, so the great thing about all the work Daniel just talked about where we've actually reduced the optionality and been quite prescriptive about how you should do things. It means you can actually test things cuz generic OTH two, it's just too flexible. Nobody has ever produced a comprehensive OTH two test suite. But for fpi we can absolutely do that. And this is what we really use to drive the interoperability in large scale ecosystems. It's great having a protocol that's interoperable, but if people don't actually implement it, like the specification says it's still not gonna be interoperable or it's not going to be secure. So we have a complete conformance testing program. It does positive and negative tests. So it tests the happy flow, it checks what happens when, yeah hey let's put this incorrect signature on an object and see what happens. It shouldn't work. And the test suite detects all those things. And then there's, there's a, a certification program around that actually lets you get your results formally published. So you're on a list of people that are known to have passed the test.
And yeah, it's quite a cheap and easy program compared to if sometimes people think about these things, comparing it to, you know, getting a sensor to do an audit of you. It's not that it's an open source serve software. You actually run the test yourself against your own system and then it's, it pretty much gives you a pass or fail and then you just have to package the resorts up and send them to open ID foundation to get your official certified mark. So we'll just talk a little bit about who's actually using this now. So FPI was first adopted in the UK open banking. They were very much the trailblazers with open banking and immediately saw the value in FPI and actually contributed to the spec development and gave us lots of useful impact. So that's been life for four years now, five years, something quite a while now and people have continued to copy that, that model really.
So I think Australia was the next one to go live. Then Brazil with open banking, which later became open finance there and then they launched open insurance very recently as well. So they're, they're going wide and fast on their ecosystems and they've really gone all completely full in on conformance as well to make sure that they can grow at that kind of scale and speed. FDX in the USA has formally adopted fpi and they also have a Canada chapter. We've got banks in Japan live with fpi. We've got the yes.com ecosystem in the the Europe and Steiner's health ecosystem in Norway. And did I mention Kingdom of Saudi Arabia? I think that's one of the latest editions. They just went live early in the year again, just really copying what the UK did and then we've got Russia who are using it, but they picked their own crypto for Russian reasons.
Yeah, so coming to the end of our talk and I'm happy that we are right on time. If you want a high security in Intel Porwal or two implementation FPI and FPI two in particular is your best choice. It is really a batteries included specification. So we hope that we as we speaking as the open ID f p working group that we provide you with everything that you need to really get your API running quickly. It incorporates all the latest security recommendations, ensures interoperability, which also of course means through the conformance testing that when you say your API uses F P two, you automatically get vendors that can provide you with software that is already conformance tested. So that's a, a huge benefit. So you don't need to, and your implementers don't need to write everything themselves. The future rich extensions, I can imagine that there might be more in future for specific use cases and Joseph has talked about that this has already gained adoption worldwide. Probably some other use cases that we don't even know about as well. So that's the specification that you want to use if you need these properties. Thank you very much.
Well thank you very much. And of course, do we have any questions from the audience? No, well just let's cut of all this sinking in. We need some time to digest it and have
A question.
Thank you for a fantastic talk. That was really good. I was wondering, do you have any numbers for coverage on the RP slash client side for the client libraries or CERTIF certifications?
So client side libraries certification is a bit of a more difficult topic. It's very easy to get the banks certifying. We are working to get more clients certified, but certainly one of the things Brazil did was they mandated RP certification. So every library that is being used in Brazil is now indirectly certified, but we would like to have more certified libraries. Ultimately, if anybody has written a OAuth FPI client library and would like to get it certified, please come talk to me and I'll help you through the process.
Okay, awesome. Thank you. Thank you again.
