https://github.com/fedidcg/FedCM/issues/429
An extension to the existing FedCM API that allows a website to provide its preference for a streamlined UX (automatically, rather than explicitly, re-authenticating the user) when their users return to them. The API design requires that the preference is only respected for returning users, that is if the user has previously and explicitly granted permission for the Relying Party (RP) and Identity Provider (IdP) communication in the browser through a FedCM call.
https://github.com/w3ctag/design-reviews/issues/813
Pending
Gecko: we have been actively working with Firefox to standardize this API. In general we are aligned on the feature itself. e.g. auto re-authentication can provide streamlined UX without reducing privacy. Meanwhile, there are some open questions about what API is more suitable to achieve this goal. e.g. Firefox proposed to reuse the “mediation mode” in Credential Management API which is a promising direction as well. We will keep evaluating all the proposals and reach an alignment before shipping.
WebKit: No signal for “auto re-authn” yet. Positive for the general FedCM API.
No compatibility risk from an API’s perspective. Auto re-authn is supported by adding a new boolean to the existing FedCM API which is default to false (defaults to the existing behavior).
On cross-browser interoperability, because the Auto re-authn API simply controls a UX preference suggested by the relying party, the UA may choose not to respect it (for example, either across all relying parties or through browser settings) and fallback to the existing sign-in flow that requires an explicit user confirmation.
Overall, this is a small addition to the FedCM API, and as such mostly inherits the interop and compatibility risks from that API. See https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/E9pgS7GEBAAJ for the discussion.
Similar to the FedCM API, we deliberately leave the bulk of the work to the IdP to ensure that minimal RP change is needed (no RP change is needed for IdPs who have already supported similar flow).
This feature, specifically, is one that can be currently controlled by JS SDKs, so we expect activation to have a similar profile as FedCM: immediately enabled to websites (without any redeployment) by IdPs making use of it (by redeploying their JS SDKs).
N/A as this feature is not available on WebView.
To learn whether the new streamlined re-authentication experience performs well with users. We are planning to collect the following data points:
number of successful re-authentication flows,
how often a user may want to terminate the flow,
reasonable time for cooldown
Besides regular FedCM support, we show error messages stating why auto re-authn is unavailable.
No
Similar to FedCM API, we expect the feature to be available on all platforms (Windows, Mac, Linux, ChromeOS and Android) except WebView.
Yes. (we’re still working on making tests behave as intended on WPT.fyi)
chrome://flags/#fedcm-auto-re-authn
True
You can track our progress here:
https://launch.corp.google.com/launch/4229781
M112
https://chromestatus.com/feature/5108344837111808
(Apology for the delay in responding...) I only see M112 listed as a milestone. If this is the beginning of the OT, how many milestones do you intend to support?
thanks,
Mike
LGTM to experiment from 112 to 114 inclusive.
--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACh2XCOZhE%2BZnyUj%3DbM7ELxSZ7O1yn7KKBRpS1R1wNY_3y1O0w%40mail.gmail.com.