Re: [jose] TTL for JWK

The subtle (and maybe unimportant) distinction I was trying to make was
that this was more of a indicator about how long a key could be cached/used
with a reasonable expectation that things would still work. I tend to think
of key expiration as being something more like any use of the key after the
time should be considered invalid. I wanted to avoid requiring message
rejection if expiration checks failed (as is the case with exp in JWT).  I
remember the change to RSA to free up "exp" and was going to propose just
using that. But after thinking about it a bit, to me anyway, "ttl" conveyed
that idea better than "exp." I'd be fine with either parameter name though.

Does that make sense?

On Tue, Feb 19, 2013 at 5:04 PM, Mike Jones <Michael.Jones@microsoft.com>wrote:

>  Is this a key expiration time parameter or is there a subtle distinction
> that I’m missing?  If it is an expiration time, I’d recommend that if we do
> this, that we reuse the name “exp” from the JWT spec.  (We actually stopped
> using this name as an RSA parameter name a few drafts ago exactly so we
> could use it for this purpose.)****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* 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
> *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***
> *
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>