 Hello, everybody. My name is Dominic Patry. I'm a software engineer on the Chrome Web Identity team. You probably all want to provide a great experience on your website. And especially when it comes to personalization, sign up and sign in flows are a key to success. So today, EG, Kim, and I will talk about improving the user experience while at the same time improving security for your users. So let's get started. During this session, we want to talk on three important areas. Sign in, sign up, and security, where in the letter, we will focus on two-factor authentication. So let's get started with sign in. So this is my inner state of mind. Not right now, but when I'm thinking about the sign-in experiences on the web, too often I'm really disappointed. You know, these situations where you got a new phone or a new computer and what was that password again? Do I have to sign in again everywhere? And this is not just limited to new devices. When I create an account on my desktop computer, I want to be signed in automatically on my phone as well. Or do you know these situations where it feels like every time you go to that newspaper website, it asks you to sign in again? Even though you're using a password manager, why do I have to press that button? Can we make that experience a bit better? So for sign-in flows, there are three goals that we want to share with you today. First, form-based sign-in should work really, really well for password managers. Some websites have implementations of sign-in and sign-up flows which do not allow the password manager to remember and fill forms very well. And for you as a site owner, that's a missed opportunity. You can increase user engagement and conversions because you can get more sign-in users. And users enjoy the convenience. It's just one thing less to care about. No dealing with forgotten passwords, one reason less to abandon an account, and no more difficult typing on a tiny keyword. You know, these at least eight characters, some lowercase, some uppercase, some number, and at least one special character that is impossible to find on a small keyword. So we'll discuss what you can do to help password managers doing a great job. But you know what would be even better than the password manager filling your username and password into the form if the sign-in would happen without any action from my site? So our goal, number two, is a returning user should be able to sign in automatically. No typing, no buttons. And we'll talk about how the Credential Manager API can help you with this goal. So you know what? Let's get rid of sign-in forms, at least in most situations. This is a huge opportunity. Less visual clutter, less typing, nothing to remember. And it works on leaf pages, you know, when somebody searches online and they land somewhere on your website, not at your home page where you have the sign-in flow, but somewhere on your site. Let the browser take care of signing you in. And that should work not only with passwords, but also with federated logins. So number three, federated login is a fantastic technology. It allows making logging in more secure, so much more secure. And you know, this is where Google, Facebook, Twitter, or many others vouch for your identity. The user needs a single account, and that account can be properly secured with second factor authentication, and all the bells and whistles that A, only big providers implement, and B, only few users care to configure for every website they have an account with. So I want my password manager to handle federated logins just like it handles passwords. And the Credential Management API allows you to store meta information about federated credentials just like it allows you to save passwords. The information is synced across devices and persisted beyond the lifecycle of cookies. So let's talk about sign-up. Even though typical users, and maybe I should say also Google I.O. attendance, should be aware of the best practices for passwords. They use short and simple passwords. They reuse passwords across different websites, and they do not enable second factor authentication on every website where it's possible. The password 12345 has been the most frequently used password for the past three years. At least that's what I checked. We were secretly hoping that at least 1234567 would make it this year, but no. And actually the password, that's also among the top 10. So this is so sad. According to Lawless Research, 71% of accounts on the internet are guarded by passwords that are used across multiple sites. And you know what? Sad. And second factor authentication? Second factor authentication could improve the situation so much, but it's by far not as prevalent as we would like it to be. But OK, maybe that's just the usability of second factor authentication, where you get a text message to your phone and you have to type in it. It's a bit cumbersome. So we will talk more about that later in detail, what we can do better, and how it becomes simpler for your users and even more secure. So we postulate. Sign up should be as simple as one tap of a button. You know what? Let's get rid of sign up forms as well. Picking a good password and memorizing it shouldn't be your burden. The password manager should know your identities, and you tap on one of them, and the website gets the name, the email address, and the generated password. And actually, in the long term, we can be even more ambitious. We can create password less accounts. And we'll talk more about that later. So finally, there is security. Fishing is a huge problem, and we want to fix that. And there are many real opportunities ahead with this technology. You know how many modern phones contain fingerprint scanners and secure elements? Wouldn't it be cool if you could use that for biometric authentication in a secure and privacy-preserving way on the web? We want to share with you some details of what we're working on together with the Web Auth and Working Group of W3C. Our end goal is that identity becomes the first class citizen of the web. We want one API, the credential management API, to manage your identity for passwords, identity providers, second factors, biometric reauthentication, for sign-in and for sign-up. The browser should take care of identity management and simplify the process to pressing a button. And here we want to show how you can help us help your users. What you see on this slide is the outline of our presentation. At the same time, this is where we try to get you motivated to help. There are two things where you can help us today. We will talk how you can help the password manager doing a great job for our users for form-based sign-in. And this alone should get you more signed-in users. And then we'll talk about, then building on this, we'll talk about how using the Credential Management API allows you to automatically sign-in users and how it provides better support for federated credential management. Then we'll give you an outlook to two APIs that are not quite ready to be used yet. We want to share our vision for getting rid of sign-in, sign-up forms, and making sign-up really, really simple. Then we want to talk about two-factor authentication and new ways of doing this. So let's start with the basics. We recognize that passwords are not going to go away anytime soon. We have a huge existing ecosystem. But please help us do a good job for your users. Here you see two screenshots of the friendly password manager in Chrome asking whether you want to save a password and fill it later on a website. And we've shared with you at the 50th release of Chrome that Chrome fills nine billion forms and passwords for our users every month. This is huge, but it's not always working perfectly. So here are the top three issues where the Chrome password manager struggles with today. First, broken markup and improper annotations. This breaks Chrome's heuristics that determine what data to save for the user. Then there are unnoticeable form submissions, and they break the decision process whether we want to offer to save a password. And then finally, mixing HTTP and HTTPS. This is the worst offender with regards to automatically filling in passwords back into forms. So let's drill into each of these issues. A popular way of keeping the password manager from doing its job properly is to omit the form tag. This is really difficult if you have unrelated text fields on your page, maybe a search box somewhere, and then the login form somewhere else. And similar problems occur if you combine the sign-in and sign-up forms or their text fields into the same form element. And of course, please do not use empty or duplicate name and ID attributes, because these are used to identify the fields in the forms. Finally, figuring out the meaning of fields is really difficult. Think about a sign-up form. It has a name, an email address, a phone number. But which one is expected to be used to identify the user later during sign-in? Could be anything, right? So you can help the password manager by telling it explicitly what is the username that you want to see later. And you can do that by setting the autocomplete attribute to one of your form fields to username. And this provides a so much better user experience. And you can also please tell us the semantics of password fields. Is a field representing the current password, which the password manager is supposed to fill in? Or is it a news password where we can offer password generation? So unnoticed form submissions. The Chrome password manager is built upon one principle, which is we only want to offer to save a password when the login succeeded. And to check that, we use a very simple heuristic. If the login failed, then typically the landing page contains another login form, so that the user has a second chance to type their password and this time correctly. If there is no such login form on the landing page, we assume that the login succeeded. And then we can ask the user whether they want to save their password. This is very simple for conventional form submissions using HTTP post. But if you're using XML HTTP requests or the Fetch API to log in the user, there is no navigation event. So when should we check whether the login form is gone? We'd love you forever if you could do two things for us. First, remove the login form after a successful login. And second, call history push state or history replace state to simulate a navigation. Because that simulated navigation triggers our heuristics that check whether the login form is gone and then we can offer to save a password. Third, Chrome loves HTTPS. Please use it sensitively, but avoid a few pitfalls. Quite often we see code like this on an HTTP page. That's an insecure page. The page posts the form to an HTTPS endpoint and people think, hey, this is secure. The password is sent over an encrypted connection. Well, that's true, but it's not secure. The HTTP page itself is insecure and it's easy to inject JavaScript and that JavaScript can steal credentials or you can modify the target URL and thereby again steal the credentials. And the problem we observe quite often is that the user lands on an insecure HTTP landing page, the home page, which has username and password fields like here, but the sign up page is on a secured HTTPS page. So now the user saves their password during the sign up flow, but it would be totally irresponsible if we would take that password, which was stored in a secure context and fill it into the insecure HTTP page and that again creates a bad user experience. And then some developers think, I'll just embed an HTTPS iframe into my HTTP page, but that's not really different from a security perspective. The iframe can be silently swapped for a spoofed version and again credentials can be easily stolen. So please, if you allow the user to sign into your website, move on to HTTPS, but on all pages. And we've provided some instructions and tips for you at the URL that you can see there on the left on the screen. And you know what? If you help us improve the reliability of password managers, people may start to getting used to the idea that they don't have to memorize and type their passwords anymore. And this is when people will hopefully start using unique and randomly generated passwords for websites. And we're in the stage of crossing the T's and dotting the I's to soon launch the password generation feature in the Chrome browser. We just need to make sure that we're covering all the edge cases and that users are always able to access their passwords. And there's another positive side effect of generated passwords. A user who doesn't know their password is a user who's really hard to fish. So think about it, less phishing, less impact of leaked credentials, and the user save time and have a better experience when they're automatically signed in. Wouldn't that be cool? But there are still some issues left. We can take the guesswork out of our heuristics. We can support federated login by the password manager. And we can create an even better experience with the credential for the user when they're automatically signed into a website without pressing a button. And all of that can happen with the credential management API. To talk more about that, let me invite Aji on stage. Hello, my name is Aji, and I'm a developer at Google working on the open web. So Dominic talked about how we can make the password manager work more effectively by improving your forms. Now, let me talk about the credential management API that enables a seamless sign-in experience. It has roughly three benefits. First, with the credential management API, you can show a native account to the dialogue when a user is trying to sign in. This way, users can sign in by selecting an account with just one tap. Second, because the credential management API remembers federated accounts such as Google or Facebook, users can get a consistent user experience for selecting an account across one that's ID and password accounts and also once with federated accounts. Third, the credential management API allows user to sign in automatically. This is typically useful when login sessions of your website are short so that users don't have to proactively tap on sign-in button. This is also helpful if users have multiple devices. They will be signed in automatically just by opening your website. We have introduced several websites that started to using this API at Google IE last year. They have implemented this feature, mostly for their desktop version of a website, but we are seeing more and more of this applied to progress web apps. For example, Flipkart, an Indian top e-commerce website, launched this credential management API just last week. Another example is Wego. A successful startup in Singapore has also launched the implementation recently. AliExpress from China has launched the integration a while ago and they proved the higher engagement of this API with this API is not just in theory. They have achieved 41% more sign-in users by using the credential management API. Additionally, they decrease the signing failure rate by 85% and increase the conversion rate by 11% that's incredible. Now, let's take a closer look into how it works along with some updates to the upcoming changes to the API to obtain a credential call navigator credentials get. By giving it password and federated parameters, you can specify the types of credentials you want to retrieve. With this call, you will receive undefined when there's no credential stored and no credential stored. If there's only one credential, you will receive it immediately so that you can use that for automatic authentication. And if there are more than two credentials stored, an account-chooser dialogue will show up so that the user can select the one that should be passed to your website. If you want to let a user to sign in automatically, you should avoid showing the account-chooser. You can simply add unmeditated true to the call to turn off showing it. In case the user has more than one credential stored, you will receive undefined so that you can defer the process to the user's explicit sign-in like tapping on the sign-in button. Starting from Chrome 60, you should replace unmeditated true with mediation silent. This is equivalent, but it enables some extra use cases for the API. For compatibility with older version of Chrome, I'd recommend using both parameters for the time being. When a user signs out of your website, the user probably doesn't want to get signed back in automatically at the next visit. To avoid those situations, you can call WD credentials require user mediation. This way, users will be able to indicate their intention to sign in by selecting an account. Once you receive a credential, you can use it to authenticate a user. Because a credential object does not expose the password to the JavaScript, you would have to use fetch function in order to send the credential object to server. This introduced a number of restrictions. We have received feedback that developers could not use the API because they had to send the password as part of a JSON object, or had to send the hash value of the password to their server. After performing a security analysis and recognizing that conceding passwords from JavaScript did not really prevent all attack vectors as effectively as we were hoping, we had decided to make a change. Starting from Chrome 60, you will be able to access the raw password from JavaScript. I'm really excited about this change because it drastically simplifies using this API. To feature detect this exposure of a password, you can simply check to see if password property of a credential object returns undefined or not. But frankly, if your server requires a password as part of a JSON object or a hash of the password, you probably should not call the API in order, in order versions than Chrome 60. In that case, please just check the user agent string. You can, of course, store new credentials or update existing ones using the credential management API. As Dominic mentioned, submitting a form would trigger a prompt to store the credential even without using a credential management API. But with the API, you have better handling of this. By authenticating a user through Ajax first, then storing the credential only when it succeeds, you can keep the credential information always valid and sane. To store a credential, you can simply construct a password credential object with a DOM element of the sign-in form. Of course, the sign-in form needs to be properly annotated with auto-complete attributes, then call navigator credentials stored. This should happen in forms, including sign-in, sign-up, and please don't forget to apply this to password change forms as well. That will keep users' passwords always up to date. By the way, a sign-in to a website using a third party account, such as Google or Facebook, is what we call federated login, as Dominic mentioned. In general, federated login represents a few protocols depending on identity providers. For example, Google uses OpenID Connect, Facebook uses OS2, and Twitter uses OS1. When you store a federated account using credential management API, you are not storing credential information such as an ID token for OpenID Connect or an access token for OS. Instead, you are storing strings that represent an identity provider and ID for the user, and optionally, some other information as you can see on the slide. One last important update to the API is that credentials is about sharing credentials across origins. Access to credentials in credential management API has been strictly restricted by the same origin policy. In Chrome 57, we have introduced mediated sharing of credentials between subdomains. This is useful when a website's subdomain is different between, for example, desktop and mobile. There are also cases where you want to let users sign in using a credential that is stored to a totally different domain. Learned companies single sign-on services may typically appreciate this. To associate one origin to another, you will use something called digital asset links. Create a JSON file that looks like this at both domains at slash well-known slash asset links.json and reference each other. This way, you can declare that these two or more domains can share credentials with each other. Okay, so that's the credential management API. To learn more about it, please visit g.show slash credential management API. So far, we've been talking about how we can improve the sign-in user experience by concealing passwords from the users. The credential management API does a great job at letting users forget about their passwords. Now, let's move on to the sign-up API and see how we can help creating stronger passwords. Sorry, stronger credentials. John Rain published a report that says 58% of US consumers say that passwords discourages them from creating a new account. I'd like to share a success story from Hotel Tonight using SmartLock for passwords on their Android native apps. We want to bring that very sign-up flow you are going to see to the web. But first, this is how you would create an account with Hotel Tonight in the old flow. You had to enter your email address, a password, and your name. This is a lot of typing for a mobile phone. Additionally, you would have to verify the email address by clicking on a link in a confirmation email. Now, here is what you see in their new flow instead. The user taps on sign-up button, then the account to the dialogue is shown immediately. At least accounts registered on the phone are saved in SmartLock for passwords. This enables account creation with a single tap. When the user taps on one of the items, the email address and name are shared with a website. The cool part of this is that OpenID connects support ID tokens that are issued by the identity provider. So if you click on the Gmail address, the website gets an ID token with Google and does not even ask you for a password. Also, they have proof that you own that email address so there's no need to send a verification email as a confirmation. This smooth flow created a 23% higher conversion rate for Hotel Tonight, and now about two-thirds of all accounts are created this way. The whole flow is a bit like what you know from regular OpenID Connect, but there are two important differences. First, the user sees what they share, their name, email address, and maybe an avatar. But no social circle, no permission to access their address book or post on their behalf. Users are much less hesitant to click the buttons and rightfully, so I would say. Second, because everything is mediated via secure environment, secure environment, there is no clumsy redirect flow that moves the user away from your site or app. Everything is very smooth. You can learn more about this experience at g.co slash smart lock case studies. And finally, a team at Google is prototyping this feature as a JavaScript library. And we will be working on bringing this feature natively to the browser later this year. So if you're interested to become an early access partner, please go to g.co slash web sign up API so you can reach out us. So we have shared a lot about managing ID password credentials or federated login credentials. Now let me invite Kim to talk about what we are working on to reduce the risk of credential theft by bringing security key second factors and fingerprint authentication to the web. Thanks, Eiji. Hi, I'm Kim. I'm a software engineer on Google's identity and authentication teams. So let's talk about second factor auth. Let me start by recapping the motivation for second factor authentication. Now you all already know that passwords have problems. Dominic and A.G. already mentioned some of the downsides. Password reuse is rampant, and as you know, it only takes the compromise of one website to compromise that account for multiple others. But even if you were superhuman and had unique random 14 plus character passwords that you never forgot or used a password manager to do it for you, passwords could still be intercepted by man in the middle attackers if websites forget to use HTTPS everywhere, like Dominic showed us. And sometimes users simply give their passwords away by typing them into fake forms. And tricking users in this manner is called phishing. And unfortunately, phishing is pretty darn effective. One of our studies found that well-designed phishing pages will trick nearly half of targeted users. Even the laziest of phishing pages, for example, containing only input for username and password, will still trick about 3% of users. If you have a large user base, that's still a lot of users. So it's clear that protecting your accounts with only a password puts your account at risk. And one solution to this is something you're probably very familiar with, the OTP, or one-time password. It's a generated code that's valid for only one login, such as something you might get texted to you on your phone. But unfortunately, these also have downsides. SMS codes have coverage issues, delivery delays, and a non-negligible cost for the organization sending them out. You could get an OTP dongle to display codes for you, but you have to have one per website. And that can add up in cost. And they're a little fragile sometimes. In either case, the user experience for either of these is not great. Generally, you have to copy the code off your phone or device into the website. And for this reason, security-wise, they still aren't perfect. OTPs can be phished just like passwords. Users can be tricked into typing them into a fake form. So we really wanted to make it easier to be a security-conscious user. And our answer to these problems was a second-factor device called a security key. Now, security keys can come in multiple form factors. You could be a USB device, a Bluetooth device, possibly even your phone. But the key difference is that security keys interact directly with browsers to authenticate you. There's no typing in of codes. There's a one-to-many relationship where your single security key can work on many websites. Our stats show that these are faster and produce fewer support incidents than OTP. And of course, best of all, they protect against password phishing. You may already have heard of security keys. We're using them at Google. And there are several other companies that use them as well. They're currently using a protocol that's standardized by the FIDO Alliance. And FIDO stands for Fast Identity Online. They're a group that publish security specifications for strong authentication. So then what is Web Authent and why do we need it? Web Authent stands for Web Authentication. It's the next chapter in the story. It's essentially FIDO++, a next-generation protocol made for the web and in standardization with the W3C. So Web Authent is a future addition to the credential management API that AG showed us. It's not in Chrome yet, but we wanted to give you a heads up that it's coming and show you what it will look like. So let's first take a look at how security keys might be used. So this is our fast and friendly Google login page. And you enter your username and password as usual. But because I'm a security key user, Google knows to prompt me to use my security key. Now on my work laptop, I actually have a small USB security key that just stays plugged in all the time. So I just reach out and tap it, and I'm in. This is showing you the use of a portable key, in which case you would plug it in and tap it, and then you'd be logged in. In either case, the tap action produces a cryptographic assertion that proves that I use my key. In other words, that a real human being is logging in and not a remote attacker. So even if a remote attacker had my password, they wouldn't be able to get past this stage. And here you can see it also works for mobile environments. For example, using a Bluetooth device on your mobile phone, or you would just press that button. So now that I showed you how it would actually look to a user, let's take a look under the hood at the protocol itself, kind of at a high level. So there are two steps using a security key. First is a one-time registration operation, one-time per security key and account. This is to let the server know that you're a security key user so that you can use it on successive logins. So what this would look like is I would log into my account. I would go to my settings page, similar to how I would set up using OTP. And I would say I want to register my security key. I'd be prompted to insert my security key and tap it. And what this does is this tells your security key to generate a private and public key pair for this account. The public key is sent back to the server, and you can see the server stores my public key associated with that registration. That's the first step. The second step is simply getting assertions from the key every time you want to sign in. And here you can see that the browser sends my super secure, super secret password to the server. That is, of course, vulnerable in all the ways that we mentioned before. And because I previously registered my security key, the server knows I'm a security key user. And using the WebOSN API, it asks for an assertion and provides a unique challenge to prove that a real person is here. So using the challenge, the browser will then construct a cryptographic proof to prove that I am indeed here. And this has several key parts. First is the physical touch or action. Malware can't cause this to happen, like I said before. Second is freshness via that server-provided challenge. This makes the proof resistance against reuse and binds it to this specific session. Third is the origin, and that's what provides the phishing resistance. And you can also include state that identifies the TLS connection, and this prevents man-in-the-middle attacks. So you take all of this together, the browser packages it up, and asks the security key to sign it with the private key that it has stored for this registration. And after the key is tapped, it does. So because the security key was previously registered, the server already knows my public key and is able to verify the signed proof and the data that it contains. And this protects against all three issues that I mentioned earlier, password to use, interception, and phishing. So now let's take a look at the actual API. Like I said before, two phases. And the first is registration to tell the website that you have one of these keys. The call to do this is navigator.credentials.create, and you specify a public key credential type. At a minimum, you provide information about the account and the relying party and a unique challenge. So this asks the key to mint that new key pair, and you send the information about the credential, including the public key back to the server. Now, every successive time the user wants to log in, the relying party can request assertions from the security key. So you do the usual gathering of username and password. If the user is a security key user, you make the call to navigator.credential.get to perform the second factor authentication. It's the same API as for the other credential types. You specify a public key credential instead of, say, password or federated credential. This looks for your registered security key and asks for that touch to permit the key to do the signing. And the resulting assertion is what's sent back to the server for verification. Again, this assertion proves that a real user is here logging in. So these are two API calls that are simple and secure. And we think this is the new future of second factor authentication. So you've seen the API. You've seen how it's going to be used. Something else that's cool about WebAuthn that we keep mentioning is that it will support biometrics for faster re-authentication. Security keys show that a real human being is logging in. But of course, biometrics uniquely identify you. So a typical use case would be banking. You're logged into your banking app, and it either times out or you log out. For some reason, you need to log back in. In this scenario, you don't want it to log you back in automatically. That just wouldn't make sense. Of course, you would hope the bank would verify that it was actually you. So using the exact same WebAuthn API, if you have a biometric-capable device, the website can request a biometric assertion to know who you are and confirm the login. So yes, you will be able to use your fingerprint reader on your phone for the web. Native apps can already do this. You might have a banking app that does this, for example, but browsers cannot. And that's what WebAuthn will provide. So I know that's a really brief introduction. Again, the APIs aren't available yet, but you don't have to wait to use Security Keys themselves. You can use them via an existing Fido API. Android also has Fido APIs, which they announced here at I.O. Definitely get a Security Key, add it to your Google account, whatever other accounts you can, and here are some resources to get you started. But in the meantime, if you do want to learn more about WebAuthn, you can read the actual spec. It's public. Feel free to join the mailing list to see what we're working on and definitely watch the working group blog for updates. OK, now back to Dominic to wrap up. So at the beginning of this presentation, we shared our goal, the goal to have one API to manage all of your identity needs, for sign-in with a password, federated login, two-factor hardware tokens, and even fingerprints. And we hope that by now the puzzle pieces connect to the big picture. So we hope that you will help us getting the password manager work really, really well for your websites so that users stop relying on their one, two, three passwords that they type into every website. And hopefully, this allows us to get users to use generated passwords soon. So already today, you can start using the Credential Management API to keep your users signed in across devices, and users don't need to see and fill sign-in forms as often as they used to. We've seen how the Credential Management API allows you to store and retrieve usernames and passwords, but also information about federated login. We shared with you our vision that we want to facilitate entire sign-up flows with convenient browser UI. And we've talked about our ongoing work on two-factor authentication. This will facilitate two major use cases, securing accounts with unfeasible second factors and convenient reauthentication using, for example, fingerprints, both using the same API. Actually, everything we talked about today will be covered by one API, the Credential Management API. We hope that this gives you more signed-in users and moves them to more secure accounts. We want to continue from here, and we hope that we got you excited. Please speak to us and let us know what you think.