Re: [jose] TTL for JWK

[Richard Barnes <[e-mail]>]

One thing to note, though: If all fields weren't critical, then Brian could
just add this to his JWKs and the parsers wouldn't choke.  This is actually
a nice example of a non-critical field.

Thanks,
--Richard



On Wed, Feb 20, 2013 at 6:58 PM, Brian Campbell
<[e-mail]>wrote:

> 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
>>>
>>>
>>
>