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 <jric...@mit.edu> 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 > OAuth@ietf.org > 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._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
