[Technical_wg] Expiration of Client-Accounts at DENIC-Authority
sanz at denic.de
Fri May 17 13:12:53 UTC 2019
> I think it's indeed reasonable to expire some registrations after a
thanks for the feedback.
> 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
Yeah, well, not really: we'd fully abid to
> 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.
The question is: is there value in a given client_id? I mean: they are
server-generated (there's no such thing as a vanity client_id) and should
have no visibility for the users (if a client name is registered).
The latter is true: long-term consents would be lost. But then, again,
they expire sooner or later.
> One way would be to push extension of the specification to define also
No need to: RFC 7591 and 7592 ftw
> or the other way would be to prolong client account at the time it's
Per se that wouldn't help with the other problem that secrets don't
expire, so we thought it'd be a good idea to introduce that additional
measure "Activate automatic refreshing of client secret with each client
registration *update*", not just read.
> Clients can then prevent re-registration by reading
> their Client Configuration before trying to re-register.
> Kind Regards,
> -----Original Message-----
> 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
> value 0 (no expire).
> b) Delete clients that do not renew their secrets before their
> c) Activate automatic refreshing of client secret with each client
> d) We still should decide what to do those legacy clients with
> 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