[Technical_wg] Expiration of Client-Accounts at DENIC-Authority

Pawel Kowalik pawel.kowalik at ionos.com
Fri May 17 13:29:13 UTC 2019

>> One way would be to push extension of the specification to define also 
write commands,

> No need to: RFC 7591 and 7592 ftw

Sure, reference to an existing standard is for sure a reasonable way of doing this extension not to re-invent the wheel.

OpenID Connect Dynamic Client Registration does not have any reference to RFC 7591/7592
and is even giving an explicit statement:
"Operations on this endpoint are switched through the use of different HTTP methods [RFC2616]. The only method defined for use at this endpoint by this specification is the HTTP GET method."

So some language around it would be helpful to assure the implementations cover it right.

Kind Regards,

-----Original Message-----
From: Marcos Sanz [mailto:sanz at denic.de] 
Sent: 17 May 2019 15:13
To: Pawel Kowalik <pawel.kowalik at ionos.com>
Cc: technical_wg at lists.ID4me.org
Subject: RE: RE: [Technical_wg] Expiration of Client-Accounts at DENIC-Authority

Hi Pawel,

> 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 
write commands,

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,
> Pawel
> -----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 
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.
> Best,
> Marcos
> _______________________________________________
> Technical_wg mailing list
> Technical_wg at lists.id4me.org
> https://lists.id4me.org/cgi-bin/mailman/listinfo/technical_wg

More information about the Technical_wg mailing list