For the record, we did request reviews: here <https://github.com/fedidcg/FedCM/pull/498#issuecomment-1703004458> and here <https://github.com/fedidcg/FedCM/pull/500#issuecomment-1706732499>. I'll ask to see if they can be added to the set of users from whom we can 'request review' in GitHub UI. On Wednesday, October 25, 2023 at 7:17:53 PM UTC-4 Yi Gu wrote:
> 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/ac466a99-3619-4af7-80fb-5a6ca51321ebn%40chromium.org.
