search

w3c / secure-payment-confirmation

Secure Payment Confirmation (SPC)
https://w3c.github.io/secure-payment-confirmation/
Other
106 stars 48 forks source link

rp vs. rpId #191

Closed rlin1 closed 1 year ago

rlin1 commented 2 years ago

We use rp in CollectedClientAdditionalPaymentData But we use rpId in SecurePaymentConfirmationRequest

type is USVString in both cases and the meaning seems to be identical, i.e. RP ID.

Why is that?

stephenmcgruer commented 2 years ago

I believe this is just an oversight / historical artifact from the early days of the spec.

CollectedClientAdditionalPaymentData came first, and I think used rp 'just because', i.e. without any reason.

Adding the RP info to SecurePaymentConfirmationRequest came later, and by that time we were aware that WebAuthn's rp concept is actually a full type, PublicKeyCredentialRpEntity, and when the WebAuthn spec only needs to encode the ID (e.g. in PublicKeyCredentialRequestOptions), it names it rpId. So we followed that.

I believe we should align on the latter (rpId) in both these cases. We can either do that today with a backwards compatible change (e.g., start making CollectedClientAdditionalPaymentData return an rpId member, but note that implementations may also return rp due to historical reasons), or we can do that if/when we do a full API change away from PaymentRequest (tracked by #65 and #56 , approximately). I'm happy with either :).

stephenmcgruer commented 1 year ago

This has been fixed in the specs, tests, and in Chrome. On the Chrome side, once the change is in Stable (target end of October) we will send out an announcement asking folks to switch their validation logic over, with some deprecation period TBD (probably 3-6 months).