SPC Security Analysis #1584
Description
Follow-up to: #1579
A current W3C project known as Secure Payment Confirmation (SPC), combines a Browser-resident payment application, FIDO/WebAuthn, and 3D Secure. This solution has AFAICT, not been subjected to a peer review regarding security from a payment system point of view. Since the current specification is close to unreadable (it is a sequence diagram crammed with text), the following analysis may indeed be completely wrong.
Anyway, SPC builds on 3D Secure which is a separate card-holder authentication step performed before the actual payment request. Mapped to SPC I assume that this is how it works:
ACS is a special purpose FIDO server that verifies assertions (which also contain pieces from the payment request rendered by the built-in payment application).
It seems to me that in SPC as well as all other 3D Secure implementations, the Merchant is the actual relying party although of course the issuer also indirectly benefits from this.
I'm at loss understanding what the payment request assertion data adds to the pudding beyond proving WYSIWYS to the Merchant. This departs from most other signature schemes where WYSIWYS is primarily of concern to the "ultimate" relying party.
In theory there could be some kind of correlation between the ACS and the Pay service but that would require a lot of changes and also leaves you with the question: why complicate things with multiple steps?
How does the Issuer know that the card-holder actually have been authenticated?
As a contrast, the system that powers payments in the physical world (EMV), only requires a single step and makes the Issuer the sole relying party. That is, EMV builds on a true end-2-end security model.