Authorization server behaviour for Client-Credentials Grant flow

Context

For our use case we have a number of server-side applications which need to access resources in Solid Pods using an organisation-level WebID. Before, we used an oAuth 2.0 Client-Credentials Grant to authenticate with an OAuth AS that had support for DPoP, the webid claim and scope. This flow was implictly possible under an earlier definition of the spec as an Access Token was employed as bearer token throughout it (however OAuth discovery was broken, as the specification assumes the OIDC discovery URI to be used).

Problem description

With the recent revision of the Solid OIDC specification, we noted the use of an additional authorization service that is identified by the as_uri provided in the 401 error response of the storage endpoint. The specification however only explicitly mentions the OIDC ID token as a supported UMA profile, and not the use of Access Tokens.

Perhaps now is the time to clarify the specification and also permit the use of oAuth 2.0 Access tokens as first-class citizens (and not by coincidence as was previously the case).

Ways to resolve this issue

• Clarify how applications outside of a browser session should obtain the token necessary to authenticate with the authorization service.
• Add OAuth Access Token support as an explicit requirement for the authorization service.
• Or specify the requirements for the JWT expected by the authorization service in more abstract terms, rather than directly limiting it to concrete authentication standards (i.e. "a signed JWT with some claims X, Y and Z, which could be an OIDC ID Token or a non-opaque OAuth Access Token" )

Impact

• OAuth discovery URIs differ from OIDC discovery URIs in their format. The specification must then also clarify how to handle both of these for an issuer at the level of the authorization service, e.g. by differentiating through the claim_token_format.
• Perhaps it implies that the naming of the specification should be reconsidered, or that this capability has to be split out. But this is a broader discussion to be had, I think.

We can elaborate on this issue and our use case in a next Authentication Panel meeting if desired.

Start by reviewing the Solid OIDC specification sections covering the 401 response, authorization service, UMA profile, and claim_token_format. Compare the client-credentials use case with the current requirements and resolve whether access tokens, abstract signed JWTs, and OAuth versus OIDC discovery must be specified; done means the specification has one settled, implementable behavior.