<div dir="ltr"><div>Oh, and can the client_id value change? There seems to be nothing explicitly forbidding it nor anything stating that it could happen. <br><br>Allowing it to change enables secret rotation and other changes and eventually update capability for stateless (to the AS) clients. <br>

<br></div>A few of us discussed the concept during IETF Vancouver and, if I recall correctly, there seemed to be some general consensus that it'd be a good idea. But no actual action or text has come of that in the connect specs or the IETF registration.  <br>

<div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 19, 2013 at 7:08 AM, Brian Campbell <span dir="ltr"><<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
</blockquote></div><br></div></div></div>