Re: [OAUTH-WG] Access Token Hash for DPoP

Brian Campbell <> Thu, 18 March 2021 21:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9FEA3A0AB6 for <>; Thu, 18 Mar 2021 14:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3cJRkxZtqh7P for <>; Thu, 18 Mar 2021 14:56:00 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B4503A0AB2 for <>; Thu, 18 Mar 2021 14:56:00 -0700 (PDT)
Received: by with SMTP id a1so9457483ljp.2 for <>; Thu, 18 Mar 2021 14:56:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6Yv4wX9znGSyZhXeczPzNcJs1ytIaV+JvGIMQOhY83Y=; b=ZzL1k3JNIoRdvkqmqr9WpzPNWDhIhjIYNKgg1bpA2Ogn8I1hcRlmbSQ10KzwHeWV+j wom7ep7utlBcquu5amKGXNx05xGl0/91mBMmDp2kcH3fvqjRLPK/RE8YfpP6sjb+YXtj HKQFvFlEB+aWkwdxLeXbu6mPMW7SJHctAe3KJojB0U2Llps3pWiUciQA1N+mfEpymOsv XbmHRkeTJQ0gHTLCOEau0Hx6OBl6KP3kyJLKJ14z1KakqSjD5Bk7pdyeNHCAwSqJf0El fe8jHpjR4j2LG+nxtIaEMIbcchL2QszHiuuGeJeU3dy14i/A3V6mY7cWfoXuDnm9fRYO P26g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6Yv4wX9znGSyZhXeczPzNcJs1ytIaV+JvGIMQOhY83Y=; b=Azx7jQlWgoy1sUA7n3HDX6lTBeRU1oCPMjjamD2/ZcXJVkABoyDPtM0j2MQ1mCOEM7 4Oc9OzEpoEtBVMGCJiJJ8WNOyOpyYdrmiRABpAVd2nMIUVU+EPdp6XJUqHn0ILRWGPJO Qm5/94kGJUWC/TWtQ7dZGzOu4UBMKRfkbm+9juMkk9klB6M1TYQFDWhLXhOcv+oU/fGZ EuqoIRbYtKrJwF/I1dVhQizuycZVZ8toNp3EdkbMenxJaoHy4O191PWy7SqicMxlwcik tt1ILTkcDL6R++mua73jRCsKHR4EuiXo0RaSqUA2m/5B41lQayc3Lj4vHOf5miQndyzR bjrg==
X-Gm-Message-State: AOAM531RLRxwrzVhr2uR/15Y4xu3ME60Ousc3PRkezokkiJLrOitWOZW NZyjLuEepsfw4FQuItGwPNFp5+BvGn9vY5gkDsKAYTxcSYTIx8CftR+6DjltWz1LABzIQui2JC+ Pv6217HIlCw/9Tg==
X-Google-Smtp-Source: ABdhPJyikePbzYjMErkKnp9FOLdbHMtrK8jLKclYvGRTSB699U+t2uLCnFjZ2AKDHqymAlsuI37TwintKc4L6rAZi9c=
X-Received: by 2002:a2e:87d8:: with SMTP id v24mr6395372ljj.387.1616104556159; Thu, 18 Mar 2021 14:55:56 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Thu, 18 Mar 2021 15:55:30 -0600
Message-ID: <>
To: Justin Richer <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="000000000000fd796805bdd6a950"
Archived-At: <>
Subject: Re: [OAUTH-WG] Access Token Hash for DPoP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Mar 2021 21:56:03 -0000

Thanks for this, Justin.

Gauging consensus on the two issues discussed again on the call earlier
this week has been difficult. Obviously. As I've said, I've gone back and
forth in my thinking about both more than a few times.  But my sense of the
room on Monday was that whatever consensus exists is leaning towards
basically the opposite of what I'd proposed during the meeting to move
forward. So it's feeling to me like adding an access token hash and not
changing the confirmation is the path forward.

On Tue, Mar 16, 2021 at 8:08 AM Justin Richer <> wrote:

> As discussed on the call yesterday, I have put together a modest proposal
> for adding access token hash to the DPoP draft.
> Instead of using the existing OpenID Connect “at_hash” claim and
> definition, I opted for a new claim “ath” with a fixed hash method. While
> we could re-use the existing claim definition, I think it makes more sense
> to have the function be simpler. I made this decision based on years of
> feedback from developers on dealing with the OpenID definition: most of the
> confusion and errors come from deciding which hash algorithm to use and
> from the “left-bytes” truncation, both of which can fail in unsafe ways
> under the right error conditions.
> If SHA256 is obsoleted or another method is more appropriate given the
> space, then a new claim can be invented with defined semantics tied to a
> new hash method, obsoleting the “ath” method for
> “ath_but_better_this_time”.
> If people want to use the “at_hash” claim, this definition doesn’t
> actually get in the way of using that alongside “ath". We might want to
> change the normative requirement to something like “MUST include ‘ath’,
> ‘at_hash’, or another token hash method” instead, but I didn’t go that far
> here.
> And finally, as I said on the call, I think this is a good idea and one
> I’ve implemented support for in a test project, but not something I
> consider make-or-break for publication of DPoP.
>  — Justin
> _______________________________________________
> OAuth mailing list

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