Hey, yes you will need a separate chromestatus entry for the removal
(enforcement phase).
LGTM1 for the new location of the parameter, new error name, and
deprecating old location of the parameter and old error name
(everything up to and including the warning phase)
Thanks,
Vlad
On Wed, Oct 22, 2025 at 6:33 PM Nicolás Peña Moreno <[email protected]>
wrote:
Ok, sounds good. Requesting lgtms for the warning phase then. Will
we need a separate chromestatus later to request approval for the
enforcement phase?
On Wed, Oct 22, 2025 at 4:03 PM Vladimir Levin
<[email protected]> wrote:
Yes, that would be the plan. This intent when approved would
cover both new nonce parameter and the error rename up to and
including the "warning phase". A separate intent will be
required for the "enforcement phase" (one intent for both
error rename and nonce parameter).
On Wed, Oct 22, 2025 at 12:42 PM Nicolás Peña Moreno
<[email protected]> wrote:
To clarify, are we approved for what we called the warning
phase for both the nonce parameter and the error rename?
Then, we'd send a separate intent for the enforcement
phase for both of these, with data showing usage drop. Is
that correct?
On Wed, Oct 22, 2025 at 11:22 AM Vladimir Levin
<[email protected]> wrote:
We discussed this at API owners:
The general sense is that this intent may be doing too
many things.
We're happy to approve this intent as shipping the new
location for the parameter and deprecating the old
location (with a warning).
However, we also believe that the removal (in Chrome
145) has to be a separate intent to remove requiring
separate approvals. For the removal, we would want to
see stats to see that the usage is dropping due to
deprecation low enough that the risk of removal is
acceptable.
Does that sound like a reasonable path forward?
Thanks,
Vlad
On Monday, October 20, 2025 at 2:17:27 PM UTC-4
[email protected] wrote:
Responding for Suresh since he's OOO this week.
For breakage, we already have UKM metrics for any
UI breakage (the error API usage from the IDP side
may cause the UI to look differently when some
error occurs). I noticed we don't have metrics on
the JS getter side, so we will add those since the
RP side can also break with this change. We plan
to have outreach publicly through our devrel
channels and also talking to the few IDPs that use
the error API. Since FedCM use mainly happens
through SDKs, we're confident that the combination
of public announcement plus IDP outreach will
sufficiently mitigate the breakage, even if we
find that today the number of sites using this is
currently high.
On Friday, October 17, 2025 at 12:59:49 PM UTC-4
[email protected] wrote:
On 10/17/25 10:39 a.m., suresh potti wrote:
Contact emails
[email protected]
https://github.com/w3c-fedid/FedCM/pull/768
<https://github.com/w3c-fedid/FedCM/pull/768>
https://github.com/w3c-fedid/FedCM/pull/498
<https://github.com/w3c-fedid/FedCM/pull/498>
Summary
Migration of nonce to params Field:The nonce
parameter in navigator.credentials.get() is
moving from a top-level field to the params
object for better API design, extensibility,
and maintainability. This structured approach
simplifies parsing for Identity Providers,
supports future-proofing without versioning,
and aligns with modern API patterns. For
Relying Parties, the impact is minimal—they
provide the same nonce value in a new
location.Migration PlanChrome will enforce
this rule in two phases:Chrome 143 (Warning
Phase):nonce accepted both at top level and
inside params. Top-level usage triggers a
console warning.Chrome 145 (Enforcement
Phase):Top-level nonce removed; must be
passed within params.Rename code to error in
IdentityCredentialError:The code attribute in
IdentityCredentialError is renamed to error
for clearer semantics, better developer
experience, and alignment with web standards.
This change reduces ambiguity and avoids
conflicts with DOMException.code.
Additionally, error.code becomes error.error,
retaining its DOMString type.Migration
PlanChrome will enforce this rule in two
phases:Chrome 143 (Warning Phase):Both error
and code attributes are supported. Using code
triggers a console warning, guiding
developers to migrate.Chrome 145 (Enforcement
Phase): Attribute code will be removed, only
attribute error remains. Update code before
this version to prevent breakage.Blink component
Blink>Identity>FedCM<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EIdentity%3EFedCM%22>
Web Feature ID
fedcm<https://webstatus.dev/features/fedcm>
TAG review
None
Risks
Interoperability and Compatibility
Chrome 143 allows old and new patterns with
warnings. By Chrome 145, top-level nonce and
code attributes are removed, requiring params
for nonce and error for
IdentityCredentialError. Failure to migrate
breaks authentication and error handling,
runtime issues, and degraded user experience.
Can you say more about the expected impact
here? The severity of breakage sounds pretty
high - do we have a sense of how many sites
will be affected, etc?
Gecko: No signalWebKit: No signalWeb
developers: Supportive, comments from Ben
Vandersloot in
https://github.com/w3c-fedid/meetings/blob/main/2025/2025-07-08-FedCM-notes.md<https://github.com/w3c-fedid/meetings/blob/main/2025/2025-07-08-FedCM-notes.md>WebView
application risks
FedCM does not work in WebView.
Ongoing technical constraints
None
Debuggability
Same as other FedCM features. The network
view in devtools would be especially helpful
for debugging this feature.
Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux,
ChromeOS, Android, and Android WebView)?
NoFedCM in general is not supported on
webview. Supported on all other blink platforms.
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yeshttps://wpt.fyi/results/fedcm/fedcm-error-attribute?label=experimental&label=master<https://wpt.fyi/results/fedcm/fedcm-error-attribute?label=experimental&label=master>
Flag name on about://flags
fedcm-nonce-in-params, fedcm-error-attribute
Finch feature name
FedCmNonceInParams, FedCmErrorAttribute
Requires code in //chrome?
False
Estimated milestones
Shipping on desktop
145
Shipping on Android
145
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5124072820310016<https://chromestatus.com/feature/5124072820310016>
This intent message was generated by Chrome
Platform Status <https://chromestatus.com/>.
--
You received this message because you are
subscribed to the Google Groups "blink-dev"
group.
To unsubscribe from this group and stop
receiving emails from it, send an email to
[email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3dffeb38-f53f-4e49-90e6-3fefc96ea32an%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3dffeb38-f53f-4e49-90e6-3fefc96ea32an%40chromium.org?utm_medium=email&utm_source=footer>.
