LGTM3 to ship and deprecate (but not yet remove). On Fri, Oct 24, 2025 at 8:36 AM Mike Taylor <[email protected]> wrote:
> LGTM2 > On 10/23/25 3:43 p.m., Vladimir Levin wrote: > > 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/a4fa2612-b996-4457-864f-d7a0704381ce%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a4fa2612-b996-4457-864f-d7a0704381ce%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/CAFUtAY9qQH2yAuGWqmc1io94cdcjek3xBmZicTtniX3CEtcdew%40mail.gmail.com.
