On Wed, Mar 6, 2024 at 8:28 AM Nicolás Peña <n...@chromium.org> wrote:
> > > On Wednesday, March 6, 2024 at 5:11:09 AM UTC-5 Yoav Weiss wrote: > > On Wed, Mar 6, 2024 at 10:21 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > > > > On Mon, Mar 4, 2024 at 9:36 PM Mike Taylor <miketa...@chromium.org> wrote: > > LGTM1 > On 3/4/24 1:33 PM, Nicolás Peña wrote: > > Contact emails > > n...@chromium.org > > Explainer > > https://github.com/fedidcg/FedCM/issues/428 > > > A few lines summarizing this issue would be most useful when evaluating > this and understanding what y'all want to ship. > In particular, it'd be useful to understand the request flow, what is the > request's origin (as IIUC, we're talking about requests issued from the > browser), and what is the request destination that we may want IDPs to > check. > > Examples of the checks IDPs would have to make would also be helpful. > > > Sure! From the spec > <https://fedidcg.github.io/FedCM/#idp-api-id-assertion-endpoint>, here is > a sample request: > > POST /fedcm_assertion_endpoint HTTP/1.1 > Host: idp.example > Origin: https://rp.example/ > Content-Type: application/x-www-form-urlencoded > Cookie: 0x23223 > Sec-Fetch-Dest: webidentity > account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true > > With this change, Sec-Fetch-Mode will now be cors in this request and the > IDP is expected to return the following in the response (no preflight is > performed): > Do you mean Sec-Fetch-Dest? > > Access-Control-Allow-Origin: https://rp.example/ > Access-Control-Allow-Credentials: true > > > > Also, is the "identity assertion" endpoint the same as the token endpoint > <https://github.com/fedidcg/FedCM/blob/main/explainer.md#token_endpoint>? > > > Yea. I think that explainer doc is not super up to date. > > > > Specification > > https://github.com/fedidcg/FedCM/pull/547 > > Summary > > The fetches in the FedCM API are hard to reason about because of the > properties required of them. While there is ongoing discussion regarding > the accounts endpoint, there is broad consensus that the ID assertion > endpoint should use CORS. This aligns security properties of this fetch > more closely to other fetches in the web platform. > > Blink component > > Blink>Identity>FedCM > <https://g-issues.chromium.org/issues?q=status:open%20componentid:1456331&pli=1&authuser=0> > > TAG review > > Not requesting a TAG review. We have already had extensive discussions > with Fetch experts. > > TAG review status > > N/A > > Risks > > Interoperability and Compatibility > > This is a backwards incompatible feature, but one that is warranted due to > consensus reached by our security reviewers as well as other browser vendor > engineers. We have a manageable list of IDPs that we know are using the > FedCM API and we have reached out to all IDPs that are currently deploying > FedCM to make sure that they won’t break with this change. > > > Gecko: Positive based on TPAC discussions and https://github.com/fedidcg/ > FedCM/issues/428. Not filing a standards position request for small > additions at the explicit request from Firefox (they prefer PRs). > > WebKit: Positive based on TPAC discussions and https://github.com/fedidcg/ > FedCM/issues/428. Recently, standards position requests for smaller FedCM > features have been closed, pointing to the (unresolved) main FedCM one in > https://github.com/WebKit/standards-positions/issues/309 so not filing > one for this. > > Web developers: No signals > > Other signals: > > Ergonomics > > N/A > > > Activation > > N/A > > > Security > > By adding CORS, we add a check that the IDP explicitly agrees for the > browser to share the ID assertion response to the RP. In addition, having > this fetch align with most other credentialed fetches in the browser means > that any future protections are received by default, and we do not have to > special case this fetch. > > > 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 > > > Debuggability > > We surface errors when there is a network problem with the ID assertion > fetch. This will help developers understand when this feature introduces a > problem in their FedCM calls. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)? > > No. FedCM is not supported on Android WebView. > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > https://wpt.fyi/results/credential-management/fedcm- > identity-assertion-nocors.https.html?label=experimental& > label=master&aligned (will pass on Chrome once we ship) > > Flag name on chrome://flags > > None > > Finch feature name > > FedCmIdAssertionCORS > > Requires code in //chrome? > > True (because FedCM API does) > > Tracking bug > > https://issues.chromium.org/issues/40284123 > > Estimated milestones > > DevTrial on desktop > > 120 > > > DevTrial on Android > > 120 > > We want to ship on M124 > > 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). > > https://github.com/whatwg/fetch/issues/1637 > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5094763339710464 > > 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/1814484e-4a0c-4210-b936- > 29ead46f32c5n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1814484e-4a0c-4210-b936-29ead46f32c5n%40chromium.org?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/91c26d40-ccc9-4abe-bf97- > 38cd9e48f684%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/91c26d40-ccc9-4abe-bf97-38cd9e48f684%40chromium.org?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/a349c863-9904-491f-9e9d-31227683d4ffn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a349c863-9904-491f-9e9d-31227683d4ffn%40chromium.org?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/CAOMQ%2Bw-VMnjLjXrv8Am9Fh6AXgU%2BOp%2BjGLy%3DfLeyK2gKnNq3Zg%40mail.gmail.com.
