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? 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/CADsXd2MixYEn8cWM_orn4nYEqLhgyedTbbc3fhoq1n3NA43ePQ%40mail.gmail.com.
