Intent to Ship: FedCM extensions: Error API and Auto-Selected Flag API

171 views
Skip to first unread message

Yi Gu

unread,
Oct 23, 2023, 9:03:59 AM10/23/23
to blink-dev

Contact emails

yi...@chromium.org


Explainer

https://github.com/fedidcg/FedCM/issues/488

https://github.com/fedidcg/FedCM/issues/497


Specification

https://github.com/fedidcg/FedCM/pull/498

https://github.com/fedidcg/FedCM/pull/500


Design docs


https://docs.google.com/document/d/1DEjbFSAMmmT47_n8JBLmcleCNPz_WS5a24WDrglSQMo/edit?usp=sharing


Summary

Dedicated APIs to help developers and users to better understand the authentication flow. Both APIs are triggered post user permission to sign in to an RP with an IdP. i.e. after the user clicks the "Continue as" button.


- With Error API, if a user's sign-in attempt fails, the IdP can share the reasons with the browser to keep both users and RP developers updated.

- With AutoSelectedFlag API, both IdP and RP developers could have a better understanding about the sign-in UX, evaluate performance and segment metrics accordingly.



Blink component

Blink>Identity>FedCM


Search tags

fedcm


TAG review

https://github.com/w3ctag/design-reviews/issues/893


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

These are extensions to the FedCM API. Apple and Mozilla have both expressed a positive opinion on the initial FedCM API[1] and Mozilla is currently prototyping the FedCM API. If a user agent chooses to not implement these extensions, it may hurt the quality of the UI that they can provide to users, but should not break the FedCM flow.


Gecko: Under consideration (https://github.com/fedidcg/FedCM/pull/498

https://github.com/fedidcg/FedCM/pull/500) Firefox has asked us not to file standard position, and they provided feedback in the GitHub PR.


WebKit: No signal (https://github.com/WebKit/standards-positions/issues/249)


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.


Other signals:


Security

For the Error API, the browser may open a pop-up window with a URL provided by the IdP when an error happens. It has the same web platform properties as what one would get with window.open(url,””,”popup,noopener,noreferrer”)) that loads the error.url. There's no communication between the website and this pop-up is allowed (e.g. no postMessage, no window.opener). We have also considered the potential phishing risk and had the mitigations in place (see the explainer for more details).



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

FedCM is not supported in WebView



Debuggability

The two new APIs are extensions of the FedCM API which has proper devtools support.


For the Error API, the browser takes an error returned by the IdP (if any) and rejects the promise with an error exception. For RP developers, the only thing that they need to take care of is handling the exception which may not need DevTools support. For IdP developers, the only potentially useful information that we could add to the console is when the error URL is cross-site to the IdP in which case we won't use the error URL in the flow.

For AutoSelectedFlag API, it just introduces a new boolean for both IdP and RP developers to parse. We believe that in this case we don't need to provide extra information in DevTools.



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?


FedCM is available in all Blink platforms except for WebView.



Is this feature fully tested by web-platform-tests?

Yes.

Testing on wpt.fyi is blocked on https://github.com/web-platform-tests/wpt/pull/40709 getting reviewed and merged. Otherwise, we are adding tests that will be in the credential-management directory as shown on the WPT dashboard here: https://wpt.fyi/results/credential-management?label=experimental&label=master&aligned



DevTrial instructions

https://github.com/fedidcg/FedCM/blob/main/explorations/HOWTO-chrome.md


Flag name on chrome://flags

chrome://flags/#fedcm-error

chrome://flags/#fedcm-auto-selected-flag


Finch feature name

FedCmError

FedCmAutoSelectedFlag


Requires code in //chrome?

True


Tracking bug

https://crbug.com/1477253


Launch bug

https://launch.corp.google.com/launch/4273845


Sample links


https://drive.google.com/file/d/1Z8r4OkQMmKulGv-vf-XTfwqh6VUyGZF9/view?usp=sharing


Estimated milestones

Shipping on desktop

120


Shipping on Android

120





Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5384360374566912


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/YfaGM8v-Ocs/m/4E0RHMhJAwAJ


This intent message was generated by Chrome Platform Status.


Yoav Weiss

unread,
Oct 25, 2023, 11:18:57 AM10/25/23
to blink-dev, blink-dev
On Monday, October 23, 2023 at 3:03:59 PM UTC+2 blink-dev wrote:

It'd be useful to write a short (inline?) explainer here outlining what this does and how it'd look like.
Specifically, would we start throwing on errors in scenarios that silently failed before?
 

Similarly a short explainer outlining what this does and how would help reviewing this intent. 
What's preventing these PRs from landing?

Yi Gu

unread,
Oct 25, 2023, 4:14:34 PM10/25/23
to Yoav Weiss, blink-dev
Thanks Yoav for the review!

> It'd be useful to write a short (inline?) explainer here outlining what this does and how it'd look like. Specifically, would we start throwing on errors in scenarios that silently failed before?

For the Error API, it allows IdP to signal to the browser about the sign-in failure details such that the browser can make sure the user is kept informed with possibly next steps. Without this API, when a user clicks the "Continue as Name" button to sign-in, if it fails for whatever reasons, the browser rejects the promise silently so the user could be confused about the status. The fact that we are delaying rejecting the promise (for privacy reasons) would make it worse because the website wouldn't learn about the failure immediately either. With this API, the browser will first show a native UI with proper strings to explain the error to users and possibly allow users to learn more about next steps. It will also reject the promise with the errors (if provided by IdP) via IdentityCredentialError instead of a generic DOMException (which we currently use). You could find more details here.

For the AutoSelected Flag API, it shares whether auto re-authentication has been triggered during the flow with both IdP and RP. By default the CredentialManagement API supports credential auto selection when possible. However, the browser may decide not to trigger auto selection for legitimate reasons. While the exact reason should be opaque to IdP or RP, we could share with them the outcome such that they can better understand the flow and handle things differently. e.g. for metrics purposes they could know how many transactions were done with auto re-authentication to better understand the performance; in addition, an IdP can use the signal (boolean) to support some security related features. e.g. a user may prefer explicitly selecting an account with an IdP, if the IdP gets a token request that shows the account was automatically selected, they could reject the request and trigger a new sign-in flow to ask for explicit user mediation. You could find more details here.

> What's preventing these PRs from landing?

We aligned with Mozilla, who is prototyping FedCM in Firefox right now, that such spec changes should be reviewed by at least two implementers before merging. While we have discussed the two APIs at FedIdCG and it "generally looks reasonable", it's not yet formally reviewed by Mozilla (hence the "Under consideration" signal).

Thanks.
Yi

Mike Taylor

unread,
Oct 25, 2023, 6:51:35 PM10/25/23
to Yi Gu, Yoav Weiss, blink-dev

On 10/25/23 4:14 PM, Yi Gu wrote:

Thanks Yoav for the review!

> It'd be useful to write a short (inline?) explainer here outlining what this does and how it'd look like. Specifically, would we start throwing on errors in scenarios that silently failed before?

For the Error API, it allows IdP to signal to the browser about the sign-in failure details such that the browser can make sure the user is kept informed with possibly next steps. Without this API, when a user clicks the "Continue as Name" button to sign-in, if it fails for whatever reasons, the browser rejects the promise silently so the user could be confused about the status. The fact that we are delaying rejecting the promise (for privacy reasons) would make it worse because the website wouldn't learn about the failure immediately either. With this API, the browser will first show a native UI with proper strings to explain the error to users and possibly allow users to learn more about next steps. It will also reject the promise with the errors (if provided by IdP) via IdentityCredentialError instead of a generic DOMException (which we currently use). You could find more details here.

For the AutoSelected Flag API, it shares whether auto re-authentication has been triggered during the flow with both IdP and RP. By default the CredentialManagement API supports credential auto selection when possible. However, the browser may decide not to trigger auto selection for legitimate reasons. While the exact reason should be opaque to IdP or RP, we could share with them the outcome such that they can better understand the flow and handle things differently. e.g. for metrics purposes they could know how many transactions were done with auto re-authentication to better understand the performance; in addition, an IdP can use the signal (boolean) to support some security related features. e.g. a user may prefer explicitly selecting an account with an IdP, if the IdP gets a token request that shows the account was automatically selected, they could reject the request and trigger a new sign-in flow to ask for explicit user mediation. You could find more details here.

> What's preventing these PRs from landing?

We aligned with Mozilla, who is prototyping FedCM in Firefox right now, that such spec changes should be reviewed by at least two implementers before merging. While we have discussed the two APIs at FedIdCG and it "generally looks reasonable", it's not yet formally reviewed by Mozilla (hence the "Under consideration" signal).
I don't see anyone from Mozilla as a reviewer for either PR - is there a plan to request review from them?
--
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/CACh2XCM8FnGsYjCQhzskrzU4RK9fMvpSBv23VV4Cdtr%2BMj0O2w%40mail.gmail.com.

Yi Gu

unread,
Oct 25, 2023, 7:17:53 PM10/25/23
to Mike Taylor, Yi Gu, Yoav Weiss, blink-dev
We sync’d with @bvandersloot-mozilla in FedIdCG [1] and they have confirmed that it’s on their list.


Nicolás Peña

unread,
Oct 26, 2023, 10:27:09 AM10/26/23
to blink-dev, Yi Gu, Yoav Weiss, blink-dev, Mike Taylor
For the record, we did request reviews: here and here. I'll ask to see if they can be added to the set of users from whom we can 'request review' in GitHub UI.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Mike Taylor

unread,
Oct 27, 2023, 4:45:29 PM10/27/23
to Nicolás Peña, blink-dev, Yi Gu, Yoav Weiss

Thanks Nicolás and Yi.

LGTM1 % the PRs landing before this ships, and assuming Mozilla does not have feedback that materially changes the API shape. If that's the case, can you report back?

thanks,
Mike

Rick Byers

unread,
Oct 27, 2023, 5:18:00 PM10/27/23
to Mike Taylor, Nicolás Peña, blink-dev, Yi Gu, Yoav Weiss
FedCM has decided to follow a WHATWG-like working mode where normative PRs land only with 2+ implementer support. Given that reviews were requested almost 2 months ago, and the blink launch process is designed not to stall indefinitely on consensus, I don't think API owners should be blocking this intent further on the PRs landing. Mike, WDYT?

Rick

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
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.

--
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/0efea540-3115-4435-8837-fd4983ffd68d%40chromium.org.

Chris Harrelson

unread,
Oct 27, 2023, 5:27:57 PM10/27/23
to Rick Byers, Mike Taylor, Nicolás Peña, blink-dev, Yi Gu, Yoav Weiss
However, even for WHATWG specs we have in the past blocked approval until spec PRs landed in cases where the only blocker was editorial review. This appears to be a similar situation.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9xmqXCW%3DHowGt_2FCjaoEp0SPzOuqhSD%3Dcg6wrjH2fhw%40mail.gmail.com.

Mike Taylor

unread,
Oct 30, 2023, 12:21:59 PM10/30/23
to Chris Harrelson, Rick Byers, Nicolás Peña, blink-dev, Yi Gu, Yoav Weiss

I'd like to remove my condition around my LGTM - I was able to reach out to Ben offline to confirm that he's roughly in favor of the proposed additions. Given that, I don't think we should block on reviews (acknowledging a private chat is not an official position or statement of support).

So, LGTM1 to ship.

Rick Byers

unread,
Oct 30, 2023, 2:35:06 PM10/30/23
to Mike Taylor, Chris Harrelson, Nicolás Peña, blink-dev, Yi Gu, Yoav Weiss
Thanks Mike. LGTM2

Yoav Weiss

unread,
Nov 1, 2023, 4:35:25 AM11/1/23
to Rick Byers, Mike Taylor, Chris Harrelson, Nicolás Peña, blink-dev, Yi Gu
LGTM3
Reply all
Reply to author
Forward
0 new messages