[Openid-specs-ab] Key Binding - hash of code

[Dick Hardt]

Well, it is saving bytes to prevent HTTP header limits!

The RP does not know (or care) if the code is a JWT -- it is just long --
but I agree with the goal.

Here is what I think you are proposing:

- RP calculates a hash of the authorization code using the same algorithm
as `ath` is in DPoP (SHA256)
- RP includes the hash as the `c_hash` claim in the DPoP JWT sent to the
token endpoint
- OP calculaets same hash and verifies it equals `c_hash`

Correct?




On Thu, Aug 21, 2025 at 4:58 PM Filip Skokan <panva.ip at gmail.com> wrote:

> Hello Dick,
>
> The scheme could still work (i.e. use the same hash that the signature
> algorithm of the DPoP Proof uses), but I would just suggest to just do
> fixed SHA-256 like DPoP implementations already do with the ath claim.
>
> c_hash and code_hash seems redundant so you'll have some explaining to do
> when registering these claims in the IANA JWT Claims Registry.
>
> And the reason not to include the entire code is not to save a couple
> bytes here and there, it's to prevent issues with OPs that might use JWTs
> as their authorization codes. You'd be duplicating a JWT that's already
> part of the request payload inside another JWT that goes into a header
> potentially running into server HTTP Header limits.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Thu, 21 Aug 2025 at 17:43, Dick Hardt <dick.hardt at gmail.com> wrote:
>
>> Hey Filip
>>
>> You suggested we include a hash of the code rather than the code in the
>> DPoP JWT, similar to `at_hash` -> let's call if `code_hash`
>>
>> In at_hash, the hash algorithm is based on the hash algorithm used in the
>> ID Token's JOSE Header. In the code_hash case, the RP does not yet have the
>> ID Token, so it does not know which hash algorithm to use. Given this, the
>> code path for generating the `at_hash` is not going to be the same for
>> `code_hash`. (see snippet from spec below)
>>
>> While there are some OPs that generate long codes, I think we are adding
>> another step for implementers to stumble so that we save some bytes
>> sometimes. Was there another motivation for keeping it short? It is a one
>> time call in the flow.
>>
>> /Dick
>>
>> > at_hash
>> OPTIONAL. Access Token hash value. Its value is the base64url encoding of
>> the left-most half of the hash of the octets of the ASCII representation of
>> the access_token value, where the hash algorithm used is the hash
>> algorithm used in the alg Header Parameter of the ID Token's JOSE
>> Header. For instance, if the alg is RS256, hash the access_token value
>> with SHA-256, then take the left-most 128 bits and base64url-encode them.
>> The at_hash value is a case-sensitive string.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250821/fda0158a/attachment.htm>