TRANSCRIPT | OPEN BANKING WITH NATHAN COFFING

You’re listening to the Identity at the Center podcast. This is a show that talks about identity and access management and making sure you know who has access to what. Let’s get started.

Welcome to the Identity at the Center podcast. I’m Jeff, and that’s Jim.Why don’t we go ahead and introduce Nathan Coffing. He is the head of strategy at Cloudentity. Welcome, Nathan, to the show. Thanks for joining us.

Thanks for having me.

I know we’re going to talk a little bit with you about open banking and how that has started to open up for organisations to start taking advantage of. But before we get to that, I think it would be helpful for the folks who are listening to understand your journey. You’ve known Jim for a long time in prior roles and the maturation of your own career, but how did you get into the IAM space? Is it something that you chose, or did it choose you?

Well, we got to go back to the Netscape iPlanet days, where I was actually at Boeing working on the cyber side, building some of the initial firewalls. Then Sun chose me somehow. I’m not sure how they got my number, but apparently there was data sharing back then that required some type of consent, right? I got recruited into the iPlanet-Sun alliance, or the AOL-Sun alliance, and then from there continued both in the identity space as well as the cyber space. So, I spent about 15 years doing just identity and then hopped back over to the cyber side, joining as one of the first couple of dozen employees at Imperva back in 2008, 2009. Then, I really saw kind of this inculcation, this need to bring cyber together with identity. I think that’s one of the core tenets of the podcast, right? It’s identity at the center, whether that’s the center of your application security or the center of your user security, which becomes a fundamental part to building out your next generation of applications. Sorry to give you a plug, guys, but it’s too easy.

I definitely love that. I always love hearing about somebody’s journey in this industry, because usually, they started off somewhere like — I don’t want to say at the bottom, but they started out somewhere in the guts of the machine. You started off with the Netscape directory, which of course is core functionality, but it’s more or less the back office. Now, you said you’re the chief strategy officer at Cloudentity, and I’m wondering if you could tell us a little bit about that role.

I alluded to it in that previous monologue. We’ve looked to bring dynamic authorisation — bring in a lot more context. That can be cyber context. It can be consent context. We want to push it all the way up to the edge of the service. So, we started thinking, “How can we start building product around this?” looking at micro services, API-led infrastructure, back in 2015, 2016, and then started rolling intelligence on top of it. Machine learning is a much better descriptor than AI, but I know AI is more in vogue to use those words these days. So, we started pulling these different pieces together, making sure that we could have adequate datasets, adequate rules and adequate policy decision points at the edge of the service. As we’ve built that, we started getting believers both in the marketplace — meaning some early adaptors of our technology — as well as the believers in the VC marketplace, and underwent the first round of funding last year. As part of that, I shifted out of the sheer tech point of view and moved into “How can we lead the team? How can we start building a bigger, broader team?” We’ve been able to bring in some incredible talent both from people running in the OAuth circles as well as other IAM platforms.

So, Nathan, I was wondering: When you go to a prospect, is this something where they’ve sought you out because they understand your technology, or are you usually going through an education process?

I’d say that’s transitioning over the last three to six months. Part of it is due to COVID; part of it is due to the adoption of distributed services. But what we’re seeing is that as people move into the next generation of services — and whether that’s a Kubernetes or a service mesh or functions — they have no idea how to bring identity constructs into that, much less cyber constructs. 

One of the big goals as you’re building this next generation of services is to make them immutable: How can I externalise identity, authorisation and privacy, make that incredibly easy for my developers? Anytime I bring in a new service, it’s protected by a default set of rules. If we think about identity for the last two dozen years, what’s been the hard part? It’s always been onboarding applications, bar none. Now, you’re starting to have the capabilities to automate that onboard, make them very, very seamless. I can onboard 10,000 services in a matter of minutes so long as there are next-generation services that are API-driven. So, you’re able to really start driving innovation forward, and instead of becoming this tax that happens after the fact, you’re able to lead the digital transformation by saying, “I’m going to make these parts easy for you.” We can even talk about that from a customer perspective. 

Now, the reason that we have open banking at the center of this discussion is because that’s really one of the first mandated and regulated areas where APIs have to be the center, meaning the first real API-centric transaction requirements coming from federal bodies or government regulatory bodies, depending upon the nationality.

So, we’ll talk about open banking here a little bit. Why don’t we start with “What is open banking?” because I think people may be using it and they don’t maybe even know it. I think of services — maybe something like Plaid, where you’re connecting different financial services together, or Mint, Personal Capital. There’s a bunch of these out there that let you interface and pool financial data into third-party apps that aren’t necessarily owned by the financial institutions themselves. Is that a good explanation of it, or is there more to it?

You’re hitting on the core tenets, and it’s really about the democratisation of banking: I won’t be able to build a bank, but I’ll be able to build a service that can consume bank data. The second aspect of it is the utilisation of privacy and consent. I’ve seen the GDPR, the CCPA, things of that nature bubble down on a larger industry basis, but then open banking has been very, very explicit in the flows: “Here’s where I need the consent to what. Here’s how fine-grained that consent should be.” We’re also seeing that start to now percolate into some of the different standards bodies. 

What we’ve seen just in the last six to seven months is a grant management standard pop into the OAuth standards bodies, and that’s becoming increasingly important because everybody, every user, now wants to understand where their data goes. They’re tired of seeing the Facebook or Cambridge Analytica examples, or the Experian data breach that just happened the week before last, where there was highly insecure API, and no authentication for user or for another service. No authorisation, and the only construct protecting it was public data, meaning my birthdate — I’m sorry, not even my birthday: first name and last name, my address, and then an unvalidated birthdate. 

When you’re using it in an API perspective, you can programmatically go and download all of it. You can literally iterate all the way through and take public records that you either pulled from the dark web, and just boom, boom, boom, boom. Now, I’ve got everybody’s credit score number, and that’s sensitive data to me. I’m sure it is to everybody else listening as well.

One of the challenges that I’ve seen, having been a consumer of some of these services, is the inconsistency with how they may be implemented, and I think of things where you have to go into this interface, you type in your ID and password for the target financial institution, and if they have MFA in place or some other type of second factor that you need to provide, it’s a very sticky situation sometimes where you’re waiting. It’s almost like they’re doing screen-scraping behind the scene sometimes, and it’s frustrating for me as a consumer trying to keep my accounts linked. And me not knowing enough of how it works between the open banking standards that have been developed and companies who maybe aren’t using it. Is that a symptom of a poor implementation of it? Is that just how it works right now, or maybe I’m not even using open banking, and that’s why my experience is so poor?

So, if they are screen-scraping, they’re not using open banking. Screen-scraping is a security vulnerability. They’re doing an impersonation against both your bank’s standards of conduct as well as even their partners’ standards of conduct that you’re logging into. That’s been the de facto for the last half dozen years as we’ve seen financial aggregators really come to fruition. Now that’s changing because of open banking. Literally everybody realises that’s a big problem, so how do we start to normalise that, and how do we build common patterns around consent and around data? So, if you’re seeing screen-scraping, if you’re seeing that delay, you’re probably not in an open banking ecosystem, and you don’t have the security which is wrapped around open banking. 

Now, I’m going to go back to an earlier point, Jeff, and it’s a lot worse than we actually think, particularly over here in North America. What I mean by that is, we’ve got all of this identity and authorization sprawl, depending on when your application was built. Maybe it was a 2008 mobile app, or maybe it’s a 2020 mobile app. You probably have a different IDP. You have hard-coded authorisation, you have hard-coded privacy built into it, and even those different services or those different applications from a singular bank don’t talk to each other well. 

Now, the banks are obviously trying to fix that and give a little bit better user experience, but within some of the credit bureaus, I can jump from service to service to service. I’ll have to reauthenticate, I’ll have to reauthorise, I’ll have to regrant consent, because none of it is stored outside of the applications. It’s all hard-coded in there, and nobody has any good way of reporting. 

Now, that’s obviously a tremendous liability for the banks, the credit bureaus, etc., or for any of the financials, because they’re storing different data. And any time a regulatory body comes and says, “Hey, show me. Prove to me that Nathan allowed you to use his account data. Prove to me that Nathan even allowed you to use his last name,” they have to go and say, “OK, well, I don’t know what the policies look like. I’ve got to find the developer that wrote that application.” That developer has to go back to the code, and more than likely, they’re developers in another company by now. They have to go back into the code, try to extract it and then showcase exactly what transpired. You and I both know that’s almost an impossibility. The reality is, going across all those different systems and platforms, trying to showcase exactly what happened within a transaction, is a lot harder than it is to explain. 

So, being able to externalise that, normalise it and then use a common authorisation, privacy identity standard, across all of them, well, that’s exactly what OAuth was designed to be. What I mean by that is, we saw OAuth and OIDC pop out in 2011 to 2012, depending upon which one we’re going to count by. The design there was, “Let’s separate context. Let’s separate the authorisation construct away from the identity, the session building.” But what we saw the industry do is, we took these big monoliths that we’ve been using for WAM for the 2000s: “Oh, let’s layer on top of federation. Let’s layer on top of OAuth. Let’s layer on top all of these things.” We threw another monolith at it, and we built these giant constructs that are difficult to use, difficult to upgrade and aren’t meeting the needs of modern application developers. 

So, we said, “Well, what happens if we go back to the original intent? What happens if we take that authentication as a session generation, and then there’s all kinds of great context that comes from your authentication provider. And then authorisation and application identity — that’s a whole separate construct.” Then, when I want to move into finer-grained authorisation or I want to move into fine-grained consent management or I want to layer on top open banking-based regulatory demands, now I can do that very simply. I can spin up open banking APIs in minutes instead of saying, “Oh, I’ve got to build this giant sandbox. I’ve got to upgrade my OAuth server to FAPI 1.0 compliance. I’ve got to do all of these different things,” which could be man-months or man-years.

You know, I’m curious, because I highlighted my poor experience with not having open banking in my life. In your mind, what does good look like from an open banking implementation? Is there a gold standard or an example that you can provide to say, “If you’re doing it right, here’s what it should look like”? What’s the process as a normal customer trying to collect my finances?

I’m going to do one better than that, and I’m going to talk about the gold standard that we’ve seen already in the U.K. There’s a company called Sterling Bank. Obviously, we’re not familiar from North America so much. But what the millennials and Gen Z have said is, “I want all of my financial services,” and this is not just banking and moving money around, but also home insurance, car insurance, life insurance, all of these different financial services, available in a singular portal. 

And by using open banking, now, Sterling Bank has created that portal for Gen Z, and they’ve seen tremendous account adoption because of it. What they’ve seen is a tremendous boom to account adoption by third parties and by additional new customers because now they have this comprehensive ecosystem. They never have to leave that Sterling Bank’s portal. They’re able to see, “OK, I’m going to sign up for these different insurance, different retirement funds, different investment means,” as well as do their regular banking all from a singular interface, and it’s completely changed the way that people interact with them. That’s what the account aggregators, the Mints, etc., have striven to do in North America, but without having this common symbiotic methodology of exchanging data, protecting privacy — of all of these different fundamental features of open banking — they’re not able to get there in a secure manner.

It sounds to me like the millennials and Gen Z are driving the demand for open banking. Would you say that’s accurate? I’m kind of wondering about the value proposition for the banks. Is this something that they want to be able to enable these financial aggregators in a secure way, or is it a compliance driver?

So, it started as a compliance driver. Well, that was a two-part question. Let me start from the beginning. First of all, Gen Z and millennials are the first digital natives — Gen Z even more so than millennials, meaning they grew up always on internets everywhere, services should be everywhere. So, they’re looking for distributed services and the best user experience possible. That means pushing the service all the way down to the edge of the millennials or to the edge of the Gen Z. So, my phone has got to be able to do everything in that circumstance. We should look at banks. Banks are responsible for where we are today. What I mean by that is not just technological innovation but also innovation across infrastructure, etc. Banks have really stepped up to the plate — in the last 5,000 years is a fair way to say it due to the exchange of money and helping us build the world as we know it today. 

So, when they first started adopting open banking, it was absolutely across the barrier. It’s another regulatory burden that we have to pass through. But we’ve started to see that transition where it’s no longer seen as that, because not only are they getting better engagement from their customer communities but now they’re also getting much better visibility into how their services are being used, what APIs are being called, who are their biggest users, how are they transferring money, what other partnerships and what other services should they package and integrate that are allowing them to better monetize their customers. All of that very rich data that now they’re allowed to have because they have the appropriate consent is also the data that’s feeding back into a circular loop of better services, which they’re able, again, to offer out and to monetise and to build better customer adherence.

Have you seen any differences in how the pandemic has affected uptake of some of these services around getting open banking off the ground and becoming more digital-first, less touch? I look around in my hometown, and I see bank branches shutting down. They don’t have the physical presence anymore. I can’t remember the last time I went into a bank. I’ve been digital banking for at least — it feels like 10 years, and that’s probably the trend for the future. I see a lot of those spaces being repurposed for other things. One has been turned into an electric car charging spot because they have the parking and, again, no one else is using it. 

I’m curious if from your perspective, having worked on this much more closely, the pandemic has driven this any more than it probably would have gone already with the natural flow and evolution of services, or if, yes, there was something here where COVID’s here and we’ve got to speed this up faster than we were planning on doing.

You’re bang on. I feel like that was a softball, to be honest, because what has COVID done? It’s pushed work from home, it’s pushed distributed services out everywhere, and whether that’s upgrading your VPN into a ZTNA, per the podcast last week, or whether that’s offering your services out in a very distributed fashion and in a very integrated fashion to your consumers or to your partners to resell, both of those are driving at lightning speed. You’re right — we don’t go into any branches anymore. Even Starbucks, I have to order online. And then I can go pick it up from a branch, but the reduction in touch interaction is a fair way of saying it. Due to COVID, it has really pushed net-new digital services and net-new ways to engage with your customer base out into the marketplace.

 I’m thinking about these open banking APIs, and I’m wondering, are banks deploying the APIs as bolt-on to their applications and their systems, or are they deploying the APIs and then building their services on top of it? I’m getting at that from the standpoint of the security being layered at the API level. It seems to me that if you’re building apps on top of it, you still want to put that security at the API level. So, broad question: Are the banks themselves using those APIs they’re deploying, and then why is securing at the API level necessary?

Lots of questions there, so let’s just parse it out one by one by one. When we look at open banking, I break it into three major fundamental steps: The first is building an API-driven infrastructure, and this is where you’ll create a net-new API through Apigee or Axway or one of the API gateway vendors to your back-end services. That’s step one, and that is just to participate in an API-driven ecosystem, which obviously open banking is one of. 

Step two is bringing in that security layer. Open banking has designated FAPI, which is Financial API. It’s a standard put out by the OIDF, the OpenID Foundation, that mandates a number of things — big things like pairwise identifiers. Shared secrets, essentially, is an easy way to think about that. Mutual TLS between client and server, secure software assertions, so you have a signed certificate that says, “I can be a client of this service,” or the fundamental pieces. They have mandated — a gold standard for API security is the easiest way to think about that, and that should be carrying across all industries, because we wouldn’t have the Experian problem, just to relate it back, today if that was in place yesterday. 

Now, the third step is that consent factor, and this is where things start to get really interesting, because consent has changed rather dramatically in the last five years. So, starting off with the GDPR, we’ve got all of these blanket consents: We got the pop-up ad or the pop-up banner saying, “Hey, I’m consenting to my cookie. Take all of my data, or store your cookie here and capture my IP and everything else,” which we all hate, but it seems to be a necessary part of using the internet at this juncture. That’s been around for a little while, and that was the start of “How do I mitigate some of the GDPR needs?” That’s a very blanket-based consent. The second is the OAuth-based consents that I think most of us are familiar with. This is where I go into Facebook, and Facebook says, “Hey, I want to see your first name, last name, phone number, and I’m going to do whatever I want with it. I’m going to store it, and it’s gone from you now.” That’s the second one, and that’s definitely not fine-grained enough, because there’s no real consent. There’s just, “Hey, take my data and do whatever with it.” 

Now, the third one, which open banking has introduced, is really consent that actually happens before the OAuth consent — that is, “I’m going to consent, and it’ll be a very fine-grained consent around this account with this transaction ID, and I’m going to consent to sending it to this third party.” This is where those third-party providers and the aggregators really come to bear. 

What we’re seeing is very disconnected approaches to consent — again, based upon that sprawl we were talking about earlier. You might have the blanket consent, you might have some OAuth consent, but unless you’re an open banking ecosystem, you’re not bringing to fruition the open banking consent. So, we brought all of those together. You have a common model for consent that spans those three different types. Actually, a fourth type as well, but we’ll dive down the rabbit hole if we go that way. 

So, I have a common model for understanding what I have consented to an organisation as well as what I’ve consented to an organisation to share about me, and I can go and revoke, manage it. I can use it one time, you can use it seven times, you can use it for 30 days, you can use it for 24 hours. So, I’ve got very fine-grained controls around how I’m willing to share my data out to an organisation and how that organisation has to treat the data going out to third parties. 

The rest of your question was, where should API security lie. The very interesting thing about APIs is, something like 80% of the internet traffic is now API-driven. And you have to think about APIs as machine-to-machine or service-to-service, because that is the fundamental underlying flow. Whether it’s me going through an Apple or my iPad, it’s making an API call back up to Wells Fargo or to my bank, and that is a machine-to-machine communication. 

We have to start rethinking identity. We’ve always thought about identity as a user identity. Super easy — I know how to authenticate users. We can do that very well, although we don’t do that very well, but that’s a different point of discussion. Now, when we start thinking about identity of machines, I’ve got two different aspects of that: I’ve got workload identity, and this is like the carbon. This is my function that’s spun up, or my Kubernetes pod that I just spun up. That Kubernetes pod registers, and if it’s in something like Istio or a service mesh, it will go and get its own SPIFFE (Secure Production Identity Framework for Everyone), which is an X.509 cert, essentially, that’s giving a very short-term — oftentimes, it’s 90 minutes to two hours — identity down to the workload. 

Now, we’ve also brokered that, so we can take a SPIFFE identifier and now assign a service identifier or OAuth client ID down to that workload identity, bring those together, and now we have a much better way of governing a user, accessing a service identity which is tied to a machine identity. I have independent client identities that are now tied to different workload identities so every instance of my service that spins up has its own unique identity instead of the old way, which was an IPA key that was shared across a hundred different services — or a thousand different services, even. Now I have individual X.509 certs. If I have a breach, I can know exactly which individual instance it was. As opposed to “Oh, my service got breached,” I can say, “This service instance got breached. I’m going to go and rectify and look at the audit logs for that as well.”

That sounds pretty spiffy to me. One thing I thought as you were describing that framework which included open banking, you peel out the open banking thing. I’m just free styling here: It sounds very much like a framework that can be used across industries, which I think is what you said. But I was also having the thought that, to put it in OAuth parlance, you’re talking a lot about allowing certain scopes. That put me into the mind-set, the thinking, of when it comes to that, that’s almost functionality — sure, security, especially from an authorization context, but that’s really at the core functionality of what is happening here.

Jim, you’re right. Putting it into that OAuth scope parlance, what we were talking about thus far was like OAuth client credential flows: “How am I going to get a service identity to a machine identity?” Now, when I start talking about “How am I going to authorise data?” and whether that’s privacy-related data, be it grants or even other data that might be PII, that might not be PII, those are the scopes that you’re talking about. What we’ve done — and not to toot our own horn too much — but we’ve built governance around those scopes. 

As a developer, I have governance that covers exactly what’s going to transpire so when I register a service, I can no longer ask for “Hey, I want that full jot. I want the full user record. I need all of these data” unless I actually need it, and that’s a very different way of treating it. I just used this metaphor on the Open Banking World Congress last week, but what we’re seeing is that PII for the last decade has been called “It’s the new oil,” whether it’s the Harvard Business Review or CIO Monthly. 

But what it’s really becoming is the new CO2, because we’re not able to control it, we’re not able to constraint it. It’s propagating wildly because they’re sending these giant jots or these giant access tokens from service to service to service — no idea where the data goes. It might get dumped to the syslog, it might get pumped out to another API that we’re unaware of, it might go into any recording platform or it might go to a rogue service. No clue once it’s out the door. By actually doing governance around the access token, what are we able to do? We’re able to say Service A can see the full user record, and Service B can only see first name and transaction ID.

 I think of all the things that can go wrong from a security perspective when it comes to APIs, and then you toss in Facebook having access to financial records. You mentioned Facebook, and I’m like, “Oh, there’s no way I’m ever going to allow like Facebook to be financially connected to the rest of my stuff.” But that’s just an editorial comment. From a security perspective, what is the worst thing that could happen if the open banking APIs — or just APIs in general — aren’t properly secured? 

Obviously there’s theft. Someone could intercept and steal money. I think of Initech, if you’re a fan of Office Space, where you’re developing an API that takes fractions of a penny from a bunch of different accounts and you hope you’re never caught. What are some of the other things that maybe aren’t as noticeable from a security perspective that people should be concerned about, and drive toward making sure that APIs are properly governed, are properly secured and being utilized the way that they’ve been designed to?

That’s a good question, and it’s relatively scary when we start to talk about it. If I look at what’s driving my Tesla, it’s APIs. It’s calls from a service on my steering wheel and my accelerator down to the central control panel and then talking out to the internet somewhere. So what’s the worst-case scenario? Well, somebody takes that over, and we’ve seen it hacked many a time already. Not Tesla, necessarily, but Dodge and a few other ones have had their auto-drive features and APIs hacked. We saw that with Mercedes the end of last year. It wasn’t a hack of the driving system, but it was a hack of the data coming through the Bluetooth platform. So, it’s not just personal data but your actual livelihood that can be impacted, and whether it’s a heart monitor, an IoT device, or whether it’s the car that you’re driving, not doing API security right is going to fundamentally put you at risk and put your organisation at risk for not just financial liabilities but also, potentially, the livelihood of people.

I think about that too. It’s a connected world, and if a human designed it, that means that there are flaws in it and there will be ways to break systems as they’ve been designed. 

With that, that’s probably a good spot where we can go ahead and leave it. Nathan, thank you so much for joining us, and hopefully, people were able to get an idea of at least, if they aren’t familiar with open banking, how they might already be using it and not even just be aware of it, but how technologies and standards are developing to make life easier to be able to manage finances, and underneath it all, there’s identity. It’s part of this process, etc. 

I will have a link to Nathan in the show notes if you want to connect with him on LinkedIn. Obviously, you can connect with Jim and me in there as well. We’re always happy to engage and talk with our listeners and get ideas for shows and so forth. Also, I have a link to Cloudentity’s website, so you can learn more about what Nathan and his company have been doing in this space so you can get familiar with their offering. For us, you can always find us on the web at Identityatthecenter.com. You can find us on Twitter @IDACPodcast. And with that, we’re going to go ahead and close it out for this week. We appreciate everyone — thanks for listening, and we’ll talk with you all in the next one. 

Thanks for listening to the Identity at the Center podcast. If you like what you heard, don’t forget to subscribe, and visit us on the web at Identityatthecenter.com.