Should Solid-OIDC mention RFC 8707 OAuth 2.0 Resource Indicators ?

[NSeydoux]

This question comes from experimenting with node-oidc-provider, the OIDC Provider component used in the Community Server. In its latest version, node-oidc-provider bases its support for JWT-formatted Access Tokens on OAuth Resource Indicators (see RFC 8707: by default, the OP returns opaque Access Tokens, and it may be configured to return JWT Access Tokens instead based on the Client-specified Resource Indicator. It is also possible to provide a default indicator to be used in the case when the Client does not specify any Resource Indicator.

While this is a specific use case which does not mandate a spec change, I found it an interesting consideration. The assumption in the RFC seems to be that there is an a-priori knowledge of the RS the OP is issuing tokens for, which does not apply in an ecosystem such as Solid. However, in the same way that the spec mandates that a Solid-OIDC compliant OP should emit Access Tokens with the value solid as their audience, it may include a recommendation for an IRI identifying all of Solid RS, rather than the Clients trying to guess which RS they will be interacting with, or each OP coming up with ad-hoc ways of identifying Solid-compliant RS. The RFC mandates that the Resource Indicator is an IRI, so I guess Solid-OIDC could include a MAY suggesting to use something like http://www.w3.org/ns/solid/ for a Resource Indicator if the Clients desire so, and the OP may use it to make a distinction between Solid and non-Solid RS. The Client-provided Resource Indicator does not need to be used as-is in the audience, so keeping the current solid audience is not an issue, even though it could be considered making it the same IRI.

Do you think such an addition is worth considering, or is it preferable to keep these specifications completely orthogonal and leave it up to individual OP and Clients to use Resource Indicators as they see fit ?

[NSeydoux]

Some discussion happened during a weekly meeting which is relevant to the current issue.

To summarize, an architectural change is being considered, where the authentication and authorization would be properly separated. This means that Solid-OIDC would only deal with authentication, and would not issue access tokens, which are means of getting authorization. Instead, each resource server could elect an authorization server they would rely on to enforce access control. The authorization server would consume the ID token issued by the Solid-OIDC identity provider, but could also receive any range of additional claims. In this context, the authorization server may implement OAuth 2.0 authorization.

In this context, the current issue would be out of scope for Solid-OIDC, as it is relevant to the creation of the access token, and not the ID token. However, should some OAuth providers become trusted authorization servers by some Solid Resource Servers, it still makes sense to suggest a unified way to denote the intention to use a given access token against some Solid Resource Server.

[elf-pavlik]

Thanks for posting the summary @NSeydoux

We could consider transferring this issue to AuthZ panel.

[woutermont]

@NSeydoux, I've read the notes of the meeting of August 30th, but I fail to see the rationale of restricting Solid-OIDC to authentication, just to come up with an elaborate new structure for authorization that relies on the same kind of AS.

As I have also tried to argue in solid/data-interoperability-panel#139, Resource Indicators would indeed be a good candidate to use within Solid-OIDC. Apart from identifying the Solid ecosystem as target 'resource', the indicators could also be used to agree on the shapes and/or shape trees a client can access.

[acoburn]

There are several issues to unpack here.

I fail to see the rationale of restricting Solid-OIDC to authentication

OpenID Connect is a specification that deals with identifying agents (authentication). Solid has historically used the access tokens that are generated by an OpenID Connect server. This has two consequences:

• The OIDC access tokens are extremely powerful. They can be used for access across the entire Solid ecosystem. There are legitimate concerns about exfiltration of these tokens. (DPoP does help)
• By relying on OIDC for access tokens, it means that Solid necessarily restricts itself to identity-based access controls. And while Solid has historically made use of identity as the basic unit for access control, that is not the only way to structure an access control system. Capability-based systems provide a powerful complement to identity-based systems. With Verifiable Credentials becoming more widely used, a purely identity-based access model will ultimately become a limiting factor for Solid
• Arguably, OIDC access tokens are only intended for endpoints on the given OIDC server. Following that logic, using these access tokens to gain access to resources in Solid is a mis-use of OpenID Connect.

just to come up with an elaborate new structure for authorization that relies on the same kind of AS

That elaborate new structure is rooted in widely deployed, existing practice with OAuth2. If anything, this new structure is more in line with how authentication and authorization work on the Web today.

Furthermore, supporting capability-based authorization is not possible with a purely OIDC-based authorization mechanism.

I would add that, from the perspective of Solid-OIDC, we should keep that specification focused on authentication; we cannot simply pack more and more features into a single specification, especially when those features are out of scope.

[woutermont]

I definitely agree that Solid-OIDC should be focussed on authentication, not authorization, and that using identity tokens to do so would be cleaner than using access tokens; no argument there. What I wondered was primarily why a complete overhaul of the authorization part would end up centralized around RS-linked OAuth2, while the latter is already present in all IDPs compliant with Solid-OIDC.

[elf-pavlik]

Arguably, OIDC access tokens are only intended for endpoints on the given OIDC server. Following that logic, using these access tokens to gain access to resources in Solid is a mis-use of OpenID Connect.

To my understanding access token issued by OP is intended to be used with UserInfo endpoint. This is information about authenticated user so in that case it makes sense.

Using terminology of GNAP Roles, we have two distinct roles: End-user (the one using the client) and Resource Owner (the one who owns the data). Even GNAP tends to assume that they will often be the same party but in solid having those two different is a very common case.

Given different End-user (EU) and Resource Owner (RO), Resource Server (RS) stays associated with Resource Owner not the End-user. In that case I think Authorization Server which issues Access Tokens that are used with RS should also be associated with RS & RO rather than EU.

On the other hand, besides identity we often also want to authorize clients. Solid Application Interoperability 6. Data Authorization aims at addressing that issue. Its currently being refactored but in short. End-user gives a consent for access specific data, for some of it they also act as Resource Owner, for rest of it they do not. That consent can be translated into granular grants, one per target RS. Relevant grants should be provided to RS associated AS. That RS & RO associated AS already knows User Authrization details provided by RO, receiving the grant it will also know Client Authorization details provided by EU. Combining those two now it can coordinate with RS, which who they have bi-directional trust, how to enforce both User and Client Authorization.

Sequence diagram in solid/solid-oidc/pull/18 currently misses the EU associated party that would gather client authorization consent from end user (Interop Authrization Agent). In Interop Primer sequence diagrams I'm actually starting with UX friendly scenario when it is indeed combined with IdP and user faces single combined consent screen. Still as in solid/solid-oidc/pull/18 IdP and Interop Authorization Agent both stay associated with End-user. Tokens id token and data grant should be exchanged with RS associated AS, and final Access Token should be obtained from there.

Approach above also gives a lot of flexibility on how AS and RS, who again have bi-directional trust, can coordinate on enforcing both user and client authorization. Some implementation can have them as part of the same monolith, others can use microservices etc. I'm not 100% sure here but possibly some of them could internally use ACP, others WAC, others something else (for example just rely on data grants), since RO communicates with AS of their choice and 'data grant' uses independent format to represent client authorization.