LGTM2 On Wed, Nov 27, 2024 at 9:40 AM Vladimir Levin <vmp...@chromium.org> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Nuwsiq37AK4MCT_TYRi7p1Yxq-Pz%2BGe_jt%3DfX6L%3DayjA%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/CAFUtAY8QRk-HgkU%2BEGDNPTcCJgHHF%2Bx6e7LnFWsy%3DVKC1sPd3g%40mail.gmail.com.
