Re: [jose] TTL for JWK

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 <bcampbell@pingidentity.com
> 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 <prateek.mishra@oracle.com
> > 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 listjose@ietf.orghttps://www.ietf.org/mailman/listinfo/jose
>>
>>
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>