Authentication on the web is currently handled in the following way: anyone can install a server that will authenticate users on the web. The problem is interoperability. If a client (an application) wants to authenticate a user, it has to be approved by the authentication server. This goes against the principle of permission-less innovation, which is at the heart of the web.
In the decentralized authentication web, the best attempt so far is that of ActivityPub. All servers are interoperable with respect to authentication: if user A emits an activity, it is forwarded by A’s server to its recipients, and A’s server is responsible for A’s identity.
There is one key problem left with this approach. Applications are not yet fully interoperable. For the example, if you have a hundred friends, and want to share an activity to them (but not make it public), you could send it and copy it to all of your friends’ servers. This makes 100 copies of everything you do on the web. This is not great, because then you won’t be able to easily update it, for instance.
What you could do is send just a link to your friends, and host the activity on your web space. You do not want to make it public, and you also don’t want to protect it with a password, since it would just move the problem of copying the password instead of copying the contents. If you only let your ActivityPub friends read your activity, only their servers will be able to load it, so they will not understand most of it. If a clever application wanted to mix data from different places, it would need to get the authorization of all activitypub servers that you use. Since applications are tied to the data they manage, this is inpractical.
There would be a need to store all the data on the same place, and give different people different kinds of access to it. However, this requires that the same client is used for all kinds of data. Due to the lack of support for user certificates on major web browsers, it is not possible to use the user’s browser as the activitypub application.
In the Solid ecosystem, there is a clear distinction between servers and applications. An application is free to read data from all places at the same time, using a permission-less authentication system. Since the applications do not need to store data, the cost of having users is neglectible, so users do not need prior approval before using them (making captchas and the like a thing of the past). Servers do not have a say in which applications the user uses.