LGTM3 On Mon, Oct 30, 2023 at 7:35 PM Rick Byers <rby...@chromium.org> wrote:
> Thanks Mike. LGTM2 > > On Mon, Oct 30, 2023 at 12:21 PM Mike Taylor <miketa...@chromium.org> > wrote: > >> 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. >> On 10/27/23 5:27 PM, Chris Harrelson wrote: >> >> 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. >> >> On Fri, Oct 27, 2023 at 2:17 PM Rick Byers <rby...@chromium.org> wrote: >> >>> FedCM has decided to follow a WHATWG-like working mode >>> <https://github.com/fedidcg/FedCM/issues/431> 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 >>> >>> On Fri, Oct 27, 2023 at 4:45 PM Mike Taylor <miketa...@chromium.org> >>> wrote: >>> >>>> 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 >>>> On 10/26/23 10:27 AM, Nicolás Peña wrote: >>>> >>>> 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/0efea540-3115-4435-8837-fd4983ffd68d%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0efea540-3115-4435-8837-fd4983ffd68d%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/CAFUtAY9xmqXCW%3DHowGt_2FCjaoEp0SPzOuqhSD%3Dcg6wrjH2fhw%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9xmqXCW%3DHowGt_2FCjaoEp0SPzOuqhSD%3Dcg6wrjH2fhw%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/CAL5BFfUvv6DtP5w%2B3jUfGQJTPAYAzeq_qE1MP1OLQunmataXJA%40mail.gmail.com.
