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]
