-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Autoexpiry of DCR-registered clients #167
Comments
I think we may need to rethink how we use the term ephemeral client. Spec takes into consideration 3 cases:
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
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.
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: |
11.2. 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.
The text was updated successfully, but these errors were encountered: