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% >>> 3DBNNCJZcsgK34w6YOJ7p9YaX5jW4xJA7M7Pg%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/CACh2XCMst2oCeMUHwXpnmbfV1qZRJuPhZZqPDotjY8P3t_6_cQ%40mail.gmail.com.
