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

From: Mike Jones <[email-masked]>
Date: Fri, 9 Apr 2021 03:38:28 +0000

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 <[email-masked]> On Behalf Of Brian Campbell
Sent: Wednesday, April 7, 2021 1:30 PM
To: oauth <[email-masked]>
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: <[email-masked]<mailto:[email-masked]>>
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
Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Html:           https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html
Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-dpop-03
Diff:           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.

---

From: Filip Skokan <[email-masked]>
Date: Fri, 9 Apr 2021 09:45:06 +0200

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=[email-masked]>:
> 
> 
> From: <[email-masked]>
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Fri, 9 Apr 2021 09:03:46 -0600

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/
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 <[email-masked]> 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
>
> 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 <[email-masked]> *On Behalf Of * Brian Campbell
> *Sent:* Wednesday, April 7, 2021 1:30 PM
> *To:* oauth <[email-masked]>
> *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
>
> URL:
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt
> Html:
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html
> *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.*

-- 
_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._

---

From: John Bradley <[email-masked]>
Date: Fri, 9 Apr 2021 11:20:16 -0400

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
> 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/>
> 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 <[email-masked]
> <mailto:[email-masked]>> 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=[email-masked]
>>     <mailto:[email-masked]>>:
>>
>>     
>>
>>     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 <[email-masked]
>>     <mailto:[email-masked]>> *On Behalf Of * Brian Campbell
>>     *To:* oauth <[email-masked] <mailto:[email-masked]>>
>>     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
>>
>>     From: <[email-masked] <mailto:[email-masked]>>
>>     <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>
>>     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:
>>     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./*
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> 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./
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 12 Apr 2021 11:28:11 -0400

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 <[email-masked]> wrote:
> 
> 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.
> 
>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>>> 9. 4. 2021 v 5:38, Mike Jones <Michael.Jones=[email-masked] <mailto:[email-masked]>>:
>>> 
>>> 
>>> From: OAuth <[email-masked] <mailto:[email-masked]>> On Behalf Of Brian Campbell
>>> To: oauth <[email-masked] <mailto:[email-masked]>>
>>> 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:
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>>> 
>>> The IETF Secretariat
>>> 
>>> 
>>> 
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: John Bradley <[email-masked]>
Date: Mon, 12 Apr 2021 11:45:34 -0400

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. 
>
>> On Apr 9, 2021, at 11:20 AM, John Bradley <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> definition of at_hash are no longer really neccicary in current
>> browsers and networks.
>>
>> A new claim is fine.
>>
>>> 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
>>>     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
>>>
>>>>     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
>>>>
>>>>      
>>>>
>>>>     snippet is copied below. The main change here is the addition
>>>>     of an access token hash claim.
>>>>
>>>>
>>>>        -03
>>>>
>>>>     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
>>>>     e-mail and delete the message and any file attachments from
>>>>     your computer. Thank you./*
>>>>
>>> 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./
>>>