OAuth is merely a way to authorize access. Depending on which scopes are requested, it could be a one-off request. Typically in webapps, access is assumed to be a one-off unless the "offline_access" scope is requested for example.
Furthermore OAuth would improve recurring payments - the website can request a max payment amount or frequency and the user (on their bank's authentication page) can further constrain those settings if needed.
No - access is assumed to last for a session. It is explicitly not one-off. "Offline access" allows the grantee to request new tokens without further input from the granter (via refresh tokens); it does not mean that access tokens can only be used once.
3-D Secure already allows users to grant one-time requests, without the song and dance of a useless access token.
> the website can request a max payment amount or frequency and the user (on their bank's authentication page) can further constrain those settings if needed.
I fail to see how this is a feature of OAuth specifically.
Through proper scoping the "session" can be boiled down to "this single payment request, for X merchant and Y amount", so not a problem in practice?
> 3-D Secure already allows users to grant one-time requests, without the song and dance of a useless access token.
3D-Secure is terrible implementation, requiring the user to input potentially sensitive data into (what looks like) an iframe on a potentially untrusted webpage. There's no guarantee the 3D-Secure frame you see is real. OAuth in contrast relies on redirecting to your bank's website, so provided you check the domain and HTTPS is not compromised you can be guaranteed you're talking to your bank and not an impostor.
3D-Secure also relies on the device you're making the payment on be capable of running a web browser and accepting user input. It's impossible to use on certain devices (TVs, etc) while OAuth supports alternative flows for exactly this purpose.
> I fail to see how this is a feature of OAuth specifically.
OAuth already supports requesting specific scopes and passing arbitrary metadata to the auth server, where as 3D-Secure authenticates the current transaction but otherwise you're still just handing over a card number and given the number is typically the same everywhere, the bank has no easy & reliable way to enforce per-merchant limits.
Why do we need to switch from a system that already meets the requirement to one that needs to be limited via implementation to achieve the same thing?
> 3D-Secure is terrible implementation...3D-Secure also relies on the device you're making the payment on be capable of running a web browser and accepting user input.
I see the problem here - you are conflating protocol with implementation. Nothing about the 3-D Secure protocol requires an iframe, a sketchy webpage, or entering a password (much like nothing about the OAuth protocol requires that the provider uses the same domain they use for day-to-day operations to handle auth requests) - in fact, 3DS2 supports out-of-band authentication.
If a protocol has flaws, that's typically a call to update the protocol (as OAuth itself was updated from 1.0 to 2.0, and as 3-D Secure has been). It's usually not a call to switch to a different protocol that's not actually made for the use case in question and needs to be stretched to fit. Again, the problem of transaction approval is explicitly not one of access delegation (and not every security problem can be framed as one of access delegation).
> OAuth already supports requesting specific scopes and passing arbitrary metadata to the auth server...the bank has no easy & reliable way to enforce per-merchant limits.
Much more information than just the card number is passed along when you make a transaction using a card, including information used for things like risk assessment and rewards programs.
Maybe this is a cultural difference, but it's simply absurd to me that one could think that their bank of all entities has no insight into their card transactions. That there's no trendily designed UI on a system/dataset does not mean it does not exist.
