rp vs. rpId

[rlin1]

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]

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]

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).