Re: [jose] TTL for JWK

[Brian Campbell <[e-mail]>]

I was specifically trying to avoid "creeping back toward X.509" and that
was a big part of the distinction I was trying to make in calling it TTL
and treating it as some kind of cache duration hint while not wanting it to
be a hard expiration date that had to be validated.

But, again, I think it's moot because I've been swayed here into thinking
that this proposal isn't fully baked and that I can use other means to
address the immediate problem I'm trying to solve.

Thanks to everyone for the input though. It's been valuable (to me at
least) to help clarify some thinking around these concepts.


On Wed, Feb 20, 2013 at 4:24 PM, Richard Barnes <[e-mail]> wrote:

> Yeah, even after reading the thread, this proposal seems really unclear.
>
> Now, my first thought on reading Brian's initial mail was, "oh, it looks
> like we're creeping back toward X.509!"  Which I don't mean as a bad thing.
>  After all, a lot of the fields we already have in JWK are analogous to
> PKIX fields, and what are certificates but a key, some attributes, and a
> signature over that package.  If we were going to go down that path
> (PKIJ?), then this sort of attribute would completely make sense,
> especially if it were phrased as an absolute time, like the PKIX notAfter.
>
> But if we are going to go down that path, I think we need a recharter...
>
> --Richard
>
>
>
>
>
>
> On Wed, Feb 20, 2013 at 10:19 AM, Brian Campbell <
> [e-mail]> wrote:
>
>> A fair question Prateek, but if you take that to it's logical end, it
>> might suggest that "use", "kid" and "alg" be removed from JWK as well.
>>
>> But my resolve for this proposal is weakening so it's not worth arguing
>> about.
>>
>>
>> On Wed, Feb 20, 2013 at 7:54 AM, Prateek Mishra <
>> [e-mail]> wrote:
>>
>>>  Shouldn't this be a part of a key management layer distinct from JWK?
>>>
>>> I was under the impression that JWK was limited to
>>>
>>> [quote]
>>>
>>>
>>>
>>> JavaScript Object Notation (JSON) data
>>>    structure that represents a public key.  This specification also
>>>    defines a JSON Web Key Set (JWK Set) JSON data structure for
>>>    representing a set of JWKs.
>>>
>>> [\quote]
>>>
>>> - prateek
>>>
>>> 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 [e-mail]://www.ietf.org/mailman/listinfo/jose
>>>
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>>
>>
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>