[Federation] How can an explicitly registered client find out the client_id was invalidated or expired?

[Vladimir Dzhuvinov]

With explicit registration at an AS / OP the client / RP receives a client_id to use in the subsequent authorization or authentication requests.

https://openid.net/specs/openid-connect-federation-1_0.html#explicit

According to the OIDC Federation spec the client_id will become invalid when the trust chain expires, or when the AS / OP decides.

10.2.2. After Client Registration

A client registration using this specification is not expected to be valid forever. The entity statements exchanged all have expiration times, which means that the registration will eventually time out. An OP can also, for administrative reasons, decide that a client registration is not valid anymore. An example of this could be that the OP leaves the federation in use.

At present there is no direct way to signal this. If the client / RP makes a request the authorization endpoint MUST NOT redirect automatically back to the client, so the client has no easy way to find out what happened.

https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2.1

If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.

We encountered this issue during the interop in 2020. The client could guess and retry the explicit registration if it doesn’t hear from the AS / OP for couple of minutes, but this is horrible UX if the user is forced to wait and retry the request. I wonder what can be done here. At the time ppl were interested in the explicit client registration because it doesn’t require the client to host any endpoints (as is the case with auto registration).

One untested idea at the time was to return a registration_client_uri and registration_access_token familiar from OIDC Dyn Reg and RFC 7592, so the client could use those to check if its registration is still valid.

https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse

https://datatracker.ietf.org/doc/html/rfc7592#section-3

‌

[Vladimir Dzhuvinov]

Further observations:

Clients that use PAR may deduce their client_id is no longer valid if they receive an invalid_client error at the PAR endpoint: https://datatracker.ietf.org/doc/html/rfc9126#section-2.3

This is one viable work around that the current spec gives, of course if both OP and client support PAR.

I noticed this spec example includes a registration_client_uri and regisration_access_token, which as mentioned in my previous comment, could be used by the client to check if its explicit registration is still there https://openid.net/specs/openid-connect-registration-1_0.html#ReadError .

"registration_access_token": { "value": "nLe19cJ5e9SXXiPqnRRuxpjyWI73bDhD" }, 
"client_id": { "value": "m3GyHw" }, 
"registration_client_uri": { "value": "https://op.umu.se/openid/registration?client_id=m3GyHw" },

https://openid.net/specs/openid-connect-federation-1_0.html#rfc.appendix.A.3.2

What are the potential issues with this approach:

1) These two parameters are OPTIONAL , so an OP may not have them; 2) The `registration_client_uri` is prohibited per spec from returning a clear stated status code (404) on invalid regisration; 3) The registration may expire in the time window between the check and prior to the authorization request → bad UX.

The federation_registration_endpoint could be specced to to support client_id checks in exchange for a credential, but this will also suffer from issue 3 above.

My conclusion is that for best & reliable UX clients should use PAR, because it wraps the client_id / authentication and the authorisation request into a single “transaction”. Providing an additional endpoint for the purpose of checking the client_id will not work well as UX.

‌

[Giuseppe De Marco]

I think that’s resonable suggesting PAR for the implementers of the explicit client registration

[Michael Jones]

As discussed on the 14-Jul-22 working group call, we could add text saying that a way to determine whether a client is still valid is to use PAR.

[Michael Jones]

We discussed this on the 19-Aug-22 Federation Editor’s Call. This is really an issue about Connect itself - not Federation.

That said, any attempt to use the client_id will either succeed or fail. Failure will tell you that it’s no longer valid. PAR is one way to use it, if supported by the OP.

We propose to close this in a week unless objections are received before that.

[Vladimir Dzhuvinov]

I was wrong that PAR can be a reliable fix. We still have the authorization request and it is still possible for an RP to use PAR and find its registration invalidated when it makes an authorization request.

I made a PR to inform implementers that requests to the OP can fail at any time because of the nature of explicit registration and that strategies can be devised to work around that, without further specifics:

https://bitbucket.org/openid/connect/pull-requests/287

[Giuseppe De Marco]

@Vladimir Dzhuvinov for this kind of problems in italy we adopt the resolve endpoint,

the RP knows the final metadata and the recognizable Trust marks and the trust chain evaluated by an OP, simply requesting at the resolve endpoint of the OP.
If an OP doesn’t have registered a RP it means that the resolve endpoint response would be 404 Not Found.

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/287