[OAUTH-WG] Re: DPoP-bound JWT Authorization Grant

[Brian Campbell <[e-mail]>]

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=
[e-mail]> 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=
> [e-mail]> 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 <[e-mail]> 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=
>>> [e-mail]> 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 -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> _______________________________________________
>>> OAuth mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>
>> *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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>

-- 
_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._