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]> 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]>
> 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] <[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]
> <[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] <[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
>
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to