Yes in the POP specs sending a Thumbprint of the public key might save space vs including the entire public key in the token, especially for RSA keys. That would mostly apply to channel binding & token binding where the public key is delivered outside the token.
Leaving it up to those specs to define the element is OK with me. Agreeing on the method to calculate the hash is still useful. John B. > On Jan 25, 2015, at 1:50 PM, Brian Campbell <[email protected] > <mailto:[email protected]>> wrote: > > I'd be okay with dropping the "jkt" member definitions. It's not clear that > they really add anything in the context of this draft. > > A "jkt" claim for JWT might be useful as a common way for an issuer to say > that a subject/presenter can/should/must present some proof-of-possession of > the key identified by the thumbprint claim. Is something like that in the > OAuth POP work already? It's been a while since I've looked at that stuff. > But I digress as that's all for a different WG. > > > > On Sat, Jan 24, 2015 at 5:20 PM, John Bradley <[email protected] > <mailto:[email protected]>> wrote: > 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] > <mailto:[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] >> <mailto:[email protected]>] >> Sent: Saturday, January 24, 2015 12:08 PM >> To: Mike Jones; [email protected] <mailto:[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] >> <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] <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] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/jose >> <https://www.ietf.org/mailman/listinfo/jose> > > _______________________________________________ > jose mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/jose > <https://www.ietf.org/mailman/listinfo/jose> > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
