Consider additional context on AS / UMA

In the recently submitted iteration of the Solid-OIDC specfication there are references made to an Authorization Server that SHOULD implement a UMA 2.0 Grant for OAuth 2.0 Authorization (UMA).

Specifically:

In Authorization Server Discovery:

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

In Obtaining an Access Token:

For Authorization Servers that conform to [UMA], the http://openid.net/specs/openid-connect-core-1_0.html#IDToken profile MUST be supported. This profile MUST be advertised in the uma_profiles_supported metadata of the Authorization Server discovery document User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization § rfc.section.2.

When using the http://openid.net/specs/openid-connect-core-1_0.html#IDToken profile with an UMA-based Authorization Server, the Authorization Server MUST be capable of exchanging a valid Solid-OIDC ID Token § 8.1 DPoP-bound OIDC ID Token for an OAuth 2.0 Access Token.

Note: Clients can push additional claims by requesting an upgraded RPT User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization § rfc.section.3.3.1

Authorization Server MUST pefrom § 9.3 DPoP Validation and § 8.1.1 ID Token Validation

I don't believe any more normative detail needs to be added to the Solid-OIDC specification on this subject - but I do think that non-normative supplementary context should be provided to support adoption by developers of Solid-OIDC implementations and the users of those implementations, possibly in a separate document.

For example, Solid Community Server bundles in an existing OpenID Provider that conforms to Solid-OIDC. It would seem that to be fully conformant they would also need to bundle in an AS that implements UMA. Client-side authentication libraries would similarly need some adjustment. I'm sure an overview detailing these considerations would be useful and welcome.

Consequently, it would helpful to showcase the real benefits of a UMA flow in the primer, separately from a "classic" Solid-OIDC flow. I know that the Primer accurately reflects the changes in the specification, but it does little to demonstrate the benefit of them. A second "robust" flow that showcases those benefits could help motivate implementations to fully support this functionality.

Start with the Solid-OIDC sections on Authorization Server Discovery and Obtaining an Access Token, then review the Primer and the linked UMA flow. Done means adding non-normative implementation context and a separate UMA-based example flow that explains its benefits without changing normative requirements.