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/CAOmohS%2BjtPDhDKDBxQFRhmPj1_GM-vBomFn2_M__urxP-jkDnA%40mail.gmail.com.

Reply via email to