<div dir="ltr"><div><div>It's my understanding that, while general update/delete management functionality was removed from Registration ,  the Client Read Request was put or left in largely to facilitate rotation of the client_secret value. Sec 4.3. Client Read Response calls out the secret specifically in, "Upon a successful read operation, the
 Authorization Server SHOULD return all registered Metadata about this 
Client, including any fields provisioned by the Authorization Server 
itself. Some values, including the client_secret value, might have been 
updated since the initial registration."  Please correct me, if I'm wrong here.<br><br></div>But how does that really work?<br><br></div><div>Is the client expected to make a read request at exactly the instance indicated previously with the client_secret_expires_at response parameter? That seems fragile. To avoid the fragility, should the AS be expected to keep both the old and new secret for a given client for some grace period around the client_secret_expires_at time?<br>

<br></div><div>Or does a read request actually (sometimes) trigger the change in client_secret? While perhaps practical in some cases, I think that'd bring a tear to the eye of even the most casual RESTafarian.<br><br>

</div><div>Or is a client expected to do a read request anytime token endpoint authentication or a symmetric crypto operation is unsuccessful and then retry it? That seems very complicated. And the client is supposed to be simple(er). <br>

<br>Or something else? <br><br>Or am I missing the point somewhere? <br></div><div><br></div><div><br></div><br><div><div><br><br></div></div></div>