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

Torsten Lodderstedt torsten at lodderstedt.net
Sun Dec 22 14:41:15 UTC 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131222/51b838ad/attachment.html>


More information about the Openid-specs-ab mailing list