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/CAAATDinPmOv9nPfuJY5DCXoi5vk0qfnfdpW%3DWxKAVb0BuxWJvw%40mail.gmail.com.
