<div dir="ltr"><div dir="ltr">Changes made to repo. Updated text included for IPR. <div><br>Updated public page not yet updated -- GitHub is having issues with some actions<br><br></div><div><a href="https://dickhardt.github.io/openid-key-binding/main.html">https://dickhardt.github.io/openid-key-binding/main.html</a></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Aug 21, 2025 at 6:21 PM Filip Skokan <<a href="mailto:panva.ip@gmail.com">panva.ip@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Yes, that sounds about right. </div><div><br></div><div><div dir="ltr" class="gmail_signature">S pozdravem,<br><b>Filip Skokan</b></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 21 Aug 2025 at 19:14, Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Well, it is saving bytes to prevent HTTP header limits!<div><br>The RP does not know (or care) if the code is a JWT -- it is just long -- but I agree with the goal.<br><br>Here is what I think you are proposing:<br><br>- RP calculates a hash of the authorization code using the same algorithm as `ath` is in DPoP (SHA256)<br>- RP includes the hash as the `c_hash` claim in the DPoP JWT sent to the token endpoint<br>- OP calculaets same hash and verifies it equals `c_hash` </div><div><br>Correct?<br><br><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 21, 2025 at 4:58 PM Filip Skokan <<a href="mailto:panva.ip@gmail.com" target="_blank">panva.ip@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello Dick,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><div dir="ltr" class="gmail_signature">S pozdravem,<br><b>Filip Skokan</b></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 21 Aug 2025 at 17:43, Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hey Filip<div><br></div><div>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`</div><div><br>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)<br><br>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.</div><div><br></div><div>/Dick<br><br>> <span style="color:rgb(0,0,0);font-family:verdana,charcoal,helvetica,arial,sans-serif">at_hash</span></div><dl style="color:rgb(0,0,0);font-family:verdana,charcoal,helvetica,arial,sans-serif"><dd>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 <tt style="color:rgb(0,51,102);font-family:"Courier New",Courier,monospace">access_token</tt> value, where the hash algorithm used is the hash algorithm used in the <tt style="color:rgb(0,51,102);font-family:"Courier New",Courier,monospace">alg</tt> Header Parameter of the ID Token's JOSE Header. For instance, if the <tt style="color:rgb(0,51,102);font-family:"Courier New",Courier,monospace">alg</tt> is <tt style="color:rgb(0,51,102);font-family:"Courier New",Courier,monospace">RS256</tt>, hash the <tt style="color:rgb(0,51,102);font-family:"Courier New",Courier,monospace">access_token</tt> value with SHA-256, then take the left-most 128 bits and base64url-encode them. The <tt style="color:rgb(0,51,102);font-family:"Courier New",Courier,monospace">at_hash</tt> value is a case-sensitive string.</dd></dl></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>