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