<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">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>On Dec 22, 2013, at 11:41 AM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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">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 class="webkit-block-placeholder"></div><pre class="k9mail"><hr><br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></pre></blockquote></div></div>_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></div></body></html>