Trying to understand Solid-OIDC better

Solid-OIDC primer から始め、UMA のステップと、OIDC の aud claim に solid を含める要件を追跡します。これらの要件を、提案されている key-pair、ID-token、DPoP のフローと比較します。仕様ドキュメントで互換性に関する疑問とセキュリティ上の根拠に回答または明確化がなされれば完了です。

I'm working on a decentralized app and Solid-OIDC is very close to the type of authentication system I need, and I'm wondering if I can adopt it instead of doing a home-grown system. Sorry this turned out long but I would appreciate any answers.

My current design is essentially:

1. Client app creates a key pair, hashes the public key, and uses that key as the nonce in an OIDC flow with any OIDC provider (Google, GitLab, LastLogin, self-hosted, etc). The goal is for the OIDC provider to certify (perhaps unwittingly) that the sub owner controls the key pair, a la OpenPubKey.
2. When the app makes requests to backend servers, it includes the ID token and a DPoP header for each request. Assuming the backend trusts the OIDC provider, requests are now authenticated, without requiring a previous relationship between the app and the backend server.

After reading through the Solid-OIDC primer, I see a couple areas of incompatibility due to extra steps. Since with auth extra steps often indicate potential security holes, I want to make sure I understand why they're necessary in the Solid case:

1. Why is the UMA step necessary? My understanding is the purpose is that Alice could define specific permissions for Bob, then when Bob gets a token it's scoped to those permissions. But won't he always get the same permissions? Why not skip UMA altogether and just verify it's Bob making each request using a method similar to what I described above?
2. Why is it necessary for the OP to add solid to aud? Does it matter if Bob wants to use his key pair to interact with multiple backends and multiple protocols? The main downside I see here is you can no longer use any OIDC provider, but must use a Solid-OIDC provider.