We sync’d with @bvandersloot-mozilla <https://github.com/bvandersloot-mozilla> in FedIdCG [1] and they have confirmed that it’s on their list.
[1] https://github.com/fedidcg/meetings/blob/main/2023/2023-10-02-notes.md#notes On Wed, Oct 25, 2023 at 6:51 PM Mike Taylor <miketa...@chromium.org> wrote: > 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 > <https://github.com/fedidcg/FedCM/issues/488#issuecomment-1679742999>. > > 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. > <https://github.com/fedidcg/FedCM/issues/497#issuecomment-1698174046> > > > 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 > <https://github.com/fedidcg/meetings/blob/main/2023/2023-10-02-notes.md> > 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? > > > Thanks. > Yi > > On Wed, Oct 25, 2023 at 11:19 AM Yoav Weiss <yoavwe...@chromium.org> > wrote: > >> >> >> On Monday, October 23, 2023 at 3:03:59 PM UTC+2 blink-dev wrote: >> >> Contact emails >> >> y...@chromium.org >> >> Explainer >> >> https://github.com/fedidcg/FedCM/issues/488 >> >> >> 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? >> >> >> https://github.com/fedidcg/FedCM/issues/497 >> >> >> Similarly a short explainer outlining what this does and how would help >> reviewing this intent. >> >> >> Specification >> >> https://github.com/fedidcg/FedCM/pull/498 >> >> https://github.com/fedidcg/FedCM/pull/500 >> >> >> What's preventing these PRs from landing? >> >> >> >> 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 >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity%3EFedCM> >> >> Search tags >> >> fedcm <https://chromestatus.com/features#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 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/bzghj9N3AQAJ>[1] >> and Mozilla is currently prototyping >> <https://groups.google.com/a/mozilla.org/g/dev-platform/c/ncmUwK1uO98/m/COhPA4ZrAAAJ> >> 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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> 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 >> <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 blink-dev+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACh2XCM8FnGsYjCQhzskrzU4RK9fMvpSBv23VV4Cdtr%2BMj0O2w%40mail.gmail.com?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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f3bf599d-4ce2-482d-8153-87bba1dd1836%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f3bf599d-4ce2-482d-8153-87bba1dd1836%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACh2XCNbNHshaR_OismwF0_aynN_Cv41TNK7ztpga%3DqHPEqQqA%40mail.gmail.com.