I think that using "auth" with the fixed full sha256 hash is fine.
The original response size reasons for truncating the hash in the definition of at_hash are no longer really neccicary in current browsers and networks. A new claim is fine. On 4/9/2021 11:03 AM, Brian Campbell wrote: > For a hash of the access token in the proof JWT, discussion about > whether to use the existing 'at_hash' claim or define a new 'ath' > claim using only SHA-256 have been floating around since last year > (https://mailarchive.ietf.org/arch/msg/oauth/QKMHo6gGRAaANadsAWWlSuRDzXA/ > <https://mailarchive.ietf.org/arch/msg/oauth/QKMHo6gGRAaANadsAWWlSuRDzXA/> > attempts to describe the tradeoffs) without a clear consensus emerging > for one over the other. I've been on the fence myself seeing the > merits and drawbacks in both. In the absence of clear preference or an > obvious 'best' option, the PR from Justin > https://mailarchive.ietf.org/arch/msg/oauth/C2G9cUetGSj6WnNcRdZE8wLR19I/ > <https://mailarchive.ietf.org/arch/msg/oauth/C2G9cUetGSj6WnNcRdZE8wLR19I/> > with the SHA-256 only 'ath' claim was sufficient to make the decision. > > I'm not married to the 'ath' but don't want to change it back and > forth. I would like to see something like consensus for making a > change. And strong consensus has been elusive here. > > > > > > > On Fri, Apr 9, 2021 at 1:45 AM Filip Skokan <panva...@gmail.com > <mailto:panva...@gmail.com>> wrote: > > I would support that too but only if the way it's calculated would > get aligned as well. If it remains being a fixed sha256 of the > whole token rather than what at_hash does, using a new claim makes > sense. > > Odesláno z iPhonu > >> 9. 4. 2021 v 5:38, Mike Jones >> <Michael.Jones=40microsoft....@dmarc.ietf.org >> <mailto:40microsoft....@dmarc.ietf.org>>: >> >> >> >> I had expected that we would use the existing member name >> “at_hash” for the access token hash value, rather than the new >> name “ath”, since there’s already precedent for using it. Could >> we change to the standard name for this when we publish the next >> version? >> >> >> >> Thanks, >> >> -- Mike >> >> >> >> *From:* OAuth <oauth-boun...@ietf.org >> <mailto:oauth-boun...@ietf.org>> *On Behalf Of * Brian Campbell >> *Sent:* Wednesday, April 7, 2021 1:30 PM >> *To:* oauth <oauth@ietf.org <mailto:oauth@ietf.org>> >> *Subject:* [OAUTH-WG] Fwd: New Version Notification for >> draft-ietf-oauth-dpop-03.txt >> >> >> >> A new revision of DPoP has been published. The doc history >> snippet is copied below. The main change here is the addition of >> an access token hash claim. >> >> >> -03 >> >> * Add an access token hash ("ath") claim to the DPoP proof >> when used >> in conjunction with the presentation of an access token for >> protected resource access >> >> * add Untrusted Code in the Client Context section to security >> considerations >> >> * Editorial updates and fixes >> >> >> >> ---------- Forwarded message --------- >> From: <internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>> >> Date: Wed, Apr 7, 2021 at 2:16 PM >> Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt >> >> >> >> A new version of I-D, draft-ietf-oauth-dpop-03.txt >> has been successfully submitted by Brian Campbell and posted to the >> IETF repository. >> >> Name: draft-ietf-oauth-dpop >> Revision: 03 >> Title: OAuth 2.0 Demonstrating Proof-of-Possession at >> the Application Layer (DPoP) >> Document date: 2021-04-07 >> Group: oauth >> Pages: 32 >> URL: >> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt >> <https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt> >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ >> <https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/> >> Html: >> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html >> <https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html> >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-oauth-dpop-03 >> <https://tools.ietf.org/html/draft-ietf-oauth-dpop-03> >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-03 >> <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-03> >> >> Abstract: >> This document describes a mechanism for sender-constraining >> OAuth 2.0 >> tokens via a proof-of-possession mechanism on the application >> level. >> This mechanism allows for the detection of replay attacks with >> access >> and refresh tokens. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at >> tools.ietf.org <http://tools.ietf.org>. >> >> The IETF Secretariat >> >> >> */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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
