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 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
