Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt
Rob Otto <robotto@pingidentity.com> Fri, 22 November 2019 08:10 UTC
Return-Path: <robertotto@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB09120133 for <oauth@ietfa.amsl.com>; Fri, 22 Nov 2019 00:10:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vlsm_QJ69yfr for <oauth@ietfa.amsl.com>; Fri, 22 Nov 2019 00:10:18 -0800 (PST)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A5E12003E for <oauth@ietf.org>; Fri, 22 Nov 2019 00:10:17 -0800 (PST)
Received: by mail-pl1-x62a.google.com with SMTP id d7so2810781pls.3 for <oauth@ietf.org>; Fri, 22 Nov 2019 00:10:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s6QA1G2b66fpp9ApLL45YOuLrOgxIzcDYro2Ugzfch0=; b=N2jH1jNyXFVVGt0mJrW35xy3uWVKMbVVLZj8RsmQP7tDoyO4QCKxybAWJefUy4d/e1 B2CDSSj++Hl1yhRf/IC43OSxbIV015wA9+zx0mf2XcqYwEO/u6vzNj/9L2X1cYEETukU y93On7Be/S8gks0Qo0FVzCzxeMkurh3GE/aApoB6onbs9Yjp8MQMxh7S43GsE7CDBViP ttXraZrj8LFvzrV0l1yNG4arfyVPKIiLyPbcCixu0Pe6fhziw3KvdL0k/QsT5LLWxd4c svQVQDkwn4VIm8rSj+sn8sjJ79pKDo+hfzmWDu5N9jgWD1HNUBHKR3xh7a1IdcKM7xnZ BJIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s6QA1G2b66fpp9ApLL45YOuLrOgxIzcDYro2Ugzfch0=; b=F5jWDjH2j1+Agrn/ubq4npL5MLhqX+ifR3TUdOLSrOF+6BaSlqXNMc1PAv8PfJ+7+z Ma8ndHEdXHT12RzuNssjcmTPrO8SGy/ZCEcgYnYmoLy3UOGq9tp/+46uhsUPcG8thU7X NeQWA+oU4tos5hPExGWee+5ptN1EyLEWj3ZPNNNucQC33Wp8pPw/6i+J1FYeuHh7wm6N y8DxLLtjEsqRBO720sjYXoU8EYDc5hhljlv22R8aJzwrAc3J385u9/qC3dONh4nIbk4B D0zWZnSft+EgHdkBB8HmhvcMtu+Cpwa1QieWSEccZOLg+y8KlhX+nMj6MBXrjhO17oq3 c7SQ==
X-Gm-Message-State: APjAAAUnh2wxjywf9sDB8YzkNwLOUsHUgyJG0aoVwjjdlejJoKyxfLJQ QQZ2/IiLvU8RosM1pi3puzVx/gjIg/31sdcUoQ3QMC4iN3sZS1sMM1/fuOSlIaJTqTwXGKEWL0m K9TXs6e6rUPhis+tf
X-Google-Smtp-Source: APXvYqwIA02JG2f+ZQ7VkAz9BwPP79uZbeRDzwToD3X1yjzArZvXfqKt1jB8B7Vcc2+AEjhALTUn8a+FnhdKT7rTbtI=
X-Received: by 2002:a17:90a:f84:: with SMTP id 4mr16789695pjz.110.1574410217182; Fri, 22 Nov 2019 00:10:17 -0800 (PST)
MIME-Version: 1.0
References: <2EF412B8-AF8C-4642-9BE0-1B528B0C63D5@amazon.com> <288343F2-ACF0-43E0-8577-26AF45330E5C@forgerock.com> <CAD9ie-u_SM+1hRuBWR7zBGSi4Ex59Ht0SzoVTeFuWTRc3cFJXw@mail.gmail.com> <6DECA422-AACC-4DAA-8CD2-FF57CE02DE3E@mit.edu> <CABh6VRHoBqbQAe4U8UxXodCc8oOpOb=GRb_82gT6X9H5rp0n8Q@mail.gmail.com> <1119B3F6-01A0-4885-A352-5C719A7CDE2C@lodderstedt.net>
In-Reply-To: <1119B3F6-01A0-4885-A352-5C719A7CDE2C@lodderstedt.net>
From: Rob Otto <robotto@pingidentity.com>
Date: Fri, 22 Nov 2019 08:10:06 +0000
Message-ID: <CABh6VRG7nZ0JhX8u8OM6cxR_2m6ZebbkCDPd_OzRHvBv2EQtkA@mail.gmail.com>
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b9f18a0597eaf1b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Ao2lIcZO-xRatYYR7DkcjZdGzU0>
Subject: Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2019 08:10:21 -0000
Hi Torsten - thanks for the reply. Responses in line. Grüsse Rob On Fri, 22 Nov 2019 at 07:59, Torsten Lodderstedt <torsten= 40lodderstedt.net@dmarc.ietf.org> wrote: > Hi Rob, > > > On 22. Nov 2019, at 15:52, Rob Otto <robotto= > 40pingidentity.com@dmarc.ietf.org> wrote: > > > > 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. > > I would like to unterstand why mTLS adds “significant overhead in terms of > infrastructural complexity”. Can you please dig into details? > I guess it's mostly that every RS-endpoint (or what sits in front of it) has to have a mechanism for accepting/terminating mTLS, managing roots of trust, validating/OCSP, etc and then passing the certificates downstream as headers. None of it is necessarily difficult or impossible to do in isolation, but I meet many many people every week who simply don't know how to do any of this stuff. And these are typically "network people", for want of a better word. There are quite a few SaaS API management and edge solutions out there that don't even support mTLS at all. You also have the difficulty in handling a combination of MTLS and non-MTLS traffic to the same endpoints. Again, it's possible to do, but far from straightforward. > > Our experience so far: It can be a headache to set up in a microservice > architecture with TLS terminating proxies but once it runs it’s ok. On the > other side, it’s easy to use for client developers and it combines client > authentication and sender constraining nicely. > I do think its an elegant solution, don't get me wrong. It's just that there are plenty of moving parts that you need to get right and that can be a challenge, particularly in large, complex environments. > > > > > 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. > > My experience is most developer don’t even get the URL right (in the > signature and the value used on the receiving end). So the total cost of > ownership is increased by numerous support inquiries. > I'll not comment, at the risk of offending developers :) > > best regards, > Torsten. > > > > > 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 > > Rob > > > > > > On Fri, 22 Nov 2019 at 07:24, Justin Richer <jricher@mit.edu> 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 <dick.hardt@gmail.com> wrote: > >> > >> > >> > >> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden <neil.madden@forgerock.com> > wrote: > >> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle < > richanna@amazon.com> 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@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > > > Rob Otto > > EMEA Field CTO/Solutions Architect > > robertotto@pingidentity.com > > > > c: +44 (0) 777 135 6092 > > Connect with us: > > > > > > > > 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._______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > -- <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Rob Otto EMEA Field CTO/Solutions Architect robertotto@pingidentity.com c: +44 (0) 777 135 6092 Connect with us: [image: Glassdoor logo] <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image: LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter logo] <https://twitter.com/pingidentity> [image: facebook logo] <https://www.facebook.com/pingidentitypage> [image: youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image: Google+ logo] <https://plus.google.com/u/0/114266977739397708540> [image: Blog logo] <https://www.pingidentity.com/en/blog.html> <https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ> <https://www.pingidentity.com/en/events/d/identify-2019.html> -- _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._
- [OAUTH-WG] Fwd: New Version Notification for draf… Brian Campbell
- Re: [OAUTH-WG] Fwd: New Version Notification for … Denis
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Paul Querna
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… David Waite
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Dick Hardt
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Rob Otto
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Mike Jones
- Re: [OAUTH-WG] New Version Notification for draft… Filip Skokan
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Rob Otto
- Re: [OAUTH-WG] New Version Notification for draft… Filip Skokan
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Mike Jones
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Dick Hardt
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Aaron Parecki
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Petteri Stenius
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Jim Manico
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Dave Tonge
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Jared Jennings
- Re: [OAUTH-WG] New Version Notification for draft… Aaron Parecki
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New Versio… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New Versio… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIE… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIE… Rifaat Shekh-Yusef