I am ok with that. If we need to differentiate between a arbitrary key identifier and a key identifier that is cryptographically related to the public key, we could register the additional element later.
John B. Sent from my iPhone > On Jan 24, 2015, at 5:50 PM, Mike Jones <[email protected]> wrote: > > While this may surprise you, that wouldn’t personally bother me. The use > cases I know of would either use it as a Key ID or Subject claim value. The > “jkt” definition was there just to be parallel with “x5t”. What the draft is > really about is the computation definition. > > What do others in the working group think about Jim’s suggestion? > > -- Mike > > From: Jim Schaad [mailto:[email protected]] > Sent: Saturday, January 24, 2015 12:08 PM > To: Mike Jones; [email protected] > Subject: RE: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint > > Implied in my comment is that the parameter jkt would go away. > > From: Mike Jones [mailto:[email protected]] > Sent: Saturday, January 24, 2015 11:39 AM > To: Jim Schaad; [email protected] > Subject: RE: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint > > I agree with you that we should probably add text saying that the thumbprint > value could be used as a Key ID (Hideki Nara made this point yesterday as > well), and that it is an application decision whether to carry the value in a > “jkt”, “kid”, or another field. (In one case, OpenID Connect uses it as the > “sub” (subject) claim of a JWT, for instance.) > > -- Mike > > From: jose [mailto:[email protected]] On Behalf Of Jim Schaad > Sent: Saturday, January 24, 2015 10:39 AM > To: [email protected] > Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint > > I am wondering why this needs to be tagged as a thumbprint. Is there a > reason why this draft should not be presented as – here is a way to compute a > kid value for a key that will produce a unique value. This would be similar > to how the computations are presented in PKIX for the subject key identifier > extension. > > Jim > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
