[Openid-specs-ab] Issue #1529: [Federation] How can an explicitly registered client find out the client_id was invalidated or expired? (openid/connect)

[Vladimir Dzhuvinov]

New issue 1529: [Federation] How can an explicitly registered client find out the client_id was invalidated or expired?
https://bitbucket.org/openid/connect/issues/1529/federation-how-can-an-explicitly

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](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.](https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.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](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://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse)

[https://datatracker.ietf.org/doc/html/rfc7592#section-3](https://datatracker.ietf.org/doc/html/rfc7592#section-3)

‌