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]<mailto:[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]<mailto:[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
