Subject: [OAUTH-WG] client_secret_expires_at redux again (was Re: Dynamic Client Registration Sent to the IESG)

From: Brian Campbell <[email-masked]>
Date: Thu, 11 Sep 2014 16:19:45 -0600

Why does expiration only apply to the client secret[1]? If there's a need
for the AS to set an expiration, isn't it broader than that and apply to
the whole client or the client id? If there's a need to signal an
expiration time on the client secret, doesn't it follow that the client's
JSON Web Key Set (the jwks parameter) might also need to be expired? And
what about strictly implicit clients or other public clients, is there no
case that an AS would want to expire them?

I realize I've asked this before (more than once) but I've never gotten an
answer. To me, whats in this draft that's on its way to the IESG is awkward
and/or incomplete.

I believe that either the client_secret_expires_at should be removed from
draft-ietf-oauth-dyn-reg or it should be changed to something that isn't
specific to the client secret - something like client_expires_at or
client_id_expires_at.

[1] client_secret_expires_at in
https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20#section-4.1

On Wed, Sep 10, 2014 at 5:50 PM, Hannes Tschofenig <
[email-masked]> wrote:

> Hi all,
>
> I have just sent the Dynamic Client Registration document to the IESG.
> The final shepherd write-up for the document can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/shepherdwriteup/
>
> Ciao
> Hannes
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 12 Sep 2014 14:08:14 +0000

It used to be simply "expires_at" but after discussion on the list it was changed to "client_secret_expires_at", since the client's secret is the most likely part to expire and need to be refreshed. Of course this refresh makes the most sense if you're implementing the management spec where you can actually do something other than re-register, but it's still handy for the client to know that its server-issued credentials won't be good anymore at a certain point.

Since the JWKS is provided by the client and not by the server, the server doesn't really need to tell the client when it expires.

The parameter is not passed back if there is no client_secret, such as a public or implicit client. There's text in the security considerations about expiring those kinds of clients* but after discussion on the list it was decided that it's too specific to a server policy to try to signal. Plus, nobody seems to do that today. Client secrets *do* expire in some setups, but client IDs don't, in my personal experience.

 -- Justin

* And I just noticed that this paragraph still mentions the "delete action", so we need to clean that part up in the next revision.

On Sep 11, 2014, at 6:19 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Why does expiration only apply to the client secret[1]? If there's a need for the AS to set an expiration, isn't it broader than that and apply to the whole client or the client id? If there's a need to signal an expiration time on the client secret, doesn't it follow that the client's JSON Web Key Set (the jwks parameter) might also need to be expired? And what about strictly implicit clients or other public clients, is there no case that an AS would want to expire them?

I realize I've asked this before (more than once) but I've never gotten an answer. To me, whats in this draft that's on its way to the IESG is awkward and/or incomplete.

I believe that either the client_secret_expires_at should be removed from draft-ietf-oauth-dyn-reg or it should be changed to something that isn't specific to the client secret - something like client_expires_at or client_id_expires_at.

[1] client_secret_expires_at in https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20#section-4.1

On Wed, Sep 10, 2014 at 5:50 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Ciao
Hannes

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Fri, 12 Sep 2014 12:32:02 -0300

Yes the JWKS expiry is logically controlled by the client.  If it is going to roll those keys it should be using a jwks_uri if there is no management API to push a new JWKS.

In general symmetric client secrets create key management problems.  My preference is to move to asymmetric keys.

John B.

On Sep 12, 2014, at 11:08 AM, Richer, Justin P. <[email-masked]> wrote:

> On Sep 11, 2014, at 6:19 PM, Brian Campbell <[email-masked]> wrote:
> 
>> On Wed, Sep 10, 2014 at 5:50 PM, Hannes Tschofenig <[email-masked]> wrote:
>> Hi all,
>>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 12 Sep 2014 10:53:15 -0600

Okay, I see 'Changed "expires_at" to "client_secret_expires_at" and
"issued_at" to "client_id_issued_at" for greater clarity.' in the document
history for -11 (full 'management' was in the draft back then).

But to me, it doesn't improve clarity. And it seems limiting. But I seem to
be in the minority of people that think that or care. And I'm not sure I
even care. So I'll drop it.

On Fri, Sep 12, 2014 at 8:08 AM, Richer, Justin P. <[email-masked]>
wrote:

>  It used to be simply "expires_at" but after discussion on the list it was
> changed to "client_secret_expires_at", since the client's secret is the
> most likely part to expire and need to be refreshed. Of course this refresh
> makes the most sense if you're implementing the management spec where you
> can actually do something other than re-register, but it's still handy for
> the client to know that its server-issued credentials won't be good anymore
> at a certain point.
>
>  Since the JWKS is provided by the client and not by the server, the
> server doesn't really need to tell the client when it expires.
>
>  The parameter is not passed back if there is no client_secret, such as a
> public or implicit client. There's text in the security considerations
> about expiring those kinds of clients* but after discussion on the list it
> was decided that it's too specific to a server policy to try to signal.
> Plus, nobody seems to do that today. Client secrets *do* expire in some
> setups, but client IDs don't, in my personal experience.
>
>   -- Justin
>
>
>  * And I just noticed that this paragraph still mentions the "delete
> action", so we need to clean that part up in the next revision.
>
>   Why does expiration only apply to the client secret[1]? If there's a
> need for the AS to set an expiration, isn't it broader than that and apply
> to the whole client or the client id? If there's a need to signal an
>  I realize I've asked this before (more than once) but I've never gotten
> an answer. To me, whats in this draft that's on its way to the IESG is
> awkward and/or incomplete.
>