[Openid-specs-fapi] EUIDW-4-Payments update: dropping OAuth

[Anders Rundgren]

On 2024-07-03 20:12, Anders Rundgren wrote:
> On 2024-07-03 18:41, Joseph Heenan via Openid-specs-fapi wrote:
>> Hi Anders
>>
>> I’m unsure what point you were trying to make, but for clarity this flow is still based on OAuth2. (It uses OpenID for Verifiable Presentations, which is built on top of OAuth2.)
>>
>> I guess you may mean it’s not based on a standard OAuth2 authorization code flow with the bank.
> 
> Indeed, the revised flow has no resemblance to OAuth2.

This is (IMO...) a good move [*].  However, the reliance on "Signed Payment Request" will most likely prove to be a genuine blocker.

In pure frustration over this *extremely poor* API extension concept, I built an alternative some years ago. Now it is time to dust it off: https://github.com/cyberphone/open-banking-2.0?tab=readme-ov-file#open-banking-20

According to my sources, banks already build on similar concepts for internal services, so this project is "merely" about streamlining and standardization.

Note that there are no conflicts between Open Banking 2.0 and FAPI; they operate at different levels.

Anders

*] Although using existing Open Banking APIs would have been an option, DigitalLabor [probably] didn't consider this since "Signed Payment Request" seemed like a cooler idea.  I guess the Berlin Group recommended it as well since this is exactly the kind of applications it was designed for :)

> 
> Regarding Verifiable Presentations, it is a bit of a misnomer since Merchants are not verifiers.  In fact, the Payer (PSU) has no direct contact with the actual verifier at all.
> 
> Anyway, this is just the beginning.  With respect to FAPI, the lack of a suitable Open Banking API may be worth looking into.  The Berlin Group's take on this matter, is simply put too awkward to ever become mainstream.
> 
> Anders
> 
>>
>> Thanks
>>
>> Joseph
>>
>>
>>> On 2 Jul 2024, at 23:19, Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
>>>
>>> Apparently the EUIDW folks finally realized that OAuth is the wrong solution for wallet-based payment authorizations:
>>> https://github.com/digitallabor-berlin/eudiw-sca/blob/ea5db12b59f583f79e3c866896565fa6c93ae2e4/openbanking-r2s.md#payment
>>> That is, a PISP is now just a backend process, technically no different than Stripe & Co, while the wallet only communicates with the Merchant.
>>>
>>> My review of the update:
>>> https://github.com/openid/OpenID4VP/issues/180#issuecomment-2203209092
>>>
>>> Anders
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-fapi mailing list
>>> Openid-specs-fapi at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>
>> _______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-fapi
>