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

Filip Skokan <> Tue, 19 May 2020 13:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 415EB3A02C1 for <>; Tue, 19 May 2020 06:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 KJ7kv10BMYeZ for <>; Tue, 19 May 2020 06:19:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 90F723A03FE for <>; Tue, 19 May 2020 06:19:57 -0700 (PDT)
Received: by with SMTP id f83so14861965qke.13 for <>; Tue, 19 May 2020 06:19:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UZ0NHknFQOmb2aaxC13mTx8nw6bpfZIJQ6YQuCZRfEw=; b=r0uuCJsCP3kWQ0//uoLEuVN6EPVw8nppaMq8wwvcSDYHTqDfGnahsJN757ylTMxRnM PeMgQOMdZC2Ro4QmbRSo81vLKsoHrmGLCxaEbEAyinqPsO/FnbjLQQf/w2fSOOKQSVxz rfHdTkqnprBK3AGAvNBd5h1IVSHSqoHU7vauKTBmk70mpDgRjyKIvQp8NGto7N+digVA r2TXhJArXEkjRDFhKBHcB8O0Bhaq7dX2+c8LRAaufyvfmZX6/0FdeanXk5j4qIFVh4pJ mplSByFmtv79ZDmLQW8oPjGtjBADJuaIVfmnlYtiFSt6075NIGSJuza22ozAuU9jWg2M eMkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UZ0NHknFQOmb2aaxC13mTx8nw6bpfZIJQ6YQuCZRfEw=; b=uOhmyFOMZ+VsdWdL1t5uOugOQ6DFJUq+SZRT+jzncMFCFcRPTfIJaveykRn1vUIn9P EIJGW6G96c4pgEGdVdyyWp1DNed7X/xgY6QZCkQSXJFvUhAWfmFwdRKSTS+OTfe6Fh1q 573dXENfDHH3W7KSjIwD58GGSUFHFbwH+20gas62G/RZokWbCGOkaf1nhh5o8aSeUiP2 tyv5USve1egsEqJ96SscxKGsFeYmIej8Lke6LIolE/JXSTfBijFuuqP7QyK8rzKiNeK7 KjE6U3mxXJvbZNMjx3oCKw/yBnSe7fFh4A4NBfPRdEIIDt7DFTJCLD/Savqe1alMEXBJ 2IkQ==
X-Gm-Message-State: AOAM533wweFkVk7Bd48PDm2LHgKUSxu0gc4+0sTr522ablLjVvueucYf fhO5SnUnqWhRYZyS34QDJ0MjtLnD/Iq8Cg7jUpOLrkOOxg==
X-Google-Smtp-Source: ABdhPJy0/X/Qdpdv8mfQCAYNd98gn3hP7Fd26b6AGj/8bHy8188RlCK/ps0FflKlB5czcwXPONiZyMzalaW4I/9iSDs=
X-Received: by 2002:a5b:44d:: with SMTP id s13mr34097756ybp.414.1589894396216; Tue, 19 May 2020 06:19:56 -0700 (PDT)
MIME-Version: 1.0
From: Filip Skokan <>
Date: Tue, 19 May 2020 15:19:18 +0200
Message-ID: <>
To: oauth <>
Content-Type: multipart/alternative; boundary="000000000000b7934105a6002205"
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: Tue, 19 May 2020 13:20:18 -0000

This is a RE: to yesterday's interim meeting discussion, largely related to
the first rollout step where we want to constrain refresh tokens but leave
protected resource access intact.

I'll start off with a case that I hope we can agree is absolutely necessary
for DPoP to solve - that is constraining refresh tokens for browser based
applications. Now, *do we see this as a secondary objective? I think it
should be on par with access token constraining.* SPAs using code flow and
having access to refresh tokens as means against the continuous browser
efforts to cut down on storage access is a real case servers will be
eventually forced to adopt.

Since rollout for DPoP needs to begin with the AS and Client supporting it
(regardless what order i guess) there are going to be instances where the
RS will be supporting both Bearer and DPoP at the same time.

As discussed yesterday, the client shouldn't know/care and change its
behaviour when it comes to using access tokens.

*But what is the client behaviour we take for standard?* Because I can see
two conflicting implementations in the wild

   1. The client echoes the token_type it received from the token endpoint
   as the authorization scheme
      - (optionally) throws on unrecognized token type values
   2. The client uses Bearer as a fixed authorization scheme and ignores
   the token_type it received

#2 is an implementation which I suspect has no idea about DPoP, but if
extended to send DPoP headers (through various mechanism - library
extensions or even manipulating the `XMLHttpRequest` prototype) will

   - 🎉 get the benefit of having its Refresh Tokens bound
   - 🎉 most likely continue to work with RSs that only support Bearer
   - ❌ will cease to work with RSs that will adopt support for DPoP because
   it'll be using the wrong scheme, that is unless (🎉) RSs supporting DPoP
   choose to suspend the requirement to use the new scheme and instead depend
   on the presence of `cnf.jkt` as means to trigger DPoP validation. *Q: is
   that an acceptable thing to do?*

Arguably, client behaviour #1 is what a client should be using if it
supports other schemes besides Bearer. But it may as well be the behaviour
of a client that has no clue about DPoP, right? Again, such client can be
made to support DPoP in a SPA through manipulation of the XMLHttpRequest
prototype, in which case the developer needs to do the same for
the protected resource calls. But at this point the developer has to know
which RS to apply DPoP to and which not - ergo - which to send Bearer vs.
DPoP scheme to? The developer will have to write a whitelist of resource
servers anyway - and there we get to the point where client has information
and functionality that it shouldn't /need to/ have.

Its great that we have token_type, authorization header schemes, etc...,
but we don't seem have a well defined (or at least followed) behaviour for
our clients around handling the token_type response values and their usage.

A developer has to resolve to navigate this monkey course unless the RS
definition on the AS is aware of the fact that the RS does support DPoP, so
that the issued token_type is always correct for the RS. So, *should we
make that a recommended way of 'indicating' when to issue Bearer vs DPoP
access tokens?*

What else could we do that doesn't give more decision making to the clients
so that the very first step - *Refresh Tokens get constrained* - is achieved*
but Protected Resource access is unaffected?*

Note that this was not "a thing" for mTLS because it continues to use the
Bearer scheme (for better or worse) and it completely omits possible
continuous rollout or discussing what are the signals the RS must use to
require mTLS to be used), same for the abandoned OAuth 2.0 Token Binding
draft (also continued to use the Bearer scheme).

I suspect we have just this opportunity to fix token types and their use
and if we can't, we'll have to resolve to abandon that extension point as
one that doesn't support continued rollout of real sender constraining
mechanism (e.g. http signatures in the future) and just continue using
Bearer because in the end, given that RSs could be relying on the presence
of the cnf claim to figure out the token's constraining mechanism, would
that be such a bad thing?

Put it the other way around. By introducing Bearer scheme, do we actually
gain anything of value that can't be gained through other means?

Note that this message didn't start with the goal of questioning the new
scheme use, it just sort of landed there... My pedantic nature would love
to see the new scheme and token_type extension point used as it was meant
to be but I also recognize the many issues it brings that could be
sidestepped by not introducing it in the first place, all without losing

Previous material on the topic

   -, decision to break
   backwards compatibility amongst the authors
   - ML
   in my opinion inconclusive, no consensus

S pozdravem,
*Filip Skokan*