OIDC dynamic client registration validity

[Wessel, Keith]

So, if the registration endpoint is paying attention to the defaultRegistrationValidity property and I'm not overriding that property elsewhere, then the expiration time would be calculated at the time of registration and saved in the expires column in the StorageRecords table for that entry, correct?

I've never touched it or changed the default. So, I have to suspect that in the past, it was somehow defaulting to no expiration and, possibly, that has changed?

Still doesn't explain how the entry in question disappeared last week, though, since you've already told me that the JPA storage service just ignores expired entries instead of deleting them.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Tuesday, March 1, 2022 7:05 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: OIDC dynamic client registration validity

On 2/28/22, 10:04 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

>    Thanks, Scott. I see a value in the json stored in the value column 
> of the StorageRecords table for the secret expiration time, but I don't see anything stored in that JSON that seems to define a registration expire time.

There isn't.

> There's a value for when the client was registered, but not for when 
> it expires. And the expires column of the StorageRecords table for 
> everything with an oidcClientInformation scope is null, so it's not 
> stored there,

That means "no expiration".

The control over this is the profile configuration for the registration endpoint.

-- Scott


--
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!uCesHmsrv162H3dKehU_O72u6bbcFAWB_bvrGSC703emSdcpGUOLk6evOJKKJ4Y4tA$
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net