Re: [jose] TTL for JWK

[Brian Campbell <[e-mail]>]

To Mike's comment on the ttl of an IP packet - I did extensive research on
wikipedia that suggests a TTL can either be a counter or a time-stamp. The
idea is the same - discard or stop using at such and such a point. TTL may
not be right but it seemed closer than exp for what I was aiming for.

To James and John's comment on JWK Set and HTTP, I was thinking a per key
usage but the way I was envisioning it does ultimately result in the whole
JWK Set being refreshed (re-fetched?) and that would argue for it being at
the JWK Set level. And yeah, at that point it'd make sense to just use HTTP
cache control. I'd been trying to avoid that because of a suspicion that
the HTTP headers would likely be set wrong or ignored by some. But using
that as a justification to reinvent the concept at another layer sounds
rather silly when I say (er type) it out loud. So, I dunno, maybe this
isn't such a great idea after all and using HTTP level caching mechanisms
to address my particular problem is a better approach.

To James' other comment on "MUST-understand-everything" - I don't always
answer rhetorical questions in a public forum but, what the heck, it'd be
more than just awkward. It'd be darn near impossible for any deployments
that had more than just single bilateral relationships. You're point is
taken (though I already fall in the not-MUST-understand camp) but I don't
believe the must-understand requirement applies to JWK as the drafts are
currently written, does it?







On Wed, Feb 20, 2013 at 5:27 AM, Manger, James H <
[e-mail]> wrote:

> 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 <[e-mail]>
> 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:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Brian Campbell
> *Sent:* Tuesday, February 19, 2013 3:43 PM
> *To:* [e-mail]
> *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***
> *
>
> ** **
>