(Google internal. See tracking bug for implementation and GitHub PR for specification)
This entry covers a few incremental extensions to the FedCM API:
With LoginHint, the RP can specify a hint about the user account they want displayed in the FedCM UI. Accounts which do not match the hint are not displayed. This is mainly used to provide a better UX for returning users and is a feature supported by OpenID.
The UserInfo extension allows the IdP to personalize the login experience for returning users, for instance via personalized sign-in buttons. After the user has used FedCM with a given IdP on some RP site, this API fetches the user accounts from the IdP and returns basic information like name, email, and picture from the response to an IdP iframe on subsequent visits to the RP.
With the context parameter, the IdP can request for the FedCM dialog to show a different title than “Sign in”, to improve the message being displayed to the user in the FedCM UI (alternatives currently include “Sign up”, “Continue” and “Use”).
These are extensions to the FedCM API. Apple and Mozilla have both expressed a positive opinion on the initial FedCM API. They have not yet been implemented but Mozilla is prototyping. If a user agent chooses not to implement these extensions, it will limit the quality of the UI that it can provide to users, but should not break the FedCM flow. LoginHint not being implemented means that all available accounts are shown, not just the one that the RP wants to display. Context not being implemented means that the user agent shows the default UI. And UserInfo not being implemented means that the IDP cannot show personalized buttons, but they would fallback to the generic ones. Given that Mozilla has also expressed a positive position for the extensions in this Intent (see below), we do not anticipate interop issues.
Gecko: Positive For incremental improvements to FedCM, Firefox has asked us not to file standards position, and they will instead provide feedback in the GitHub PR. Their LGTM on the PR is thus considered as a positive signal.
WebKit: No signal
Web developers: Positive These features are being developed to address existing use-cases which will not be possible once third-party cookies are phased out.
No new ergonomics risks.
No new activation risks.
Context API has no security risks. For LoginHint API, it is important that the user agent treats no-match the same way as receiving an empty accounts list. For UserInfo API, it can only be called from within the IdP’s same-origin <iframes>, but still our developer documentation will point out to identity providers that they need to be careful when using this API in order to not accidentally leak information to relying parties through postMessage.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
N/A as this feature is not available on WebView.
We added console errors
No: all except WebView
#fedcm-login-hint, #fedcm-rp-context, and #fedcm-user-info
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
This intent message was generated by Chrome Platform Status.
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/00000000000091d33205fe18c70b%40google.com.