Support for multiple RPs in the Payment Request API for SPC

[fahads9]

Presently, Payment Request supports multiple credentialIDs tied to a single RP. However, there could be multiple trusted RPs for a given payment card - Issuer, Network, PSP, Merchant (etc.). As such, it'd be great if we could explore the possibility of supporting multiple RPs in the Payment Request API for SPC.

For better security, it may be apt to only allow a combination of credentialId's and rpId's.

For example:

[
{
rpId: 'www.issuer.com',
credentialIds: [base64ToArray("M1NrOF7hN4+WZOO2+uSz6VLtXm59OaEEzfglijzldNk="), base64ToArray("5eCuzI40QZ54d88A1NjTay8uvdCfSeSPI9XRLOvPMOk=")]
}
{
rpId: 'www.network.com',
credentialIds: [base64ToArray("M1NrOF7hN4+WZOO2+uSz6VLtXm59OaEEzfglijzldNk="), base64ToArray("5eCuzI40QZ54d88A1NjTay8uvdCfSeSPI9XRLOvPMOk=")]
}
]

[stephenmcgruer]

Thanks for filing this issue! The below is just some initial musing as I think about it :)

From an API surface perspective, I think this would be fairly easy to support in a backwards-compatible way. We could make SecurePaymentConfirmation.rpId the 'default' RP, and then allow overriding it per-credentialId:

dictionary SecurePaymentConfirmationRequest {
  // The default rpId for any BufferSource credentialIds
  required USVString rpId;

  required sequence<(BufferSource or CredentialSource)> credentialIds;
}

dictionary CredentialSource {
  // Overrides the default rpId.
  required USVString rpId;
  required BufferSource credentialId;
}

However, unfortunately it seems less clear to me how feasible it is from a structural perspective. The issue is that WebAuthn has no concept of a multi-RP call. All WebAuthn calls implicitly have just one RP, the current origin. So this would move us away further from WebAuthn, which may conceptually cause us pain in the future.

Practically, does that matter? I'm not sure. It would probably strengthen the requirement for the browser to have access to a silent credential listing/credential existence API, because we would have to implement this in the browser side, something like:

1. For each credential in credentialIds with id=acbd1234 and rpId=bar.example, silently check if it exists
2. If it does exist, call down into WebAuthn with only id=abcd1234 and rpId=bar.example

Today in theory SPC passes the entire set of credentialIds down into WebAuthn/the authenticator (see https://w3c.github.io/secure-payment-confirmation/#sctn-steps-to-respond-to-a-payment-request, step 6). However at the same time, practically speaking in Chrome's implementation we don't do that because we don't want WebAuthn/the authenticator to additionally show a passkey selector UX. So maybe its fine for the specification to change anyway!

[tblachowicz]

I think the spec change outlined by @stephenmcgruer to address issue raised by @fahads9 makes perfect sense. I’d support the approach with default RP and ability to override it per credential ID.

One the concern related to selection of the credential I’d be on the side of practice rather then theory. I think it should be a choice of the browser implantation rather than spec matter how to select the credential(s) to authenticate the confirmation. Passing all credential IDs to WebAuth is one way of doing it and silently checking the credential existence is another. If there is a need as requested by @fahads9 the browser implementation should make it possible.

[stephenmcgruer]

Passing all credential IDs to WebAuth is one way of doing it and silently checking the credential existence is another.

One clarification - it is not possible to pass credential IDs across different RPs to WebAuthn, to my knowledge. We should definitely double-check that with WebAuthn/FIDO folks, but it's generally a core concept in WebAuthn (since its always in a "first-party" context, e.g. Relying Party using a passkey on its own domain).

So a browser could not implement multi-RP support for SPC by passing all credential IDs to WebAuthn. It could only do something less effective, e.g. choosing only one RP for the call (or worse, try each RP in turn in a different flow).

[stephenmcgruer]

We discussed this issue at the Web Payments Working Group session (minutes) during TPAC 2025. The consensus was that it was reasonable to define this entirely within SPC, with the expected behaviour that SPC would just choose a single RP for the call, filtering out any RPs that have no credentials available. However, in the discussion the subsequent day on prioritization, I believe the consensus was also that this is currently a low priority issue for integrators of SPC.

Despite that, for fun, I prototyped it in Chrome yesterday morning (yay jetlag ✈️ ) - https://drive.google.com/file/d/1m-vuTOnc81JPDAEetOSFnpnoJlh5LZ3l/view?usp=sharing

[tblachowicz]

One clarification - it is not possible to pass credential IDs across different RPs to WebAuthn, to my knowledge.

Thank you @stephenmcgruer for the clarification!

It could only do something less effective, e.g. choosing only one RP for the call (or worse, try each RP in turn in a different flow).

I wonder on what condition the browser would choose the RP for the call. Such approach does not seem correct to address the issue outlined by @fahads9. OS I think trying each set of Credential IDs grouped by RP ID is unavoidable, but I'm not familiar with platform and/or CM APIs so it's hard to tell.