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

[Filip Skokan]

Yes, that sounds about right.

S pozdravem,
*Filip Skokan*


On Thu, 21 Aug 2025 at 19:14, Dick Hardt <dick.hardt at gmail.com> wrote:

> 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/ef1fbb7f/attachment.htm>