solid
Autoexpiry of DCR-registered clients
11.2. Client IDs:
Implementors SHOULD expire ephemeral Client IDs that are kept in server storage to mitigate the potential for a bad actor to fill server storage with unexpired or otherwise useless Client IDs.
With Solid clients registered via DCR, things can get even worse as the applications normally do not bother (and are not required) to reuse client ID and secret across the sessions, registering a new one upon every user login. Thus, the number of dynamically registered clients could easily reach N_users * N_logins. OTOH, we cannot rely on the user agent for the proper client clean-up (even if we require it). That said, it is even more important for the OP to be able to automatically expire DCR-registered clients rather than the ephemeral ones.
I'd suggest adding this to the Section 11.
I think we may need to rethink how we use the term ephemeral client.
Spec takes into consideration 3 cases:
- Clients using Client ID document and not registering at all (recommended)
- Clients using Dynamic Client Registration
- Clients using static registration
I don't think we should consider clients using static registration as ephemeral. Since the registration was created via user interaction it probably shouldn't be auto expiring.
While Client ID documents can be cashed, their identifiers and not managed by the server so they also don't seem to be of concern when it comes to expiring client ids.
This leaves us DCR-registered clients. We could probably be more specific in this section and talk about DCR-registered clients and expiring client ids created via DCR.
@acoburn mentioned during today's call https://datatracker.ietf.org/doc/html/rfc7591#section-3.2.1
client_secret_expires_at REQUIRED if "client_secret" is issued. Time at which the client secret will expire or 0 if it will not expire. The time is represented as the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time of expiration.
We could reference it as well when we talk about expiring client ids.
Thanks @elf-pavlik , that makes absolute sense, though things could a bit more complicated with Client IDs.
While Client ID documents can be cashed, their identifiers and not managed by the server so they also don't seem to be of concern when it comes to expiring client ids.
From the implementor's PoV, most likely Client ID-based ("ephemeral") clients will be internally implemented as "normal" or "materialized" clients. For example, in Keycloak you can't just create an in-memory client on the fly, feed it to the authentication process and expire it afterwards; introducing such in-memory clients will require enormous coding efforts. That's why we're simply retrieving Client ID document and feeding it into the same DCR API. Thus, the client will be persisted, reused upon subsequent invocations, auto-updated when the cached document expires, and finally itself auto-expired and removed.
That's why I think it's important to retain the mentioning of expiring "ephemeral" Client IDs by the implementations.
Expiring DCR clients is an implementation detail. While doing so is likely a very good idea, there already exists a mechanism by which a server can indicate to a client when that DCR registration will expire: client_secret_expires_at.
