Chase moves to Open Banking API

[Jack]

On 2022.10.08 17:04, Dawid Wrobel via KMyMoney-devel wrote:
> On Sat, Oct 8, 2022 at 10:27 PM Jack via KMyMoney-devel <
> kmymoney-devel at kde.org> wrote:
> 
>> While direct connect using ONLY name/password may not be considered  
>> safe, I can think of ways to still use Direct Connect with 2FA.  For  
>> example, any attempt to make such a connection triggers a text to a  
>> mobile phone, where you can reply "Y" within some limited time to  
>> authorize the connection.  A variant is something that Heroku uses  
>> (owned by Salesforce, it's hosting site for web apps) which is a  
>> custom phone app.  When you try to log in to their site, the app  
>> pops up and you click OK or not, to allow or block the login from a  
>> browser.
> 
> That's exactly how these "Open" APIs work. That's not the problem,  
> actually, we could totally use those APIs instead of Direct Connect.  
> The problem is the added requirement of being a pre-authorized entity  
> via on-purpose-issued certificates, as opposed to a regular TLS  
> encryption.

That's not my understanding.  I've seen mention of a one time  
authorization for the bank to give your data to Intuit (and I'm still  
not sure where Yodlee fits in.)  It sounds to me that when you request  
data in Quicken, it talks to Intuit.  That purpose-issued certificate  
you mention is used to secure the connection between Intuit and the  
bank, but it means your data does flow through Intuit.  (I don't really  
trust Intuit much more than I trust Yodlee.)  Even if KDE/KMM could  
become such a pre-authorized entity, I don't think we want to become  
that type of middle-man.  In addition, what is now the authentication  
between your copy of Quicken and Intuit?  If that uses 2FA, great, but  
I haven't heard so.  If it doesn't, then the added security is only  
between the bank and Intuit, not between you and Intuit.

I'm sure I"m missing something, and I'd love to see a more detailed  
description of how it all actually works.

Jack