# Delivering seamless sign in and digital credentials on Android - Speakers: Chiping Yeh (Developer Relations Engineer), Tom Colvin (CTO, Apptaura) - Track: Apps foundation - Video: https://www.youtube.com/watch?v=YqdfIR7NUl0 - Page: https://developer.android.com/events/dev-summit/talks/delivering-seamless-sign-in-and-digital-credentials-on-android ## About the talk As the industry moves away from passwords and physical wallets, delivering a modern user journey demands both seamless authentication and trusted identity verification. While passkeys establish secure one tap logins, switching devices remains one of the largest drop off points in user engagement. Learn how to reduce migration friction using the Restore Credentials API to meet the new Google Play Zero Tap Sign In standard. This session explores how a single integration with Android Credential Manager unifies passkeys, silent device restoration, and Digital Credentials, allowing you to verify identity attributes directly from the device and build an effortless, secure onboarding flow. ## Summary - Jetpack Credential Manager provides a unified API for passkeys and passwords. It handles the authentication interface and cryptographic operations without developers needing to write UI code. - Conditional Create lets apps upgrade password users to passkeys silently in the background after a successful password autofill. This opportunistically generates and stores a passkey without interrupting the user. - Google Play will require zero-tap sign-in by April 2027 to maintain full publishing capabilities. Apps can meet this requirement by generating a restore key using the Restore Credentials API. - The Digital Credentials API coordinates exchanges between credential holders and verifiers. Holders retain sharing control, while credential payloads stay end-to-end encrypted and inaccessible to Google. - Email and phone number verification replace one-time passwords and magic links with verified digital credentials. Users give consent directly in the Credential Manager bottom sheet without leaving your app. ## Skills - [Restore Credentials skill](https://goo.gle/restore-credentials-skill) ## Resources - [Android passkey demo code](https://goo.gle/android-passkey-demo) - [Android identity code samples](https://goo.gle/android-identity-samples) - [Zero-tap restoration guide and policy](https://goo.gle/zero-tap-restoration) - [Digital Credentials sample app](https://goo.gle/digital-credentials-sample) ## Topics android, credential-manager, passkeys, restore-credentials, digital-credentials, authentication ## Transcript ### Introduction and passkey overview [00:05](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=5s) Hello, everyone. [00:07](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=7s) Thank you for joining us today. [00:09](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=9s) Today, we're excited to talk about the future of authentication and digital identity. [00:15](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=15s) So, I'm Tom Colvin. [00:15](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=15s) I'm CTO of Apptaura, and I'm a GDE on Android, and I'm joined by Chiping Yeh, who is a senior Android Developer Relations Engineer at Google. [00:26](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=26s) The venerable password is dead. [00:30](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=30s) Or, at least, it should be. [00:32](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=32s) I'm going to talk to you today about a passwordless world. [00:37](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=37s) Passwords are a well-known vulnerability in our security infrastructure. [00:42](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=42s) Even when they're securely stored, they're vulnerable to phishing, to server breaches, and automated attacks like credential stuffing. [00:49](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=49s) As an industry, we've tried to address this by enforcing complexity: special characters, numbers, mandatory rotations. [00:58](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=58s) Evidence shows that this has failed, partly because the more difficult you make it, the more you, paradoxically, encourage insecure behavior. [01:09](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=69s) Because a complex password that's changed regularly is one that's likely to be written on a sticky note. [01:16](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=76s) And even SMS-based two-factor authentication has proven vulnerable to interception like SIM swapping. [01:25](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=85s) Today, though, this problem is largely solved. [01:29](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=89s) Passkeys are the-- built on FIDO standards and use public-private key cryptography. [01:34](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=94s) They're highly resistant to phishing, aren't exposed in a server breach, and are tied directly to the user's phone security via screen lock, which, in most cases, is based on our biometrics, fingerprints, etc. And they actively improve user experience with unified experience across platforms and no need to remember complex passwords. [02:00](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=120s) Our manifesto today is simple. [02:03](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=123s) It's time to move to a passwordless world. ### Jetpack Credential Manager and passkey implementation [02:07](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=127s) And the tools to do it are already in our hands. [02:11](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=131s) Central to making this jump on Android, we have Jetpack Credential Manager. [02:16](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=136s) That's supported all the way back to Android 4.4, and with passkeys supported since Android 9, it provides a single, unified API that supports passkeys as well as traditional, authentication like federated sign-in, like, sign in with Google, and including a graceful fallback to passwords if we need it. [02:36](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=156s) You call the Credential Manager API, and it handles the UI to select what authentication method the user wants to see. [02:44](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=164s) It then does the heavy lifting to return the correct cred- credential, securely obtained. [02:52](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=172s) It supports sign-in, sign up, and back up of credentials. [02:57](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=177s) And you can use it to update and delete credentials. [03:00](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=180s) It also helps users move their passwords and passkeys pro- between credential providers in just a few clicks, and no file downloads required. [03:10](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=190s) It's designed to give users complete control over their data and the freedom to switch providers whenever they need to. [03:19](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=199s) And credential pro- Manager supports many form factors including watches, TV, XR, automotive, phones, foldables, tablets. [03:31](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=211s) And, most importantly for us, it has a dedicated flow for passkeys. [03:36](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=216s) Here's what it looks like for the user during sign up. [03:39](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=219s) My app tells the Credential Manager that passkey authentication is available, and it provides it with details gathered from the back-end. [03:47](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=227s) You hit Register, and Credential Manager give manager gives you a bottom sheet with a screen lock prompt. [03:54](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=234s) This is most commonly unlocked with biometrics like fingerprint or face scan. [04:00](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=240s) And Credential Manager then ha- handles the complex cryptography work like actually creating the passkey. [04:07](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=247s) And it saves the passkey to my credential manager, which, in this case, is, Google Password Manager, but it could be something else. [04:16](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=256s) Here's what the code looks like. ```kotlin val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest( requestJson = registerRequestJson ) val createCredentialResponse = credentialManager.createCredential ( context = localActivity, request = createPublicKeyCredentialRequest ) ``` [04:18](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=258s) Firstly, we are creating this `createPublicKeyCredentialRequest` object using the details of the back-end provides, that's this `registerRequestJson`. [04:30](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=270s) Then, we call the magic method, `credentialManager.createCredential`. [04:34](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=274s) We pass in that request and the local context, which allows it to show the UI. [04:40](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=280s) Notice, by the way, that I haven't had to write any UI code whatsoever here. [04:47](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=287s) Credential Manager takes care of that entirely for us. [04:51](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=291s) Now, this is the sign-in process. [04:53](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=293s) For the user, it looks remarkably like the sign up process. [04:57](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=297s) There's one unlock prompt, and you're done. [05:01](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=301s) For developers, only slightly different. ```kotlin val getPublicKeyCredentialOption = GetPublicKeyCredentialOption( requestJson = authenticationRequestJson ) val signInRequest = GetCredentialRequest(listOf(getPublicKeyCredentialOption)) val result = credentialManager.getCredential ( context = localActivity, request = signInRequest ) ``` [05:04](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=304s) First, we get the details of the sign in from the back-end to build a GetPublicKeyCredential instance. [05:10](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=310s) We tell the Credential Manager what types of credentials we support. [05:14](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=314s) Here it's just passkeys. [05:16](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=316s) But we can add other types of credential, too, if we want to. [05:20](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=320s) Then we call `credentialManager.getCredential` passing in that list of credentials that we've just requested. [05:27](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=327s) Again, no UI code. [05:29](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=329s) No need to write any UI code. [05:31](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=331s) Credential Manager fully takes care of that for us. [05:35](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=335s) It nudges the user towards the most frequ-- frequently used option leaving the other others available as a backup. [05:44](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=344s) That automatically solves one of today's most annoying authentication problems. [05:48](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=348s) Did you notice? [05:50](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=350s) That is remembering what method I last used to sign in. [05:55](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=355s) Look, there's the answer neatly presented in a bottom sheet. [06:00](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=360s) That isn't, by the way, just an annoyance for the user. [06:02](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=362s) It's a genuine friction point. [06:04](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=364s) It causes unnecessary account recoveries, and it has commercial impact like abandoned shopping carts. [06:13](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=373s) Here is my demo application code, which you can use to try out Credential Manager for yourself. [06:18](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=378s) And you can see these flows on your own device. [06:21](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=381s) And there is the official Goo-- code code samples on the left. [06:29](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=389s) That handles creating passkeys. [06:32](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=392s) What about upgrading existing password users to passkeys? [06:38](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=398s) Well, a powerful tool for that is Conditional Create. [06:41](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=401s) If your user has just signed in using their password, and it's been autofilled by a supported credential provider, then we know they're actively engaged, and we've freshly verified their identity. [06:54](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=414s) In that case, Conditional Create allows us to request the creation of a passkey automatically in the background. [07:02](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=422s) It doesn't interrupt the user's workflow. [07:04](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=424s) The passw-- the passkey is just silently generated, and it's stored. [07:09](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=429s) Google Password Manager shows a notification to confirm that that's happened. [07:14](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=434s) Other password managers might do different. [07:19](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=439s) The code for Conditional Create looks very much like the code for signing up. ```kotlin val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest( requestJson = registerRequestJson, preferImmediatelyAvailableCredentials = false, isConditional = true ) val createCredentialResponse = credentialManager.createCredential ( context = localActivity, request = createPublicKeyCredentialRequest ) ``` [07:22](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=442s) The magic fla-- flag is `isConditional` true, which ensures that the user doesn't see that UI. [07:30](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=450s) And since it works opportunistically, we will put that in a try-catch. [07:34](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=454s) We will handle any errors silently, so we don't bother the user if the process fails. [07:39](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=459s) Then the passkey is saved to the user's Credential Manager, and it's there for them next time. [07:48](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=468s) Credential Manager also allows credential providers to securely import and export their credentials. [07:54](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=474s) Just a few clicks. [07:55](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=475s) There's no downloads needed. [07:57](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=477s) This gives more flexib-- flexibility, all whilst keeping the information secure. [08:03](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=483s) The flow looks like this. [08:05](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=485s) In their new credential provider, the user requests to import credentials. [08:10](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=490s) Then the Credential Manager handles the import UI, allowing the user to select the source of the credential data. [08:19](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=499s) The exporting credential provider can then provide its own UI, and it allows them to educate the user and provide the relevant warnings. [08:28](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=508s) And finally, the user's new credential provider is given the data via a secure channel. [08:35](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=515s) So it's able to import it without having any user interaction. [08:41](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=521s) But what happens if the user revokes a passkey from their app or their website? [08:48](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=528s) Then the credential provider doesn't necessarily know that that's happened. [08:53](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=533s) The next time they try and sign in, the Credential Manager will offer that dead passkey, and they will just have a rejected attempt. [09:03](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=543s) Likewise, when a user updates their username or display name, a sync is required. [09:10](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=550s) Now with the Signal API, your app can flag these specific states to the credential provider. [09:18](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=558s) Take the case of signing in with a revoked password as an example. [09:22](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=562s) Your app can catch that specific error state and use it to tell the user's credential provider. [09:27](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=567s) The credential provider can then update itself so that that particular passkey isn't offered. [09:38](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=578s) So those are some of the features of Credential Manager, and it's incredibly helpful for getting users to sign up using passkeys and for prioritizing passkeys over other methods when we're signing in. [09:50](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=590s) But remember our ultimate aim here is to go completely passwordless. [09:57](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=597s) How does Credential Manager help with that goal? ### The route to passwordless [10:03](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=603s) Here's our proposed five-step process. [10:05](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=605s) In the first two steps, you upgrade your password users to passkeys. [10:10](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=610s) Firstly, we try opportunistically, using Conditional Create. [10:14](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=614s) Then, if such an opportunity hasn't arisen, we, eventually, are going to need the user's intervention, so in-app invitations asking users to set up passkey. [10:25](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=625s) We can gradually start to show those more and more prominently. [10:29](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=629s) After all, from a user's perspective, they usually just need to provide their screen lock, like biometrics. [10:38](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=638s) Once analytics show that the vast majority of your users have accounts using passkeys, then passkeys can be mandated for all new users. [10:47](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=647s) But those old users, this that's who we deal with in these last three steps. [10:57](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=657s) We encourage passkey users to remove their passwords. [11:02](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=662s) So in step 3, we are allowing them to do this manually, with a very clear Delete Password option in their account settings. [11:11](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=671s) In step 4, we start to push for password deletion, using, for example, in-app notifications, paired with educational copy. [11:20](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=680s) And finally, you switch from password deletion being opt-in to opt-out. [11:27](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=687s) Eventually, even that last opt-out can disappear. [11:31](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=691s) Analytics will give us confidence to remove the password flows from the app altogether. [11:41](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=701s) So, moving to a passwordless world is no longer a theoretical security concept for sometime in the future. [11:48](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=708s) It's highly supported. [11:50](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=710s) The APIs are robust, the user experience is excellent. [11:55](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=715s) I encourage you to start integrating passkey flows with Credential Manager today. [12:00](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=720s) Begin upgrading your users, and let's finally leave passwords in the past. [12:06](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=726s) Thank you. [12:08](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=728s) Now I'd like to hand it over to Chiping to talk about the next evolution in device migration and identity. [12:16](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=736s) Cool. [12:18](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=738s) All right, thank you, Tom. [12:20](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=740s) As Tom highlighted, seamless authentication on user devices is critical. [12:25](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=745s) But what happens when a user gets a new phone? [12:28](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=748s) The biggest drop off in the user journey today often happens when they switch devices. [12:33](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=753s) Today, I want to first talk about how we are solving that and quickly cover an upcoming Play Store requirement around credential restoration. [12:42](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=762s) Starting in April 2027, Google Play will require apps to meet the zero-tap sign-in requirements to maintain full publishing capabilities and optimal visibility in the Play Store. [12:54](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=774s) What is zero-tap sign-in? [12:56](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=776s) Effectively, this means users do not need to manually re-authenticate in your app when transitioning to a new device. [13:04](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=784s) How do we implement this? [13:07](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=787s) The primary method we recommend to do this is through Android's Restore Credentials API via Credential Manager. [13:14](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=794s) This API allows you to generate what's known as a restore key, which is saved on the user's device or in the cloud based on the user's backup settings. [13:24](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=804s) We recommend generating this key in the background once the user is signed in. [13:29](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=809s) In this diagram, we illustrate a user signing in to the app. [13:33](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=813s) Then, the restore key is created while they are using the app at some point. [13:39](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=819s) This key is then stored locally or, if enabled, remotely on the cloud. [13:46](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=826s) When the user sets up their new device, the restore credential is silently transferred over in the background during the device setup process. [13:54](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=834s) Users can choose to restore data from the cloud or device-to-device transfer. [14:00](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=840s) Then, when your app is opened, you can call the Credential Manager API to use this restore key to sign the user in on the new device on their first launch. [14:10](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=850s) This allows the user to quickly and securely log into your app right away. [14:15](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=855s) And if you'd like to have your app restored immediately after setup without being opened, you can implement a custom backup agent to do this. [14:24](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=864s) This will allow the user to log in to your app without manually opening it. ### Case study: Uber [14:30](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=870s) Some of our partners have already implemented this in their app. [14:34](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=874s) Uber is the world's largest ride-sharing company, providing millions of people transportation, while also supporting food delivery, healthcare transportation, and freight logistics. [14:44](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=884s) Simplicity of access is crucial. [14:46](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=886s) And when users switch to a new device, they expect a seamless transition without needing to log back into the Uber app or go through SMS-based one-time authentication every time. [14:56](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=896s) This frequent device turnover presents a challenge for user retention. [15:00](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=900s) Following an assessment of user demand and code prototyping, Uber introduced Restore Credentials support into the Uber Rider app, and the results have been very positive. [15:12](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=912s) They estimate that it will save 4 million average daily logins per day, and they expect this number to increase as adoption grows. [15:24](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=924s) Please see this QR code and link to learn more about this upcoming policy and how your app can meet zero tap restoration requirements. [15:33](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=933s) Again, this will be coming in April of 2027, so please make sure to mark that on your calendars. [15:41](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=941s) And if you'd like a head start in implementing Restore Credentials in your app, please see this QR code and link for access to our Restore Credentials skill. [15:50](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=950s) This skill can be used to help quickly develop or test the feature with your agent of choice. ### Digital credentials and architecture [15:58](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=958s) Now, let's look ahead at the next frontier of digital identity: the Digital Credentials API via Credential Manager. [16:07](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=967s) Let's go over what Digital Credentials are and how they work. [16:12](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=972s) Digital Credentials are cryptographically verifiable digital documents that users can use to provide information about themselves. [16:21](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=981s) These documents are stored within digital holders on a user's device and can be requested by other apps on the device or presented to the world in a hybrid manner, similar, such as through a QR code. [16:34](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=994s) The uses are wide and varied, from verifying identity to accessing services to purchasing items online. [16:42](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1002s) Digital Credentials offer a secure and convenient way to share information without needing physical cards. [16:50](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1010s) Digital Credentials involve three parties: the issuer, the holder, and the verifier. [16:57](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1017s) The life of a digital credential generally flows from left to right. [17:01](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1021s) Let's go over each of these entities and what role they play. [17:06](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1026s) The first is the issuer, which, as the name implies, is a party that issues a credential, just as the government issues your passport. [17:15](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1035s) However, in the digital world, to prevent spoofing, these credentials are also signed by the issuer with their digital certificate, so anyone receiving the credential can know exactly who it's from. [17:27](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1047s) And actually, anyone can be an issuer, whether it's a gym, a hotel, or even yourself. [17:34](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1054s) You just need to make a credential and sign it. [17:39](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1059s) Okay, so the issuer creates and issues credentials, but they need to be stored somewhere, just as how you need to store your government ID in your own wallet. [17:49](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1069s) This is the next party, which is called the holder, which is also commonly described as a digital wallet. [17:56](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1076s) Holders, as the name implies, primarily hold credentials that are issued from issuers. [18:03](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1083s) They reside as an app on your device, and then they can present them to requesting parties. [18:09](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1089s) And similarly to issuers, anyone can be a holder. [18:13](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1093s) In fact, it's not uncommon for issuers and holders to be managed by the same entity. [18:18](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1098s) Think a gym who wants to both create their own digital membership credential and also manage it through their own app. [18:26](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1106s) That would be both an issuer and a holder in one. [18:31](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1111s) Okay, the third party is the verifier, or the party that requests the Digital Credentials. [18:38](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1118s) Verifiers make credential requests usually to check attributes about a user, such as age requirements, or family name, et cetera. [18:46](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1126s) These are the businesses or apps that need additional user data to perform a service, such as purchasing alcohol or verifying a minimum age. [18:58](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1138s) On Android, interactions between these three parties and the user are coordinated through Credential Manager with the Digital Credentials API. [19:07](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1147s) The issuer can call the API to issue credentials to a holder, although this is unnecessary if they're the same entity. [19:13](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1153s) After the credential is issued, a verifier can call an API to request the credential. [19:19](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1159s) Credential Manager matches the request with all available holders and presents them to the user to select the credential and provide consent. [19:29](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1169s) Once a holder is selected, it is invoked and can do additional checks if needed before sharing the credential ultimately with the verifier. [19:38](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1178s) Once the verifier receives the credential, they can also perform various checks on the legitimacy of the credential, including checking the original issuer. [19:48](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1188s) Now, you might be wondering, how are Digital Credentials exactly secure? [19:53](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1193s) Well, there's security actually built into each step of the process, and we'll go through some of them now. [20:01](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1201s) So, on the issuer side, when the issuer wants to share a credential with a holder, it needs to verify that the holder cannot be tampered with or copied, basically that it can be trusted. [20:13](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1213s) How can it verify this? [20:16](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1216s) Well, before an issuer releases the credential, it needs the holder to prove its own identity and security of the device that it's operating on. [20:25](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1225s) The holder sends its wallet attestation, usually as a verifiable certificate chain. [20:31](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1231s) The holder also generates a hardware-bound key pair. [20:34](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1234s) It sends the issuer the public key from this key pair with Android key attestation such as such that the issuer can validate the hardware legitimacy. [20:45](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1245s) The issuer will sign this public key into the issued credential, so that the credential is officially bound to the single device. [20:56](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1256s) On the holder side, once the holder has a new credential, it registers only its credential metadata with Credential Manager. [21:04](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1264s) Credential Manager uses this metadata to determine which holders to show when a verifier makes a credential request. [21:13](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1273s) No real user data is ever registered with Credential Manager or exposed to Google. [21:18](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1278s) And even when Credential Manager is selecting wallets to display to the user, the contents inside of each wallet aren't revealed at that point in time. [21:30](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1290s) Now, when a credential request is made and a user consents to share a credential, the selected holder is invoked and workflow control is handed over to the holder. [21:42](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1302s) As you might remember, a holder is just an app, so the app is invoked. [21:46](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1306s) At this time, the holder can see things such as the requesting verifier and the requested credential, and can decide if it wants to share that credential with that verifier even if the user already gave permission. [22:00](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1320s) The credential data itself is not accessible to Google. [22:03](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1323s) Only the routing metadata is registered, and the payload is end-to-end encrypted between the holder and verifier. [22:09](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1329s) This gives the holder control over which parties it wants to share its credentials with. [22:17](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1337s) Lastly, on the verifier side, after the credential has been requested and the holder shares the credential, the verifier receives the credential presentation from a holder. [22:29](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1349s) Now, the verifier can check if the response was freshly generated by the original credential holder for the request. [22:35](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1355s) It can confirm that the credential response is signed using the holder's device-bound key, including requesting a one-time token and calling origin observed by the holder. [22:46](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1366s) The verifier can also check the authenticity of the credential issuer by verifying the issuer certificate, ensuring it came from a trusted source. [22:55](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1375s) In short, issuers get hardware guarantees, holders get control of which credentials they want to share, verifiers get cryptographic proof of issuer and holder, and then users retain full consent over which data they want to share. [23:12](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1392s) Now that we've covered how Digital Credentials are secure, let's get into some of the use cases of Digital Credentials that are available today through the Digital Credentials API on Android. ### Email and phone verification [23:25](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1405s) The first of these that I'm going to cover is called email verification. [23:30](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1410s) This API takes a user's logged in Gmail directly from their device, and presents it as a Google-verified digital credential to your app, removing the need to send one-time passwords or magic links. [23:44](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1424s) This means the user never leaves your app and only needs to provide consent with one tap to the familiar Credential Manager bottom sheet. [23:53](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1433s) Here's a demo of the here's a demo recording of the API in action. [23:58](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1438s) This is a sample app which implements email verification through the Digital Credentials API. [24:04](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1444s) When I tap on "Request verified email", Credential Manager requests a verified email digital credential from the holders on the device that hold this type of credential. [24:15](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1455s) In this case, only Google is the holder of this verified email credential, which you see displayed in the bottom sheet. [24:22](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1462s) This is one of the emails that the user is logged into on the device. [24:26](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1466s) And, in fact, Google is both the issuer and holder of the digital credential in this case. [24:33](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1473s) Once I select the credential I want to share, it's returned to the app, which currently just displays the fields contained in the credential, which is the verified email. [24:42](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1482s) In your app, you can use this information to proceed to the next app screen, such as creating a passkey or other account creation steps. [24:52](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1492s) For the user, it's really just as simple as giving consent and then moving on to the next screen. [25:01](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1501s) If you'd like to try it out, you can navigate to our GitHub sample and install it on your own device. [25:06](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1506s) Please try to use it on a physical device, and note that you will need to be signed in to at least one Gmail account on your device. [25:11](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1511s) So, I'll give a little bit more time if people are interested. [25:25](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1525s) All right. [25:25](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1525s) Sounds exciting, right? [25:27](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1527s) And when you think of email verification, what's the next form of user verification that comes to mind? [25:31](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1531s) That's right, phone number verification. [25:34](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1534s) The Digital Credentials API also natively supports phone number verification, removing the friction and vulnerability of SMS OTPs. [25:45](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1545s) The way phone number verification works is also through the Digital Credentials API, and in this case, the phone number on the device the phone number on the device is requested and presented as a digital credential. [25:59](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1559s) The user only sees the familiar Credential Manager bottom sheet to share or verify their phone number, staying within the app, and only requiring a few taps to complete verification. [26:12](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1572s) Here, you can see an example app where the customer is able to share their phone number with a single tap, all without leaving the app. [26:21](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1581s) So, how does this setup work? [26:25](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1585s) Well, if we map this to digital credential parties, the issuer, in this case, is the telephone carrier of the phone number on the device SIM card, and the holder is Android Telephony. [26:37](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1597s) When a verifier, such as your app, requests the user's phone number, it is retrieved from Google Telephony with a Digital Credentials API call. [26:46](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1606s) You might be wondering how billing works. [26:48](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1608s) There is an extra step that is unique to this flow, where the credential is passed to your carrier or aggregator for billing purposes. [26:56](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1616s) This happens after the phone number is retrieved from Google Telephony, where it is stored in an encrypted state. [27:03](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1623s) This is then passed to the carrier, which decrypts and returns the phone number to your app's back end directly, during which you are billed. [27:12](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1632s) The great thing about this is that the carrier will only charge you for successful verifications, which are transferred through data or Wi-Fi, and much more reliable than SMS. [27:23](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1643s) Here, we have a demo of the phone number verification in action, using Firebase as the carrier aggregator. [27:32](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1652s) The app asks for a user's phone number as part of the sign-in process. [27:36](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1656s) This user has multiple SIM cards, and chooses one to share with the app. [27:41](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1661s) Once the user confirms their choice, the exchange happens all in the background. [27:46](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1666s) Then, you just see the next screen with the retrieved phone number populated. [27:52](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1672s) The user never had to leave the app, and only had to select and confirm the phone number to share to progress through the flow smoothly, all in a few taps. [28:04](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1684s) Just let this finish so you can see the completion one more time. [28:10](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1690s) And so you see the phone number on that final screen. ### Resources and conclusion [28:16](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1696s) And that's it. [28:17](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1697s) We've covered a lot of ground today. [28:19](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1699s) We first explored using Credential Manager to improve your passkey implementation, and move to a passwordless world. [28:25](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1705s) Please see our resources on Credential Manager and passkeys here to get to learn more and get access to our sample apps. [28:34](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1714s) Next, we covered the upcoming zero-tap sign-in requirement for your apps that makes it seamless for your users to sign in when setting up a new device. [28:42](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1722s) This will be mandated in the Play Store by April 2027, so please note this on your calendars. [28:51](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1731s) Finally, we covered how digital credentials work, and some of their most useful features on Android. [28:56](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1736s) Please see our resources on digital credentials here for a deeper dive into the content and access to our samples. [29:04](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1744s) Everything we've shared today is live and ready for you to build with. [29:10](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1750s) The future of identity on Android is here, and more exciting than ever. [29:15](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1755s) Thank you for your time, and I know it's lunchtime, so please enjoy the food outside. [29:19](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1759s) And don't be afraid to come up to me or to Tom with questions about passkeys or digital credentials. [29:25](https://www.youtube.com/watch?v=YqdfIR7NUl0&t=1765s) Cheers.