Authentication in 2026: A guide to passkeys, digital credentials and more (I/O Connect ‘26)

[00:06] - Hello everyone, and welcome or welcome back to the IO Connect Chrome stage. Let me introduce my colleague, Yu Tsuno, who is a web ecosystem consultant on Chrome. And I'm Natalia Markaborodova, a developer relations engineer on Chrome as well. [00:25] Thanks, Natalia. [00:26] And welcome, everyone. [00:27] I know that currently AI is in everyone's mind, [00:31] But today's topic, what we cover is [00:34] authentication. [00:36] Thank you for staying in the room. [00:38] because... [00:39] we believe that authentication is still a very, very important topic to cover. [00:44] And-- [00:45] We're not only going to cover authentication for human user, but also for the evolving agentic web [00:53] AI agents as well. [00:54] And-- [00:55] authentication is the gateway into your entire application [01:00] And-- [01:00] The experience often accounts for the first impression about your solution. [01:05] And as for AI agent, we will see how much exactly agent experience builds on top of authentication later in this session. [01:14] But first, let's focus on the most important thing, human user experience. [01:20] Imagine a website where the first thing your user interacts with is a high-friction sign-up form. [01:26] And at that point, it often happens that the user simply bounces and never comes back to your site. And if they stay, they must be really highly motivated to use your service.

[01:38] but their first impression will be already spoiled. [01:41] And that's just the first friction. [01:44] Um... [01:45] Now, think of all the other frustration that your user might face [01:49] like, [01:50] phishing attacks. [01:51] and also stolen identity. [01:54] All of those things can happen if you are still relying on legacy technologies. [02:01] But the good news is that we have some recommendations in place to help you improve the user experience and reduce the security risks. [02:10] And we're going to cover these best practices later in this session for you to achieve better results. [02:17] That's right. [02:18] My team is working directly with partners. [02:21] to put this recommendation in practice [02:24] and it has been really rewarding to see the results [02:27] that improving with an actual metrics [02:30] So by applying these best practices [02:32] We have seen, for example, [02:34] doubling the sign-in speed, [02:36] and four times higher success rate. [02:39] For example, Pixiv achieved 99% [02:43] success in logging rates. [02:46] And to enable you to achieve such results, we want to help you understand identity as a whole. And for that, let's first zoom out and take a look at the user account lifecycle. And let's not just talk about which technologies are out there. Let's... [03:05] have a look how they fit in every stage of this user account lifecycle. And by user account lifecycle here, we mean the following stages. First, your user needs to create an account. Then, sometimes you need to verify user attributes.

[03:20] Then subsequent sign-in experience also matters. And finally, we'll talk about account recovery. [03:28] And for every single stage of this account lifecycle, we will talk about modern technologies that can improve your user experience at every particular point. And these technologies include [03:40] pass keys, the email verification protocol, the digital credentials API, FEDCM, and many more. And by the way, if you've seen our pre-recorded session on authentication, you will notice some overlap. But in this session, we cover some technical aspects in more detail. We also cover the most recent updates on some APIs, like, for example, the most recent shape of the email verification protocol. And we also cover new topics like agentic identity. [04:10] Learn more. [04:12] And before we dive in, we have a QR code here for a blog post that we cover some of the topics that we are covering today. [04:19] So in case you want to check [04:22] Today's topic later. [04:23] You can... [04:24] check from this link. [04:27] And first, let's again highlight the goal here. [04:31] So as you design your authentication solution, your main goal is to phase out weak and high friction sign-in methods and enable... [04:41] simpler, more user-friendly, and more secure methods. And after this session, we hope you'll be equipped with the knowledge to do so.

[04:52] And from here, so let's dive in with account creation. [04:56] which is one of the first steps. [04:57] And as we have mentioned before, legacy sign-ups often act as an immediate hurdle here. [05:04] a long list of required fields that user needs to type, [05:08] and if the cognitive load outweighs [05:10] the perceived benefit, the user [05:12] likely to bounce. [05:14] So you can make a better first impression [05:16] And here are some best practices and tips how we can reduce frictions. [05:22] So one thing to address, that you can do to address this problem is considering [05:29] Federated identity. So federated identity is a mechanism that allows your user to sign up on your site [05:37] with an account from an identity provider. [05:40] For example, [05:41] Google, or any other identity provider. And an identity provider as a service is a service that the user already has an account with. [05:51] And the user has already shared some account information with this service. [05:55] such as, for example, email, username, [05:58] first, last name, et cetera. [05:59] So why would you force your users to enter this information on every single site again and again? [06:05] when they can simply request [06:07] the identity provider, to share this information with your web application. [06:12] and it makes it much easier for the user. [06:16] And this means your user can skip TDS forms and sign up with a single click.

[06:22] And most importantly, a trusted identity provider has already performed user contact information verification [06:28] And this means that you won't have to perform checks like the email verification dance. [06:34] and the user is more likely to complete the signup process [06:37] without context switching. [06:39] Since Identity Federation makes it so easy to create an account, you can implement this as a default option [06:45] for [06:46] the initial signup process. [06:49] And [06:50] For the identity federation, we recommend the pattern federate then upgrade. [06:55] It means that we recommend creating a federated account first with a single click, simple and easy, [07:01] and then immediately prompt your user to create a passkey on this device so that the subsequent sign-ins are even [07:09] smoother for the user and maybe even enable cross-device sign-in journey. [07:16] If you're an identity provider, [07:19] you can make the federated flow even better. Consider using the federated credential management API. [07:25] FATCM for short. [07:26] to improve the identity federation flow. [07:28] So FAT-CM allows for one top privacy-oriented user experience [07:34] Sign in with Google has already transitioned using the FedCM. [07:37] And other identity providers have also enabled these capabilities as well. [07:44] So while identity federation is the recommended approach, if you really, really need to use those signup forms, we recommend helping the browser to enable

[07:55] Autofill. [07:57] And this is a huge UX improvement. [08:00] It doesn't require much implementation. You simply need to use descriptive name and ID. [08:06] attributes for your form inputs. [08:08] And most importantly, apply the correct autocomplete values [08:12] such as new password or email, [08:15] to help the browser accurately assist the users. [08:19] And by the way, my favorite thing about Autofill is that it does more than just saves your users from typing. Autofill has evolved into a gateway for new exciting features. [08:31] such as, for example, the email verification protocol [08:34] or [08:35] the passkey from Autofill UI. And we will cover these features later in the session. [08:44] First, let's talk about data verification. [08:47] including emails. [08:49] As we have mentioned before, trusted identity provider has already verified some user data [08:54] such as email addresses. [08:56] But if you rely on sign-up for [08:58] that data you receive isn't always verified, [09:02] We recommend verifying that first. [09:06] And email remains one of the primary identifiers for many users. [09:11] and many applications. And understandably so, because email is a stable [09:17] cross-platform communication channel that virtually every user relies on. [09:22] And therefore, email serves as a baseline for, for example, billing or long-term account recovery.

[09:30] If your application accepts false or non-existent emails, [09:34] It can create high friction and silent failure where users never receive critical information. [09:40] And this leads to immediate churn as users perceive your platform as broken. [09:45] Furthermore, invalid emails result in high bounce rate, [09:48] that [09:49] damage your sender reputation, and churn higher email service provider fees [09:54] for message that never [09:56] you get received. [09:58] And currently, many identity solutions rely on email one time passwords, or some of them rely on magic links. [10:07] And the common downside of both of these approaches is the contact switch. What do we mean by contact switch? [10:14] Your user has to go find their inbox, wait for the delivery of the email, and then click that link or copy that OTP, and this is a notorious problem. [10:24] conversion killer. [10:25] And also OTPs remain still vulnerable to phishing. [10:29] And while magic links point the user to the correct [10:33] page. [10:33] email clients usually open a link in an in-app browser, which is separate from where the user is trying to sign in. [10:40] And this can cause additional confusion and abandonment for the user. [10:44] And if the user finds an unexpected [10:47] empty cart, for example, after [10:50] in the checkout process after clicking the magic link, that can be also [10:54] cause a huge issue. [10:56] - Right, and one of the options that you can use to make this experience better for the users is the email verification protocol, which is rolling out for the origin trial very soon.

[11:08] And the email verification protocol allows your web application to obtain a verified email [11:15] without sending an email at all. [11:17] And for your user, this means a complete elimination of the [11:22] wait time and the check your inbox friction. [11:26] the verification flow is completely browser mediated. [11:31] So how does this work under the hood? [11:33] It's a three-way handshake between the email provider [11:37] and the browser. [11:38] and the special-- [11:40] specialized issuer. [11:42] The email provider can opt in [11:43] delegated verification authority to an issuer. [11:46] The issuer holds a first-party authentication cookie [11:50] that proves the user is logged in and has control over the email. [11:55] when the user either [11:56] enters their email in your app, [11:59] or the browser sends a request to the issuer to verify this email. [12:04] The issuer then checks the authentication cookies, signs a secure digital token, and passes it to the browser. [12:12] and the browser passes it back to the requesting app. [12:16] And to enable the email verification protocol on your website, you simply need to annotate your inputs properly. So, and here on the screenshot, you can see the latest shape [12:29] beautiful and declarative of the email verification protocol API. So what you need to do is to simply annotate your email inputs with the [12:37] autocomplete value set to email, just like you would do for enabling autofill, and then also include a hidden input annotated with email verification token, and do not forget to include a fresh N1s value to make sure the request

[12:54] is not intercepted by a malicious party. [12:56] And please note that the email verification protocol is still in an early development stage, which means the shape of the API might change based on your feedback. And since we are already talking about user data verification, [13:09] There are [13:10] other important aspect to cover. [13:12] It's not always only the contact [13:14] information to be verified. [13:16] There are cases where you might need to verify the legal name, [13:20] or the age attributes. [13:23] Um... [13:24] like their legal name, yeah, age eligibility as well. [13:27] So before finalizing account creation, [13:30] And this is sometimes needed to comply with the local regulations. [13:35] And digital identity... [13:37] credential API are already available in some regions, and you can use this API for privacy preserving user attributes verification. [13:46] So to understand how this works, let's first get a high-level overview of the Disho credential [13:53] three-party model. [13:54] and [13:55] This includes the following parties. [13:57] So one... [13:58] the issuer. [13:59] A trusted party... [14:01] cryptographically signs a credential claim. [14:04] For example, this can be the organization that issues the driving license. [14:09] and two, the holder. [14:11] That's your user mobile device that stores the signed claim. [14:15] And third, [14:16] the verifier. [14:18] That is the website or the mobile app that requests the proof by the digital credentials API. [14:24] And the browser mediates the communication between all these three parties.

[14:30] And here is the screenshot of how it looks for the user on their mobile device. So you can request user attributes from a digital credential that is stored in a compatible wallet on [14:43] a user's mobile device by calling the Digital Credentials API. [14:48] So in this case, the browser and the operating system of the user's device will work together to facilitate the communication between the browser and between the [14:59] apps. [15:00] or wallets installed on the user's [15:03] let's say phone. [15:04] then the verifier will only receive the information that [15:09] the prompt [15:12] displayed to the user. So the user gets a comprehensive disclosure of which exactly data is being shared. And then the verifier, meaning your site, can check the authenticity of the credential [15:24] with the issuer directly. [15:28] And speaking of digital credentials in general, we are now observing how this landscape is maturing beyond just government-issued credentials, [15:37] to-- [15:38] more comprehensive verifiable credentials model. And the digital credentials API [15:44] plays the role of a transport layer here, simply connecting your application to the user's [15:51] mobile [15:52] wallet. [15:54] And therefore, the digital credentials API can serve as a very versatile tool to check credentials of any type, be it, for example, digital certificates or boarding passes. So as long as the user has compatible apps, compatible wallets installed,

[16:10] on their mobile devices. [16:12] And as long as they hold a credential from an issuer that you personally trust, you can request this information using the digital credentials API. [16:22] Hopefully you can use the digital credential API to buy a beer after this session. Joke aside, I think it's a pretty good start. [16:30] to cover the technology that can make authentication [16:33] creation process much better. [16:35] So let's move on to the next step. [16:38] motivating the user after the registration [16:41] and data verification. [16:43] Well, I hope the people will sign into those services again and again. [16:48] And as you can imagine, a smooth sign-in [16:51] experience is important because it sets the tone for the entire user journey. [16:58] So you probably noticed that there are many different sign-in options. [17:01] Nowadays, [17:02] And that's a good thing. Different people have different preferences, [17:06] like people still use passwords, and some people might log in with a federated login, [17:11] but also with Paschke's. [17:13] And in this session, we are really strongly recommending to implement passkeys. [17:19] for your services. [17:20] and [17:21] It's because... [17:23] pass keys are an easier and more secure alternative to passwords and ODP [17:28] and are fishing resistant. [17:30] And we see how more and more industry leaders and partners are implementing [17:34] past geese [17:35] and joining the PASCIS. [17:37] Bandwagon. [17:39] - Yeah, but how do you make sure you're not just blindly following another trend out there, but are actually making your users experience the smoothest and

[17:49] easiest that is possible out there. [17:52] Well, first let's take a look at the fact that you can actually offer pass keys alongside other different options consolidated in a unified UI. [18:04] So starting from Chrome 148, you can drastically reduce friction [18:10] using the immediate login dialog. With this API, the user clicks a sign in button, and then the browser instantly presents [18:18] an immediate login dialog, which is a clean unified dialog that [18:23] simply offers the user their saved credential with a single click. [18:28] And the real magic happens here. [18:30] Imagine a guest user is-- [18:32] trying to use [18:33] favorite, or my orders. [18:35] Um... [18:36] And for the site to display those information, you need to be signed in. [18:40] And there's an implicit sign-in intention behind this click. [18:44] And when multiple credentials are available, [18:47] for the same account, the browser intelligently selects the [18:50] best appropriate option. [18:52] Unlike other [18:54] Pasqui's request. [18:55] If there are no credentials available, [18:57] the browser will immediately return an error without showing any UI. [19:01] And your website can then fall back to navigating the user to standard sign-in page. [19:07] And you might be thinking, wait a minute, but what if the user doesn't yet have passkeys [19:13] Well, you're right. Some people [19:16] users still rely on passwords. There are also some browsers that do not yet support the immediate login dialog. And for you this means

[19:26] you need a fallback. [19:28] As a backtrust practice, we highly recommend that you cover both [19:32] sign-in form supporting passwords and pass keys. [19:36] This is possible when the passkey [19:38] form from autofill feature is enabled. [19:41] and you route user to a traditional sign-in page, this feature takes full advantage of the familiar form Orville experience. [19:48] And when the user focuses on the username field, [19:52] the browser automatically suggests [19:54] both passkeys and passwords. [19:57] This ensures that the users who have passkeys get the streamlined experience today, while you gradually transition those who still rely on passwords only. [20:07] So, and speaking of gradually transitioning users to PASCIs, what are actually the strategies? When is it best to create a PASCII? [20:16] So you should prompt your user [20:18] to create a PASCII during or right after sign up. And crucially, before creating a PASCII, make sure that the user is [20:27] who they say they are. [20:29] Because if their email, for example, has already been leaked, this step will prevent an attacker from creating unauthorized credentials. [20:39] For your existing users, we recommend requesting automatic [20:43] pass keys creation. [20:44] using conditional create feature. [20:47] This feature lets your website trigger pathkick creation without [20:51] having any user additional prompts. [20:53] For example, Adidas implemented this. [20:55] with conditional create.

[20:57] And we saw an 8% uplift in Paschi's creations. [21:03] And, interesting enough, some platforms even see uplift in conversion to passkeys by simply notifying the users about the passkeys benefits, like Pixif. [21:16] who implemented this simple security confirmation screen, and it bumped the Apache adoption rate by 6% among new users. [21:26] And another good practice is to make sure implementation [21:30] handles failed packs. [21:31] PASC's creation attempts. [21:33] If a public key fails to save on your backend, send a signal to the passkey provider with a signal API. [21:40] We'll talk about this. [21:41] API later in this section. [21:45] And finally, do not forget to notify your user about passkey creation every single time when a passkey is well created. And again, this will defend against unauthorized credential addition, and it's just a good practice to build user trust. [22:02] So do not forget to send an email or an app notification. [22:09] And it's important that your user experience is consistent [22:12] not just in the desktop browser, but across all user devices. [22:17] and sure, smooth... [22:18] cross-platform experience, you can establish a verified relationship between your website and your mobile app. [22:25] For your Android app,

[22:27] Specify the association using the digital asset links protocol. [22:32] And don't forget to update your app manifest file on Android size. [22:36] This file verifies that your web origin and your native app [22:39] owned by the same entity. [22:41] and enables seamless credential sharing. [22:45] Without it, user [22:46] who wants to try to log in to the app for the first time, who created the... [22:51] account on the web first. [22:53] they would not [22:55] have the password to log in on that app, and vice versa. [22:59] So, and with digital asset links, we've covered how to sync your web and mobile applications. But what about the applications that span multiple distinct websites, like, for example, regional sites for [23:14] Germany.de [23:17] or an international site .com. [23:20] Well, as you might know, by design, a PASCII is securely tied to a specific domain where it was created. And this [23:29] specific domain is known as the reliant party ID. [23:34] However, if as we've mentioned, your service spans multiple regional sites, you can use the related origin requests, [23:41] to securely share the same Paschi across multiple sites that you own. [23:47] And to set this up, you need to simply serve a configuration file where you list the domains that you own. [23:55] And this is a huge improvement in user experience, because imagine how frustrating it must be for the user when they have to create a brand new passkey for every single site

[24:07] that is based in a different region. [24:09] So make it easier for your users. [24:12] And also, let me point out a common pitfall that I have seen working with partners. [24:18] We have often seen related origin requests [24:21] implemented [24:22] unnecessary for subdomains. [24:24] And if you're just sharing pass keys across your subdomains of your service-- [24:29] Um... [24:30] save your extra configuration, and simply using the main domain as the relying party ID. [24:36] at [24:36] And that will be the right approach. [24:39] And since we already covered [24:42] the cross-site experience, let's also talk about cross-device experience here as well. [24:47] There are cases when a user has a passkey on [24:50] One device, but not on the other. [24:53] With cross device flow, browser can display QR code. You might have seen it in the past. [24:59] that the user can scan it and sign in with the other device [25:02] using the saved paskis. [25:05] And this is designed robust as well, because [25:07] This won't work without a sufficient [25:10] proximity of the two devices. [25:12] thanks to the Bluetooth technologies. [25:15] Well, but we have also received feedback that scanning a QR code is not necessarily always the most optimal user experience. [25:24] So-- [25:25] We've taken this feedback into consideration, and we've been exploring other alternatives. [25:31] And that's how we came up with the idea of NFC invocation. And think of this NFC invocation method as tap to pay, but for your identity.

[25:43] This is useful in situations when two devices both have NFC [25:48] And you can sign in with a passkey. [25:52] from one device where it's already created on another device. [25:56] where there is no passkey yet, by simply tapping this device against the other one, [26:01] For example, imagine your user is signing in on a game console where [26:05] Well, they haven't yet created a passkey. [26:07] And they can simply tap their phone to share this basket and sign in. [26:13] And here's another piece of feedback. [26:16] regarding the QR code. [26:18] When a user has no passkey save, [26:20] at all, and that [26:22] they got displayed a QR code, the user can get confused, and they may have no idea about path keys, [26:28] what to do with the QR code. [26:32] For such cases, [26:33] There is the cross-device fallback URL extension that you can use. [26:37] that provides the backup link. [26:39] This URL is the link to your standard sign-in page that the browser offers to open for alternative sign-in flows. [26:48] And here is another pro tip. When your user is signing in using the cross-device flow, this probably means that they don't yet have a local passkey stored on that device where they are signing in. And since recently, you can use the authenticator attachment value, [27:07] to check if the user is signing in [27:09] cross device. [27:10] And if so, you can prompt the user to create a passkey on that device locally.

[27:16] to simplify the next [27:18] Sign in. [27:20] Join us. [27:22] And once your user has pass keys, [27:24] You need to keep them perfectly in sync. [27:27] One of the biggest friction points we have seen is [27:30] Delete the past keys. [27:31] In other words... [27:32] Go Spaskis. [27:35] This happens when a user deletes their account or revokes the device on your website. [27:39] but the passkey itself is still saved in the password manager. [27:43] The next time they try to log in, they select the ghost pass key, and it just fails. [27:49] To prevent this, you should use the signal API that we covered a little bit before. [27:53] it acts as a direct line of communication between your [27:58] backend and the user's pass keys provider. [28:01] If your user tries to log in with a key that no longer exists, [28:05] in your database. [28:07] You simply send a signal that the password manager hides or deletes that. [28:11] You can also use the Signal API to keep the user data, such as email and name, fresh. [28:17] And here you can see example how Pixiv handles the-- [28:21] passkey deletion process. [28:23] using the Signal API to ensure that the pass key stayed synced. [28:30] And let's talk about another essential component of a great user experience. [28:35] you want to give [28:36] control over pass keys to your users. And here's how you can do that. [28:41] So first, your user should be able to create multiple passkeys. This is crucial for potential future account recovery.

[28:50] It's also a good practice to offer your users a dedicated page where they can manage all their passkey's. [28:57] For example, you can integrate this page already into your existing [29:01] password management pages, [29:04] where the users expect to manage their passwords, or maybe two-factor authentications. [29:11] To make sure UI is truly helpful, [29:13] The API provides metadata that lets you display exactly where each passkey lives. [29:19] like showing the Google Password Manager logo or the Bitwarden logo next to it. [29:24] You can also check the... [29:26] backup eligible status. [29:28] This allows you to clearly tell the user whether a specific passkey safely syncs across [29:33] their devices in the cloud, or if it's tied strictly to the current device or not. [29:40] So when prompting users to create a passkey, you are in fact not limited to using the device. [29:46] You can also use the external hardware like [29:49] physical security USB keys. [29:52] and your power user will appreciate the flexibility to choose [29:55] to set up [29:56] they prefer. [29:57] So we recommend adding this option [29:59] as well in the passkey management page as well. [30:03] And that's how you build a good sign-in user experience. [30:08] And here we are at the next stage of the user account lifecycle. [30:13] we are going to cover things that you need to know about account recovery. [30:18] You might be thinking, what happens if

[30:20] the user loses their device, or [30:24] even deletes the pass keys. [30:26] Don't panic, don't worry. [30:27] We have a recommendation in place today to help you user access or recover their account. [30:34] And we've talked before about how pass keys are synchronized and end-to-end encrypted. [30:41] This means that if your user loses their device that has a passkey saved, that's not yet a tragedy because they can [30:50] simply sign in on the other device and sign into their [30:55] Passkey Manager, for example, Google Password Manager, and their key is securely stored there. [31:02] So the user can sign in to the Google account, provide their Android lock or their Google password manager pin, and access their synced pass keys. And for your application, this means that they can still access it. [31:17] Seamlessly. [31:19] Right. And this is not only for Google. [31:21] Other password manager also supports this synchronization and end-to-end encryptions. [31:28] And if the user loses access to all their PASCII-enabled devices, well, you can still fall back to verified attributes that we've covered before. [31:38] For example, you can let the user [31:40] sign in with the same original federated account that they've signed up with. [31:46] Or you can use other methods, like for example, the email verification protocol to make sure that the user is still in control over their account.

[31:55] And overall, we recommend diversifying the recovery methods. For example, try to encourage your users to use different providers for pass keys and for federated accounts. Like that, you can make sure that the user still has access to maybe at least one of the provider when they lose access to the other one. [32:18] And with this method, you can always help your user restore access to your application. [32:23] But before you roll out all of these recommendations and new past keys experience, [32:29] Testing is [32:29] very crucial. [32:31] and Chrome DevTools. [32:33] now has a fantastic building support that allows you to simulate virtual authenticator. [32:38] You can even emulate physical USB security keys [32:42] right in your browser. [32:43] without needing the actual hardware on your... [32:46] this. [32:47] For automation, there are even frameworks that fully supports this end-to-end testing flows, for example, Selenium. [32:54] We are also introducing new JSON serialization methods [32:58] This make it infinitely... [33:00] easier to parse passkey credential data back and forth between your front end and your [33:06] saving from without custom parsing logic. [33:10] So that's what we wanted to cover and highlight about testing your solution. [33:15] And now, do you remember how we started this session at the very beginning? [33:20] authentication experience is actually foundation for agentic experience as well. [33:25] So up until now, we have talked about the identity for purely human experience.

[33:30] But the definition of user-ex, [33:32] expanding. [33:33] the ecosystem is moving rapidly in the direction of agentic web. [33:38] and you will soon need to tailor your site and services [33:41] of the identity solution [33:43] for a new type of user. [33:45] autonomous agents. [33:48] So these agents act on behalf of your user complete task, like [33:52] booking the trips or [33:55] managing subscriptions [33:57] And if an agent can't recognize the identity elements of your application, [34:02] you may be blocking the tools your user want to use. [34:06] And we might not have enough time to cover it all, but long story short, the Chrome team is currently experimenting with [34:15] new improved authentic authentication [34:19] discovery. [34:20] We are experimenting with semantics and annotation and new elements. [34:25] to help the agent discover [34:27] such user journeys on your application as, let's say, login [34:32] or [34:32] Federated. [34:33] Log in. [34:34] Yeah, also quickly covering another AI-powered feature, which is the automatic password change that has been launched last year. [34:42] Um... [34:43] So it helps users quickly update password found in public data breaches for Chrome desktop users. [34:49] And when a user signed in to support website, [34:51] using compromised password, [34:53] Google password manager may offer to change it for them. [34:56] If they accept, the automated password change process starts

[35:02] And to help Browser enable the feature, provide your password change [35:05] URL in the well-known file. [35:08] And it's also a general recommendation to annotate your inputs [35:11] with autocomplete attributes [35:13] to improve auto-pilot. [35:15] autofill accuracy, enable password generation, and also enable this. [35:19] feature like automated password change. [35:22] And just like you can help your agents discover, or users' agents discover, log in journeys on your web application, the agents can also help you build your solutions. But as a part of this project, we've prepared a set of authentication tech-specific skills that will help you to develop a great identity solution and follow all the best practices that we've covered to date. [35:50] And these were our top recommendations that we wanted to cover today. [35:54] And we covered [35:56] the best practice for every stage of the account [35:59] life cycle. [36:01] Now you know how to reduce user friction during the account creation process using the FEDCM and AutoFill. [36:09] how to verify user attributes with the new email verification protocol and the digital credentials API. [36:16] and how to implement passkeys [36:18] for the best sign-in experience and how to [36:21] help the users [36:22] recovered your account. [36:24] And you also now equip with the right tools, for example, the modern web guidance. [36:29] that will simplify your development process.

[36:32] Yeah, and by the way, feel free to take the picture of the slide so that you can come to it later, do your homework, read about all these technologies online. We also have the hashtag to share any impressions on social media. [36:46] And here is also a QR code that you can scan. [36:52] to read the blog post that also covers the technologies that we've talked about. [36:58] right now. [36:59] and [37:00] Thank you from us for this session. [37:03] We are you and Natalia from Chrome. And closing the session on authentication in 2026, we now hope that you will go and make your user account lifecycle an enjoyable experience. Thank you.