Clients should be required to support need_info section of UMA2 to better meet authorization goals

[amodm]

As per the current Solid-OIDC draft sec 9.1:

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

However, there's no equivalent of

clients MUST (SHOULD?) have support for UMA2 interaction workflows

If the client doesn't understand UMA2 (in particular, need_info etc), the client wouldn't be able to fulfil UMA2's authorization requirements, culminating in a 401/403. Or am I reading UMA2 specs incorrectly?

This puts the Pod Provider in a spot. One can easily see the users complain that (non-UMA2) clients work with other pod providers, but not this server (which supports UMA2). This disincentivizes pod providers to support UMA2, while placing no incentives for clients to support it.

Given that Solid-OIDC concerns itself only with authentication, and not authorization, as stated by @acoburn in #158, the recommendation for servers to support UMA2 seems either out of place, or should be done only in conjunction with requiring clients to support UMA2. Personally, I'd prefer the latter.

[elf-pavlik]

To stay focused on AuthN we don't want to go beyond pushing a DPoP-bound ID Token.
I agree that UMA2-related requirements on client and server need to be written better. The main reason for their current state is the intention to support other claims pushing mechanisms besides UMA2. We already discussed adopting a similar approach as we have in Solid Notifications and Subscription Types. For Solid-OIDC we would have UMA2 as one of the claims pushing mechanisms which would have it's own mini spec with clear requirements on the client and the server. Other mechanisms would just need to provide similar mini specs. Given that we just need to clarify features discovery and negotiation.

This puts the Pod Provider in a spot. One can easily see the users complain that (non-UMA2) clients work with other pod providers, but not this server (which supports UMA2).

Currently, UMA2 is the only claims pushing mechanism mentioned by Solid-OIDC, what exactly do you mean by non-UMA2 clients?

[amodm]

I'm not contesting the focus on Authn, I agree with that fully. The way I understood Solid-OIDC spec and the discussions related to UMA2 is the following:

1. Solid-OIDC wishes to stay focussed on Authn, while allowing implementation providers the choice of the authorization mechanism, negotiated via the appropriate WWW-Authenticate header.
2. UMA2 is the suggested such mechanism, and as such the process of authorizing (e.g. limiting permissions for the client to a subset of user's ACLs) will be governed by UMA2's protocols

Now compare this with how UMA2 would likely implement authorization for Solid clients:

1. Client hits the resource URL, receives a 401 along with as_uri
2. Client hits the Auth Server, presenting the ID claim as received from user's OP
3. Auth Server determines (from the ID claim, and the pre-configured ACLs), which permissions/scopes are allowed for the user
4. Auth Server, implementing UMA2, also wants to formally give the user (RP) an opportunity to limit the permissions for this specific client, instead of allowing it to impersonate all permissions of RP.
5. The mechanism that provides this in UMA2 is need_info, which a UMA2-enabled client can understand and then initiate a user-interactive session with the AS. A client which does not understand UMA2 will not be able initiate this interaction.

As you can see, unless I'm wrong somewhere, it's not just about pushing the claim. It's more about the interactive authorization process. If the client isn't required to understand UMA2, I will be vary of enabling UMA2 as the authorizing mechanism in my server (note that I can still enable UMA2 for as_uri etc, without the need_info, but I lose out on the interactive authorizing mechanism).

The OAuth2 interactive process cannot help here, because as per Solid-OIDC the client initiates the Token endpoint directly, and not the Authorization endpoint (in case of resource server's AS).

[amodm]

A very related scenario is Authorization Panel sec 3.1.5

[amodm]

what exactly do you mean by non-UMA2 clients?

Currently, the Solid-OIDC spec does not require its clients to comply with UMA2. Yes, it calls out specific features of UMA2, e.g. as_uri, grant_type of ...uma-ticket etc, but to a reader of the spec, it seems more of leveraging bits & pieces of UMA2, and not compliance.

As an example of this, Solid-OIDC spec makes zero references to need_info, and the Primer mentions it only in the context of errors, not as a trigger for user interaction.

This gives an impression that I can create a Solid compliant client, without honouring UMA2's user-interaction protocols (need_info), while still doing the ID token push. This is what I meant by a non-UMA2 client.

[elf-pavlik]

Thank you for all the details @amodm I will see if we can arrange a panel meeting for next Monday and discuss it /cc @acoburn

It ties nicely into a direction where AuthZ would not require ID Token at all and the client shouldn't push it as a claim eagerly. The mini spec using UMA in Solid-OIDC should most likely build on need_info and required_claims.

Auth Server, implementing UMA2, also wants to formally give the user (RP) an opportunity to limit the permissions for this specific client, instead of allowing it to impersonate all permissions of RP.
A very related scenario is Authorization Panel sec 3.1.5

We are in a process of discussing Authorization Grants and reconciling them with Data Grants defined by the interop panel. This is out of scope for AuthN panel but we need to make sure that Solid composes all the specifications in a way that is consistent, this includes the usage of claims pushing mechanisms like UMA2.

[amodm]

@elf-pavlik just checking in to see if any progress was made here. I'd logged into the meeting a few times after this issue was created, but the meetings weren't happening at that time it seems.

[amodm]

This also fits in nicely with the objectives being discussed at solid/authorization-panel#46

I've modified the title to better reflect what I'm proposing here.