[Spec] SPC is overly restrictive on what constitutes "third party"

[stephenmcgruer]

In #327, @nsatragno pointed out that we are being overly restrictive in SPC with regards to what origins can 'claim' webauthn credentials for example.com:

This seems more restrictive than what you want.

subdomain.example.com can claim example.com on a regular WebAuthn request. Shouldn't it be allowed to pass all the same extensions as in a normal WebAuthn request?

What about related origins?

Her comment was in reference to that pull request, but it applies to existing SPC spec text, see https://w3c.github.io/secure-payment-confirmation/#ref-for-steps-to-silently-determine-if-an-spc-credential-is-third-party-enabled where we again say "If the data["rpId"] is not the origin of the relevant settings object of request".

We need to update the spec to match WebAuthn behavior as to what other origins can "claim" credentials for a given origin.

[ianbjacobs]

Let's put this on the 2 July agenda.

[davidbenoit]

I do like the idea, and alignment with webauthn, but there are many 3rdparty bank service providers that run using subdomains (ex: of investment partners, payment partners, bill payment services, etc.). So example.bank may have invest.example.bank, pay.example.bank, bill.example.bank. It may seem reasonable to share credentials, it may not be reasonable for these subdomains to claim being the issuer. It may be true (likey WILL be true) that banks would use a 3rdParty for SPC, but a subdomain like banal.example.bank has no business being able to make that same assertion.

Inclusion of these subdomains requires the owner of example.bank to create the DNS records, but that owner should also have a mechanism to restrict which of those subdomains can act in this way. Maybe something similar to how SFP records would could be applied here?

[stephenmcgruer]

Thanks for the input david! I'll try to dig in myself to understand this area better, but in the meantime @nsatragno may have thoughts as my local friendly WebAuthn expert :)

[nsatragno]

So example.bank may have invest.example.bank, pay.example.bank, bill.example.bank. It may seem reasonable to share credentials, it may not be reasonable for these subdomains to claim being the issuer.

Relying parties should be checking the origin field on the WebAuthn response to disallow assertions coming from origins they don't trust, which could include their subdomains. The relying party ID validation mechanism functions mainly as a protection for users against tracking. It is not designed to provide security for assertions coming from untrusted domains. And, payment credentials can be asserted from subdomains just fine today through regular WebAuthn requests.

My understanding is that the only thing the extra payments specific restriction achieves is preventing payment credentials from being created with RP IDs that would otherwise be allowed by WebAuthn. Of course it's your call what SPC should do, but I find it a little strange that SPC has that added restriction.

[stephenmcgruer]

Thanks Nina!

Relying parties should be checking the origin field on the WebAuthn response to disallow assertions coming from origins they don't trust, which could include their subdomains.

How does this work for extensions such as largeBlob, which can contain private information? Are those explicitly scoped to the exact RP, or could a subdomain read and write the largeBlob data for their 'parent' origin?

[nsatragno]

That is where the "mainly" caveat comes from. The RP ID is load bearing in terms of security for extensions that store secrets on keys (large blob, prf, cred blob). This happened somewhat accidentally.

But I'm not sure that's particularly relevant for SPC.

[stephenmcgruer]

But I'm not sure that's particularly relevant for SPC.

It's not, I was just curious to understand why origin-claiming wasn't a security issue there. Thanks for explaining :)

[ianbjacobs]

We discussed this at the 16 July 2026 call and there were no objections to aligning with Web Authentication. At this point, the next step would be to do a pull request to update the specification.