On Tue, Mar 15, 2022 at 4:52 PM Mike Taylor <[email protected]> wrote:
> On 3/9/22 10:27 AM, Nick Burris wrote: > > Contact emails > > [email protected], [email protected], [email protected], > [email protected] > > Explainer > > https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md > > Specification > > https://w3c.github.io/secure-payment-confirmation/ > > Design docs > > N/A > > Summary > > Three changes to the Secure Payment Confirmation API, implemented and > flagged as “V3” of the API. > > - > > Add Relying Party ID as a required input (issue > <https://github.com/w3c/secure-payment-confirmation/issues/164>). This > is a breaking change, see issue and compatibility section. > - > > Add an optional boolean to allow failed instrument icon download (issue > <https://github.com/w3c/secure-payment-confirmation/issues/125>). > - > > Add payeeName as an optional input (issue > <https://github.com/w3c/secure-payment-confirmation/issues/163>). > > > Original feature summary: Secure payment confirmation augments the > payment authentication experience on the web with the help of WebAuthn. The > feature adds a new 'payment' extension to WebAuthn, which allows a relying > party such as a bank to create a PublicKeyCredential that can be queried by > any merchant origin as part of an online checkout via the Payment Request > API using the 'secure-payment-confirmation' payment method. > > Blink component > > Blink>Payments > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments> > > TAG review > > https://github.com/w3ctag/design-reviews/issues/675 > > TAG review status > > Closed (Resolution: satisfied) > > Interoperability and Compatibility > > One of the API changes, the relying party ID input, is a breaking change > as it is a new required field. We are confident in this change as the > feature is relatively new and has little usage, and we have discussed these > changes with the external partners who are using the feature. Adapting to > the change is also forwards-compatible, in that partners can add the new > input today without breaking their code, and then it will just continue > working after this ships. > > How confident are y'all that all SPC users will be aware of this breaking > change? Do we have UKM? > Our metrics show that SPC currently has near zero usage, so we are confident that there's at least no deployed usage of the feature that this will break. We are in contact with multiple partners working on products using SPC who are aware of the change. If it does break something that's in development that we're not aware of, the error message indicates what's missing, and such a developer would likely know where to get the latest info on SPC (the github repo, blink-dev) or can at least find us. :) > > > Gecko: No signal ( > https://github.com/mozilla/standards-positions/issues/570) Historically > (>1 year old) positive signal from informal conversation in W3C Payment > Handler meetings. However Firefox have since not been involved in the API > development. > > WebKit: No signal ( > https://lists.webkit.org/pipermail/webkit-dev/2021-August/031956.html) > > Web developers: Positive ( > https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0005.html) > Support and involvement in API development from multiple web developers and > payment industry partners. Both Stripe and AirBnB have publicly stated that > they have either completed or are in the process of > prototyping/experimenting with SPC > > > > Debuggability > > Existing devtools debugging features should cover SPC (e.g. breakpoints, > console, etc) > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ? > > Yes, coverage for the new input fields will be added to the existing test > suite: > > > https://wpt.fyi/results/secure-payment-confirmation?label=master&label=experimental&aligned > > Flag name > > SecurePaymentConfirmationAPIV3 > > Requires code in //chrome? > > Yes: minor changes to the chrome UI code, to possibly display a > placeholder card icon when the new ‘iconMustBeShown’ option is false, and > to render the optional payeeName alongside or instead of the payeeOrigin. > > Tracking bug > > API V3 bug: https://crbug.com/1298505 > > Original feature bug: https://crbug.com/1124927 > > Launch bug > > Original SPC launch bug: > https://bugs.chromium.org/p/chromium/issues/detail?id=1236570 > > We believe this is a small enough change to an existing feature that it > doesn’t require its own launch bug. > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5675682238562304 > > Links to previous Intent discussions > > Intent to Prototype v1: > https://groups.google.com/a/chromium.org/d/topic/blink-dev/myUR5gyd5Js/discussion > > Intent to Experiment v2: > https://groups.google.com/a/chromium.org/g/blink-dev/c/6Dd00NJ-td8 > > Intent to Ship v2: > https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/U5K69fbA6SU > > > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADvKJHOGtvDnZxVCyDOFWPJuvCu5L9BdAjgoLH-rKF_zYsyOqg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADvKJHOGtvDnZxVCyDOFWPJuvCu5L9BdAjgoLH-rKF_zYsyOqg%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADvKJHO2JyZHa83kO1jD4EHdesbsVrdNCWCBGPk-cCnF0CLDKQ%40mail.gmail.com.
