<div dir="ltr">Yes, there's still work to be done here and probably in the IETF's OAuth WG. <br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Dec 22, 2013 at 8:05 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">On the call we discussed it and came to the consensus that reading the client config MUST not change the configuration.<div>

<br></div><div>The AS may change configuration based on other factors however.   </div><div><br></div><div>At the moment there is no update function in Connect's dynamic client registration.  </div><div><br></div><div>

We need to define an extension for secret rotation that answers all of your questions in an interoperable way.</div><div><br></div><div>likely to get things to work properly AS will need to think of the client_id provided to the client as a reference or a signed assertion to a internal client identifier so that grants can persist across changes.</div>

<div><br></div><div>In many respects this is a OAuth discussion rather than something that is specific to connect.</div><div><br></div><div>John B.</div><div><div><div><div class="h5"><div>On Dec 22, 2013, at 11:41 AM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>> wrote:</div>

<br></div></div><blockquote type="cite"><div><div class="h5"><div>Hi,<br>
<br>
I would be very interested to further discuss secret rotation (esp. for stateless clients) and how it affects protocol design.<br>
<br>
Who is triggering the rotation? Client or AS? If it is the AS, how is the client supposed to realize the change?<br>
<br>
What is the advantage of secret rotation over a new registration? In my opinion, the fact that the client id is kept stable over time.<br>
<br>
regards,<br>
Torsten.<br><br><div class="gmail_quote"><br>
<br>
Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>> schrieb:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<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><br><br></div></div>
</blockquote></div><br></div></div></div><div style="margin-top:2.5em;margin-bottom:1em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(0,0,0)"><br></div><pre><hr><br>Openid-specs-ab mailing list<br>

<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>

</pre></blockquote></div></div></div></div>_______________________________________________<div class="im"><br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>

<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></div></blockquote></div><br></div></div></blockquote></div><br></div>