+Ben and Martin from Mozilla -- could you weigh in on whether we should create a Mozilla standards position request for this?
Daniel: there is no technical limitation that prevents a non-IDP from calling this API, apologies for the unclear phrasing. However, a non-IDP (or indeed an IDP that does not use FedCM) will get no benefit from calling this API. Christian On Wed, Oct 18, 2023 at 12:11 PM Daniel Bratell <bratel...@gmail.com> wrote: > Hi, I just have a couple of questions without having read through the > intent in detail. > > You say "Our goal is to open this up to other websites in the future.", > but what does that mean? Is there some kind of web site restriction today? > > Not creating a https://github.com/mozilla/standards-positions/issues > entry seems a bit wrong even if someone at Mozilla has said it is not > needed. They have in the past specifically wanted us to explicitly use the > standards-positions repo rather than relying on negative or positive > statements elsewhere. Would it be best to post one just in case? > > /Daniel > On 2023-10-12 21:04, Christian Biesinger wrote: > > Contact emails > > cbiesin...@chromium.org > > > Explainer > > > https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md > > > Specification > > https://github.com/fedidcg/FedCM/pull/436 > > > Summary > > The Login Status API <https://github.com/fedidcg/login-status> (formerly > IdP Sign-in Status API) allows identity providers to signal to the browser > when their users are logging-in/out. Our goal is to open this up to other > websites in the future. > > This signal, in this intent, is used by FedCM to address a silent timing > attack, and in doing so, allows FedCM to operate without third party > cookies altogether. This update would address the last remaining backwards > incompatible changes we had previously identified in the original I2S of > FedCM > <https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/E9pgS7GEBAAJ> > as part of our scope of work. > > In the future, we expect that the Login Status API may also be used > outside of FedCM (e.g. the Storage Access API > <https://github.com/fedidcg/login-status#storage-access-api>) and may be > useful for websites that are not identity providers (e.g. extending > browser storage > <https://github.com/fedidcg/login-status#extending-site-data-storage>). > > > 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>, login > <https://chromestatus.com/features#tags:login> > > > TAG review > > https://github.com/w3ctag/design-reviews/issues/884 > > > TAG review status > > Pending > > > Chromium Trial Name > > FedCmIdpSigninStatus > > > Link to origin trial feedback summary > > https://github.com/fedidcg/FedCM/issues/ > > > Origin Trial documentation link > > > https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md > > https://developer.chrome.com/blog/fedcm-chrome-116-updates/#idp-signin-status > > > Risks Interoperability and Compatibility > > For interop: > > This I2S is composed of two different (but interdependent) APIs: The Login > Status API and FedCM. > > With regards to the Login Status API > <https://github.com/fedidcg/login-status>, both Firefox and Safari are on > board with the general API (breakout notes > <https://www.w3.org/2023/09/13-login-status-minutes.html>, follow up notes > <https://github.com/fedidcg/meetings/blob/main/2023/2023-09-14-TPAC-notes.md#login-status-api>) > . There is an overall agreement on starting from a self-declared status and > also some general agreement on where the Login Status API may lead in the > future, including having higher assurance levels and applications outside > of FedCM. > > With regards to its use in FedCM, Firefox is generally in agreement with > the shape of the solution. Firefox is working on the implementation behind > a flag. Safari isn’t shipping FedCM yet. > > For compat: > > While this is a backwards incompatible change for FedCM, we are in active > conversations with all IdPs that are currently using FedCM (as shown by our > UKM metrics) and they are onboard with this change. > > Gecko: Under consideration (https://github.com/fedidcg/FedCM/pull/436) We > have been working with the Firefox team for the last year or so on this API > (e.g. TPAC 2022 > <https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM_%20Options%20for%20the%20Timing%20Attack%20Problem%20(8_16_2022).pdf>). > We generally agree on the shape of the solution and we are working with > them to write the spec in a way that allows Chrome and Firefox to implement > FedCM in an interoperable way. (Firefox has asked us ( > https://github.com/fedidcg/FedCM/issues/431#issuecomment-1425025469) to > rely on PR comments instead of filing standards positions for these FedCM > extensions) > > WebKit: Under consideration ( > https://github.com/WebKit/standards-positions/issues/250) > No signal. Safari has so far shown overall support for FedCM [1], but > haven't yet formed a position on this specific extension of FedCM [2]. We > are generally in agreement of the API shape using the Login Status API [3], > but we haven't yet gotten signals from them on how FedCM, specifically, is > going to be using this signal. > [1] https://lists.webkit.org/pipermail/webkit-dev/2022-March/032162.html > [2] https://github.com/WebKit/standards-positions/issues/250 > [3] https://github.com/privacycg/is-logged-in/issues/53 > > Web developers: Positive ( > https://developers.google.com/identity/gsi/web/guides/supported-browsers#third-party_cookies) > We have been working with the FedID CG to develop this API and running > experiments with the Google Identity Services team. > > Other signals: > Ergonomics > > This is an API that is designed to be used by identity providers, when > their users login in to their websites. We exposed an HTTP header, since we > heard from them that logins are often made through 302 redirects. We are > also exposing a JS API for IdPs who find it easier to use JS than HTTP > headers. We show an error message in devtools when a FedCM request fails > because the user is not signed in. > 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? > > n/a, FedCM not supported on Webview > Debuggability > > We show errors in devtools to help with debugging. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, Chrome OS, Android, and Android WebView)? > > No > FedCM in general is not supported on WebView, but we support this API on > all other blink platforms. > > > 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/fedcm-login-status directory as shown on the WPT > dashboard here: > <https://wpt.fyi/results/credential-management?label=master&label=experimental&aligned> > https://wpt.fyi/results/credential-management/fedcm-login-status?label=experimental&label=master&aligned > > > DevTrial instructions > > > https://github.com/fedidcg/FedCM/blob/main/explorations/HOWTO-chrome.md#idp-sign-in-status-api > > > Flag name on chrome://flags > > FedCmIdpSigninStatus > > > Finch feature name > > FedCmIdpSigninStatus > > > Requires code in //chrome? > > True > > > Tracking bug > > https://crbug.com/1451396 > > > Launch bug > > https://launch.corp.google.com/launch/4280114 > > > Estimated milestones > > Shipping on desktop > > 120 > > OriginTrial desktop last > > 119 > > OriginTrial desktop first > > 116 > > DevTrial on desktop > > 115 > > Shipping on Android > > 120 > > OriginTrial Android last > > 119 > > OriginTrial Android first > > 117 > > Anticipated spec changes > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > > n/a > > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5177628008382464 > > > Links to previous Intent discussions > > Intent to Experiment: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XHJ-LMsCa-PMf1Ft51DCJK1dkzRrFZmRZuzL_Qe2WK2iA%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/CAPTJ0XHZQ7dzGGrY%2BNznzTLA3ap1W8EbLJuMGVxV4sk4oFxvHQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XHZQ7dzGGrY%2BNznzTLA3ap1W8EbLJuMGVxV4sk4oFxvHQ%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/CAPTJ0XHNAms2DKDockc-kEf2WY8u%2BxfjGz966dWoRoh3x%3DbiAw%40mail.gmail.com.
