Verification of certificate trustworthiness (e.g. in JWS and Client Certificate)

I am comparing implementation complexity of JWS and Client Certificate and troubleshooting Client Certificate at the same time.

I understand that both methods require to prove that the certificate (x5c in JWS or the actual Client Certificate) is trustworthy (as per https://tools.ietf.org/html/rfc7515#section-10.3). How should this validation process be achieved? Where do I get the root certificate from if I wanted to extract public key from the root?

For JWS I intended to hold a copy of a certificate (or at least its public key) in application memory. Before I validate the signature wih x5c certificate, I would validate the certificate itself. Is this correct approach?

For Client Certificates – the plot thickens, especially in my scenario (*) and it is not transparent to me since it is handled by HTTP server, not by my application, therefore I believe it can differ between server implementations, unless there is some standard? RFC5280 Section 6 on Path Validation cover this? My HTTP server expects me to install a “client certificate” (yes, on the server) and I am curious what the validation procedure would be (what is compared – just the keys or entire certificate, maybe just the root certificate?) and why it cannot use the same certificate that is already used for authenticating the server/domain (since they share the root certificate). In reality, each client has been issued their own certificate (with a shared root), so which client certificate am I expected to provide? Should I provide 1K client certificates for 1K clients?


(*) I am not a CA that self-signed client certificates, but they have issued a server certificate for my subdomain that is intended to handle the traffic. This means that I do not have direct access to private key and the root certificate.