Intent to Ship: FedCM nonce param and error attribute rename

[suresh potti]

Contact emails

sures...@microsoft.com

Specification

https://github.com/w3c-fedid/FedCM/pull/768 

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 Plan
Chrome 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 Plan
Chrome 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

Web Feature ID

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.

Gecko: No signal

WebKit: No signal

Web developers: Supportive, comments from Ben Vandersloot in 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?

Yes
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

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

On 10/17/25 10:39 a.m., suresh potti wrote:

Contact emails

sures...@microsoft.com Specification

https://github.com/w3c-fedid/FedCM/pull/768 

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 Plan Chrome 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 Plan Chrome 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

Web Feature ID

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 signal WebKit: No signal Web developers: Supportive, comments from Ben Vandersloot in 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?

Yes 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

This intent message was generated by Chrome Platform Status.

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3dffeb38-f53f-4e49-90e6-3fefc96ea32an%40chromium.org.

[Nicolás Peña Moreno]

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.

[Vladimir Levin]

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

[Nicolás Peña Moreno]

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?

[Vladimir Levin]

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). 

[Nicolás Peña Moreno]

Ok, sounds good. Requesting lgtms for the warning phase then. Will we need a separate chromestatus later to request approval for the enforcement phase?

[Vladimir Levin]

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

[Mike Taylor]

LGTM2

[Rick Byers]

LGTM3 to ship and deprecate (but not yet remove).

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a4fa2612-b996-4457-864f-d7a0704381ce%40chromium.org.