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

[John Bradley <[e-mail]>]

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. <[e-mail]> 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.
> 
> On Sep 11, 2014, at 6:19 PM, Brian Campbell <[e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth