Consider additional context on AS / UMA

先从 Solid-OIDC 中关于 Authorization Server Discovery 和 Obtaining an Access Token 的部分开始，然后查看 Primer 和链接的 UMA flow。完成的标准是添加非规范性的实现上下文，以及一个单独的、基于 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.