Re: [OAUTH-WG] DPoP and refresh tokens

Brian Campbell <> Wed, 28 October 2020 22:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDE0A3A0925 for <>; Wed, 28 Oct 2020 15:20:50 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=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 rd3ZRjkQUTkz for <>; Wed, 28 Oct 2020 15:20:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12AFD3A08F6 for <>; Wed, 28 Oct 2020 15:20:48 -0700 (PDT)
Received: by with SMTP id 141so803887lfn.5 for <>; Wed, 28 Oct 2020 15:20:48 -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=P6VGBDl4ySB1VPTg8MdmZ9BjH5oO5C1ZoAUb7nKBhU0=; b=bzaDzyONsGOhOB21cxz2HOJBvpM4dRVn5ECV0+nzbYsoq2sjrX0qHV7bN+7k9q7+3I 7MOKhiBpxLc+WUodxX4SaOrv5rGV1FVoIwj45UoB8hueMZXsIDPyTZangGld1VnYY712 0N0nef6a2hBVNQik+7MP/d8sobPn4COIZoHcnlG40Iv+7Gx9g9B45AVgFT3fQMNO0WV/ 1B9AlxKYukiegqK/cDefSpRVn16pZmY+l++JEKt7n20X0KXM4Jx8TmKSedE9q3R5TTi3 ycRN9Yfpy4tzs8qvr0gDqFIcEdexHt7e1wq/PjF+VPVb372iEo1u4P4VOrkRpGVfZUeB gzuQ==
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=P6VGBDl4ySB1VPTg8MdmZ9BjH5oO5C1ZoAUb7nKBhU0=; b=XPwb9otNV7h2QJ4pQGJN9BtyMttq9ZseJeekpD3eUqMh5YXU3NmQkZ9wvE1Muf8grf q/8LEPqF84jV8KIDKmKr288eGr0scuNlpJdeTWNsl9y42FAF6qFY4gJEPXNNSJbuYuqp mHZRWwdP8xingjXQclMDjeXLAmvrH9Ei4Gkw45YQ+B4hITOjdJ1oSGP2rvoibJSUq9eQ lKLmNMX035s8E1r9TM1MpIN8p3Co1Uu0IqfsraCIf0Ww92hzfHdfzO/8jrKY+4n4Xdip 8L1x2L9uTekm4NKpfJWj2YSslcwFoz1ziFK0oPUV1Nw5cetpMXRR98FSX4ZggGMl/zYQ ytqA==
X-Gm-Message-State: AOAM531ajGfRAFMsnWVLqbsmAIzLyM+LDQgVRvc6srnmKKodiEt000lw xamwpMl9jZjboueaxWhUKNM91eK86Ie/PvJgMfuNwBWYWO5rN2m6LPiZjalt/LxAjQwpF7hYww3 kHbGhKolBsVDW9Q==
X-Google-Smtp-Source: ABdhPJypbeEAdIIIWJ9P1qEyeDpDjeWVyt0UFTYVKj4430LXNSYvKAVSVOeHoUlV3mWYWsd40+bVmq2bRzA58AKvcNQ=
X-Received: by 2002:a05:6512:31d5:: with SMTP id j21mr406601lfe.560.1603923646992; Wed, 28 Oct 2020 15:20:46 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Wed, 28 Oct 2020 16:20:20 -0600
Message-ID: <>
To: Dick Hardt <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="00000000000039f43705b2c2935b"
Archived-At: <>
Subject: Re: [OAUTH-WG] DPoP and refresh tokens
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: Wed, 28 Oct 2020 22:20:51 -0000

I'm currently working on the draft and hope to have a new revision
published relatively soon. Just the other day I made some changes to the
text around RTs with
that maybe/hopefully makes some of it more clear? But basically the RTs are
only bound for public clients and the exact mechanism to do it is left up
to the AS. The AS both creates and consumes the RT so however it chooses to
associate the DPoP key with the RT is its own implementation detail.
Getting a new bound access token using an RT is meant to be covered in sec
5 "Token Request (Binding Tokens to a Public Key)" with RT being just one
of the grants that could be presented in the token request in conjunction
with the DPoP proof, and the AS would bind the AT it issues to the key in
that DPoP proof. I'd sort of assumed that would just be understood. But do
you think it (including the recent changes) needs more explanation?

I do think using DPoP only for token refresh (only for public clients
though) would be appropriate, for some cases anyway. This has come up on
the list here previously and the general consensus was also that it'd be
useful. I plan to add some language describing that (and loosening some
language that could be perceived as prohibiting it) but haven't gotten to
that item on the editing todo list yet.

On Wed, Oct 28, 2020 at 2:46 PM Dick Hardt <> wrote:

> Hello
> I was reviewing the latest DPoP draft[1] and saw numerous mentions of
> using a DPoP proof for refreshing an access token, but no explicit
> description of how to do that, nor an example. Was this intentional?
> Perhaps a new section "Refreshing an Access Token"?
> Additionally, I can imagine that an AS can improve its security posture by
> adding support for DPoP *just* to token refresh and not requiring existing
> resource servers to upgrade. Rotating refresh tokens would not be as
> critical for public clients using DPoP for token refresh.
> Would using DPoP only for token refresh be appropriate? If so, language
> describing that would be helpful. :)
> /Dick
> [1]
> ᐧ
> _______________________________________________
> 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._