Hi Aran, all very good questions, thank you
Only apps that you have given access to your data will be able to see it. Once a third party developer has received your data, there is nothing we can do to guarantee it won’t fall into the wrong hands. This is similar to you giving somebody a bank statement today to prove your identity. That party could now go and steal your identity using information on the statement. I think we can do a combination of a few things to protect our customers:
Establish the identity of the app developer through a KYC process. If anything goes wrong they won’t be able to just disappear
Allow our users to share very granular bits of data and possibly time-box them. E.g. if you apply for a loan on a website and “connect with Mondo”, they only need access to your data for a short period of time
Make it very easy for our users to see and revoke previously granted permissions
Educate developers how to securely deal with customer data. Incompetent developers are a bigger threat than malicious developers
How the approval process will work exactly is still unclear. Especially because in a PSD2 (the European Payment Services Directive that mandates banking APIs) world it may be the FCA/regulators that need to approve third party developers, but they don’t know how exactly that would work, either.
I’ve responded to the TAuth article over at Hacker News: https://news.ycombinator.com/item?id=11637128 The short answer is that OAuth 2 and client side certificates aren’t mutually exclusive. Client side certificates also aren’t the only way to defend against that kind of MITM attack. The entire HN thread has some really good input from other people, too, including a post from @oliver about a more secure OAuth implementation.
Our API is only a prototype and doesn’t allow you to move money, open accounts, etc… As we add those more dangerous capabilities we’ll look to mitigate the attack Stevie describes.
Hope that helps