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

"Richer, Justin P." <jricher@mitre.org> Fri, 12 September 2014 14:08 UTC

Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2D01A086B for <oauth@ietfa.amsl.com>; Fri, 12 Sep 2014 07:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.551
X-Spam-Level:
X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kc5aJ9jmMeGK for <oauth@ietfa.amsl.com>; Fri, 12 Sep 2014 07:08:22 -0700 (PDT)
Received: from smtptsrv1.mitre.org (smtptsrv1.mitre.org [192.52.194.77]) by ietfa.amsl.com (Postfix) with ESMTP id C234C1A06B3 for <oauth@ietf.org>; Fri, 12 Sep 2014 07:08:15 -0700 (PDT)
Received: from smtptsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6F950C506EF; Fri, 12 Sep 2014 10:08:15 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtptsrv1.mitre.org (Postfix) with ESMTP id 4BEC0C506D3; Fri, 12 Sep 2014 10:08:15 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.225]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Fri, 12 Sep 2014 10:08:15 -0400
From: "Richer, Justin P." <jricher@mitre.org>
To: Brian Campbell <bcampbell@pingidentity.com>
Thread-Topic: [OAUTH-WG] client_secret_expires_at redux again (was Re: Dynamic Client Registration Sent to the IESG)
Thread-Index: AQHPzg6X9kZOMRod4EKxZmg/Jhd6GJv9zO0A
Date: Fri, 12 Sep 2014 14:08:14 +0000
Message-ID: <AC1D34BF-6EDD-4EFE-A0FD-AE4C2B43B2D4@mitre.org>
References: <CA+k3eCT4u1h9zDa_6z9jx9RpQQvVCyRAO4+NmJPN6FpKWRYWAw@mail.gmail.com>
In-Reply-To: <CA+k3eCT4u1h9zDa_6z9jx9RpQQvVCyRAO4+NmJPN6FpKWRYWAw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.146.15.23]
Content-Type: multipart/alternative; boundary="_000_AC1D34BF6EDD4EFEA0FDAE4C2B43B2D4mitreorg_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Uzdvamk3vsd99evnqetaLFCFHuo
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] client_secret_expires_at redux again (was Re: Dynamic Client Registration Sent to the IESG)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Sep 2014 14:08:25 -0000

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


_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth