Thank you for the explanation! LGTM1
On Mon, Nov 25, 2024, 1:53 p.m. Christian Biesinger <cbiesin...@chromium.org> wrote: > > > On Mon, Nov 25, 2024 at 12:47 PM Vladimir Levin <vmp...@chromium.org> > wrote: > >> Hey Christian, >> >> Thank you for your reply. Additional questions below. >> >> On Fri, Nov 22, 2024 at 7:00 PM Christian Biesinger < >> cbiesin...@chromium.org> wrote: >> >>> Hi Vlad, >>> >>> The fields are standardized in the linked spec PR at >>> https://github.com/w3c-fedid/FedCM/pull/668/files#diff-40cc3a1ba233cc3ca7b6d5873260da9676f6ae20bb897b62f7871c80d0bda4e9R1371 >>> We only want RPs to specify fields that are in this spec or a future >>> version of it, although I recognize that because of the semantics of this >>> parameter we can not enforce that. (custom scopes should be sent in >>> `params`) >>> >>> multiple configURLs is needed because our partner needed to use a >>> different ID assertion endpoint for users requesting additional scopes. >>> >>> I am unsure if I can share the exact use case of our partner regarding >>> labels. But there are certain account types of this partner that they only >>> support on the "authorization" endpoint and not on the regular >>> "authentication" endpoint, and so they want that to be reflected in the >>> account list (instead of failing later on). >>> >> >> That's understandable, I was just hoping for an example of how this flow >> would work. My understanding is something like the following. Suppose I >> have two accounts Foo and Bar that are provided by one IdP and the RP will >> need some additional scope that is only available for Foo. Then the filter >> API allows the browser to filter out Bar and only display Foo as an >> available option. What I'm missing is how this is orchestrated. Is it that >> RP that requests this filtering or IdP and how does the browser orchestrate >> this. From my reading IdPs return a list of all possible labels for each >> account and RPs request specific labels, and then the browser does the >> filtering. Is that correct? I'm guessing there is no optionality here in >> that if the list, for example, ends up being filtered to nothing, then RPs >> don't have a chance to say "this scope was nice to have but not required". >> What is the UX here if there is no match? >> > > Let's say some account types do not support scopes at all and some do. > Then the IDP will provide two different config files, one with `accounts: > {include: "supports_scopes"}`, one with `accounts: {include: > "does_not_support_scopes"}`. The account endpoint will send the correct > label for each account. If an IDP has a smallish list of possible scopes, > they can also provide a per-scope config file. We could let an RP specify > labels directly in the future but have not done so here. (such a feature > would have overlap with account/domain hints) > > It is correct that there is no way to say "an account label would be nice > but is not required", or indeed "a field would be nice but is not > required". This could be added in the future. > > UI-wise, "no matching accounts" is treated the same as if an account hint > or domain hint does not match. The UI has gone through a few iterations, I > believe what we settled on was show a dialog with a "log in to IDP" button > for passive mode and a list of greyed out accounts for active mode, but I > may misremember these details. > > Christian > > >> Thanks, >> Vlad >> >> >>> I have summarized the OT feedback in the initial email under "Link to >>> origin trial feedback summary". >>> >>> Thanks, >>> Christian >>> >>> On Fri, Nov 22, 2024 at 3:12 PM Vladimir Levin <vmp...@chromium.org> >>> wrote: >>> >>>> Hey, >>>> >>>> Looking over the first three APIs (Continuation API, Parameters API, >>>> Fields API), I understand how it solves the problem of asking for >>>> additional data from IdPs. Essentially (and please correct me if I'm >>>> wrong), RPs specify a list of fields (i.e. scopes), then the browser >>>> chooses whether to mediate or delegate based on whether it knows how to >>>> handle these scopes. [Side question: are these fields/scopes standardized >>>> somewhere: how is collision with what IdPs can provide vs the browser >>>> thinks it can mediate avoided?]. >>>> >>>> What is unclear to me is how the next two features (Multiple >>>> configURLs, Custom account labels) contribute to the experience. It seems >>>> that it allows the IdPs to provide different sets of accounts for different >>>> labels. Does that mean when the browser mediates account selection, it >>>> considers these labels and filters some accounts? Is this used when RPs >>>> need a particular field and only some accounts provide that? Is there a >>>> comprehensive "real world" example of this somewhere in the docs? >>>> >>>> Separately, these features went through OT: is there a doc summarizing >>>> the participants' feedback? >>>> >>>> Thanks! >>>> Vlad >>>> >>>> On Wed, Nov 13, 2024 at 12:23 PM Christian Biesinger < >>>> cbiesin...@chromium.org> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Nov 13, 2024 at 11:29 AM Chris Harrelson < >>>>> chris...@chromium.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Nov 7, 2024 at 3:46 PM Christian Biesinger < >>>>>> cbiesin...@chromium.org> wrote: >>>>>> >>>>>>> >>>>>>> Contact emails >>>>>>> >>>>>>> cbiesin...@chromium.org >>>>>>> >>>>>>> Explainer >>>>>>> >>>>>>> Use case we want to support: >>>>>>> https://github.com/w3c-fedid/FedCM/issues/477 >>>>>>> >>>>>>> Derived explainers: >>>>>>> >>>>>>> https://github.com/fedidcg/FedCM/issues/555 >>>>>>> >>>>>>> https://github.com/fedidcg/FedCM/issues/556 >>>>>>> >>>>>>> https://github.com/fedidcg/FedCM/issues/559 >>>>>>> >>>>>>> https://github.com/fedidcg/FedCM/issues/552 >>>>>>> >>>>>>> https://github.com/fedidcg/FedCM/issues/553 >>>>>>> >>>>>>> Specification >>>>>>> >>>>>>> https://github.com/w3c-fedid/FedCM/pull/662 (continuation API) >>>>>>> >>>>>>> https://github.com/w3c-fedid/FedCM/pull/661 (parameter API, merged) >>>>>>> >>>>>>> https://github.com/w3c-fedid/FedCM/pull/668 (fields API) >>>>>>> >>>>>>> https://github.com/w3c-fedid/FedCM/pull/667 (multiple configURLs) >>>>>>> >>>>>>> https://github.com/w3c-fedid/FedCM/pull/669 (account labels) >>>>>>> >>>>>> >>>>>> Most of these are still open, is something blocking finishing and >>>>>> landing these spec PRs? >>>>>> >>>>>> >>>>> >>>>> We are waiting for reviews from outside of the team and WG approval to >>>>> land them. No real blocker otherwise. A lot of WG calls have been >>>>> cancelled >>>>> recently which makes landing these take longer than we had hoped for. >>>>> >>>>> Christian >>>>> >>>>> >>>>>> >>>>>>> Summary >>>>>>> >>>>>>> This bundles a few features that we would like to launch at the same >>>>>>> time. We are bundling them together because they can be used by IdPs to >>>>>>> implement authorization flows such as letting a user grant access to a >>>>>>> user’s calendar to an RP. See also >>>>>>> https://github.com/w3c-fedid/FedCM/issues/477. Specifically: >>>>>>> >>>>>>> - >>>>>>> >>>>>>> The IdP needs to be able to show a custom prompt for the >>>>>>> permission (continuation API) >>>>>>> - >>>>>>> >>>>>>> The RP needs an extensible way to communicate to the IdP what it >>>>>>> wants access to (parameters API) >>>>>>> - >>>>>>> >>>>>>> The RP needs to be able to customize/suppress the text referring >>>>>>> to the IdP sharing “name, email address and profile picture” because >>>>>>> in >>>>>>> this situation they are asking for different information (fields API) >>>>>>> - >>>>>>> >>>>>>> The IdP may want to use a different endpoint to implement the >>>>>>> authorization flow (multiple configURLs) >>>>>>> - >>>>>>> >>>>>>> Certain accounts may only be eligible for one of the >>>>>>> authentication and authorization flows and so there needs to be a >>>>>>> way to >>>>>>> show different accounts in the two flows (account labels API) >>>>>>> >>>>>>> >>>>>>> In addition, the APIs are solving a series of related FPWD blockers >>>>>>> <https://github.com/w3c-fedid/FedCM/wiki/Status-of-FPWD%E2%80%90identified-Issues> >>>>>>> identified >>>>>>> <https://lists.w3.org/Archives/Public/public-fedid-wg/2024Jul/0006.html> >>>>>>> by the FedID WG. >>>>>>> >>>>>>> Continuation API: >>>>>>> >>>>>>> https://github.com/fedidcg/FedCM/issues/555 >>>>>>> >>>>>>> This lets the IDP open a popup window to finish the sign-in flow >>>>>>> after potentially collecting additional information. >>>>>>> >>>>>>> Parameters API: >>>>>>> >>>>>>> https://github.com/fedidcg/FedCM/issues/556 >>>>>>> >>>>>>> This lets RPs pass additional data to the ID assertion endpoint >>>>>>> >>>>>>> Fields API: >>>>>>> >>>>>>> https://github.com/fedidcg/FedCM/issues/559 >>>>>>> >>>>>>> This lets RPs bypass the data sharing prompt in favor of the IDP >>>>>>> prompting >>>>>>> >>>>>>> Multiple configURLs: >>>>>>> >>>>>>> https://github.com/fedidcg/FedCM/issues/552 >>>>>>> >>>>>>> This lets IDPs use different config files in different contexts >>>>>>> without weakening FedCM privacy properties, by allowing one accounts >>>>>>> endpoint for the eTLD+1 (instead of one config file, which is more >>>>>>> limiting >>>>>>> than necessary) >>>>>>> >>>>>>> Account labels: >>>>>>> >>>>>>> https://github.com/fedidcg/FedCM/issues/553 >>>>>>> >>>>>>> Combined with the previous proposal, this allows filtering the >>>>>>> account list per config file without providing additional entropy to the >>>>>>> IDP. >>>>>>> >>>>>>> >>>>>>> Blink component >>>>>>> >>>>>>> Blink>Identity>FedCM >>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity%3EFedCM> >>>>>>> >>>>>>> TAG review >>>>>>> >>>>>>> https://github.com/w3ctag/design-reviews/issues/945 >>>>>>> >>>>>>> TAG review status >>>>>>> >>>>>>> Pending >>>>>>> >>>>>>> Chromium Trial Name >>>>>>> >>>>>>> FedCmContinueOnBundle >>>>>>> >>>>>>> Link to origin trial feedback summary >>>>>>> >>>>>>> What we learned during the origin trial: >>>>>>> >>>>>>> >>>>>>> - >>>>>>> >>>>>>> This bundle works well for implementing an authorization flow >>>>>>> for an identity provider >>>>>>> - >>>>>>> >>>>>>> The parameter API needed to be refined to be easier to use for >>>>>>> an IDP (allow nested objects; send the parameters as serialized JSON >>>>>>> instead of individually prefixed parameters) >>>>>>> - >>>>>>> >>>>>>> The fields API has gone through various iterations during the >>>>>>> trial and is now easier and more flexible to use >>>>>>> - >>>>>>> >>>>>>> We have identified a possible future extension to the >>>>>>> continuation API (adding an IdentityProvider.reject function to >>>>>>> mirror >>>>>>> .resolve) but are not shipping it as part of this launch. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Origin Trial documentation link >>>>>>> >>>>>>> >>>>>>> https://developers.google.com/privacy-sandbox/blog/fedcm-chrome-126-updates#origin_trial_fedcm_continuation_api_bundle >>>>>>> >>>>>>> >>>>>>> WebFeature UseCounter name >>>>>>> >>>>>>> kFedCmContinueOnResponse >>>>>>> >>>>>>> Risks >>>>>>> >>>>>>> Interoperability and Compatibility >>>>>>> >>>>>>> No compatibility risk as this adds new parameters to dictionaries in >>>>>>> a function argument. >>>>>>> >>>>>>> No concern about interoperability because other browser engines >>>>>>> currently do not ship FedCM. >>>>>>> >>>>>>> >>>>>>> Gecko: No signal. For incremental improvements to FedCM, Firefox >>>>>>> has asked us not to file standards position, and they will instead >>>>>>> provide >>>>>>> feedback in the GitHub PR. They have interacted on the spec PRs (e.g. on >>>>>>> https://github.com/w3c-fedid/FedCM/pull/662) and on the explainers >>>>>>> (e.g. https://github.com/w3c-fedid/FedCM/issues/477) but have not >>>>>>> expressed an explicit positive signal. >>>>>>> >>>>>>> WebKit: No signal ( >>>>>>> https://github.com/WebKit/standards-positions/issues/336) >>>>>>> >>>>>>> Web developers: Positive ( >>>>>>> https://github.com/fedidcg/FedCM/issues/488#issuecomment-1749682526) >>>>>>> Also: >>>>>>> https://github.com/fedidcg/FedCM/issues/496#issuecomment-1781364610 >>>>>>> https://github.com/fedidcg/FedCM/issues/533#issuecomment-1878581998 >>>>>>> >>>>>>> Other signals: >>>>>>> >>>>>>> Ergonomics >>>>>>> >>>>>>> This improves ergonomics for passing custom parameters to the IDP >>>>>>> because it now provides a structured way to do so instead of (ab)using >>>>>>> the >>>>>>> "nonce" parameter. >>>>>>> >>>>>>> Otherwise no impact on ergonomics either way. >>>>>>> >>>>>>> >>>>>>> Activation >>>>>>> >>>>>>> No particular risks. >>>>>>> >>>>>>> >>>>>>> Security >>>>>>> >>>>>>> We made sure that the popup from the continuation API is same-origin >>>>>>> with the IDP, and that it cannot communicate with the RP except through >>>>>>> the >>>>>>> narrow IdentityProvider.resolve API. In particular, window.opener is >>>>>>> null. >>>>>>> >>>>>>> The additional parameters from the parameter and fields API are only >>>>>>> sent to the server after user interaction, and from a privacy >>>>>>> perspective >>>>>>> are equivalent to the existing "nonce" field. However, from a developer >>>>>>> ergonomics perspective the additions are much easier to use. >>>>>>> >>>>>>> Account labels were carefully designed not to add entropy and in >>>>>>> particular not to send additional data to the server. >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> Debuggability >>>>>>> >>>>>>> We show console messages to assist debugging where appropriate. >>>>>>> >>>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>>> >>>>>>> No >>>>>>> >>>>>>> FedCM in general is not supported in webview >>>>>>> >>>>>>> >>>>>>> Is this feature fully tested by web-platform-tests >>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>> ? >>>>>>> >>>>>>> Yes >>>>>>> >>>>>>> >>>>>>> https://wpt.fyi/results/fedcm/fedcm-authz?label=experimental&label=master&aligned >>>>>>> >>>>>>> We are investing why they are failing on wpt.fyi even though they >>>>>>> pass in our internal infrastructure (e.g. >>>>>>> https://ci.chromium.org/ui/test/chromium/ninja%3A%2F%2F%3Ablink_wpt_tests%2Fvirtual%2Ffedcm-authz%2Fexternal%2Fwpt%2Ffedcm%2Ffedcm-authz%2Ffedcm-continue-on-with-account.https.html >>>>>>> ) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Flag name on chrome://flags >>>>>>> >>>>>>> fedcm-authz >>>>>>> >>>>>>> Finch feature name >>>>>>> >>>>>>> FedCmAuthz >>>>>>> >>>>>>> Requires code in //chrome? >>>>>>> >>>>>>> True >>>>>>> >>>>>>> Tracking bug >>>>>>> >>>>>>> https://crbug.com/40262526 >>>>>>> >>>>>>> Launch bug >>>>>>> >>>>>>> https://launch.corp.google.com/launch/4348692 >>>>>>> >>>>>>> Measurement >>>>>>> >>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/4955 >>>>>>> In addition, we have several UMA metrics. >>>>>>> >>>>>>> Estimated milestones >>>>>>> >>>>>>> Shipping on desktop >>>>>>> >>>>>>> 132 >>>>>>> >>>>>>> Origin trial desktop first >>>>>>> >>>>>>> 127 >>>>>>> >>>>>>> Origin trial desktop last >>>>>>> >>>>>>> 131 >>>>>>> >>>>>>> Origin trial extension 1 end milestone >>>>>>> >>>>>>> 133 >>>>>>> >>>>>>> Shipping on Android >>>>>>> >>>>>>> 132 >>>>>>> >>>>>>> Origin trial Android first >>>>>>> >>>>>>> 128 >>>>>>> >>>>>>> Origin trial Android last >>>>>>> >>>>>>> 133 >>>>>>> >>>>>>> >>>>>>> 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). >>>>>>> >>>>>>> None >>>>>>> >>>>>>> Link to entry on the Chrome Platform Status >>>>>>> >>>>>>> >>>>>>> https://chromestatus.com/feature/6495400321351680?gate=4886628616372224 >>>>>>> >>>>>>> Links to previous Intent discussions >>>>>>> >>>>>>> Intent to Prototype: >>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/qqrG6yn1u1Q?pli=1 >>>>>>> >>>>>>> Intent to Experiment: >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XEedt%2Bu2pS_2NHHfxtEV9JJ7wbuKNEnieeWr6w8FtwKLw%40mail.gmail.com >>>>>>> >>>>>>> Intent to Extend Experiment 1: >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/66ec74bf.2b0a0220.195547.03af.GAE%40google.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 visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XHfrr2FvW4qP%2BsS3Jn7DoE5oyTZETyuJTgT9wSN46ao4Q%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XHfrr2FvW4qP%2BsS3Jn7DoE5oyTZETyuJTgT9wSN46ao4Q%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 visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XFsZ%3DqJf9GogNxH7Zj_UJU2UMLvMtncetQ6pqUWzZBcJQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XFsZ%3DqJf9GogNxH7Zj_UJU2UMLvMtncetQ6pqUWzZBcJQ%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Nuwsiq37AK4MCT_TYRi7p1Yxq-Pz%2BGe_jt%3DfX6L%3DayjA%40mail.gmail.com.
