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/CAFUtAY9F_a4_VV4FZjAqYpnU-6Lp20wZeqUPhO-JjLM%2B7nh%2Bcg%40mail.gmail.com.
