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] > >>> > >>> > >
