Sorry I ment "ath" was fine as a claim name for that. I added the extra u.
On 4/12/2021 11:28 AM, Justin Richer wrote: > 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 >> <mailto: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 >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
