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

[Brian Campbell]

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. 
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 
> 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 <
> hannes.tschofe...@gmx.net> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>   ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[John Bradley]

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.  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  
> 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 
>>  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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Richer, Justin P.]

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 
mailto:bcampb...@pingidentity.com>> 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 
mailto:hannes.tschofe...@gmx.net>> 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

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 <
hannes.tschofe...@gmx.net> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth