solid
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].
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.
I think a part of this issue is covered by specifying/clarifying conformance classes - in issue https://github.com/solid/solid-oidc/issues/20 .
