[Openid-specs-ab] client_id and statelessness (was Registration: how does client_secret rotation work?)

John Bradley ve7jtb at ve7jtb.com
Sun Dec 22 15:05:50 UTC 2013


On the call we discussed it and came to the consensus that reading the client config MUST not change the configuration.

The AS may change configuration based on other factors however.   

At the moment there is no update function in Connect's dynamic client registration.  

We need to define an extension for secret rotation that answers all of your questions in an interoperable way.

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.

In many respects this is a OAuth discussion rather than something that is specific to connect.

John B.
On Dec 22, 2013, at 11:41 AM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:

> Hi,
> 
> I would be very interested to further discuss secret rotation (esp. for stateless clients) and how it affects protocol design.
> 
> Who is triggering the rotation? Client or AS? If it is the AS, how is the client supposed to realize the change?
> 
> 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.
> 
> regards,
> Torsten.
> 
> 
> 
> Brian Campbell <bcampbell at pingidentity.com> schrieb:
> Oh, and can the client_id value change? There seems to be nothing explicitly forbidding it nor anything stating that it could happen. 
> 
> Allowing it to change enables secret rotation and other changes and eventually update capability for stateless (to the AS) clients. 
> 
> 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.  
> 
> 
> On Thu, Dec 19, 2013 at 7:08 AM, Brian Campbell <bcampbell at pingidentity.com> wrote:
> 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.
> 
> But how does that really work?
> 
> 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?
> 
> 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.
> 
> 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). 
> 
> Or something else? 
> 
> Or am I missing the point somewhere? 
> 
> 
> 
> 
> 
> 
> 
> 
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131222/293d9971/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131222/293d9971/attachment.p7s>


More information about the Openid-specs-ab mailing list