Re: [jose] TTL for JWK

"Manger, James H" <James.H.Manger@team.telstra.com> Wed, 20 February 2013 12:27 UTC

From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Brian Campbell <bcampbell@pingidentity.com>, "jose@ietf.org" <jose@ietf.org>
Date: Wed, 20 Feb 2013 23:27:29 +1100
Thread-Topic: [jose] TTL for JWK
Thread-Index: Ac4PGGcpcpAJELR9RWSUebHnGEPWmAAStvzg
Message-ID: <255B9BB34FB7D647A506DC292726F6E115076349DB@WSMSG3153V.srv.dir.telstra.com>
References: <CA+k3eCTZ4KeC7ZH41OWkjkLCp0RiRBkze=4NpFO7AG5zVq-bJQ@mail.gmail.com> <4E1F6AAD24975D4BA5B168042967394367477CB0@TK5EX14MBXC284.redmond.corp.microsoft.com> <CA+k3eCTbKzWaSr0cmSKTgfs2WMwfGjxatCMjFJekf+8E5SRjXQ@mail.gmail.com> <84EEBC7B-1C68-485E-998D-D01CAE884675@ve7jtb.com>
In-Reply-To: <84EEBC7B-1C68-485E-998D-D01CAE884675@ve7jtb.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115076349DBWSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [jose] TTL for JWK
Precedence: list

This feature sounds so close in function to an HTTP Cache-Control header. Surely we can just use this existing mechanism? Particularly as the real use case mentioned in getting a JWK from an HTTPS URI.


P.S. If we do defer specifying “TTL for JWK” now, but after a few years experience of rolling keys in OpenID Connect decide it would be good, then I wonder how awkward deploying it would be due to the MUST-understand-everything rule?

--
James Manger

On 2013-02-19, at 9:26 PM, Brian Campbell <bcampbell@pingidentity.com<mailto:bcampbell@pingidentity.com>> wrote:

…this was more of a indicator about how long a key could be cached/used with a reasonable expectation that things would still work…
From: jose-bounces@ietf.org<mailto:jose-bounces@ietf.org> [mailto:jose-bounces@ietf.org<mailto:jose-bounces@ietf.org>] On Behalf Of Brian Campbell
Sent: Tuesday, February 19, 2013 3:43 PM
To: jose@ietf.org<mailto:jose@ietf.org>
Subject: [jose] TTL for JWK
I'd like to float the idea of introducing a time to live parameter to the base JWK document, which could probably fit in as a subsection of §4 that defines parameters common to all key types [1].

The motivation is that many uses of JWKs will involve caching of JWK data and a TTL parameter could be used to indicate how long a key could be safely cached and used without needing to recheck the JWK source. I don't want it to be a hard expiration date for the key but rather a hint to help facility efficient and error free caching.

OpenID Connect has a real use case for this where entities publish their keys via a JWK Set at an HTTPS URL. To support key rotation and encryption, there needs to be some way to indicate the TTL of a public key used to encrypt. Of course, this isn't the only way to skin that cat but it strikes me as a good way and one that might provide utility for JWK in other contexts.
JSON Web Token [2] defines a data type that is "A JSON numeric value representing the number of seconds from 1970-01-01T0:0:0Z UTC until the specified UTC date/time" that seems like it could be co-opted to work well as the value for a "ttl" parameter.

[1] http://tools.ietf.org/html/draft-ietf-jose-json-web-key-08#section-4

[2] http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-2

Re: [jose] TTL for JWK Richard Barnes
[jose] TTL for JWK Brian Campbell
Re: [jose] TTL for JWK Mike Jones
Re: [jose] TTL for JWK Brian Campbell
Re: [jose] TTL for JWK John Bradley
Re: [jose] TTL for JWK Matt Miller (mamille2)
Re: [jose] TTL for JWK Mike Jones
Re: [jose] TTL for JWK John Bradley
Re: [jose] TTL for JWK Manger, James H
Re: [jose] TTL for JWK Brian Campbell
Re: [jose] TTL for JWK Prateek Mishra
Re: [jose] TTL for JWK John Bradley
Re: [jose] TTL for JWK Brian Campbell
Re: [jose] TTL for JWK Richard Barnes
Re: [jose] TTL for JWK Manger, James H
Re: [jose] TTL for JWK Richard Barnes
Re: [jose] TTL for JWK Brian Campbell
Re: [jose] TTL for JWK Brian Campbell