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

Brian Campbell bcampbell at pingidentity.com
Mon Dec 23 18:54:40 UTC 2013


Yes, there's still work to be done here and probably in the IETF's OAuth
WG.


On Sun, Dec 22, 2013 at 8:05 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> 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/20131223/7022f100/attachment.html>


More information about the Openid-specs-ab mailing list