LGTM1 On Wed, Apr 16, 2025 at 12:47 AM Stephen Mcgruer <smcgr...@chromium.org> wrote:
> Contact emailssmcgr...@chromium.org > > Explainerhttps://github.com/w3c/secure-payment-confirmation/issues/267 > > Specificationhttps://github.com/w3c/secure-payment-confirmation/pull/281 > > Summary > > Correct the error type thrown during WebAuthn credential creation for > 'payment' credentials. Due to a historic specification mismatch, creating a > 'payment' credential in a cross-origin iframe without a user activation > would throw a SecurityError instead of a NotAllowedError, which is what is > thrown for non-payment credentials. This is a breaking change, albeit a > niche one. Code that previously detected the type of error thrown (e.g., `e > instanceof SecurityError`) would be affected. Code that just generally > handles errors during credential creation (e.g. `catch (e)`) will continue > to function correctly. > > Blink componentBlink>Payments > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPayments%22> > > TAG reviewN/A - this is a compat bugfix to the SPC spec and does not > require its own review. > > TAG review statusN/A > > Risks > > Interoperability and Compatibility > > There is a *very* minor risk of web compat breakage here. If code is very > specifically handling the error type thrown for the very specific outcome > of no user activation on creating a creation in a cross-origin iframe with > the payment extension, they may stop handling that correctly. That is, if > one was doing a specific `e instanceof SecurityError`, it will no longer > catch the above case. Given that code should still be handling the overall > fact that *some* error was thrown, and that creating credentials in > cross-origin iframes is incredibly rare today - nevermind specifically with > the 'payment' extension and not having a user activation - the risk seems > low enough for this to be safe. > https://chromestatus.com/metrics/feature/timeline/popularity/4758 > measures creating credentials in a cross-origin iframe. Currently at > 0.000005% of page loads. > > *Gecko*: N/A Firefox does not ship SPC ( > https://github.com/mozilla/standards-positions/issues/570) and thus does > not support the "payment" extension, so never had this compat issue. > > *WebKit*: N/A Safari does not ship SPC ( > https://github.com/WebKit/standards-positions/issues/30) and thus does > not support the "payment" extension, so never had this compat issue. > > *Web developers*: Payment industry partners that are experimenting with > SPC have been informed, and none have raised any concerns. > > *Other signals*: > > 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 > > N/A - standard devtools tools suffice. > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?No - SPC/the payment > extension is not shipped 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> > ?Yes > > > https://wpt.fyi/results/secure-payment-confirmation/enrollment-in-iframe.sub.https.html?label=experimental&label=master&aligned > Test: "SPC enrollment in cross-origin iframe fails without user activation" > > Flag name on about://flagsNone > > Finch feature name > WebAuthenticationAlignErrorTypeForPaymentCredentialCreate > > Non-finch justification > > Note: Not planning a Finch rollout, but have a base::Feature flag for > emergency kill-switch via Finch if needed. > > Rollout planWill ship enabled for all users > > Requires code in //chrome?False > > Tracking bughttps://issues.chromium.org/u/1/issues/41484826 > > Estimated milestones > Shipping on desktop 137 > DevTrial on desktop 135 > Shipping on Android 137 > DevTrial on Android 135 > 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/5160752715137024?gate=5120826699153408 > > Links to previous Intent discussionsIntent to Prototype: > https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/X0c08UCiUGc > > > 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/CADY3MaeGOOp6eZ9Dm%3DiUm-_XCiTh0URDfRStOh9TgeuX_Yy4SA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MaeGOOp6eZ9Dm%3DiUm-_XCiTh0URDfRStOh9TgeuX_Yy4SA%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/CAM0wra_c8b15BeShfiw0_N-gTPSPb38m_SUz9Ad_0Bou_HDtWA%40mail.gmail.com.
