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

Francis Pouatcha <> Wed, 10 June 2020 23:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3AF7F3A15B6 for <>; Wed, 10 Jun 2020 16:35:53 -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, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YgFwZl3MhWlR for <>; Wed, 10 Jun 2020 16:35:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9F203A15B2 for <>; Wed, 10 Jun 2020 16:35:50 -0700 (PDT)
Received: by with SMTP id j198so5720552wmj.0 for <>; Wed, 10 Jun 2020 16:35:50 -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=RsK4i/PAK34KHWqRSztWDXFioW1YgegPKQhMi1cChKE=; b=gFaz7l07iFL0hQJG1T9r2GZDju8NtmiJpqZXILKhHqdRIRDJK6pwwfsvLQGlhHRlhU PmJZ1sQgxHSs83DTgQMPnHxf10nUXGJ0A/HtHH5uMjaM9WgOTc+ybV34BDiBUZ902B8u wRP6qYNS1ZSVN7Zf5K3tE+DRVV28ZdJYOA6pU=
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=RsK4i/PAK34KHWqRSztWDXFioW1YgegPKQhMi1cChKE=; b=LXiljn5ge4WJtltkpdLbZlVzPAVSC1RSbyQs1NnplYbkV/y1ZjRZC6iqF0KeJkrwk8 6MSH9a5oYxiZ6pPkWgpwqStH4SJi3EXSmLClO12tBLyjHA0CiQG1/fBg2pgTbvSQR84X 9nbVK1+KMxo7PRMpfq/Pz0V7vHkkHebPQSdMpxqj/Q3ULRGdrGI/d6lTiAy5izpOhCm+ fFkb/4LccUuWBN6bCq934y0quWOb7+x4RV5e1zvz/6sPdDMjEdongrX6qLcEgQUMZGYl oLNLDQjqnUpoxB7TRouwtKJUyQN5ACSC73QM7P7Lm/UQ7XjX3QtGodVfEPnmujkVb0U4 VIzg==
X-Gm-Message-State: AOAM532FPeRLrsKiGCY74Ww053cXQQK/JN1AfB1uqR5PjHiif5xFenxN wmPEUVEJr7Q3CJXpnbcuzlt4KDhPPXvOYuddRi2y7Q==
X-Google-Smtp-Source: ABdhPJzBNSiC1kjOcNszYwDKCuserG8Fz24rkXQbpHUNBKXMwOeE+d5qGL8p4xnkSySrE27IJNRDx5RYl3YQd4Vcy5c=
X-Received: by 2002:a1c:4e17:: with SMTP id g23mr5149746wmh.38.1591832149189; Wed, 10 Jun 2020 16:35:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Francis Pouatcha <>
Date: Wed, 10 Jun 2020 19:35:38 -0400
Message-ID: <>
To: Justin Richer <>
Cc: Torsten Lodderstedt <>, oauth <>
Content-Type: multipart/alternative; boundary="000000000000cb7b4405a7c34d02"
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: Wed, 10 Jun 2020 23:35:53 -0000

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

>  — 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