As mentioned, my own intention for using a new claim “ath” was to have a fixed hash size, not dependent on the surrounding JWS envelopes that “at_hash” is based on. I’ve implemented both approaches on several platforms now, and I greatly prefer the fixed hash.
It’s a new name because it is a new claim with new contents and new semantics. — Justin > On Apr 9, 2021, at 11:20 AM, John Bradley <ve7...@ve7jtb.com> wrote: > > 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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > 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
