Authentication in 2026 - Passkeys and Digital Credentials (IO Connect 26)

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

Transcript of the I/O Connect ‘26 Chrome stage talk by Natalia Macheda (Developer Relations Engineer) and Yutono (Web Ecosystem Consultant), Chrome.

TL;DR

Passwords are dead weight — they cause bounce at signup, phishing, and stolen identities. The talk is a practical playbook for modernising auth across the entire user account life cycle, plus a look ahead at authenticating AI agents. The framing: authentication is your product’s first impression, and it’s now the foundation for the agentic web too.

Real results from partners applying these practices: 2× sign-in speed, 4× higher success rate, Pixiv hit 99% login success.

The Account Life Cycle (the spine of the talk)

Every stage has a modern technology that reduces friction and risk:

1. Account creation — kill the signup form

• Federated identity (Sign in with Google / any IdP) — one-click signup, no forms, and the IdP has already verified the email. Recommended default.
• “Federate then upgrade” pattern — create the federated account first, then immediately prompt to create a passkey for smoother future sign-ins.
• FedCM (Federated Credential Management API) — one-tap, privacy-preserving federation. Sign in with Google already runs on it.
• If you must use forms → enable autofill properly: descriptive name/id + correct autocomplete values (new-password, email).

2. Verify user attributes

• Email Verification Protocol (Origin Trial soon) — get a verified email without sending an email at all. Kills the “check your inbox” context switch that murders conversion. Works via a three-way handshake (email provider ↔ browser ↔ specialized issuer holding a first-party auth cookie); browser-mediated, returns a signed token. Enable by annotating inputs (autocomplete=email + hidden email-verification-token input + a fresh nonce).
• Beats OTP (phishable, context switch) and magic links (open in in-app browsers, cause confusion/abandonment).
• Digital Credentials API — privacy-preserving verification of real-world attributes (legal name, age eligibility) for regulatory compliance. Three-party model: issuer (signs the claim, e.g. DMV) → holder (user’s mobile wallet) → verifier (your site). Browser mediates; user sees exactly what’s shared. Maturing beyond government IDs into general verifiable credentials (certificates, boarding passes) — the API is just the transport layer to mobile wallets.

3. Sign-in — implement passkeys

Passkeys = easier, more secure, phishing-resistant alternative to passwords/OTPs.

• Immediate login dialog (Chrome 148+) — click sign-in → browser instantly offers saved credential in one click; picks the best when multiple exist; returns an error with no UI if none, so you can fall back cleanly.
• Passkeys from autofill — fallback for users on passwords / unsupported browsers; username field suggests both passkeys and passwords. Lets you transition users gradually.
• When to create: during/right after signup — but verify the user first (a leaked email could let an attacker register a passkey).
• Conditional create — auto-create passkeys for existing users with no extra prompt (Adidas: +8% passkey creation; Pixiv’s security-confirmation screen: +6% adoption).
• Always notify on passkey creation (trust + defends against unauthorized addition).
• Cross-platform: Digital Asset Links + app manifest to share credentials between your web origin and Android app.
• Cross-site: Related Origin Requests to share one passkey across regional domains you own (.de / .com). Pitfall: don’t use it for subdomains — just use the main domain as the relying party ID.
• Cross-device: QR + Bluetooth proximity; new NFC invocation (“tap-to-pay for identity”, e.g. tap phone to a game console); cross-device fallback URL for confused users; use authenticatorAttachment to detect cross-device sign-in and prompt a local passkey.
• Signal API — kill “ghost passkeys” (deleted server-side but still in the password manager) and keep name/email fresh.
• Give users control — multiple passkeys (for recovery), a management page, metadata showing where each passkey lives (Google PM / Bitwarden logo) + backup-eligible status, support external hardware/USB security keys.

4. Account recovery

• Synced + end-to-end encrypted passkeys → lost device isn’t a tragedy; sign in on another device via the passkey manager (works across providers, not just Google).
• Lost all devices → fall back to verified attributes (original federated account, email verification protocol).
• Diversify recovery methods — use different providers for passkeys vs federated accounts so losing one doesn’t lock the user out.

Testing

Chrome DevTools can simulate virtual authenticators / emulate USB security keys (no hardware needed); Selenium supports end-to-end passkey flows; new JSON serialization methods remove custom parsing of credential data.

The Agentic Web (the forward-looking bit)

• “User” is expanding to include autonomous agents acting on behalf of users (booking trips, managing subscriptions). If an agent can’t recognise your auth elements, you’re blocking tools your users want.
• Chrome is experimenting with agentic auth discovery — semantics/annotations/new elements so agents can find login & federated-login journeys.
• Automatic password change (Chrome desktop) — Google Password Manager offers to change breached passwords; enable via a well-known password-change URL + proper autocomplete annotations.
• Auth-specific agent skills shipping to help devs build compliant identity solutions.

My Takeaways

• The organizing idea worth stealing: map auth decisions to the account life cycle, not to a list of technologies.
• The “verified email with zero emails sent” (Email Verification Protocol) is the sleeper feature — directly attacks the biggest signup drop-off.
• Passkeys aren’t a single toggle; the real work is the edge cases — ghost passkeys, cross-site/device, recovery diversification.
• Agentic auth is early/experimental but flagged as the next foundation. Worth watching, not building on yet.

Transcript

— Hello everyone and welcome or welcome back to the IO Connect Chrome stage. Um let me introduce my colleague Yutono, who is a web ecosystem consultant on Chrome. And I’m Natalia Macheda, a developer relations engineer on Chrome as well.

— Thanks Natalia. And welcome everyone. I know that currently AI is in everyone’s mind, but today’s topic what we cover is authentication. Uh thank you for staying in the room uh because we believe that authentication is still a very, very important topic to cover. And we’re not only going to cover authentication for human user, but also for the evolving agentic web AI agents as well. And authentication is the gateway into your entire application. And the experience often accounts for the first impression about your solution. And as for AI agent, we will see how much exactly agentic experience builds on top of authentication later in this session.

— But first, let’s focus on the most important thing. Human user experience. Imagine a website where the first thing your user interacts with is a high friction sign up form. 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. But their first impression will be already spoiled.

— And that’s the just the first friction. Um now think of all the other frustration that you might user might face like fishing attacks and also stolen identity. All of those things can happen if you’re still relying on legacy technologies.

— But the good news is that we have some recommendations in place to help you improve the user experience and reduce the security risks. And we’re going to cover these best practices later in this session for you to achieve better results.

— That’s right. My team is working directly with partners to to put these recommendation in practice and it has been really rewarding to see the results that improving with an actual metrics. So by applying these best practices, we have seen for example doubling the sign-in speed and four times higher success rate. For example, Pixiv achieved 99% success in login rates.

— 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 at the uh take a look at the user account life cycle. And let’s not just talk about which technologies are out there. Let’s have a look how they fit in every stage of this user account life cycle. And by user account life cycle here, we mean the following stages. First, your user needs to create an account. Then, sometimes you need to verify user attributes. Uh then, subsequent sign-in experience also matters. And finally, we’ll talk about account recovery. And for every single stage of this account life cycle, we will talk about modern technologies that can improve your user experience at every particular point. And these technologies include passkeys, the email verification protocol, the digital credentials API, FIDO, 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. So, stay with us to learn more.

— And before we dive in, we have a QR code here for a blog post that we cover some of the topics that we’re covering today. So, in case you want to check today’s topic later, you can check from this link.

— And um first, let’s again highlight the goal here. So, as you design your authentication solution, your main goal is to phase out weak and high-friction sign-in methods and enable um simpler, more user-friendly, and more secure methods. And after this session, we hope you’ll be equipped with the knowledge to do so.

— And from here, so let’s dive in with account uh creation, which is one of the first step. And as we have mentioned before, legacy sign-up often act as an immediate hurdle here. A long list of required fields that user needs to type, and if the cognitive load outweighs the perceived benefit, the user likely to bounce. So, you can make a better first impression, and here are some best practices and tips how we can reduce frictions.

— So, uh one thing to address uh that you can do to address this uh problem is considering federated identity. So, federated identity is a mechanism that allows your user to sign up on your site with an account from an identity provider, for example, Google or any other identity provider. And an identity provider as a service is a service uh that the user already has an account with and the user has already shared some account information with this service such as for example email, username, first last name, etc. So, why would you force your user to enter this information on every single site again and again when they can simply request the identity provider to share this information with your web application and it makes it much easier

— for the user.

— And this means your user can skip tedious forms and sign up with a single click. And most importantly, a trusted identity provider has already performed user contact information verification and this means that you won’t have to perform checks like the email verification dance. And the user is more likely to complete the sign up process without context switching. Since identity federation makes it so easy to create an account, you can implement this as a default option for the initial sign up process.

— And um for the identity federation, we recommend the pattern federate then upgrade. It means that we recommend creating a federated account first with a single click, simple and easy, and then immediately prompt your user to create a passkey on this device so that the subsequent sign-ins are even smoother for the user and maybe even enable cross-device sign-in journey.

— If you’re an identity provider, you can make the federated flow even better. Consider using the federated credential management API, FedCM for short, to improve the identity federation flow. So, FedCM allows for one-tap privacy-oriented user experience. Sign in with Google has already transitioned using the FedCM and other identity providers have also enabled these capabilities as well.

— So, while identity federation is the recommended approach, if you really, really need to use those sign-up forms, we recommend helping to enable helping the browser to enable autofill.

— And this is a huge UX improvement. Uh doesn’t require much implementation. You simply need to use descriptive name and ID uh attributes for your form inputs. And most importantly, apply the correct autocomplete values, such as new password or email, to help the browser accurately assist the users.

— 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, such as, for example, the email verification protocol or the auto the passkey from autofill UI. And we will cover these features later in the session.

— But first, let’s talk about data verification, including emails. As we have mentioned before, trusted identity provider has already verified some user data, such as email addresses. But if you rely on sign-up forms, that data you receive isn’t always verified. We recommend verifying that first.

— And email remains one of the primary identifiers for many users and many applications. And understandably so, because email is a stable, cross-platform communication channel that virtually every user relies on. And therefore, email serves as a baseline for, for example, billing or long-term account recovery.

— If your application accepts false or non-existent emails, it can create high friction and silent failure where user never receive critical information. And this leads to immediate churn as user perceive your platform as broken. Furthermore, invalid emails result in high bounce rate that damage your sender reputation and churn higher email service provider fees for message that never you get received.

— And currently, many identity solutions rely on email one-time password or some of them rely on magic links. And the common downside of both of these approaches is the context switch. What do we mean by context switch? 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 conversion killer.

— And also, OTPs remain still vulnerable to phishing. And while magic links point the user to the correct page, email clients usually open a link in an in-app browser, which is separate from where the user is trying to sign in. And this can cause additional confusion and abandonment for the user. And if the user finds an unexpected uh empty cart, for example, after in the checkout process after clicking the magic link, uh that can be also cause a huge issue.

— 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. Um and the email verification protocol allows your web application to obtain a verified email without sending an email at all. And for your user, this means a complete elimination of the wait time and the check your inbox friction. Um the verification flow is completely browser mediated.

— So, how does this work under the hood? It’s a three-way handshake between the email provider and the browser and a special specialized issuer. The email provider can opt in delegated verification authority to an issuer. The issuer holds a first-party authentication cookie that proves the user is logged in and has control over the email. When the user either enters their email or in your app or the browser sends a request to the issuer to verify this email.

— The issuer then checks the authentication cookies, signs a secure digital token, and passes it to the browser. And the browser passes it back to the requesting app. And to enable the email verification protocol on your website, you simply need to annotate your inputs properly. So, and here on the uh screenshot, you can see the latest shape, beautiful, and declarative of the email verification protocol API. So, what you need to do is to simply annotate your email inputs with the 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 um do not forget to include a fresh and nonce value to make sure the request is not intercepted by a malicious party. 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’re already talking about user data verification, there are other important aspect to cover. It’s not always only the contact information to be verified. There are cases where you might need to verify the legal name or the age attributes. Um like their legal name, yeah, age eligibility as well. So, before finalizing account creation, and this is sometimes needed to comply with the local regulations. And digital identity credential API are already available in some regions, and you can use this API for privacy preserving user attributes verifications. So, to understand how this works, let’s first get a high-level overview of the digital credential three-party model. And this includes the following parties. So, one, the issuer, a trusted party that cryptographically signs a credential claim. For example, this can be the organization that issues the driving license. And two, the holder. That’s your user mobile device that stores the signed claim. And third, the verifier. That is the website or the mobile app that requests the proof by the digital credentials API. And the browser mediates the communication between all these three parties.

— And uh here is the screenshot of how it looks for the user on their mobile device. So, um you can request user attributes from a digital credential that is stored in a compatible wallet on a user’s mobile device by calling the digital credentials API. So, in this case, the browser and the uh operating system of the user’s device will work together to facilitate the communication between the browser and between the apps or wallets installed on the user’s, let’s say, phone. Um then the verifier will only receive the information that the um the prompt 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 with the issue directly. And speaking of digital credentials in general, we are now observing how this landscape is maturing beyond just government-issued credentials to a more comprehensive verifiable credentials model. And the digital credentials API plays the role of a transport layer here, simply connecting your application to the user’s mobile wallets. 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 on their mobile devices, 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.

— Uh hopefully you can use the digital credentials API to buy a beer after this session. Um jokes aside, I think it’s pretty good start uh to cover the technology that can make authentication creation process uh much better. So, let’s move on to the next step. Um what’s awaiting the user after the registration and data verification? Well, I hope the people will sign into your those services again and again. And as you can imagine, a smooth sign-in experience is important because it sets the tone for the entire user journey. So, you probably noticed that there are many different sign-in options nowadays, and that’s a good thing. Different people have different preferences, like people still use passwords, and some people might log in with a federated login, but also with passkeys. Um in this session, we are really strongly recommending to implement passkeys for your services and with it’s because passkeys are an easier and more secure alternative to passwords and OTPs and are fishing resistant. And we see how more and more industry leaders and partners are implementing passkeys and joining the passkeys bandwagon.

— 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 easiest that is possible out there? Well, first let’s take a look that at the fact that you can actually offer passkeys alongside other different options consolidated in a unified UI. So starting from Chrome 148, you can drastically reduce friction using the immediate login dialogue. With this API, the user clicks sign-in button and then the browser instantly presents an immediate login dialogue, which is a clean unified dialogue that simply offers the user their saved credential with a single click.

— And the real magic happens here. Imagine a guest users is trying to use favorite or my orders and for the site to display those information, you need to be signed in. And there’s a implicit sign-in intention behind this click. And when multiple credentials are available for the same account, the browser intelligently selects the best appropriate option. Unlike other passkeys request, if there are no credentials available, the browser will immediately return an error without showing any UI. And your website can then fall back to navigating the user to standard sign-in page.

— And you might be thinking, wait a minute, but what if the user doesn’t yet have passkeys? Uh well, you’re right. Some users still rely on passwords. There are also some browsers that do not yet support the immediate login dialogue. And for you, this means you need a fallback.

— As a best practice, we highly recommend that you cover both sign-in form supporting passwords and passkeys. This is possible when the passkeys form from autofill feature is enabled. When you route user to traditional sign-in page, this feature takes full advantage of the familiar form autofill experience. And when the user focuses on the username field, the browser automatically suggests both passkeys and passwords. Uh this ensures that the users who have passkeys get the streamlined experience today, while you gradually transition those who still rely on passwords only.

— Um so, and speaking of gradually transitioning users to passkeys, what are actually the strategies? When is it best to create a passkey? So, you should prompt your user uh to create a passkey during or right after sign-up. And crucially, before creating a passkey, make sure that the user is who they say they are. Because if their email, for example, has already been leaked, this step will prevent an attacker from creating unauthorized credentials.

— For your existing users, we recommend requesting automatic passkeys creation using conditional create feature. This feature let your website trigger passkey creation without having any user additional prompt. For example, Adidas implemented this with conditional create. And we saw an 8% uplift in passkeys creations.

— And um interesting enough, um some platforms even see uplift in conversion to passkeys by simply notifying the users about the passkeys benefits, like Pixif, who implemented the simple security confirmation screen, and it bumped their passkey adoption rate by 6% among new users.

— And another good practice is to make sure implementation handles failed passkeys creation attempts. If a public key fails to save on your backend, send a signal to the passkey provider with a signal API. We’ll talk about this API later in this section.

— 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. So, do not forget to send an email or an app notification.

— And it’s important that your user experience is consistent, not just in the desktop browser, but across all user devices. To ensure smooth cross-platform experience, you can establish a verified relationship between your website and your mobile app. For your Android app, specify the association using the digital asset links protocol, and don’t forget to update your app manifest file on Android side. This file verifies that your web origin and your native app owned by the same entity, and enables seamless credential sharing. Without it, user who wants to try to log in to the app for the first time, who created the account on the web first, they would not have the password to log in on that app, and vice versa.

— So, and with digital asset links, we’ve covered how to sync your web and mobile applications. Um but what about the applications that span multiple distinct websites? Like, for example, regional sites for uh germany.de or uh an international site.com. Well, as you might know, by design, a passkey is securely tied to a specific domain where it was created. And this uh specific domain is known as the relying party ID. However, if, as we’ve mentioned, your service spans multiple regional sites, you can use the related origin requests to securely share the same passkey across multiple sites that you own. And um to set this up, you need to simply serve a configuration file where you list the domains that you own. 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 uh that is based in a different region. So, make it easier for your users.

— Uh and also, let me uh point out a common pitfall that I have uh seen working with partners. Um we have often seen related origin requests implemented unnecessary for subdomains. And if you’re just sharing passkeys across your subdomains of your service, um save your extra configuration and simply using the main domain as the relying party ID. Uh and that would be the right approach. And since we already covered the cross-site experience, let’s also talk about cross-device experience here as well. There are cases when a user has a passkeys on one device but not on the other. Um with cross-device flow, browser can display a QR code. You might have seen it in the past that the user can scan it and sign in with their other device using the saved passkeys. And this is designed robust as well because this won’t work without a sufficient proximity of the two devices thanks to the Bluetooth technologies.

— Well, but we have also received feedback that scanning a QR code is not necessarily always the most optimal user experience. So, um we’ve taken this feedback into consideration and we’ve been exploring um other alternatives. And that’s how we’ve came up with the idea of NFC invocation. And think of this NFC invocation method as um tap-to-pay but for your identity. This is useful in situations when two devices both have NFC and uh you can sign in with a passkey uh from one device where it’s already created on another device where there is no passkey yet by simply tapping this device against the other one. For example, imagine your user is signing in on a game console where well, they haven’t yet created a passkey and they can simply tap their phone to share this passkey and sign in.

— And here’s another piece of feedback regarding the QR code. When a user has no passkey saved at all and the they got displayed a QR code, the user can get confused and they may have no idea about passkeys and what to do with the QR code. For such cases, there is this cross-device fallback URL extension that you can use that provides the backup link. This URL is the link to your standard sign-in page that the browser offers to open for alternative sign-in flows.

— 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 to check if the user is signing in cross device. And if so, you can prompt the user to create a passkey on that device locally to simplify the next sign in journeys.

— And once your user have passkeys, you need to keep them perfectly in sync. One of the biggest friction points we have seen is deleted passkeys, in other words, ghost passkeys. This happens when a user deletes their account or revokes the device on your website, but the passkey itself is still saved in the password manager. The next time they try to log in, they select the ghost passkey and it just fails. To prevent this, you should use the signal API that we covered a little bit before. It act as a direct line line of communication between your back end and the user’s passkeys provider. If your user tries to log in with a key that no longer exists in your database, you simply send a signal that the password manager hides or deletes that. You can also use the signal API to keep the user data such as email and name fresh. And here you can see example how Pixiv handles the passkeys deletion process using the signal API to ensure that the passkey stay synced.

— And let’s talk about another essential component of a great user experience. You want to give control over passkeys to your users. And here’s how you can do that. So, first, your user should be able to create multiple passkeys. This is crucial for potential future account recovery. It’s also a good practice to offer your users a dedicated page where they can manage all their passkeys. For example, you can integrate this page already into your existing password management pages where the users expect to manage their passwords or maybe two-factor authentications.

— To make sure UI truly helpful, the API provides metadata that lets you display exactly where each passkey lives, like showing the Google Password Manager logo or the Bitwarden logo next to it. You can also check the backup eligible status. This allows you to clearly tell the user whether specific passkey safely syncs across their devices in the cloud or if it’s tied strictly to the current device or not. So, when prompting user to create a passkey, you are in fact not limited to using the device. You can also use the external hardware like physical security USB keys, and your power user will appreciate the flexibility to choose the to set up they prefer. So, we recommend adding this option as well in the passkey management page as well.

— And that’s how you build a good sign-in user experience. And here we are at the next stage of the user account life cycle. We are going to cover things that you need to know about account recovery.

— You might be thinking what happens if the user loses their device or even deletes the passkeys. Don’t panic. Don’t worry. We have recommendation in place today to help you user access or recover their account.

— And we’ve talked before about how passkeys are synchronized and end-to-end encrypted. This means that if your user loses their device that has a passkey saved, that’s not yet a tragedy because they can um simply sign in on the other device and sign in to their um passkey manager, for example, Google password manager, and their key is securely stored there. So, uh the user can uh sign in into to the Google account, uh provide their Android uh lock or their Google password manager PIN, and access their synced passkeys. And for your application, this means that they can still access it seamlessly.

— Right. And this is not only for Google. Other password manager also supports this synchronization and end-to-end encryption.

— And if the user loses access to all their passkey-enabled devices, well, you can still fall back to verified attributes that we’ve covered before. For example, you can let the user sign in with the same original federated account that they’ve signed up with, 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. And overall, we recommend diversifying the recovery methods. For example, try to encourage your users to use different providers for passkeys 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.

— And with this method, you can always help your user restore access to your application. But before you roll out all of these recommendations and new passkeys experience, testing is very crucial. And Chrome DevTools now has a fantastic building support that allows you to simulate virtual authenticator. You can even emulate physical USB security keys right in your browser. Without needing the actual hardware on your desk. For automation, there are even frameworks that fully supports this end-to-end testing flows. For example, Selenium. We’re also introducing new JSON serialization methods. This make it infinitely easier to parse passkey credential data back and forth between your front end and your server, saving from without custom parsing logic. So, that’s what we wanted to cover and highlight about testing your solution. And now, do you remember how we started this session at the very beginning? Authentication experience is actually foundation for agentic experience as well. So, up until now, we have talked about the identity for purely human experience, but the definition of user ex- is expanding. The ecosystem is moving rapidly in the direction of agentic web. And you’ll soon need to tailor your site and services of the identity solution for new type of user, autonomous agents. So, these agents act on behalf of your user, complete tasks like booking the trips or managing subscriptions. And if a agent can’t recognize the identity elements of your application, you may be blocking the tools your user want to use.

— Uh and we might not have enough time to cover it all, but uh long story short, the Chrome team is currently experimenting with new improved agentic uh authentication uh discovery. We are experimenting with semantics and annotation and new elements to help the agent discover such user journeys on your application as, let’s say, login or federated login.

— Yeah, also quickly covering another AI-powered feature, which is the automatic password change that has been launched last year. Um so, it helps user quickly update password found in public data breaches for Chrome desktop users. And when a user sign in to support website using compromised password, Google password manager may offer to change it for them. If they accept, the automated password change process starts like this. And to help browser enable the feature, provide your password change URL in the well-known file. And it also general recommendation to annotate your inputs with autocomplete attributes to improve auto auto fill accuracy, enable password generation, and also enable this feature like automated password change.

— And just like you can help your agents discover or users agents discover login 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 text text specific skills that will help you to develop a great identity solution and follow all the best practices that we’ve covered today.

— And these were our top recommendation that we wanted to cover today. And we have we covered the best practice for every stage of the account life cycle. Now you know how to reduce user friction during the account creation process using the FedCM and autofill. How to verify user attributes with the new email verification protocol and the digital credentials API. And how to implement passkeys for the best sign-in experience, and how to help the users recover their account. And you also now equipped with the right tools, for example, the modern web guidance that will simplify your development process.

— 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. And here is also a QR QR code that you can scan to read the blog post that also covers the technologies that we’ve talked about right now. And thank you from us for this session.

— 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 life cycle an enjoyable experience. Thank you.

— Thank [applause] you.

—