Subject: [OAUTH-WG] access token hash claim name in oauth-dpop draft

From: Rohan Mahy <[email-masked]>
Date: Mon, 28 Mar 2022 07:41:51 -0700

Hi,
Did you consider using the (already IANA registered) at_hash claim defined
in:
https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken
instead of defining a new ath claim?

It seems like if we don't use at_hash we should explain why ath is
better/different.
Thanks,
-rohan

---

From: Justin Richer <[email-masked]>
Date: Tue, 29 Mar 2022 09:13:40 -0400

Yes, it was considered, discussed, and rejected. The reason being “at_hash” has a somewhat convoluted definition (left-bits of a hash of an access token in the context of a JOSE object, etc), to fit some of the design constraints of ID Tokens. DPoP proofs do not have those same constraints. DPoP opted, correctly in my opinion, to simplify this by declaring a single hashing algorithm and using its full output value. Cryptographic agility would be achieved by defining a new claim with a new hashing algorithm.

 — Justin

> On Mar 28, 2022, at 10:41 AM, Rohan Mahy <rohan=[email-masked]> wrote:
> 
> Hi,
> Did you consider using the (already IANA registered) at_hash claim defined in: 
> https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken <https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken>
> It seems like if we don't use at_hash we should explain why ath is better/different.
> Thanks,
> -rohan
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 29 Mar 2022 08:38:27 -0700

I agree that the at_hash definition is bizarre. I suggest adding a sentence
when introducing the ath claim explaining that this is similar but
different from at_hash.
Thanks,
-rohan

On Tue, Mar 29, 2022 at 6:14 AM Justin Richer <[email-masked]> wrote:

> Yes, it was considered, discussed, and rejected. The reason being
> “at_hash” has a somewhat convoluted definition (left-bits of a hash of an
> access token in the context of a JOSE object, etc), to fit some of the
> design constraints of ID Tokens. DPoP proofs do not have those same
> constraints. DPoP opted, correctly in my opinion, to simplify this by
> declaring a single hashing algorithm and using its full output value.
> Cryptographic agility would be achieved by defining a new claim with a new
> hashing algorithm.
>
>  — Justin
>