As discussed on the call yesterday, I have put together a modest proposal for 
adding access token hash to the DPoP draft.

https://github.com/danielfett/draft-dpop/pull/62 
<https://github.com/danielfett/draft-dpop/pull/62>

Instead of using the existing OpenID Connect “at_hash” claim and definition, I 
opted for a new claim “ath” with a fixed hash method. While we could re-use the 
existing claim definition, I think it makes more sense to have the function be 
simpler. I made this decision based on years of feedback from developers on 
dealing with the OpenID definition: most of the confusion and errors come from 
deciding which hash algorithm to use and from the “left-bytes” truncation, both 
of which can fail in unsafe ways under the right error conditions. 

If SHA256 is obsoleted or another method is more appropriate given the space, 
then a new claim can be invented with defined semantics tied to a new hash 
method, obsoleting the “ath” method for “ath_but_better_this_time”. 

If people want to use the “at_hash” claim, this definition doesn’t actually get 
in the way of using that alongside “ath". We might want to change the normative 
requirement to something like “MUST include ‘ath’, ‘at_hash’, or another token 
hash method” instead, but I didn’t go that far here.

And finally, as I said on the call, I think this is a good idea and one I’ve 
implemented support for in a test project, but not something I consider 
make-or-break for publication of DPoP. 

 — Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to