Intent to Prototype: FedCM Conditional Mediation

[Chromestatus]

Contact emails

go...@google.com, yi...@chromium.org

Explainer

https://github.com/w3c-fedid/FedCM/issues/694

Specification

https://github.com/w3c-fedid/FedCM/issues/694

Summary

By supporting conditional mediation from the Credential Management API for FedCM, we can enhance autofill capabilities with identity attributes sourced from identity providers via a FedCM conditional request.

Blink component

Blink>Identity>FedCM

Web Feature ID

fedcm

Motivation

Input fields configured with autocomplete='webauthn' currently support Passkey's conditional mediation. Because users may also create accounts using federated credentials, exploring the augmentation of credential autofill with federated accounts presents an opportunity to mitigate account duplication.

Initial public proposal

https://github.com/w3c-fedid/FedCM/issues/694

Requires code in //chrome?

True

Tracking bug

https://crbug.com/410533051

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6471145475538944?gate=5701923141058560

This intent message was generated by Chrome Platform Status.

[Yi Gu]

Thanks Pâris for your feedback!

Previously we sent out an I2P for delegated FedCM and landed some relevant patches. As mentioned in that I2P, some components could be beneficial to the web as standalone features so we have been thinking to decouple them from the initial I2P. Regrettably the explainer I linked in this I2P does include obsolete information. I'll update it with the suggestions and ping the thread when that's done.

Yi

On Thu, Nov 20, 2025 at 4:44 AM Pâris Meuleman <pmeu...@chromium.org> wrote:

Hello,

Unless I'm missing something, the linked "specification" (Issue #694) for FedCM Conditional Mediation is too vague for a security review.

Please provide a clear spec that consolidates the feature's behavior, specifically  addressing:

1. Trust & Verification: Are the attributes used to fill inputs (e.g., email) considered verified by the IdP? If so, how does the browser and RP verify them (e.g., claims check, origin match) to ensure they can be trusted (potentially replacing site-level verification)?

2. IdP Calls & Timing: When are calls made to the IdP? Does the FedCM exchange complete before or after the autofill suggestion is displayed?

3. Data Communication: How is the verified data communicated back to the website (e.g., Promise resolve, HTMLInputElement value update)?

I see there was already some prototyping back in April? crrev.com/c/6393877

Thanks, Paris (Security Reviewer)

[Pâris Meuleman]

Hello,

Unless I'm missing something, the linked "specification" (Issue #694) for FedCM Conditional Mediation is too vague for a security review.

Please provide a clear spec that consolidates the feature's behavior, specifically  addressing:

1. Trust & Verification: Are the attributes used to fill inputs (e.g., email) considered verified by the IdP? If so, how does the browser and RP verify them (e.g., claims check, origin match) to ensure they can be trusted (potentially replacing site-level verification)?

2. IdP Calls & Timing: When are calls made to the IdP? Does the FedCM exchange complete before or after the autofill suggestion is displayed?

3. Data Communication: How is the verified data communicated back to the website (e.g., Promise resolve, HTMLInputElement value update)?

I see there was already some prototyping back in April? crrev.com/c/6393877

Thanks, Paris (Security Reviewer)

On Thursday, November 13, 2025 at 1:02:26 AM UTC+1 Chromestatus wrote: