[Technical_wg] Expiration of Client-Accounts at DENIC-Authority
pawel.kowalik at ionos.com
Fri May 17 12:56:57 UTC 2019
I think it's indeed reasonable to expire some registrations after a time.
The issue which I see is that OIDC Dynamic Client Registration specifies only GET command on the "Client Configuration" end-point, so the method you propose to prolong the account is somewhat out of standard.
The handling implemented in the clients so far, to make new registration, if the previous one is close to expire.
It has a down-side that there is always new client_id generated and any consents related to such old client_id will be lost.
One way would be to push extension of the specification to define also write commands,
or the other way would be to prolong client account at the time it's used. Clients can then prevent re-registration by reading their Client Configuration before trying to re-register.
From: Technical_wg [mailto:technical_wg-bounces at lists.id4me.org] On Behalf Of Marcos Sanz
Sent: 17 May 2019 14:32
To: technical_wg at lists.ID4me.org
Subject: [Technical_wg] Expiration of Client-Accounts at DENIC-Authority
Today it looks like a good day to discuss:
In our DENIC-ID deployment, Login-Partner (aka RPs or Clients) registrations are open to everyone and not limited in its lifetime. We're over 1.4K+ registrations since launch. Unfortunately, it looks like many of these are test accounts and some of the registrations are even duplicated hundreds of times. This is not necessarily malice, it may be carelessness or even misinterpretation of the documentation, which suggests RPs should register at an Authority during the login workflow *only if* they haven't dealt with that Authority before.
Whatever the cause might be, we are considering to let client accounts expire. Since we were anyway planning to enforce client secret expiration, we are considering to proceed as follows:
a) Activate client secret expiration for new clients and set it to something like 6 months. The client registration interface will return the expiration time of the secret in the field client_secret_expires_at (seconds since Epoch). At the moment, we return the value 0 (no expire).
b) Delete clients that do not renew their secrets before their expiration.
c) Activate automatic refreshing of client secret with each client registration update.
d) We still should decide what to do those legacy clients with non-expiring credentials.
I'd love to hear your thoughs/experiences about this.
Technical_wg mailing list
Technical_wg at lists.id4me.org
More information about the Technical_wg