Hi everyone, Thank you for the analysis and the breakdown. If Google's requirements can be fully satisfied using only Tier 2 (Foreground restoration upon app launch), I have no objections to leaving the cordova-android core as-is. If we choose an implementation using onload=true and pluginInitialize, we would anticipate certain challenges such as passing the retrieved credentials to the Web layer (especially when using Web Storage) and handling the initialization wait time. However, I assume these can be resolved on the plugin side using custom events, or alternatively, by simply calling the plugin immediately after the Web app launches. Furthermore, if no framework customization is required, I believe there is no need for Apache Cordova to provide an official plugin, and leaving it to the community should be sufficient. Best regards, TAICHI ________________________________
2026/10/13 22:37、Norman Breau via dev <[email protected]>のメール: Alrighty, I haven't tried an actual implementation yet but high-level research, I believe there is no changes required by the Cordova-Android framework. There are two phases in this system: Phase 1) Restore Key creation and Phase 2) Restore Key Consumption Phase 1 occurs after the user is signed in, and involves the user to do the following steps: 1. App code calls on app's relying server to produce a registration challenge. Server saves and returns this challenge. 2. App code receives challenge and passes them to the native credential manager (via a cordova plugin bridge). 3. credential manager creates a keypair and returns a "WebAuthn" json object which contains a public key, and other challenge details. 4. App code sends the "WebAuthn" back to the app server for the server to verify the registration, it checks the origin against the app signing cert and ensure everything matches. 5. App is completely "registered" for restore key. On phase 2, to restore auth after a device-to-device migration, the credential manager data is already copied by the time the app will launch, so on app launch, it is the app's responsibility to determine if a restore key is available, if the user is not already logged in. So the steps would look something like: 1. The app code determines using the restore key is available and necessary 2. App code calls on app server to create an auth challenge. 3. App code passes auth challenge to credential manager via plugin, so that it can sign with its private key and returns the assertion back to app code. 4. App code sends the assertion to the server for verification and then returns the authenticated response (whatever what is necessary to sign the user in). Both the registration and consumption flows are primarily app-driven with the plugin only to bridge the native credential manager calls. All networking calls are app-side. There is a BackupAgent.onRestoreFinished hook that is relevant to the restore process, but only for apps that needs to launch immediately and runs in the background -- so that doesn't really pertain to webview apps since webviews/UI cannot run in the background. I do have plans on building a credential manager plugin if I can't find any existing one -- but only after the new year. On 2026-10-12 1:15 a.m., Norman Breau via dev wrote: In an earlier message I said I'll try to look into this deeper on Monday, but Monday is a holiday in my area, so it will actually be Tuesday. And it sounds like the scope will just make sure it is **possible** for a community/third-party plugin implementation. And if something is blocking that implementation, then we can analyze what is required by the framework in order to support restore keys. On 2026-10-10 6:26 p.m., Jesse wrote: Hello friends! My gut tells me that just like Cordova does not handle logins, Cordova should not handle this ... If an app requires a server then the server can handle storing session state along with authentication. It might make sense to document how this could be done, but personally I don't think code to support it belongs in Cordova, even as a plugin. Cheers, Jesse On Sat, Oct 10, 2026 at 7:14 AM Norman Breau via dev <[email protected]> wrote: I also haven't had a good chance to look at the implementation details, I'll try to do that on Monday so that I can have a better understanding the implications on implementation, end-to-end. If it requires setup in the early stages of the android lifecycle, then we will probably need some bits changed to support that I think in the core framework. Plugins are only instantiated I believe well after the webview has been created, with a few exceptions to core plugins (code that is implemented as plugins but are bundled with the core platform). I do understand that using the restore credentials API involves an app server delivering a restore key. That means there will be some level of app developer integration regardless, as the app developer would need to add a "FIDO-compliant" server-side API for the app to receive an restore key. The server-side part is definitely out of scope of what Apache can provide and the library choices available to the app developer would ultimately depend on their server stack. I'm sure there implementations available for the common server stacks. I agree that compliance aspect of this is what makes this problem unique, but if Apache offers any builtin solution, it would definitely only be the client side piece. On 2026-10-10 10:14 a.m., 佐藤 泰知 wrote: Hi, I’d like to share my thoughts on how Apache Cordova should approach this new requirement. # Opinion I believe this feature should be provided as a plugin rather than being integrated directly into the core framework. However, considering the native lifecycle constraints, a completely standalone third-party plugin might face heavy limitations. My intuition suggests that a hybrid approach—where we add minimal extension points/hooks to cordova-android (core) and pair it with a new official or community plugin—would be the most realistic way forward. # Reasons I would like to divide my arguments into two distinct points: why it should not be in the core, and why we should provide a plugin solution rather than leaving it entirely to the community. [Why it should NOT be in the core] 1. Sign-In-Free Apps: Google's "Zero-Tap Sign-In" mandate applies only to apps that support a user sign-in flow. We should not force unnecessary core-level dependencies or background processes onto simple apps that do not require any login functionality. 2. Difference from Web Standards: While the Web has the Credential Management API (navigator.credentials), the Android Restore Credentials API is an OS-specific mechanism tied tightly to device migration. Its behavior and secure system storage are different from standard web-based passkey/authentication flows, making it inappropriate to integrate as a standard feature in the Cordova core. [Why Apache Cordova should provide a plugin solution (rather than leaving it entirely to the community)] 1. Infeasibility of standard community plugins: As detailed below, I am concerned that trying to implement this feature entirely through a regular community plugin—without making any modifications to the core framework—will result in an impossible or broken architecture due to native OS constraints. 2. Developer Needs: This is a platform compliance task rather than core business logic. Developers do not want to spend extensive development resources figuring this out; they want an environment where they can satisfy the requirement simply by installing an official or well-supported plugin. # Implementation Concerns & Technical Questions I have only had a quick look at the documentation, so I haven't been able to deeply consider the implementation at a code level yet. These are just my intuitive concerns, so please let me know if I am missing something or misunderstanding the official specifications. 1. The Challenge of Background Timing (Tier 1): According to Google's official documentation on the Two-Tier Restoration Architecture, this API is designed around a two-tier flow. Crucially, "Tier 1" must be executed in the background—specifically within the BackupAgent.onRestoreFinished() callback—BEFORE the user ever opens the app on the new device. (Ref: https://developer.android.com/agents/skills/identity/restore-credentials/skill#two-tier_restoration_architecture ) 2. Mismatch with Cordova's Lifecycle (onload="true" concern): At this "before the app opens" stage, neither the Cordova WebView nor the JavaScript environment is running. My concern is that even if a plugin sets in its plugin.xml, that only instantiates the Java class AFTER the WebView initializes. Therefore, standard plugin initialization will likely be completely too late for the Tier 1 timing. 3. Question for Everyone: If this intuition is correct, it will be extremely difficult to make this work properly with a completely isolated, standalone community plugin. It seems we might need cordova-android (core) to provide a base mechanism or hooks to catch native events like BackupAgent and delegate them to a plugin. Please let me know if my assumptions are wrong, or if you have any thoughts on how we can address this native lifecycle issue. Best regards, TAICHI ------------------------------------------------------------------------ 2026/10/10 17:28、Dave Alden <[email protected]>のメール: Hi, I had a quick look into this and some of the Android Restore Credentials API documentation implies that a backend is involved: e.g. https://developer.android.com/agents/skills/identity/restore-credentials/skill I'm not clear from the documentation whether this is a requirement or advisory, but this should be a consideration. On Fri, Oct 9, 2026 at 10:09 PM Norman Breau via dev <[email protected]> wrote: Hi all, This is to start a discussion thread and hopefully to develop a formal consensus on how Apache Cordova should handle the upcoming requirement regarding zero-tap sign in. If you're not already familiar, Google has announced that starting April 2027, apps supporting a user sign-in flow (whether mandatory or optional) must automatically restore the sign-in state when the user migrates the app from one device to another, using the Android Restore Credentials API. The announcement can be found at https://android-developers.googleblog.com/2026/08/app-quality-memory-optimization-secure-onboarding.html near the bottom, under the "Providing a secure & seamless device migration experience" header. Generally when things are add-ons, we leave that to the community to support so that Apache can focus on bridging the gaps in web features and supporting the core platform, and that could probably extend to restore credentials integration as well, because Apache doesn't provide any tools for supporting user sign-in flows either, no apache-maintained API for accessing the encrypted storage mechanism to store access tokens, but users **could** get by with using web storage. User sign-in flows is something that is very common requirement in many apps so that begs the question and I believe will start requiring app integration. So that begs the question on: 1) Whether Apache Cordova should provide a Restore Credentials Solution 2), and if so, should the solution be part of the core android framework or be a separate plugin to be installed. Or should the community take responsibility of providing the Restore Credentials integration. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
