WebAuthn and FIDO2 with John Bradley
WebAuthn and FIDO2 with John Bradley
In this episode of Identity. Unlocked, principal architect at Auth0 and podcast host, Vittorio Bertocci, has a conversation with John Bradley. John is the Senior Standard Architect at Yubico and the author of many important specifications pertaining to identity management including FIDO2.
As usual, Vittorio begins the interview by asking John how he got into the field of identity. John overviews his career and when he met Vittorio before turning to his current work on web authorization and FIDO2 standards. John’s current company is Yubico, and in his role with the organization, John wrangles standards. In other words, he represents Yubico at standards organizations and plays referee between companies in order to make sure the entire community is benefited by the companies’ shared work. Moving forward, Vittorio asks John to clarify significant terms for listeners. In order to do so, John shares the story of how Yubico and Google worked on their own program, U2F (Universal Second Factor) authentication, as other companies independently started FIDO. Yubico and Google decided to join FIDO in order to not be seen as competing, and the merged organization joined and developed technology to produce FIDO2. John further clarifies that FIDO2 is a marketing term rather than an actual standard, and the standards at play are WebAuthn and CTAP (Client to Authentication Protocol).
Vittorio and John also discuss details about how this technology works, with Vittorio boiling the ideas down to a description of a browser using CTAP to communicate with an authenticator, who then uses WebAuthn to communicate with a website. On the back end, the FIDO infrastructure is one of various options for server validation. At this point, John clarifies, he and his team see WebAuthn used more as a second factor for authentication than as the first factor; however, with Apple’s work on multi-factor authentication, John imagines that the pattern of WebAuthn use may change. John expects that people will probably use local face or touch identification for the web credential for individual devices. Once this technology becomes ubiquitous, passwords will become increasingly obsolete. Of course, there are still problems that this vision of the future raises, and John and Vittorio talk through some of these problems, the need for the industry to create new practices, and ways in which authentication will likely become more integrated into our lives (as we’ve seen it start to do in the form of such things as wearable authenticators). As the conversation moves toward a conclusion, Vittorio asks John to share about what his team is working on now and plans to work on in the days ahead, including level 2 of WebAuthn, CTAP 2.1, and much more!
Make sure to subscribe and join us for the next episode where Dick Hardt discusses GNAP.
Music composed and performed by Marcelo Woloski.
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 specs and trends from a developer perspective. Identity Unlocked is powered by Auth0. In this episode, we focus on WebAuthn, FIDO2 and various other mechanisms we use for authenticating users without asking for their passwords. Our esteemed guest today is John Bradley, senior standard architect at Yubico, an author of a very large number of very important specifications at IETF, W3C, and OpenID Foundation. Welcome John, and thanks for joining me today.
John Bradley: Hi Vittorio, thanks for having me. I guess I'm the author of a lot of frustration for developers. So hopefully we can unwind a bit of that in today's podcast.
Vittorio Bertocci: I'm sure that the developers are forever grateful for the contribution you brought in their day to day over reading those long and super useful specifications. Can we start with how you ended up working in Identity? I'm sure is going to be an interesting story.
John Bradley: Well, it started quite a while ago when I was working for a telephone company, I started a competitive local exchange carrier. We were delivering- one of the first people to deliver internet over raw fiber, we're trying to sell identity services basically as a way of tracking billing, back in the day. I also was associated with Xcert Software, which was one of the first PKI providers. We had a company called GT Trust where we ran a CA for judges and other people in Canada. So I actually hearkened back to the PKix days and the PKI forum was my first introduction and sort of migrated through the various standards from that to OpenID to Infocard, SAML, live through the obscure ID- WSF, WS- Trust Wars, which was when we first met around Infocard and WS- Trust, and then worked for the US government, writing some of their standards for Identity Systems and OpenID Connect, OAuth and now I'm working on WebAuthn and the FIDO2 standards which Apple has now rebranded "Face ID for the Web" so, now that Apple has made us cool. We're done.
Vittorio Bertocci: All right. You finally arrived, now that Apple is on board.
John Bradley: Yes.
Vittorio Bertocci: Very nice. So, now you are at Yubico, right? What do you do at Yubico?
John Bradley: I wrangle standards, which is representing Yubico in the standards organization and to some extent playing referee between the other large companies in the standards organizations, making sure that Google and Microsoft play nicely together to the benefit of the overall community.
Vittorio Bertocci: Very nice. Once again, on behalf of the community, thank you. You are doing a fantastic work there. Great, and you already mentioned one of the questions that I typically ask, which is how we met. So we met back in the day for the Infocard at the time, so like 2006, 2007?
John Bradley: Maybe before that. Before either of us had gray hair not saying anything but yeah, well it's a while ago.
Vittorio Bertocci: Indeed, wow. It is a while ago. All right, perfect. So, thank you. Great introduction. Now let's jump into the meat of the episode. We want to talk about WebAuthn, FIDO, and all these things are in which you are playing a key role for. My suggestion is, can we start by clarifying what the various terms people hear about this really mean? For example, could you walk me through the sequence of events that started from FIDO? What was FIDO? What is FIDO2, all the various parts? Tell me a story.
John Bradley: I can tell you a story. The first thing to know is that FIDO is the worst at is marketing, so there's a whole bunch of terms which even the people that were involved don't necessarily understand the relationship. So initially there was work between Yubico and Google, to create an internal authentication system for use by Google employees, which became known as U2F, Universal Second Factor Authentication. Independently, PayPal and Nok Nok Labs started the FIDO Organization, Fast Identity Online, no relationship to President Lincoln's dog. So Fast Identity Online had the mantra of trying to eliminate passwords. They were mostly focused on doing biometric authentication on mobile devices, cell phones. So both things were probably a bit ahead of their time, but all things that are successful are probably, start off being ahead of their time.
Vittorio Bertocci: Very true.
John Bradley: In order to not be seen as competing with each other, Yubico and Google decided to join FIDO and contributed the U2F standard to that organization. So the merger of the Universal Second Factor technology which people may be familiar with, where you type in your username password, and then use a security key as the second factor, which you see for Google Advanced Protection, GitHub, and other places. So that U2F technology along with enhancements from UAF, the original FIDO standard became what's now generally referred to as FIDO2, although to confuse things, there is nothing that is FIDO2, It's sort of like the spoon in the Matrix. FIDO2 is a marketing term. There is no standard called FIDO2, so don't look for a FIDO2 standard, you're never going to find it.
Vittorio Bertocci: Okay, great.
John Bradley: I said the thing they're worst at is marketing. So the actual standards that fell out of this is one called WebAuthn, which lives at the W3C because in order to make something like this successful, as we learned back in the Infocard days, you really have to have browser buy-in. So, the platforms don't want to do it, you're facing an insurmountable battle. So, the way to co-opt the platform vendors, Microsoft who hadn't implemented U2F, Apple, to get them on board, we've moved the part of the protocol that goes between the relying party and the web browser into the W3C, which was a more natural fit. The part of the protocol that goes between the web browser or platform, and the actual authenticator is called CTAP, Client to Authenticator Protocol, and there's a CTAP1, which was U2F, and CTAP2 which is the newer version of that, that supports the passwordless log in experience.
Vittorio Bertocci: So the CTAP is the thing that connects the ... like tells, what is a standard way of connecting the browser to, for example, your hardware key?
John Bradley: Yes.
Vittorio Bertocci: So that now you can have a hardware keys from different vendors. As long as we follow the standard, the browser knows how to take advantage of that hardware, right?
John Bradley: Right. And WebAuthn provides a standard way for RPs to interact across all the different browsers, Safari, Firefox, Edge, New Edge, and Chrome.
Vittorio Bertocci: And so just to un-spool that part as well, here the practical angle is a relying party is a website.
John Bradley: Yeah.
Vittorio Bertocci: And WebAuthn is the thing that does tells to the browser how to talk to the website for doing authentication.
John Bradley: Right.
Vittorio Bertocci: It's not a chain in which the browser knows how to talk with the authenticator using CTAP?
John Bradley: Yes, CTAP.
Vittorio Bertocci: And then once that is done, the outcome uses WebAuthn to talk to the website? And now the website knows what to do to authenticate your user. Is that in layman terms what happens?
Vittorio Bertocci: And the outcome of what's called is sent directly to the website? How does that exchange work?
Vittorio Bertocci: I see. And on the backend, you need to use something to digest this object and decide whether you like it or not.
John Bradley: That's another place where there's a bit of FIDO infrastructure, so FIDO has a certification program for validation servers which take the tokens and validate that. Yes, this is a particular account or was it correct for a given login? So there's backend infrastructure that you can build yourself or buy or a good number of open source projects that people can integrate that would help them validate tokens. And of course, there's lots of people like Azure who were more than happy to outsource the whole business for you.
Vittorio Bertocci: I see. So, here if we were to connect to the classic topology, you might have your website or relying party which uses something higher level, like OpenID Connect or SAML to talk to some authority. And then you could do, the WebAuthn with this authority so that your website doesn't really know what's happening and the implementation is really coming from the provider.
John Bradley: Right, and all the usual suspects, Azure Active Directory, Google, ForgeRock, Ping, and Okta all have a smorgasbord of different services where they'll do some amount of Federation, some amount of multifactor authentication and now pretty much all of them are offering WebAuthn, FIDO as one of their multifactor offerings.
Vittorio Bertocci: So, multifactor, great point. Do you see WebAuthn used more as a first factor, as in you just use that instead of a username and password, or do you see that as something that compliments username and password as a second factor, instead of classic OTP and similar?
John Bradley: We have the broadest coverage in browsers for the second-factor use case at the moment, but now with the next release of OSX and iOS 14, with Apple adding multifactor authentication platform authenticators into the Operating System, so every iPhone will have an authenticator built into it. Every Android phone will have a multifactor authentication built into it. It may be the pattern that develops is, if you're bootstrapping a new device, you might use an external authenticator and a username password external authenticator, but the RP will likely discover "Ah, yes, you have a platform authenticator in the browser that you're logging in from, wouldn't you like to configure it so that you can use Touch ID to log in next time?" So, people will wind up in most cases configuring a local, as Apple calls it, Face ID or Touch ID for the web credential on individual devices. So either OSX, Windows, Android, iOS, Chrome OS, they all will have built-in authenticators and then people will use roaming authenticators like the YubiKeys or Google tightened keys or what have you, as a way of moving identity strongly between platforms. But other than for high-security things where you might not trust the Operating System on the phone, people will likely use the built-in authenticators with your Touch ID or Face ID as a convenience thing for logging into most sites. So, the goal is eventually, as people will log into websites in the way that they're similar, they're familiar with logging into applications on their phones, when they have biometric authentication. In fact, the applications on their phones may become progressive web apps, and I'll take advantage of the same infrastructure. So, it's true sign of success is that nobody will know what we're talking about in the public. When you say, "Oh, yes, I have developed the WebAuthn," and they'll go," Oh, what the heck is that? I just use my fingerprint to log in. How hard could that have been?"
Vittorio Bertocci: Yeah, that's a nice big dream.
John Bradley: How could it have ever been any other way?
Vittorio Bertocci: That would be absolutely fantastic. And you said something interesting about applications becoming PWAs, given the recent developments in which apparently WebKit is not going to implement a large number of advanced APIs in order to avoid fingerprinting. It doesn't look super likely at least on the Apple Operating System, but that's a discussion for another day. So, basically the idea is once this thing is ubiquitous, once every device have an independent authenticator, then websites will just be able to use that as a first and potentially only factor. And so we'll break free of the various issues we have with passwords and similar. Now that sounds fantastic, but I do have a follow up question which is, say that you don't have a roaming authenticator, like a YubiKey, say that you're relying on the one that you have on the device and say that you forget the device on the back of your Uber or any equivalent flow. With a password, you have your recovery mechanisms and similar. So somehow you can get out of that situation. What do you do when you're using an authenticator?
John Bradley: Well, the best thing to do is have multiple phishing resistant authentication methods registered so that you do have a recovery. Recovering your strong credentials based on an email address recovery, probably isn't going to keep attackers out as much as you would want it, because they're just going to go after your email account to be able to do privilege escalation. So you should have multiple authenticators registered and the relying party sites, the websites are going to have to think through what their credential recovery actually needs to be. Whether they also allow you to register a federated account as a backup way in. Now, there's a number of different options. It's going to be hard to completely get rid of passwords, but maybe the password can just become your backup recovery code that you put away in your safety deposit box. My solution is, I have one YubiKey around my neck, one in my wallet and other stashed in safety deposit boxes in various countries. So you can see where I've gone with that.
Vittorio Bertocci: Of course, you have enough digital literacy to know how to handle your accounts. It's not because you work for YubiKey, but because you are an advanced user. So, you have strategies for dealing with these kind of situations, but I'm thinking of a senior citizen that is a customer of a Credit Union in rural Iowa, you cannot expect this person to go around with a keyring of authenticators. So here we'll need to, as an industry, find a way of creating your practices as in, maybe you register both your phone and your iPad at home, so that if something happens to one you have the other, because the thing that you mentioned about saving the keys. I was just watching one presentation at Identiverse. Someone from Authy was saying that the vast majority of people, when they sign you up before some service that gives you a list of backup keys, they just don't save them. Either, they email it to themselves, and then security-wise, it's not particularly secure, or they just don't save them. So, I guess that as an industry, we'll need to find ways of making sure that people can take advantage of this new capabilities without creating backdoors.
John Bradley: Right. Certainly account recovery is going to be one of the big things that we need to address again. Account recovery, just through an email or a single SMS are bad and counterproductive things. Once all the devices have built-in authenticators, as people use more devices with given services, those services should offer to register both for convenience and for backup, people are more likely to do things for convenience than for account recovery. So, having credentials on those devices is going to take care of a large part of it. But again, you probably not going to have a backup cell phone and put that in a safety deposit box, and that's where some of these roaming authenticators, which aren't horribly expensive compared to a cell phone may well be things that people either purchase or are given as part of services.
Vittorio Bertocci: Do you in the Standards Group ever consider scenarios, a bit a la Black Mirror as in implants and similar?
John Bradley: Not that we'd discuss out loud. I suppose that's possible. I mean, certainly roaming authenti..., FIDO authenticators have been built into rings and earrings and occasionally braided them into my beard. So yeah. It depends on your notion of wearable. Certainly, the authenticators will become more integrated into our lives, whether it's a ring that does both FIDO authentication and your credit card payments built into. It wouldn't surprise me at all now that Apple's also drank the Kool-Aid to see an authenticator in your Apple Watch, that can work independently. If you have a device that already does NFC, it's not hard to add FIDO functionality to that. We've certainly talked to the US military about FIDO dog tags to basically up-level the amount of security. I mean, people don't love their CAC cards as much as some people imagine. And, they're not necessarily useful for a lot of things on the web so, if we have secure standards that are capable of meeting the use cases, I can see FIDO authenticators being built into a lot of different devices. I mean, even now there's a company in Canada that makes an EKG Monitor that has a FIDO authenticator built into it.
Vittorio Bertocci: Nice.
John Bradley: If your heart stops or you take it off, then you can't authenticate anymore.
Vittorio Bertocci: Okay. That's probably the last of your problems in that case, but it's good to have. Yes, that's great. Fantastic. So let's come back to earth after this dip into Science Fiction, which might not be science fiction for long.
John Bradley: Its not Science Fiction, you can buy all of it now, I mean its a bit absurd but you can certainly get it.
Vittorio Bertocci: Very nice. I'm actually going to look it up, as soon as we are done here.
John Bradley: Yeah, I don't know about surgical implant but that's going a bit far, even for me.
Vittorio Bertocci: Well, I remember years ago that there was this party in Ibiza, in which people got an RFID embedded in their triceps so that they could buy drinks without actually pulling out any credit card. I guess that with COVID ongoing, that use case will probably not to be mainstream still for a while, but hey, if they did it in Ibiza, who knows, maybe we'll start seeing it here as well.
John Bradley: I've heard of that in bars, not bars that I go to, but bars around the world. It's not just an Ibiza thing, contactless payments. I understand that some members of society don't actually have large amounts of wallets. I know that isn't us, we always have a surplus of wallets, but if you happen to be going out in skinny pants and whatever, then that is one reason why people have gone to a chipping themselves. COVID has driven up the prevalence of contactless payments.
Vittorio Bertocci: Indeed, that's another good forcing function. All right, perfect. So thinking about the current set, all the standards that we described are all fully released. They're already fully considered RFCs or standards, and we have implementations. What else is the working group working on? What's the next thing that is not released yet, but you guys are still working on?
John Bradley: Well, we have a lot actually. So WebAuthn, W3C standards are called Levels. Why? I do not know, but we're close to finalizing level two of WebAuthn and CTAP version 2.1. And in FIDO, adding all sorts of interesting new features. We've been working with the web payments people to try and better integrate Web Authentication with some of the payments use cases for people who administer servers, we're adding the ability to have SSH Certificates attached to your FIDO credential so that you can use a FIDO Authenticator to log on and administer servers in a phishing resistant manner. When you provision the credential, you can install a certificate with the credential so that all of your roles can be automatically delivered in the same way that the SSH administrators are used to now so, good new SSH functionality on the tech side, some additional privacy features a bunch of enterprise, new enterprise features so that enterprises who are deploying these functionalities for their employees can do asset tracking on the authenticators with an enterprise attestation. Some new KDF functionality for key derivation, so when you log into your password manager with your WebAuthn device, the password manager can use that credential for key derivation to be able to decrypt its local password store, so that if your computer is compromised, nobody can get back into it without that credential. That will also allow websites, so SaaS services would be able to use the encryption key derivation part of WebAuthn to encrypt data at rest so that when you're not logged in, they can throw away the decryption keys and only be able to decrypt your data when you've actually logged in. So there's a good number of new features as well as sort of cleaning up the cruft in the specs, based on feedback from people who have implemented it so far.
Vittorio Bertocci: That sounds fantastic. Really, really interesting developments. And I'm looking forward to seeing more of that. Wonderful. I want to thank you for your time. This was awesome, really interesting. I learned a lot.
John Bradley: It's already over? We just started, Vittorio. We can go for hours.
Vittorio Bertocci: We just started but, we can, but then I guess we had people with... We can actually have you again on the show, mostly because you have your hands in so many different pies, for example, the new developments in the OpenID Connect side, that stuff that it's really lovely to cover, but that would be for another episode. For the time being, I thank you again and I hope to have you back.
John Bradley: I hope to come back as a different expert, perhaps more expert next time.
Vittorio Bertocci: Thank you, and thanks everyone for tuning in, until next time. 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.