Closed cyberphone closed 3 months ago
Sakurann
commented
3 months ago I don't think the proposal is to replace all steps 1-11 with OAuth or wallet-based model. If my understanding is correct, the proposal is to use OpenID4VP + transaction data in steps 2~5 in the diagram, when the user is being identified and user authorization is being gathered. (equivalent to this diagram in digitallabor-berlin document)
cyberphone
commented
3 months ago The following relates to this version of the specification: https://github.com/digitallabor-berlin/eudiw-sca/blob/79bdb6ef3f5a074e0e8da7c9adbb8951d3baded0/openbanking-r2s.md.
Since this is an extremely complex topic, touching many different areas, including technical, regulatory, political, "theological", and commercial issues (and thus not overly suited for GitHub discussions), I will (try to) keep it brief 😉 If we stick to step 2-5, the second UI departs from how other wallets work. This is probably due to fact that in other payment authorization systems, Merchants are not relying parties of identities or credentials, but of money. That is, "when the user is being identified" would violate privacy by design principles. Based on the current specification it is not particularly clear what the authors had in mind with "verification" by the Merchant (Payee).
Anyway, the bigger problem is actually in the other end: the monolithic nature of the Open Banking architecture promoted by the https://www.berlin-group.org/ is difficult to combine with new (and probably not entirely mature) developments, like the EU Identity Wallet. As an example, an EMV implementation was envisioned already back in 2020, but has not yet materialized. FWIW, I'm working with an Open Banking 2.0 architecture which should make the integration of arbitrary wallets, magnitudes faster and cheaper.
cyberphone
commented
3 months ago @Sakurann I don't know where this discussion should be held, but the mentioned specification requires more than twice as many protocol steps while offering half of the functionality compared to the almost 30 year old EMV standard (after applying a very modest update).
Maybe a more neutral party like https://www.sprind.org/en/ could take the lead? In particular, the two quite different ways of performing SCA (for payment authorizations only NB), would IMO greatly benefit from an independent study.
This matter seems a bit urgent since it has profound impact on the entire project, including the associated Open Banking API. @tlodderstedt
cyberphone
commented
3 months ago For the market (who neither care nor know anything about ARF, eIDAS, OAuth, EMV, Open Banking, SCA, etc.), the following picture is supposed to provide a reasonably fair description of the current status. For completeness, the "Gold Standard" is included as a reference.
cyberphone
commented
3 months ago This issue is really about the SCA-flow and its implications. Given the lack of interest in this topic, I think it is reasonable to close it.
cyberphone
commented
2 months ago Progress! The recently revised specification https://github.com/digitallabor-berlin/eudiw-sca/blob/ea5db12b59f583f79e3c866896565fa6c93ae2e4/openbanking-r2s.md seems like a MAJOR update.
The previous ultra-complex flow which was "sort of" OAuth has apparently been abandoned. The current flow is now close to a carbon copy of "EMV on steroids". The only notable difference is that in my proposal, payer authorization requests are unsigned. There are many and good reasons for that.
Payment authorization now only requires a single biometric/PIN step 😁 However, the spec. still talks about "Wallet asking the payer to consent to the presentation of a payment credential..." which is wrong. Merchants are not relying parties/verifiers. In addition, payer authorization is not about "presentation" of a payment credential, it is about using it, including its associated signature key.
A huge improvement is that the spec. now acknowledges that there is currently no suitable interface in banks:
Although currently there is no out of-the-box support for payment initiation using a verifiable presentation in existing OpenBanking standards like the Berlin Group yet, they already specify very similar concepts using a so called "signed payment request" within their Protocol Functions and Security Measures document for the OpenFinance framework, section 7.1
This is a horrible solution that I was personally involved in developing mid 2020 😱 Before publishing, I asked the ad-hoc WG to remove my name from the spec. since I had (during the work...) found a more agile concept which I also have tested in practice: https://cyberphone.github.io/doc/defensive-publications/openbanking-evolution.pdf AFAIK, the Berlin Group doesn't build PoCs. @tlodderstedt @Sakurann @selfissued
cyberphone
commented
2 months ago Since the DigitalLabor specification have over a period of only 6 months, gone through 3 completely different iterations, it seems that things are in flux, and would benefit from being spun off: https://github.com/openid/OpenID4VP/issues/188
I hope nobody takes offence but traditional payment authorization systems like EMV (as well as Apple Pay), perform SCA (Strong Customer Authentication) in a very different way than schemes based on OAuth. The sequence diagram below should give you an idea. Core features of this flow include:
In short it works like this: In step 4 a payer authorization object is created and then pushed (by the Merchant) onto the (for the selected payment credential suitable) payment backend for processing. Eventually the payer authorization object ends up at the Payer Bank (point T) where the actual verification takes place. More details can be found in: https://cyberphone.github.io/doc/saturn/saturn-core-flow.pdf.
The only drawback I'm aware of is that PII-related authorization data (like account and signature key id), must be encrypted. To maintain privacy, the encryption [public] key must be shared by multiple Payers. Merchants and payment intermediaries only need to know the end-point to the Payer's Bank and the payment method associated with the selected payment credential.
Although I have not tested it, using BLE, the Wallet should work without Internet connectivity, like payment cards always did.
That this flow isn't aligned with OAuth is not only due to historical reasons, but to the fact that the Merchant represents an additional entity, not covered by OAuth-based standards.