Clients should be required to support `need_info` section of UMA2 to better meet authorization goals

As per the current Solid-OIDC draft sec 9.1:

Authorization Servers SHOULD implement User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization [UMA].

However, there's no equivalent of

clients MUST (SHOULD?) have support for UMA2 interaction workflows

If the client doesn't understand UMA2 (in particular, need_info etc), the client wouldn't be able to fulfil UMA2's authorization requirements, culminating in a 401/403. Or am I reading UMA2 specs incorrectly?

This puts the Pod Provider in a spot. One can easily see the users complain that (non-UMA2) clients work with other pod providers, but not this server (which supports UMA2). This disincentivizes pod providers to support UMA2, while placing no incentives for clients to support it.

Given that Solid-OIDC concerns itself only with authentication, and not authorization, as stated by @acoburn in #158, the recommendation for servers to support UMA2 seems either out of place, or should be done only in conjunction with requiring clients to support UMA2. Personally, I'd prefer the latter.

Start with Solid-OIDC draft section 9.1 and the UMA2 references linked in the issue, then review the discussion in #158. Compare the server recommendation with UMA2 client interaction requirements, especially need_info. Done means reaching a clear normative decision and identifying the corresponding specification text to change.