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

[Brian Campbell <[e-mail]>]

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