Since we're past the first 6 milestones for the trial, can you send a separate intent to extend the OT, with some details on what y'all did to push it towards shipping <https://www.chromium.org/blink/launching-features/#origin-trials>?
On Thu, Sep 19, 2024 at 9:28 PM Yi Gu <y...@chromium.org> wrote: > Hello API owners, > > We have been addressing feedback from partners and CG/WG w.r.t. the API > as well as the UI since the OT starts. Therefore we'd like to extend the OT > (to M133 inclusive) to test the new changes and support partners to run > further experiments. > > Yi > > > > On Tue, Jul 9, 2024 at 9:42 AM Yi Gu <y...@chromium.org> wrote: > >> Thanks Yoav! >> >> On Tue, Jul 9, 2024 at 9:39 AM Yoav Weiss (@Shopify) < >> yoavwe...@chromium.org> wrote: >> >>> That's fine. No re-approval is needed >>> >>> On Tue, Jul 9, 2024 at 3:12 PM Yi Gu <y...@chromium.org> wrote: >>> >>>> Hello API owners! >>>> >>>> Quick update: we didn't start the OT on desktop until M125 and haven't >>>> started the OT on Android yet. Therefore we propose to update the estimated >>>> milestones to: >>>> desktop: M125 - M130 inclusive >>>> Android: M128 - M130 inclusive >>>> >>>> WDYT? >>>> >>>> Regards, >>>> Yi >>>> >>>> On Tue, Apr 9, 2024 at 12:33 AM Yoav Weiss (@Shopify) < >>>> yoavwe...@chromium.org> wrote: >>>> >>>>> That's indeed very useful to get a better understanding of the overall >>>>> flow, thanks! :) >>>>> >>>>> On Mon, Apr 8, 2024 at 5:06 PM Yi Gu <y...@chromium.org> wrote: >>>>> >>>>>> Hi Yoav, >>>>>> >>>>>> Thanks for the suggestion! We have a flowchart >>>>>> <https://raw.githubusercontent.com/yi-gu/fedcm-images/main/button_flow/ButtonFlow.jpeg> >>>>>> in that thread to try to explain what a browser would do in case a user >>>>>> is >>>>>> not logged in to the IdP but maybe it's not very clear. The answer to >>>>>> your >>>>>> questions is yes. IdP controls which login page the new window would load >>>>>> (by reusing the required "login_url >>>>>> <https://developers.google.com/privacy-sandbox/3pcd/fedcm-developer-guide#login-url>" >>>>>> field from LoginStatus API). However they cannot choose another way to >>>>>> handle user logged-out in the middle of a FedCM button flow. In addition, >>>>>> we provided this deck >>>>>> <https://docs.google.com/presentation/d/1iURrPakaHgBfQ6mAefKijjxToiTTgBSPz1rtaV0od98/edit?usp=sharing> >>>>>> of >>>>>> mocks w.r.t. how Chrome plans to implement the Button flow. We may change >>>>>> some of the UI affordance during OT and will publish a blog post with >>>>>> instruction and proposed UX soon. >>>>>> >>>>>> Please let us know if we could make it more clear for developers. >>>>>> >>>>>> Yi >>>>>> >>>>>> On Fri, Apr 5, 2024 at 9:36 AM Yoav Weiss (@Shopify) < >>>>>> yoavwe...@chromium.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tuesday, February 27, 2024 at 1:43:01 AM UTC+1 Mike Taylor wrote: >>>>>>> >>>>>>> That said, please request approvals from the various review gates in >>>>>>> your chromestatus entry before experimenting. >>>>>>> On 2/26/24 7:41 PM, Mike Taylor wrote: >>>>>>> >>>>>>> LGTM to experiment from M124 to M127 inclusive. >>>>>>> On 2/26/24 5:45 PM, Yi Gu wrote: >>>>>>> >>>>>>> Contact emails >>>>>>> >>>>>>> >>>>>>> * y...@chromium.org <y...@chromium.org>, cbiesin...@chromium.org >>>>>>> <cbiesin...@chromium.org>, tanzach...@chromium.org >>>>>>> <tanzach...@chromium.org> * Explainer >>>>>>> >>>>>>> * https://github.com/fedidcg/FedCM/issues/442 >>>>>>> <https://github.com/fedidcg/FedCM/issues/442#issuecomment-1949323416>* >>>>>>> >>>>>>> With my API owner hat off, this is not sufficient as an explainer, >>>>>>> and makes it hard for me to assess the technical complexity of >>>>>>> participating in the OT. >>>>>>> I think it'd be good to elaborate on the exact flows that button >>>>>>> mode enables. (e.g. what happens when the user is not logged in to the >>>>>>> IdP? >>>>>>> Does the browser automatically opens a separate window to handle that >>>>>>> log >>>>>>> in? Is this something that the IdP should handle? If so, how?) >>>>>>> >>>>>>> >>>>>>> Specification >>>>>>> >>>>>>> >>>>>>> * https://fedidcg.github.io/FedCM <https://fedidcg.github.io/FedCM> >>>>>>> This will be added as an extension. * Summary >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> * We plan to experiment with two new extensions for the Federated >>>>>>> Credential Management (FedCM) API: - Button Mode API - The button mode >>>>>>> lets >>>>>>> websites trigger FedCM directly when a user clicks a button (like a >>>>>>> "Sign-in with IdP" button). This means FedCM will always display a >>>>>>> visible >>>>>>> user interface for login, in contrast to the widget mode where no UI is >>>>>>> shown if a user’s login status is logged out. - When the FedCM API is >>>>>>> used >>>>>>> in "button mode" and a user isn't logged in, they'll be taken to the IdP >>>>>>> login screen (in a pop-up window). Since this happens in response to a >>>>>>> clear user action, the UI might even be more prominent (e.g., centered >>>>>>> and >>>>>>> modal) compared to the more subtle UI of widget mode. - Use Other >>>>>>> Account >>>>>>> API - With this API, an Identity Provider can request the browser to >>>>>>> show a >>>>>>> button that allows users to choose other accounts. * Blink component >>>>>>> >>>>>>> >>>>>>> * Blink>Identity>FedCM >>>>>>> <https://issues.chromium.org/u/1/issues?q=status:open%20componentid:1456331&s=created_time:desc> >>>>>>> * Search tags >>>>>>> >>>>>>> >>>>>>> * fedcm <https://chromestatus.com/features#fedcm> * TAG review >>>>>>> >>>>>>> >>>>>>> * https://github.com/w3ctag/design-reviews/issues/935 >>>>>>> <https://github.com/w3ctag/design-reviews/issues/935> * TAG review >>>>>>> status >>>>>>> >>>>>>> >>>>>>> * Pending * 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]. They have not >>>>>>> yet shipped but Mozilla is prototyping [2]. If a user agent chooses not >>>>>>> to >>>>>>> implement these extensions, the sign-in flow should not be affected in >>>>>>> that >>>>>>> user agent because developers can fallback to the existing federated >>>>>>> sign-in mechanisms. [1] >>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/bzghj9N3AQAJ >>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/bzghj9N3AQAJ> >>>>>>> [2] >>>>>>> https://groups.google.com/a/mozilla.org/g/dev-platform/c/ncmUwK1uO98/m/COhPA4ZrAAAJ >>>>>>> <https://groups.google.com/a/mozilla.org/g/dev-platform/c/ncmUwK1uO98/m/COhPA4ZrAAAJ> >>>>>>> Gecko: No signal WebKit: No signal Web developers: Positive >>>>>>> (https://github.com/fedidcg/FedCM/issues/442 >>>>>>> <https://github.com/fedidcg/FedCM/issues/442>) These features are being >>>>>>> developed to address existing feedback for the FedCM API. Other >>>>>>> signals: * >>>>>>> Activation >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> * Similar to the FedCM API, we deliberately leave the bulk of the >>>>>>> work to the IdP to ensure that minimal RP change is needed. This >>>>>>> feature, >>>>>>> specifically, is one that can be currently controlled by IdP (via JS SDK >>>>>>> for “button mode”, via server-side config for “use other account”), so >>>>>>> we >>>>>>> expect activation to have a similar profile as FedCM: immediately >>>>>>> enabled >>>>>>> to websites (without redeployment) by IdPs making use of it (by >>>>>>> redeploying >>>>>>> their JS SDKs). * Security >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> * The button mode shares most of the security properties from the >>>>>>> widget mode. e.g. honoring CSP, CORS, using security headers, not asking >>>>>>> users to type in the browser UI etc. It’s worth noting that the pop-up >>>>>>> window has the same web platform properties as what one would get with >>>>>>> window.open(url,””,”popup,noopener,noreferrer”) that loads the >>>>>>> login_url. >>>>>>> It is important to note that there's no communication allowed between >>>>>>> the >>>>>>> website and this pop-up (e.g. no postMessage, no window.opener). We have >>>>>>> shipped LoginStatus API and Error API in FedCM that use this type of >>>>>>> pop-up >>>>>>> window. * 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? None * Goals for experimentation >>>>>>> >>>>>>> >>>>>>> * Gather data on whether a browser mediated sign in flow on a >>>>>>> critical user journey is well received by users and developers. We'd >>>>>>> like >>>>>>> to see how the proposed UI/API play out and iterate on them to ship the >>>>>>> API >>>>>>> in its best shape. * Ongoing technical constraints >>>>>>> >>>>>>> >>>>>>> >>>>>>> * None * Debuggability >>>>>>> >>>>>>> >>>>>>> >>>>>>> * Same as FedCM in general – console messages in devtools and >>>>>>> general JS debugging * Will this feature be supported on all six >>>>>>> Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android >>>>>>> WebView)? >>>>>>> >>>>>>> >>>>>>> >>>>>>> * No FedCM API is not available in WebView * Is this feature fully >>>>>>> tested by web-platform-tests >>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>> ? >>>>>>> >>>>>>> >>>>>>> * Not yet. We will continue adding tests before the experiment >>>>>>> starts. * Flag name on chrome://flags >>>>>>> >>>>>>> >>>>>>> * FedCmButtonMode, FedCmUseOtherAccount * Finch feature name >>>>>>> >>>>>>> >>>>>>> * kFedCmButtonMode kFedCmUseOtherAccount * Non-finch justification >>>>>>> >>>>>>> >>>>>>> * None * Requires code in //chrome? >>>>>>> >>>>>>> >>>>>>> * True * Tracking bug >>>>>>> >>>>>>> >>>>>>> * https://crbug.com/40284792 <https://crbug.com/40284792> * Launch >>>>>>> bug >>>>>>> >>>>>>> >>>>>>> * https://launch.corp.google.com/launch/4293366 >>>>>>> <https://launch.corp.google.com/launch/4293366> * Estimated >>>>>>> milestones >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> * OriginTrial desktop last 126 OriginTrial desktop first 124 >>>>>>> OriginTrial Android last 127 OriginTrial Android first 125 * Link >>>>>>> to entry on the Chrome Platform Status >>>>>>> >>>>>>> >>>>>>> * https://chromestatus.com/feature/4689551782313984 >>>>>>> <https://chromestatus.com/feature/4689551782313984> * Links to >>>>>>> previous Intent discussions >>>>>>> >>>>>>> Intent to prototype: https://groups.google.com/a/ >>>>>>> chromium.org/d/msgid/blink-dev/CACh2XCPzJ1beiSbsmQqvu9x24zmf6 >>>>>>> LkGuup%3DgPVyXEx%2Bux9%3Dyg%40mail.gmail.com >>>>>>> >>>>>>> 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/CACh2XCNxFMQeN0%3DBNNCJZcsgK34w6YOJ7p9YaX5jW4x >>>>>>> JA7M7Pg%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACh2XCNxFMQeN0%3DBNNCJZcsgK34w6YOJ7p9YaX5jW4xJA7M7Pg%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/CAOmohSLut7awcMBbdrQTmgGg1m_wz%2BXtQxPFBzTF6czAwKOx9w%40mail.gmail.com.
