Got drawn to the topic, however usage of authentication and authorization seem like misnomer here, the core topic seems to be data ownership
The concept on a surface level to have ownership over the data makes a lot of sense and to a large part the support exists in a fragmented manner across the different providers/applications.
The concrete idea of user having a database and then authorizing that to the service is highly impractical. It might be applied for experimentation purposes in highly controlled environment but cant scale beyond that.
1. Databases require maintenance, backups, failover
2. Schema update are nightmares. No one is ever comfortable with it, specially the bigger you are.
3. Authorization seems to be following one to many pattern here, one database and multiple applications. Its a no go in case of update operations
yeah the article is dumb.
Yes, it still does authentication. It's just about hosting the data, which might make sense for niche scenarios with well defined scope. Unfortunately, many data-driven systems need some kind of data sharing. Relying on data from multiple custodians is possible and could be cool but brittle if a single view is pulling data from many custodians. Also it would be impossible to run meaningful analytics on such scattered data... I guess that could be seen as a feature.
I think this may end up happening naturally over the next decade or so thanks to AI coding. People will just stick web components bound to different data sources on the same page without even realizing it. Data can be joined and chained together on the frontend. Some shared authentication standard like JWT with asymmetric key signatures could potentially facilitate that. Multiple data custodians could verify the same JWT using the user's public key... Account could be hosted on some blockchain so it's not centralized.