Thanks Stephen, that makes sense. LGTM2
On Tuesday, July 15, 2025 at 3:20:00 PM UTC-4 Slobodan Pejic wrote: > Thanks Domenic, I have filed an issue to address this problem with the > secure-payment-confirmation specification (#307 > <https://github.com/w3c/secure-payment-confirmation/issues/307>). > > On Monday, July 14, 2025 at 10:09:19 PM UTC-4 Domenic Denicola wrote: > >> This generally looks good, but there's a bit of a hole in the spec which >> makes it unclear whether CSP, etc. apply to these image fetches: see >> https://github.com/w3c/image-resource/issues/48 . (The SPC spec calls >> "Fetch an image resource" with no request supplied, but the Image Resource >> spec is broken in that case.) >> >> On Tue, Jul 15, 2025 at 3:13 AM Alex Russell <slightly...@chromium.org> >> wrote: >> >>> LGTM1; my view is that each browser team is managing risk about >>> browser-presented UI and that nothing about this forces anyone to display >>> anything. >>> >>> Best, >>> >>> Alex >>> >>> On Thursday, July 10, 2025 at 11:24:51 AM UTC-7 Nina Satragno wrote: >>> >>>> El mié, 9 jul 2025 a la(s) 12:11 p.m., Stephen Mcgruer ( >>>> smcgr...@chromium.org) escribió: >>>> >>>>> > Hey, with regards to providing logos. My understanding is that this >>>>> would be displayed in a trusted content. Is there some affordances to >>>>> clearly indicate that these logos are provided by the merchants? I'm a >>>>> little concerned for cases like displaying arbitrary content in trusted >>>>> UI >>>>> because of things like hate symbols, among other things. >>>>> >>>>> Hi Vlad; you're completely right to be concerned in this regard - it >>>>> is a general concern with SPC. Whilst we do care about this issue, our >>>>> counter-argument is that there is no incentive to display misleading or >>>>> offensive logos using SPC. >>>>> >>>>> Firstly, if we examine the 'offensive' case - what is the value of SPC >>>>> here for someone who wants to offend? If I'm the website, I can render >>>>> offensive iconography in an HTML 'bottomsheet' UX, with a Chrome logo at >>>>> the top of it, and write whatever I want. Users will generally not know >>>>> the >>>>> difference, and many will just attribute that to being from Chrome >>>>> anyway. >>>>> We're actually not looking to present SPC as being "from Chrome" - >>>>> there's >>>>> no logo, for example. We've historically discussed this with security, >>>>> and >>>>> we have offered to remove the 'line of death/full screen scrim' to >>>>> further >>>>> divorce SPC from being 'browser UX' - but so far they haven't asked us to >>>>> do that. >>>>> >>>>> Secondly, if we examine the 'misleading' case, we cover that in the >>>>> spec (here >>>>> <https://w3c.github.io/secure-payment-confirmation/#sctn-security-payment-attack> >>>>> >>>>> and here >>>>> <https://w3c.github.io/secure-payment-confirmation/#sctn-security-merchant-data>), >>>>> >>>>> but broadly the answer is that even if you trick the user into creating >>>>> an >>>>> SPC cryptogram, it has no value unless you are literally processing a >>>>> transaction with the underlying payment providers (and they are able to >>>>> examine the output signed cryptogram to know exactly what data you >>>>> provided >>>>> to the user). So as a misleading attacker, you at best end up with an SPC >>>>> cryptogram with no use for it. >>>>> >>>>> On Wed, 9 Jul 2025 at 12:01, Stephen Mcgruer <smcgr...@chromium.org> >>>>> wrote: >>>>> >>>>>> > Sorry, I didn't read the WPT PRs you linked. I see that the tests >>>>>> already depend on test_driver.add_virtual_authenticator(). Is there >>>>>> anything blocking testing here, or is it OK if shipping this is >>>>>> conditional >>>>>> on the tests being landed? >>>>>> >>>>>> The main issue is that WebAuthn virtual authenticators are not >>>>>> supported on Chrome Android (as far as I know, cc @Nina Satragno >>>>>> <nsatra...@google.com> ), whilst this feature is shipping first for >>>>>> SPC in Chrome Android (with Desktop to follow in a few milestones). So >>>>>> they're not going to pass when initially landed (and indeed will regress >>>>>> SPC's wpt.fyi status in Chrome), *however* we discussed this >>>>>> internally yesterday and decided its still better to have tests that >>>>>> reflect the specification even if they now fail due to lack of test >>>>>> support. So our plan is to land them in the coming days (once reviewed). >>>>>> >>>>> >>>> This is correct, there's no virtual authenticator support for Android. >>>> From a WPT perspective this also seems like a reasonable approach to me. >>>> >>>> >>>>> >>>>>> On Wed, 9 Jul 2025 at 11:21, Philip Jägenstedt <foo...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> Sorry, I didn't read the WPT PRs you linked. I see that the tests >>>>>>> already depend on test_driver.add_virtual_authenticator(). Is there >>>>>>> anything blocking testing here, or is it OK if shipping this is >>>>>>> conditional >>>>>>> on the tests being landed? >>>>>>> >>>>>>> On Wed, Jul 9, 2025 at 5:17 PM Philip Jägenstedt < >>>>>>> foo...@chromium.org> wrote: >>>>>>> >>>>>>>> Hey Stephen, >>>>>>>> >>>>>>>> Is WebAuthn virtual authenticators the DevTools feature mentioned >>>>>>>> in https://developer.chrome.com/docs/devtools/webauthn? >>>>>>>> >>>>>>>> If you need powerful test automation for WebAuthn, have you had a >>>>>>>> look at what's currently possible with WebDriver BiDi and >>>>>>>> testdriver.js? >>>>>>>> Recently >>>>>>>> <https://github.com/web-platform-tests/wpt/commits/0fc79d8e619d1ab680b2688e8ec6b9dd51b19b26/resources/testdriver.js> >>>>>>>> a >>>>>>>> lot of previously "too hard" features have been added to >>>>>>>> testdriver.js, and >>>>>>>> there might be a pattern you can follow there. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Philip >>>>>>>> >>>>>>>> On Thu, Jul 3, 2025 at 7:29 PM Stephen Mcgruer < >>>>>>>> smcgr...@chromium.org> wrote: >>>>>>>> >>>>>>>>> (Also, -chrome-payments-eng@ as that is an internal group that >>>>>>>>> will not accept email from @chromium.org or other external >>>>>>>>> accounts :)) >>>>>>>>> >>>>>>>>> On Thu, 3 Jul 2025 at 13:26, Stephen Mcgruer < >>>>>>>>> smcgr...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> Quick clarification here: >>>>>>>>>> >>>>>>>>>> > Is this feature fully tested by web-platform-tests? >>>>>>>>>> > No >>>>>>>>>> >>>>>>>>>> We are working on adding tests, but since the SPC WPTs rely on >>>>>>>>>> WebAuthn virtual authenticators, and those are not available on >>>>>>>>>> Chrome >>>>>>>>>> Android, we are having to test them manually as we develop. When >>>>>>>>>> these >>>>>>>>>> features are implemented for Desktop then things should start >>>>>>>>>> working >>>>>>>>>> better! >>>>>>>>>> >>>>>>>>>> - https://github.com/web-platform-tests/wpt/pull/53358 >>>>>>>>>> (paymentEntityLogos) >>>>>>>>>> - https://github.com/web-platform-tests/wpt/pull/53333 >>>>>>>>>> (instrument.details) >>>>>>>>>> - https://github.com/web-platform-tests/wpt/pull/53386 (new >>>>>>>>>> output states) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, 3 Jul 2025 at 12:14, Chromestatus < >>>>>>>>>> ad...@cr-status.appspotmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Contact emails darwiny...@chromium.org, slobo...@chromium.org, >>>>>>>>>>> smcgr...@chromium.org >>>>>>>>>>> >>>>>>>>>>> Explainer >>>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/issues/197 >>>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/issues/275 >>>>>>>>>>> >>>>>>>>>>> Specification https://w3c.github.io/secure-payment-confirmation >>>>>>>>>>> >>>>>>>>>>> Design docs >>>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/issues/197 >>>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/issues/275 >>>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/pull/292 >>>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/pull/294 >>>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/pull/298 >>>>>>>>>>> >>>>>>>>>>> Summary >>>>>>>>>>> >>>>>>>>>>> Updates the UX elements for the SPC dialog on Android Chrome. >>>>>>>>>>> Other than just UX presentation the following are being added: - >>>>>>>>>>> Allowing >>>>>>>>>>> merchants to provide an optional list of payment entity logos >>>>>>>>>>> related to >>>>>>>>>>> the payment that will be displayed in the UX ( >>>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/pull/294). - >>>>>>>>>>> Returning different output states back to the merchant depending on >>>>>>>>>>> whether >>>>>>>>>>> the user wants to continue the transaction without SPC or to cancel >>>>>>>>>>> the >>>>>>>>>>> transaction ( >>>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/pull/292). >>>>>>>>>>> Currently, we only send a single output state back for both cases. >>>>>>>>>>> - A new >>>>>>>>>>> payment detail label field will be added to the payment instrument >>>>>>>>>>> so the >>>>>>>>>>> text be presented across 2 lines in SPC ( >>>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/pull/298) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Blink component Blink>Payments >>>>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPayments%22> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> TAG review N/A (minor additive features) >>>>>>>>>>> >>>>>>>>>>> TAG review status Not applicable >>>>>>>>>>> >>>>>>>>>>> Risks >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>> >>>>>>>>>>> Low risk. The SPC UX Refresh changes are only purely additive >>>>>>>>>>> API shapes that are all backwards compatible. The risk is that >>>>>>>>>>> other >>>>>>>>>>> browser do not implement it. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Gecko*: No signal ( >>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/570) >>>>>>>>>>> Firefox has never finalized their view on SPC, so we updated the >>>>>>>>>>> original >>>>>>>>>>> SPC issue with a note on this additional capability. >>>>>>>>>>> >>>>>>>>>>> *WebKit*: No signal ( >>>>>>>>>>> https://github.com/WebKit/standards-positions/issues/30) Safari >>>>>>>>>>> has never finalized their view on SPC, so we updated the original >>>>>>>>>>> SPC issue >>>>>>>>>>> with a note on this additional capability. >>>>>>>>>>> >>>>>>>>>>> *Web developers*: Positive Responding to requests/feedback from >>>>>>>>>>> web developers in the WPWG. >>>>>>>>>>> >>>>>>>>>>> *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 >>>>>>>>>>> >>>>>>>>>>> Web developers should be able to try the new SPC UX Refresh >>>>>>>>>>> through a Chrome flag, thus no changes are needed in devtools. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>>>>>>> No >>>>>>>>>>> >>>>>>>>>>> SPC UX Refresh is added to Secure Payment Confirmation which is >>>>>>>>>>> supported only on Android, Windows, and Mac. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>> ? No >>>>>>>>>>> >>>>>>>>>>> DevTrial instructions >>>>>>>>>>> https://docs.google.com/document/d/1w3RfvmoQqCvJkio4rxl0QR4BL1AzgHdv9a0qJhfCzpg >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Flag name on about://flags >>>>>>>>>>> enable-secure-payment-confirmation-ux-refresh >>>>>>>>>>> >>>>>>>>>>> Finch feature name SecurePaymentConfirmationUxRefresh >>>>>>>>>>> >>>>>>>>>>> Rollout plan Will ship enabled for all users >>>>>>>>>>> >>>>>>>>>>> Requires code in //chrome? False >>>>>>>>>>> >>>>>>>>>>> Tracking bug https://g-issues.chromium.org/issues/405173922 >>>>>>>>>>> >>>>>>>>>>> Launch bug https://launch.corp.google.com/launch/4397413 >>>>>>>>>>> >>>>>>>>>>> Measurement SPC UX Refresh is only additive to Secure Payment >>>>>>>>>>> Confirmation: The Secure Payment Confirmation UseCounter will be >>>>>>>>>>> used. >>>>>>>>>>> >>>>>>>>>>> Availability expectation Secure Payment Confirmation is only in >>>>>>>>>>> Chromium browsers for the foreseeable future. >>>>>>>>>>> >>>>>>>>>>> Non-OSS dependencies >>>>>>>>>>> >>>>>>>>>>> Does the feature depend on any code or APIs outside the Chromium >>>>>>>>>>> open source repository and its open-source dependencies to function? >>>>>>>>>>> None >>>>>>>>>>> >>>>>>>>>>> Sample links >>>>>>>>>>> https://rsolomakhin.github.io/pr/spc-payment-entities-logos >>>>>>>>>>> https://rsolomakhin.github.io/pr/spc-opt-out >>>>>>>>>>> >>>>>>>>>>> Estimated milestones >>>>>>>>>>> Shipping on Android 139 >>>>>>>>>>> DevTrial on Android 139 >>>>>>>>>>> >>>>>>>>>>> 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/5206050462236672?gate=5106969593249792 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Links to previous Intent discussions Intent to Prototype: >>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/683f5e54.170a0220.31427f.1558.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/CADY3MafTfsu-e69p_8ixAyLvfj0VnVuxs%3DT95w55UbeDSKKr5g%40mail.gmail.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafTfsu-e69p_8ixAyLvfj0VnVuxs%3DT95w55UbeDSKKr5g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> >>>> >>>> -- >>>> Nina Satragno >>>> >>> -- >>> 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/bbcefa96-47c5-4ad2-8f38-d735fd94e63an%40chromium.org >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bbcefa96-47c5-4ad2-8f38-d735fd94e63an%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38a9f6a8-fa87-43d2-a93f-bef198cc9795n%40chromium.org.
