Subject: [OAUTH-WG] Access Token Hash for DPoP

From: Justin Richer <[email-masked]>
Date: Tue, 16 Mar 2021 10:08:10 -0400

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

---

From: Brian Campbell <[email-masked]>
Date: Thu, 18 Mar 2021 15:55:30 -0600

Thanks for this, Justin.

Gauging consensus on the two issues discussed again on the call earlier
this week has been difficult. Obviously. As I've said, I've gone back and
forth in my thinking about both more than a few times.  But my sense of the
room on Monday was that whatever consensus exists is leaning towards
basically the opposite of what I'd proposed during the meeting to move
forward. So it's feeling to me like adding an access token hash and not
changing the confirmation is the path forward.

On Tue, Mar 16, 2021 at 8:08 AM Justin Richer <[email-masked]> wrote:

> 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
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._