eKYC with Mark Haine

Vittorio Bertocci: Buongiorno everybody, and welcome, this is Identity, Unlocked and I'm your host Vittorio Bertocci. Identity, Unlocked is the podcast that discusses identity specifications and trends from a developer perspective. Identity, Unlocked is powered by Auth0. This season is sponsored by the OpenID Foundation. In this episode, we focus on the work of the eKYC & Identity Assurance working group in the OpenID Foundation. Today, we are chatting with Mark Haine, Director at Considrd.consulting and one of the chairs or the eKYC & Identity Assurance working group, welcome Mark.

Mark Haine: Thank you, Vittorio, it's great to be here and to have this opportunity to represent the working group.

Vittorio Bertocci: Thanks for joining me today. As it's tradition, let's start with how you ended up working in identity.

Mark Haine: Okay, I'll try and keep this as brief as possible. It's been quite a journey as you can imagine. One constant, I would say has been that I've worked in financial services more or less throughout my career with a couple of diversions along the way. I started with a big bank more years ago than I can possibly believe now. I was focused on desktop support and networks and progressed there into network security, intrusion detection, scaling web applications for a stockbroking app, which saw me have the experience of some of the challenges relating to the stock market boom of 2002. Application troubleshooting and deep packet analysis, activities going on around the issues with apps and interesting attacks coming in from the internet in the early 2000s. I also got involved deeply in various access control for staff applications using Kerberos, SAML, TASS-X plus and verticals like that, all sorts of ancient technologies that developers today I think have long forgotten. I then moved into a team with another of the banks in the UK, focusing on innovation. That was an unusual little team, but we were given the opportunity to, with myself and one colleague, focus on innovation and security. In that particular organization, we identified that customer identity was sorely lacking attention and really had room for lots of improvement in a way that would result in real business benefit for that bank. That was our focus and really then my entry point into the customer identity challenges. Off the back of that engagement, the opportunity to learn about the very early days of open banking in the UK eventually resulted in me becoming one of the senior security architects at Open Banking UK, where I was first exposed to the OpenID Foundation properly, got involved in the development of the Financial- grade API, as it is now known and ultimately after a little while also engaged in some of the challenges of sharing data via APIs with third parties in an open banking and PSD2 related regulatory environment. More recently, I've been continuing doing architecture engagements for a number of organizations. One is a big European bank with challenges of a similar nature, to identify their customers, improve their user journeys, I've done a lot of work on mobile apps where the mobile app interacts with the server side using OpenID Connect. Most recently, at the start of 2020, I was very pleased to be invited to co- chair the eKYC & Identity Assurance working group, so there you go.

Vittorio Bertocci: Fantastic, and that brings us to today, that was quite a ride.

Mark Haine: Yes, indeed.

Vittorio Bertocci: Thanks, Mark, for describing your trajectory all the way here. That's a perfect segue for getting into our main topic today. I would start by first expanding the acronym and perhaps exploring a bit what's the charter of this working group.

Mark Haine: Sure, so the name of the working group actually was a topic of hot debate when I first joined the working group. There was much debate about whether we should be focusing on Know Your Customer, so Electronic KYC or identity assurance. We came down on the combined eKYC & Identity Assurance because it's largely the same process in different industries. In the financial industry there is a focus on Know Your Customer and that's driven by things like fraud, anti-money laundering and sanctions legislation and in other sectors it's more commonly known as identity assurance, it's effectively the more generic name.

Vittorio Bertocci: In practice, what is identity assurance? What it is for and why does it need a working group working on it?

Mark Haine: Well, certainly historically has been the process of establishing the identity of somebody you're interacting with in a very reliable fashion, and often, historically that was done, in the context of a bank, by somebody turning up in a physical branch with their passport or their driving license or whatever identity documents and going through a process with a member of staff to effectively identify themselves and then allow them to access the services that were provided. But today, in the times of COVID and the accelerated digital transformation that's occurring, partly because of that, we need to find ways to do that online, essentially.

Vittorio Bertocci: I see, so what the working group is aiming at is to project online, the equivalent of the in person and proofing and similar, so that people can consume that kind of high confidence authentication of entities, but ultimately in the context of online. That's a very, very important thing to do.

Mark Haine: I think there's one thing I would add as well. What we're doing is we're providing the tools to enable it to be done online in a standardized fashion. There are plenty of services out there today where you can do these processes, but they're generally vendor led and proprietary at the moment. Ultimately, that results in additional time to implement and complexity and all of the challenges associated with a proprietary solution, actually vendor lock-in at times as well. Ultimately we want to make it quicker, easier, cheaper to be able to integrate these services.

Vittorio Bertocci: Right, and by doing a standard, you will also be able to finally inter-operate, so that you just need to know that the particular entity supports the standard, and then that gives you some guarantee that you'll be able to just work with them out of a box instead of having to discover that particular dialect.

Mark Haine: Precisely, so I think as far as the working group charter is concerned, really, we've got a list of things, we have a charter on the website, which obviously everybody can go and have a read of, but the potted summary of that is that our aim is to deliver a technology solution that communicates verified claims and information about how those claims were verified, so they explicit test attestation of the verification status. It's really metadata about claims.

Vittorio Bertocci: I see, on top of the claims, you actually get information about how you obtained that knowledge to begin with.

Mark Haine: Yeah, so actually I would say it's how those claims were established, when they were established, what sorts of rules were used in the establishment of those claims and what sorts of evidence was involved. It might say that the process was done in person using a driving license, or it was done online with a certain specific process and other sets of evidence documents like a passport or a selfie or whatever.

Vittorio Bertocci: Selfie based verification sounds something very much in line with Zeitgeist today.

Mark Haine: It's live for the number of providers right now, I can think of a UK bank that has you present your passport and then present a selfie and part of it is checking that you're a real life person, because it's all very well having a passport, you could have just picked up in the street though.

Vittorio Bertocci: Of course, and do they actually want to hold a newspaper of today?

Mark Haine: Yeah, we want to make sure that the passport matches the guy that's talking in selfie, right?

Vittorio Bertocci: Yeah, well, for the time being while deep fakes are still expensive, from the competition point of view, we can get away with it, but in the future, it's going to be an interesting ride. You mentioned a UK process, I guess that working on this must be really a lot of work for harmonizing different legislative frameworks, different capabilities. You must be working in with a lot of different countries and a lot of different verticals.

Mark Haine: Yeah, absolutely.

Vittorio Bertocci: Can you talk a bit about that?

Mark Haine: Yeah, so the working group itself is a very international affair. The co- chairs are from the US, UK myself, Germany and Japan, so that's a pretty good start and we have representation from quite a number of other places as well. A couple of other European countries, Australia springs to mind. I can't think of another one off the top of my head. I think also it's worth pointing out there's a couple of people from industries outside of finance as well. It's not just about the international differences, it's also about industry differences and the different verticals. We've got members of the working group from the mobile network operators, we've got members from healthcare and software vendors as well, so technology companies represented too.

Vittorio Bertocci: It makes a lot of sense. Why was this established in the context of the OpenID Foundation? Is it a natural home for it, or were other places considered when the effort was established?

Mark Haine: I think it's clear that OpenID has a couple of things which really make it a pretty natural home for solving the challenges that we face. One is that it's very widely adopted and well tested. I think it's also clear that it's naturally good, it's a very clear claims based method for delivering information from one party to another on behalf of an end user. That fits quite well with the use cases that we are trying to solve and so just referring back to the working group charter, we do have stuff in there about how we're wanting to represent verified claims. Claims is important because that's obviously a key component of OpenID Connect itself. I think I would also add that OpenID also has solved a lot of the basic plumbing that we need for communicating sensitive information from a provider to a relying party. Also, in recent years, OpenID has worked hard with various partners to take what was started 10 or so years ago and make it suitable for much more sensitive data. The work that Torsten was talking about in your last episode on the Financial- grade API is all about protecting sensitive data in the context of OpenID exchange. One of the things that we're really aware of in the context of eKYC & Identity Assurance is that we're often going to be exchanging sensitive data between the provider and the relying party. Although we're not going to mandate the financial-grade API as a kind of prerequisite for any eKY C& IdA solution, we strongly encourage it for cases where there is sensitive data being exchanged.

Vittorio Bertocci: Of course, it makes a lot of sense and it's great that you are highlighting a fact that for us, it's obvious, but it might not be obvious for everyone in this space, which is that all the specs that we talk about are designed to be composable. You take care of the format of the information being exchanged and what we discussed with Torsten is about how those things are exchanged on the wire, it guarantees that can be deployed in the mechanics of making those exchanges. I think it's great that they are described separately, because those two are two different functions, but as you said, they make complete sense together.

Mark Haine: They do, for a lot of use cases, but we did also want to give implementers the option to choose whether to implement FAPI or not, because there could be used cases where the eKYC & IdA spec makes sense for an implementer, but they don't have really sensitive information being exchanged. It would, I think be an excessive overhead for those implementers to have to implement because that's what the spec says.

Vittorio Bertocci: Yeah, and it's also from the point of view of actual implementation, like the two things are different. One is the plumbing and the other is the kind of information you've got to expect and how to validate it, which even in the implementation, those two can be different concerns.

Mark Haine: Yeah, of course.

Vittorio Bertocci: If it makes sense that they are not bundled, but they are composable.

Mark Haine: A lot of our eKYC specification is focused on the schema of the request and response messages into the bodies of the request and response, whereas a lot of the Financial-grade API stuff is about how those requests and responses are protected from various risks. You're quite right, it is really a separate concern.

Vittorio Bertocci: That makes sense, so you mentioned implementers, so what is the level of adoption that this initiative is enjoying at this point?

Mark Haine: Okay, so it's interesting you asked that because I've just been collecting together the results of a question that we put out to the working group, which is," What's the adoption level?" There are two technology providers that we're aware of in the market that already have the identity assurance spec implemented as part of their OpenID provider software, so that's great. There are also a few real life production systems making money for people in Germany. This spec originated from the donation of work that was done at yes.com and they have a number of production implementations themselves, where they use it to communicate attributes that are originating from some of the banks in Germany to some other parties who wish to consume those attributes.

Vittorio Bertocci: Very nice, so this thing is happening.

Mark Haine: Yeah, it's real, I think is the thing to point out at this stage. I think there's also a number of projects underway that are looking at our spec as a really interesting candidate. I know for sure that there's work in Japan, we have a relationship in place now with the Ministry of Economy, Trade and Industry in Japan and there's also a couple of projects going on in the UK, looking at the spec as a really strong candidate for handling identity assurance in relation to a number of different use cases.

Vittorio Bertocci: Fantastic, this is great work. If we double-click a bit, then we go a bit more on the deliverables. What specifications do you have as part of these and what do you define in practice are those specifications?

Mark Haine: Okay, so there are two specification documents that are being developed by the working group at the moment. The main one and the one that's very much more developed is called the OpenID Connect for Identity Assurance, and that one's coming up for... Well, we're planning implementer's draft three of that one. Really, its primary content is the definition of request and response schemas for verified claims. It's an adjacent schema essentially for a blob of JSON containing a load of claims about identity assurance. I can go into that a little bit more, so there's effectively two subsections under verified claims. One is about verification and the other is about the claims themselves. That's saying that these are the verified claims and this is how they were verified. Does that make some sense?

Vittorio Bertocci: I see, so basically you define a format that the client can use for requesting a very specific set of a claims and a very specific collection of mechanisms that are acceptable for obtaining and verifying those claims.

Mark Haine: Yes, we're using something that's already in OpenID Connect core, which is the claims parameter on the request, which allows a relying party to specify exactly which claims they want back. This isn't scope based where you would get back a predefined set of claims, this is a claims parameter, which allows you to define which claims you want and whether you want to receive them via the ID token or the user info endpoint, or a combination of both.

Vittorio Bertocci: It would be interesting to also consider placing stuff in the access token, but I am biased because I am personally leading the charge on defining how to use the JWT format for access tokens, which is something that everyone does on the planet, but there was no spec until now that tells you how to do it and so it's hard to inter-operate. In a lot of scenarios, the access token is used as a first party, as the interlink, because the access token is the only thing that your backend receives. Although traditionally people say," Let's not place identity information, in the access token" in reality, the only alternative is to send the ID token, which is something that we never want to do to APIs, but sorry, I didn't want to go on.

Mark Haine: We can debate that point, if you like, I would add OAuth versus OpenID as a discussion point to that and introspection, but we should take that offline, I think.

Vittorio Bertocci: Yeah, there is a lot of work in there.

Mark Haine: Yeah, I'm sure, you and I should work on that one, too. I think just back to the structure of the messages and the request and the response side of things, the claims parameter, we're really keen on that. Sorry, I should add, you can do you eKYC & IdA idea using scopes, but we're strongly discouraging it because at the end of the day, we want the relying party to only get what it needs. From a data protection perspective, that's really powerful, the relying party doesn't need to worry about justifying why it's got data that it didn't need. In Europe, certainly under GDPR, there needs to be a pretty clear justification why somebody is processing data about an individual. If they didn't need it in the first place, then that's a problem, right?

Vittorio Bertocci: Absolutely, also scopes in general, easily misunderstood typically, they are best kept for delegated authorization and here instead it's more of a declarative thing, and given that the claims claim, actually the claims parameter gives you a chance to specify directly the info you want, no reason to use anything else.

Mark Haine: There is a benefit from the provider side as well I think, which is that it allows them to offer a service which is flexible for relying parties, so they don't need to have predefined scopes or sets of claims that are returned. They don't actually need to know what the use cases are for the data. They can provide a set of arguably X attributes that are available from the service and the relying party can use it for whatever business purpose they need it for, contracts and payments permitting, right?

Vittorio Bertocci: It absolutely makes sense, and one thing that I really love of these, which is typical of any work that Torsten does, so I can clearly see his contribution in these.

Mark Haine: Yeah, his hand in this.

Vittorio Bertocci: Exactly, the TXN claim, the fact that there is a claim that can keep track of a transaction and actually give you an audit trail, do you want to do a talk a bit about it?

Mark Haine: Yeah, absolutely, so there's a TXN claim in there, which is one of the many optional claims that can be requested and really that's intended to give that trail back from the eventual consumer of the response back to the provider and potentially inside the provider links to the processes that were underpinning that identity and how it was established. I think it also points to another really important claim that we've got in the set, and that is the trust framework. One of the things about identity assurance is that it needs to be done in the context of legal terms, usually. You can't rely on information that's provided by a technical solution if there isn't an underlying legal framework to build on and so we've got a claim in there called trust framework and effectively that's a link back to the policies that underpin the identity attributes that are being provided. That will contain things like the definition of what is meant by in person proofing or how a passport or a driving license was actually validated in the context of this provider. That gives that link from the tools, which is the stuff that we're building here, the way of communicating that data back to the rules and processes that are run by the provider to establish that identity.

Vittorio Bertocci: Do you expect those to point to something defined by other bodies like for example, NIST and similar?

Mark Haine: Actually, maybe not directly. I think what will more likely happen is that the provider itself will have a set of policies defined, which in turn may point back to NIST or UK good practice guides or whatever the equivalent are, the legal documents that define the background to all of this. But I think there will be an implementation specific trust framework probably, but I think we're yet to see quite how that all emerges and I'm sure it'll be highly variable for different implementations.

Vittorio Bertocci: Do you foresee that the client will somehow out- of- band acquire the details of what the provider can do? How a particular entity does a verification and similar so that then they know what to ask, or are you guys thinking of publishing metadata to advertise those capabilities? What's the current thinking there?

Mark Haine: The current thinking is to have an out- of- band arrangement. I think underpinning most implementations, I fully expect there to be contracts for starters, this going to be a contract to service a lot of the time. Those contracts, I think will in turn point to all sorts of other legal documents. The closest analogy in the technical space that I can think of is actually that of PKI. We have the implementation of a PKI, which deals with all the technical workings of how certificates are created and exchanged, but underpinning every viable PKI is a policy document. I feel that it's going to be very, very similar in a lot of regards to that.

Vittorio Bertocci: All right, that's fantastic, this is a really important work, very impactful. If you were to issue a call to action to developers and to the community at large, what would that be?

Mark Haine: Interesting, there's probably a couple of things that I would ask. Ultimately, we're trying to provide a robust and practical and standardized way to share information about how identity data is exchanged, especially the assured identity data. Awareness is the first thing, share that we exist with your peers, share that we exist with architects, business people that you interact with. There's not going to be much use of this if people don't know about it. When you do get involved or hear of projects that are about exchanging assured identity data, then make sure that there is some awareness of the work of the OpenID Foundation in this space. As a prompt, there's actually a wide range of use cases here. We've talked about it in context of financial services, more than anything else and that's where some of the regulatory push is coming from, but actually there's a huge number I think, of use cases that fit into this, that don't immediately jump out of the title of the working group and the names of the claims that we're using. At a very high level, I'm going to chuck some at you. There's a new staff member coming on board, what's the first thing every company does? They verify their staff member's identity, so if we can streamline that process, you've already got assured identity somewhere, wouldn't it be nice to just present it in a mobile app context to your new employer? Buying alcohol, they need to know how old you are and at the moment, the processes in that space are weak I would say. Again, give the kids an app they can use to evidence that they are of age to drink alcohol, whether it's 18 or 21, whichever country you're in. Account recovery is another interesting journey which really could be streamlined by a privacy preserving way of assuring some sort of identity data. Another one that really springs to mind, I volunteer at my local swimming club as a coach and as part of that, they need verify that I can be trusted when dealing with vulnerable people and children. That's another great use case for assured identity. The last one I'd like to share is the case where a person may be representing a company, and we have a second spec document, that's an early draft at the moment that is going to be able to communicate, not only claims about who the person is, but who they are authorized to represent as well, whether that is a person or a company. Really, there's loads of use cases for this. I'm really keen that developers are aware of it and help their peers and the projects they work on understand that this is an easier way and a more standardized way to solve these problems.

Vittorio Bertocci: Fantastic, so let's hope that the people that do work on those scenarios will take a look at the work, we'll have a link to the implementer's spec and they will participate bringing what we know about different scenarios and adopting the mechanism because of course, network effect and everything. Fantastic, thanks Mark for your time today.

Mark Haine: No problem, it's been my pleasure.

Vittorio Bertocci: Thanks everyone for tuning in, until next time. The OpenID Foundation is a proud sponsor of the Identity, Unlocked podcast. Since its formation in 2007, the foundation has committed to promoting, protecting, and advancing the OpenID community and technologies. Please consider joining the foundation and contributing to current working groups. To learn more about the OIDF, please visit www.openid.net. Thanks everyone for listening, subscribe to our podcast on your favorite app or at identityunlocked.com. Until next time, I'm Vittorio Bertocci and this is Identity, Unlocked. Music for this podcast composed and performed by Marcelo Woloski. Identity, Unlocked is powered by Auth0, copyright 2020, Auth0 Incorporated, all rights reserved.