Intent to Deprecate and Remove: Secure Payment Confirmation: Rename rp --> rpId in CollectedClientAdditionalPaymentData

[Stephen Mcgruer]

Contact emails

smcg...@chromium.org

Explainer

None

Specification

https://w3c.github.io/secure-payment-confirmation/#sctn-collectedclientadditionalpaymentdata-dictionary

Summary

Secure Payment Confirmation (SPC) is a Web API to support streamlined authentication during a payment transaction. It builds on top of WebAuthn to bring strong authentication to payment flows. In the initial spec and implementation of SPC, the output CollectedClientAdditionalPaymentData dictionary[0] of the cryptogram contained a parameter named 'rp'. This was renamed in the specification[1] to 'rpId' to align with WebAuthn, and Chrome is changing its implementation to match (that is, adding 'rpId' and removing 'rp'). [0]: https://w3c.github.io/secure-payment-confirmation/#sctn-collectedclientadditionalpaymentdata-dictionary [1]: https://github.com/w3c/secure-payment-confirmation/pull/198

Blink component

Blink>Payments

Motivation

Secure Payment Confirmation (SPC) is a Web API to support streamlined authentication during a payment transaction. It builds on top of WebAuthn to bring strong authentication to payment flows. In the initial spec and implementation of SPC, the output CollectedClientAdditionalPaymentData dictionary[0] of the cryptogram contained a parameter named 'rp'. This was renamed in the specification[1] to 'rpId' to align with WebAuthn, and Chrome is changing its implementation to match (that is, adding 'rpId' and removing 'rp'). In M107, we added[2] 'rpId' to CollectedClientAdditionalPaymentData as an additional, identical field to 'rp'. We will now be removing the old 'rp' parameter. [0]: https://w3c.github.io/secure-payment-confirmation/#sctn-collectedclientadditionalpaymentdata-dictionary [1]: https://github.com/w3c/secure-payment-confirmation/pull/198 [2]: https://chromium.googlesource.com/chromium/src/+/3472ddafd924cbffab61b88746c5fe81e71e26a7

Initial public proposal

https://github.com/w3c/secure-payment-confirmation/issues/191

TAG review

N/A

TAG review status

N/A

Risks

Interoperability and Compatibility

Compatibility: The main risk is that a developer is still using the 'rp' parameter (and has not migrated to 'rpId'), and that their cryptogram-parsing code fails. Notably, we cannot detect this via browser metrics, as cryptogram-parsing is normally done server-side (i.e. the client just sends the received cryptogram up to a server). This also means that we cannot do e.g., a devtool deprecation warning. However, there are still relatively few users of SPC, and all are active participants in its development. We have announced this planned rename previously, and will now announce its deprecation + removal timeline ('deprecate' today, remove in M113).

Gecko: N/A Firefox does not ship SPC

WebKit: N/A Safari does not ship SPC

Web developers: No signals

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?

No - SPC does not ship on WebView.

Debuggability

Developers may inspect the output CollectedClientAdditionalPaymentData dictionary in devtools if desired.

Is this feature fully tested by web-platform-tests?

Yes, in https://wpt.fyi/results/secure-payment-confirmation/authentication-accepted.https.html?label=experimental&label=master&aligned - will need to be updated in M113 to assert that the field is no longer present.

Flag name

N/A

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1356224

Estimated milestones

Deprecation: 'now' (M110, but impossible to add e.g. deprecation warnings)

Removal: M113

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5203057325899776

This intent message was generated by Chrome Platform Status, and edited by smcgruer@ by hand.

[Stephen Mcgruer]

I was asked to clarify the level of compat risk for this change (very reasonably, I did a poor job in the original email!).

Conceptually, this change is risky as we cannot detect exact usage of 'someone is reading the old "rp" field', because CollectedClientAdditionalPaymentData is essentially a data blob returned from Chrome which is usually sent to the website's server backend and processed there.

However, for SPC we believe there is low enough usage in general and we have good enough partner relations that we can make sure partners are aware of and adapt to this change* ahead of the removal. The usecounter for SPC is at ~0.0005% of page loads, and we have internal metrics with more details. We know of a short list of partners who are actively experimenting with SPC 'in the wild'. There is a slightly longer and not fully known list of partners who may be experimenting with SPC in a dev environment, but we still expect to be able to inform these partners via the Web Payments WG and Web Payments SIG where most payment partners interact.

* by using the already existing "rpId" field instead

[Yoav Weiss]

LGTM1

On Fri, Jan 6, 2023 at 2:12 PM Stephen Mcgruer <smcg...@chromium.org> wrote:

I was asked to clarify the level of compat risk for this change (very reasonably, I did a poor job in the original email!).

Conceptually, this change is risky as we cannot detect exact usage of 'someone is reading the old "rp" field', because CollectedClientAdditionalPaymentData is essentially a data blob returned from Chrome which is usually sent to the website's server backend and processed there.

However, for SPC we believe there is low enough usage in general and we have good enough partner relations that we can make sure partners are aware of and adapt to this change* ahead of the removal. The usecounter for SPC is at ~0.0005% of page loads, and we have internal metrics with more details. We know of a short list of partners who are actively experimenting with SPC 'in the wild'. There is a slightly longer and not fully known list of partners who may be experimenting with SPC in a dev environment, but we still expect to be able to inform these partners via the Web Payments WG and Web Payments SIG where most payment partners interact.

Thanks for clarifying! That upper bound seems low enough, so hopefully partner relationships/communications can ensure no breakage from this.

 

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MaeSz5M_k5FaysBE-OgV3sarO6tgXY%3DcxmAMWivAfdW_SA%40mail.gmail.com.

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW7sFdW0ig4jniA2Wya2noA6fo9VaoqgYUvPQOhSYm5Tw%40mail.gmail.com.

[Mike Taylor]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-87yGWds1pNCJ0Sn3OqMrahdv_56%2Bf43WgsS4hncQkQw%40mail.gmail.com.