To be clear, either one should work just fine. So it's kinda a trivial subjective preferences thing. But primary thinking behind using cnf.jkt in the access token (or extrapolate to whatever thing is bound to the key, like a JAG) is that the DPoP proof itself already contains the full public key so it's somewhat redundant to also have the full public key in the access token. In most cases cnf.jkt will save some space, which is probably less important with a JAG. There's probably reasonable cases to be made both ways for which method of comparison is more straightforward or more mistake prone. Avoiding the dependency on a particular hash probably isn't a bad thing though.
On Tue, Oct 28, 2025 at 7:38 PM Aaron Parecki <aaron= [email protected]> wrote: > hmm, interesting question. The JWT Authorization Grant is not a JWT Access > Token so it's not immediately apparent that it should use the semantics > defined for JWT Access Tokens. That said, it might still make more sense to > use jkt instead of jwk. What are some practical reasons for one over the > other? > > > On Tue, Oct 28, 2025 at 3:10 PM Brian Campbell <bcampbell= > [email protected]> wrote: > >> DPoP does indeed use cnf.jkt to bind the access token to the DPoP key. >> Unless there's a compelling reason to do differently (is there?), the JWT >> Authorization Grant should probably use the same mechanism. >> >> On Tue, Oct 28, 2025 at 12:20 PM Nikos Fotiou <[email protected]> wrote: >> >>> Dear Aaron, >>> In Section 4, you are saying >>> "[...] 3. The authorization server MUST verify that the JWT assertion >>> contains a cnf claim as defined in [RFC7800]. This cnf claim >>> MUST contain a jwk property representing a public key" >>> >>> However, DPoP RFC defines the following in section 6.1: >>> "When access tokens are represented as JWTs [RFC7519 >>> <https://www.rfc-editor.org/rfc/rfc9449.html#RFC7519>], the public key >>> information is represented using the jkt confirmation method member >>> defined herein." Then it defines jkt which is the base64url encoded of the >>> sha-256 thumbprint of the JWK. >>> >>> I believe that section 4 of your draft should be adapted accordingly. >>> >>> Best, >>> Nikos >>> >>> >>> >>> On Sat, Oct 18, 2025 at 7:05 PM Aaron Parecki <aaron= >>> [email protected]> wrote: >>> >>>> In considering how to add DPoP binding into the Identity Assertion JWT >>>> Authorization Grant, we realized the current RFC7523 defines JWT >>>> Authorization Grants as bearer tokens, requiring the use of >>>> `grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer` >>>> >>>> https://datatracker.ietf.org/doc/html/rfc7523#section-2.1 >>>> >>>> This seemingly precludes the use of DPoP since it would no longer be a >>>> JWT bearer token. >>>> >>>> To resolve this, I wrote a small draft that defines >>>> `urn:ietf:params:oauth:grant-type:jwt-dpop` and adds DPoP processing rules >>>> on top of RFC7523. You can find the new draft here: >>>> >>>> https://datatracker.ietf.org/doc/draft-parecki-oauth-jwt-dpop-grant/ >>>> >>>> --- >>>> Aaron Parecki >>>> >>>> _______________________________________________ >>>> OAuth mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>> _______________________________________________ >>> OAuth mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.* > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
