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 protected]> 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 <[email protected]> > 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 protected]> 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 protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
