Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

Neil Madden <> Thu, 11 June 2020 07:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ECE133A0F37 for <>; Thu, 11 Jun 2020 00:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KLpI3Y962Lso for <>; Thu, 11 Jun 2020 00:26:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A3303A0F59 for <>; Thu, 11 Jun 2020 00:26:26 -0700 (PDT)
Received: by with SMTP id l10so4984492wrr.10 for <>; Thu, 11 Jun 2020 00:26:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=pQL75m29NwUd3ZqT4WApmbSnNgrkACyGJKa5nRFid6k=; b=dmnn7JgqZEyGH124Co34Izx8RZx1vmQyrRWl1hIeUw6ne/yPkZ0nsOqmi6Iq70lGZs GbpbFHhYUM6RHPwpFT5A83AwvDkySydRQNGe7MZXw7PAj0h2iXiUJg523peBM3WZLqME 2OgU2OMbCRCzAeJPhZ+0fA9ghtaeNADp4VvyM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=pQL75m29NwUd3ZqT4WApmbSnNgrkACyGJKa5nRFid6k=; b=X43hqqOdXDVPTTvvpJwi0ckibMRT1ztLYXMou5iReBSqb834KzteNraJzz1aAX85bB at7IEhmYaa3e1tbQhGiH9gYIcItV+md3S2wFeusF/+1XcUnQ8PVR0Y8iE1aQfADdk3dT QSXuK/3TtLphzdxlJJ74rKy7iNpxNDw5Z8oKHJIIOZXXdO1V7/GyBD/Q5c84bzkrbDII khfeF8tdkzVoMXogcxIjPGlQ5kXyfnB2NFoXg7H/wepnCgMZnqL9yEo89ibnZhR1vGJd xrnAd9kCfAqZngunhIEeuJDrfDwFqC8TtiIcAEXYxYW1eLItmyk1KeKHL/t5VX9Ys3Zu sk3A==
X-Gm-Message-State: AOAM533/Kh836EZ2ejNTiwRIAzv1EKV7JfDGWy4sy7y9Wq5oZYt3/Hpm dz99x4kF80aPI47BB9IkdDvPzA==
X-Google-Smtp-Source: ABdhPJwHFnigTt1DFrhcAdXc9F1AvyrZhAsjInkE44o5xYZt7qQpXVJJG8r8Z/F5pAHPBprtZ/tc/g==
X-Received: by 2002:a5d:684a:: with SMTP id o10mr7545907wrw.4.1591860382312; Thu, 11 Jun 2020 00:26:22 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id w1sm2751350wmi.13.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jun 2020 00:26:21 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Neil Madden <>
Mime-Version: 1.0 (1.0)
Date: Thu, 11 Jun 2020 08:26:20 +0100
Message-Id: <>
References: <>
Cc: Francis Pouatcha <>, oauth <>
In-Reply-To: <>
To: Torsten Lodderstedt <>
X-Mailer: iPhone Mail (17E262)
Archived-At: <>
Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments
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, 11 Jun 2020 07:26:28 -0000


> On 11 Jun 2020, at 07:36, Torsten Lodderstedt <> wrote:
> I generally agree with the proposal, but I would suggest to limit it to public clients. 
> In case of confidential clients, the refresh token is (via the client_id) already bound to the client’s secret(s) and those can be rotated. Additionally binding the refresh token to a DPoP key would limit it’s applicability w/o a benefit. 
>> On 11. Jun 2020, at 01:35, Francis Pouatcha <> wrote:
>> On Wed, Jun 10, 2020 at 4:32 PM Justin Richer <> wrote:
>> What if we simply declare that refresh tokens are always bound to the DPoP key used to request them? Is there value in NOT binding the refresh token?
>> Fully agree. I will add a refresh_token shall always be PoP bound. Independent of the type of PoP.
>> As for access tokens, the way I read it, all of this is true:
>> - The AS could still decide to issue a Bearer token, using the token_type field, for whatever policy reason.
>> - A client getting back a Bearer token from a DPoP request would do Bearer headers. 
>> - A client getting a DPoP token from a DPoP request would do DPoP headers.
>> - An client should never send a DPoP token as a Bearer header.
>> - An RS should ALWAYS look for a DPoP binding signature from a DPoP scheme token. Missing that is an error.
>> So if we just declare that a refresh token must always be DPoP bound when DPoP is used to request it and a refresh token is issued, then we’re in the clear here, as best as I can tell, and it allows the AS some flexibility.
>> Some problems with this:
>> 1) Pretty much every single OAuth client in the world ignores the “token_type” field. But clients being updated to support DPoP wouldn’t ignore it, so that’s probably ok.
>> 2) If we wanted to make refresh token binding switchable we’d need a “refresh_token_type” field or similar, and the client would need to know how to understand it and deal with its absence (since most servers won’t send it).
>> 3) This presumes the client will not rotate its key before using the refresh token. If it does it’ll have to do a whole new grant.
>> 4) None of this prevents an RS from ignoring the DPoP signature, but I think that’s a separate problem.
>> 5) It’s arguable that we’d want a client to be able to bind a NEW DPoP key during a refresh, using the old key as proof for the refresh token and the new key going forward. Is this a case we want to enable?
>> Key rotation shall be handled separately from the refresh_token process. If a refresh_token is bound to a key, the client shall keep that key till the refresh_token is consumed. A key rotation process shall be designed such as to allow the key holder to keep obsolete keys for the completion of pending processes.
>> — Justin
>>>> On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt <> wrote:
>>> That’s correct for confidential clients.
>>> For a public client, the refresh token is just bound to the client id. DPoP allows binding to an ephemeral key pair for this kind of clients.
>> -- 
>> Francis Pouatcha
>> Co-Founder and Technical Lead at adorys
> _______________________________________________
> OAuth mailing list