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

[Dick Hardt]

Changes made to repo. Updated text included for IPR.

Updated public page not yet updated -- GitHub is having issues with some
actions

https://dickhardt.github.io/openid-key-binding/main.html

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

> 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/cd7cf2a6/attachment-0001.htm>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250821/cd7cf2a6/attachment-0001.html>