Registration - 3 - rotate/renew secret

[alexandre faria]

Dear,

On the issue [#745](https://bitbucket.org/openid/connect/issues/745/registration-222-delete-rotate_secret) the rotate_secret operation has been deleted as next operations are done through the use of registration_access_token & registration_client_uri.

But I do not see any informations on how a client, created through the dynReg endpoint, can rotate/renew the client_secret through the registration_client_uri?

As the operation metadata does not exists anymore, and actions are commonly based on the http verb, can an openid connect provider expose this endpoint? :

CURL -X POST {registration_client_uri}/rotate_secret -H ‘Authorization: Bearer {registration_access_token}’

If not, how could we manage this?

Regards,

Alexandre.

[Pawel Kowalik]

I also see that missing in the OIDC Dynamic Client Registration, that only GET verb is described and no way to prolog client_secret if expired/expiring.

OAuth2 Dynamic Client Registration describes PUT verb, with a vague description that it may be used to get new client secret. https://tools.ietf.org/html/rfc7592#section-2.2

[Michael Jones]

Yes, if your Connect implementation also supports RFC 7592, then you can use it to change client_secret values.

[Pawel Kowalik]

Hi Mike, thanks for the confirmation. Should a reference to RFC 7592 and some wording be added to OIDC Dynamic Client Registration and/or OpenID Connect Discovery then? RFC 7592 also leaves it open in A.1 whether it’s Read or Update request needed, or whether it’s supported at all. Shouldn’t it be then discoverable via OpenID Provider Configuration document? Otherwise client implementation has to rely on trial and error to figure it out.

[alexandre faria]

Dear,

By reading the RFC 7592 (2.2 Client Update Request), if the client_secret is included it the request metadata, it must match the current value. (We can not push our own credentials).

As Pawel said above, we can not guess how we can renew/rotate.

We may configure the Authorization Server to always perform a client_secret rotation on each registration update request, I do not see other options in the RFC right?

Regards,

Alexandre.