[Openid-specs-fapi] BG/Embedded SCA - Clinically free from OAuth

Torsten Lodderstedt torsten at lodderstedt.net
Sun Jul 26 15:52:21 UTC 2020



> On 26. Jul 2020, at 17:36, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
> 
> On 2020-07-26 16:18, Torsten Lodderstedt wrote:
>>> Am 26.07.2020 um 15:01 schrieb Anders Rundgren <anders.rundgren.net at gmail.com>:
>>> 
>>> On 2020-07-26 14:31, Torsten Lodderstedt wrote:
>>> <snip>
>>>>>>> The client is assumed to have a static and (per scheme) standardized payment credential, like in Apple Pay.
>>>>>> What is the client then in this approach?
>>>>> 
>>>>> There is no client in OAuth terms, the TPP is effectively a traditional backend processor:
>>>>> Merchant->User/Device // Request payment
>>>>> User/Device->Merchant // Authorize request
>>>>> Merchant->TPP // Commit payment order
>>>>> TPP->Bank // Initiate payment using a single authenticated & authorized request
>>>>> 
>>>>> Saturn takes this [since decades back established] concept one step further by replacing the TPP with a trivial identity service ran by the Merchant's Bank.  That is, reusing the four corner model.  I thought I was alone with this crazy/genial idea but I have recently found other folks pushing the very same concept!
>>>> But TPP and Akquirer act more or less similar, why do you consider the four corner model superior?
>>> 
>>> TPP and Acquirer will indeed be the same in the BG Embedded SCA proposal.
>>> 
>>> The "superiority" of the four corner approach is that the Merchant's Bank only vouches for the authenticity of the Merchant including its claimed creditor account through a light-weight discovery service. The latter also eliminates the reliance on eIDAS certificates, NCAs, and the PRETA registry.  The rationale is simply reducing costs and fuzz.
>>> Sample service: https://mobilepki.org/webpay-payeebank/payees/86344
>>> 
>>> Related: https://cyberphone.github.io/doc/research/casting-apis-in-stone.pdf
>> I think you are comparing apple to pear. Credit Card schemes are proprietary networks. Partipation is not opento everyone. Routing happens automagically within the network.
> 
> Now I don't know exactly what fruits you are looking at :-)  It was a mistake on my side mentioning Saturn in a discussion that was really about BG's Embedded SCA proposal which (if succeeding...) would make Open Banking payments comparable to Apple Pay.

Does this proposal delegate authentication and authorisation to the TPP? I’m asking since Apple Pay uses the local biometry whereas the BG Embedded Mode utilises the PSU’s credentials with the financial institution. 

> 
> In theory BG's EMV-SEPA profile would indeed permit arbitrary (but "certified") TPPs to take on the network business as an option to contracted service providers.
> 
>> Open banking in contrast is supposed to be open and to remove intermediaries. Certificates issued by trusted 3rd parties and directories are a necessary infrastructure for such an open system.
> 
> Eh...PISPs are not intermediaries?

Not if the party wanting to issue a payment IS the PISP. Technically, that would be trivial. It’s the heavy weight regulation (and the costs associated with it) preventing this scenarios. And the heavy weight regulation is partially needed because of the option to let the PISP handle the PSU’s credentials. Without that option, the rules to comply with would be more or less GDPR.

> 
>> Unfortunately, PSD2 is to heavy on regulation and to weak regarding openness and fostering of innovation. And the eIDAS certs were premature.
> 
> IMO, neither the regulators nor the technologists may have fully realized the huge differences between AIS and PIS.  The assumption seems to be that
> - Banks must offer account-to-account payment services for free to regulated TPPs
> - Banks are unable creating useful mobile payment systems
> - Cross-border fee issues is a thing of the past
> 
>> Btw: Are Akquirer required are to be TPPs?
> see above.
> 
> My turn for a question: do you think FAPI/OBIE should follow BG?

Why should we? The whole embedded stuff is contrary to any security best practice. 

best regards,
Torsten. 

> 
> Anders
> 
> 
>>> 
>>> Anders

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3946 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200726/3902faa4/attachment.p7s>


More information about the Openid-specs-fapi mailing list