Got it. So, the easy (though not exactly optimal) short-term answer is to have the application log in using those credentials, via the /login endpoint, and then just use the obtained cookie with its requests.
For an example of how to do that in code, take a look at the performLogin function in solid-cli (that function uses username + password credentials, but the same logic would apply with a WebID TLS certificate as credential).
The proper way to do this would be… well, it depends. There’s two basic options that come with trade-offs:
1 - User Token approach
A long-lived WebID-OIDC access token, which is a mechanism where a user delegates access to the app. This is a common pattern with app delegation; for example, Facebook calls this User Access Token. The benefit of this approach is that the app itself does not store the user credentials. The downside is that a human has to be involved (at least during app setup) to enter in their credentials. This is kind of like whole-disk-encryption – it’s great, and secure, but it’s annoying that a sysadmin has to be present every time the server reboots (to enter in the encryption password). This option can be done right now, with no alterations to Solid Server. (although we can probably add a nicer UI for a developer to register their own app).
2 - App Token approach
Giving an app its own credentials, its own identity. For example, Google does this with their Service Accounts (see their guide on Server to Server Applications), and Facebook does this with App Access Tokens. The benefit of this approach is - again, the app does not store user credentials, and it’s possible to have fine-grained permissions just for the app, separate from the user. But that’s also the downside, since you have to modify your ACLs to specifically give access to the app. (Notice that both Google and Facebook specifically limit what an app access token can do, it has many fewer privileges than a user token.)