Re: [OAUTH-WG] DPoP and refresh tokens

Dick Hardt <> Wed, 28 October 2020 22:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 928CD3A0976 for <>; Wed, 28 Oct 2020 15:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, 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 jjG-WGsUeEDQ for <>; Wed, 28 Oct 2020 15:35:51 -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 6834F3A0975 for <>; Wed, 28 Oct 2020 15:35:51 -0700 (PDT)
Received: by with SMTP id p15so959561ljj.8 for <>; Wed, 28 Oct 2020 15:35:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PUgJhOO/G/Av8zYZEDQ3NJZ7yia6nTTM9patQYJyCoE=; b=sGOfIB44HH78lmc4rKWWs0onHGAZbyKmTUEFCxWf14m8VPXSqiiwN+C5j+Bi2r+qiO nRvma9gC+uuFSkf8UJuIxyz5w6E3gT7gliys7m230TLIw3vRh7OAUuRlPqbE8w933ZgO rGCyoHbCzM4kKmVECVKw103UnO1326xrHR75FmtE8cZaRl1fJmzrkiI5W6CwGXmUQV9x f3WsOZ/uCszYXsP0OZErKpsMAzcnjTvEq3qYAqX51J0Bqd/SAmkAlkhfb7Key053HS7P 870yhEBQIdzTQ7ljYtYwQRHKmUSKc7+NJ5uw4MeVxmnd9NXjoL1EZT5VGMKYPSDFQP4N kucw==
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=PUgJhOO/G/Av8zYZEDQ3NJZ7yia6nTTM9patQYJyCoE=; b=KyeutyVk0kcsLqSb58wEYJjE0KoxjnUw9LGL0A/xE1DrsQkExXo3b7JUf8llbyCiO0 I8xt93YjJiXbvyaWgg1HykltdBDJ8j4hzOEbKEbe7Ax2RCLD8apa/Un3udJnPl0nH3bY wgoVP5CIjen1oMaao/Lk6zdOpneAgKvRBw0ZaX/OCvtefocaMQCRweUYKUxUnzhOzpRc vaYTZuLLAe2LhgB1Wb8BjOcWSrGiIv8oGH4jrbNDa/X3BugrrWVExyspG2EU92AOE+Q0 XUn5LAcs9sJTH6SZGdmEi5RJpSXuqPXdK96VrU3YtMwTNBOakdHHZknIeB9xg6HCqwpy gziQ==
X-Gm-Message-State: AOAM531kUb+d8qWk5FgRxb35nqSbK9Aip0CRYyIdUdqoRoiZGY0Ku4+A +xCFkfj8InXVVvCj3yly3wKTIHZ+jTjOcJBVZOk=
X-Google-Smtp-Source: ABdhPJwvheSroASMrCHCBVnVvKOakk0FPNECmf4pBb5wVh+V0UblxJXS1FfDM5EiXXUsIV5r9VInXP1eehmX+MC+Lzw=
X-Received: by 2002:a2e:9a17:: with SMTP id o23mr612213lji.242.1603924549429; Wed, 28 Oct 2020 15:35:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Wed, 28 Oct 2020 15:35:13 -0700
Message-ID: <>
To: Brian Campbell <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="00000000000003eeff05b2c2c906"
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:35:54 -0000

Hey Brian

A refresh example would make it more clear, and would also assist in
communicating that DPoP could be used just for refresh.

I see in the updated text that using DPoP with confidential clients is
discouraged. I understand the RT is sender constrained -- but
asymmetric cryptography is much stronger than a shared secret. Why
discourage its use?


On Wed, Oct 28, 2020 at 3:20 PM Brian Campbell <>

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