<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" data-smartmail="gmail_signature">S pozdravem,<br><b>Filip Skokan</b></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 21 Aug 2025 at 17:43, Dick Hardt <<a href="mailto:dick.hardt@gmail.com">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>