Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Rob Otto <> Fri, 22 November 2019 07:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7272812011E for <>; Thu, 21 Nov 2019 23:52:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 9ALoAAsFBv_g for <>; Thu, 21 Nov 2019 23:52:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9DDF1200B5 for <>; Thu, 21 Nov 2019 23:52:46 -0800 (PST)
Received: by with SMTP id a18so2766051plm.10 for <>; Thu, 21 Nov 2019 23:52:46 -0800 (PST)
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=OkzWV7VUfDUq/z3pN2+tQGmpJkCs0yO+Ez8HyXOWqBc=; b=VQKsliS8LjjIvX/fH91Fhdd9A7hoyxyh3r6YXycRl1eXSZ/+OOFvUswVN3eVTNbT7H Zolb7AvI8CMYZMz4bXXNSoh7a9BRQDR4cT70ae3rMzJllMa3R1oc+NovIRs1Hl6TVPJS 9JEDXeF0y+DiFEV9i51a6447FJb9SNuoMWFsXNr97heMHagoJsw+x1frXZ2Bwvt9H9Om RmaDZ1p4FDamIlMGTES5LX/goKpl2BlyTPdBzD0OEDAyrBS7kL1+BXkjkn8tKz8rGUw7 i5qgYQ38mmjk9I4f2ZiZUL6oYIzddGw3JtgsUIOUioJWP2rUtjghvYc1ROkP4l0UNGpm IJvQ==
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=OkzWV7VUfDUq/z3pN2+tQGmpJkCs0yO+Ez8HyXOWqBc=; b=U2Fl7rgkW5eEzkY9sdb74uiQD+YU+VFlSDIHIQGN4P3HbG3IN8MQtzcRhg2ubMX/s8 UHl7xe8s21zykFu4RL2Hyoj0MNVuZvirjtF1tbLdLuRRccAWIJ4+4qnm2jILiGWKqAEG 9X2oUjwNX4f7IvOff7duuTNTCkj5d45xlem1+x4spcL3z7vxBZ4UCqzRD1bGuDbyDm1n De5cjSfWFFl1a8q8hVFRqMu1s8K/3wfg4oqEqDoVn/7TZrviWfoURGlMtOXfsLBVSip0 1MCfLDh/pDu4hMulu9yUYxBVm5WFshHyCEXJBPp6wMfCQfm9jWGMjgs4Yd91zimES00o cdhQ==
X-Gm-Message-State: APjAAAUTPShKdbYf+DsuaiblkCKxaLaRih5UzonUO9NSZCAPe5JrpBU4 DCLRz8jRnh9SCnULPzmQkp1s1QYNNhXmUYppkgm8ituwd3KikqOjg+cyHHcxVWkEQ926GQqkFSO AVR7NydcTpn7Q5Q==
X-Google-Smtp-Source: APXvYqxlc3ve2HJ/+SbmaYRuMPO5cZAWLZc53JeW7JXZx3NvKQMpNbhX2geIvpM/Um0TnRVdlIIBn8m6sOoEezI3soc=
X-Received: by 2002:a17:902:b481:: with SMTP id y1mr12508178plr.76.1574409166046; Thu, 21 Nov 2019 23:52:46 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Rob Otto <>
Date: Fri, 22 Nov 2019 07:52:35 +0000
Message-ID: <>
To: Justin Richer <>
Cc: Dick Hardt <>, oauth <>
Content-Type: multipart/alternative; boundary="00000000000012e55e0597eab357"
Archived-At: <>
Subject: Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt
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: Fri, 22 Nov 2019 07:52:49 -0000

Hi everyone

I'd agree with this. I'm looking at DPOP as an alternative and
ultimately simpler way to accomplish what we can already do with MTLS-bound
Access Tokens, for use cases such as the ones we address in Open Banking;
these are API transactions that demand a high level of assurance and as
such we absolutely must have a mechanism to constrain those tokens to the
intended bearer. Requiring MTLS across the ecosystem, however, adds
significant overhead in terms of infrastructural complexity and is always
going to limit the extent to which such a model can scale.

DPOP, to me, appears to be a rather more elegant way of solving the same
problem, with the benefit of significantly reducing the complexity of (and
dependency on) the transport layer. I would not argue, however, that it is
meant to be a solution intended for ubiquitous adoption across all
OAuth-protected API traffic. Clients still need to manage private keys
under this model and my experience is that there is typically a steep
learning curve for developers to negotiate any time you introduce a
requirement to hold and use keys within  an application.

I guess I'm with Justin - let's look at DPOP as an alternative to
MTLS-bound tokens for high-assurance use cases, at least initially, without
trying to make it solve every problem.

Best regards

On Fri, 22 Nov 2019 at 07:24, Justin Richer <> wrote:

> I’m going to +1 Dick and Annabelle’s question about the scope here. That
> was the one major thing that struck me during the DPoP discussions in
> Singapore yesterday: we don’t seem to agree on what DPoP is for. Some
> (including the authors, it seems) see it as a quick point-solution to a
> specific use case. Others see it as a general PoP mechanism.
> If it’s the former, then it should be explicitly tied to one specific set
> of things. If it’s the latter, then it needs to be expanded.
> I’ll repeat what I said at the mic line: My take is that we should
> explicitly narrow down DPoP so that it does exactly one thing and solves
> one narrow use case. And for a general solution? Let’s move that discussion
> into the next major revision of the protocol where we’ll have a bit more
> running room to figure things out.
>  — Justin
> On Nov 22, 2019, at 3:13 PM, Dick Hardt <> wrote:
> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden <>
> wrote:
>> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle <>
>> wrote:
>> There are key distribution challenges with that if you are doing
>> validation at the RS, but validation at the RS using either approach means
>> you’ve lost protection against replay by the RS. This brings us back to a
>> core question: what threats are in scope for DPoP, and in what contexts?
>> Agreed, but validation at the RS is premature optimisation in many cases.
>> And if you do need protection against that the client can even append a
>> confirmation key as a caveat and retrospectively upgrade a bearer token to
>> a pop token. They can even do transfer of ownership by creating copies of
>> the original token bound to other certificates/public keys.
> While validation at the RS may be an optimization in many cases, it is
> still a requirement for deployments.
> I echo Annabelle's last question: what threats are in scope (and out of
> scope) for DPoP?
> _______________________________________________
> OAuth mailing list
> _______________________________________________
> OAuth mailing list

<>[image: Ping Identity]
Rob Otto
EMEA Field CTO/Solutions Architect

c: +44 (0) 777 135 6092
Connect with us: [image: Glassdoor logo]
LinkedIn logo] <> [image: twitter
logo] <> [image: facebook logo]
<> [image: youtube logo]
<> [image: Google+ logo]
<> [image: Blog logo]

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