Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-03.txt

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 <ve7jtb@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.ip@gmail.com <mailto:panva.ip@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.com@dmarc.ietf.org <mailto:40microsoft.com@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-bounces@ietf.org <mailto:oauth-bounces@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-drafts@ietf.org <mailto:internet-drafts@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