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] Specification >>>>>> >>>>>> https://github.com/w3c-fedid/FedCM/pull/768 >>>>>> <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 >>>>>> <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 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 >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ? >>>>>> >>>>>> 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 >>>>>> <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> >>>>>> . >>>>>> >>>>>> -- 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/CADsXd2M5VkcLcYjCzSUAdvwyM75vzVqq6pRG9fu2huaoVsAb_Q%40mail.gmail.com.
