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

Neil Madden <> Mon, 25 November 2019 14:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F00F120960 for <>; Mon, 25 Nov 2019 06:08:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 JJS2U4XDWtmj for <>; Mon, 25 Nov 2019 06:08:33 -0800 (PST)
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 50C57120880 for <>; Mon, 25 Nov 2019 06:08:33 -0800 (PST)
Received: by with SMTP id y5so16097950wmi.5 for <>; Mon, 25 Nov 2019 06:08:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Zys937mfqlR0moVtUxzJDpcY+1GEivjbLCFotagOT5Q=; b=GjWkPjTQ109Os/YeLQS5uFby/CuTLT11/9Nl0Ek+12VONKKFJJ4P/Sgt0FBglt/Dss 4B0YOsoEja9O2sixz7qkIzNziD+ZUu2LpxEujWX7JT8DbOToTIZilBIrtc15EoXgKZoV FRjJd+hecmssg1oLaVBp9JVFzgcxjG7MRjO1w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Zys937mfqlR0moVtUxzJDpcY+1GEivjbLCFotagOT5Q=; b=hB00CJze5+lCEc6cIFE06SHkO4jTal+cFRDy+c/YHZYwimSc7M7jxJijRErIWG2iE4 3FuFn17j7BVDEFZmSzwLmo+BOceu45E8THdmX5K3dVlbOjIVp5lgsbtpfOsOt46EysLc lMaDkNPcjDb2SQzUwhiyKO3UVBwkCVTJ+N2d53qlD5u9N8As1Po6ezn8D8DynBkeSzBz 61O8Thk1H3Chg+88sfV4RRd+7JcudT6MLe9Zm2MisF9j9Ge7k3bIqy0DeglRf9xsFUlg VC+QejOGRVHtXe+3fH4AYIUSuZkPPJYAd3Vp6j7fi+p141k0FFya9ZGvO+7q7BLkb/7Q TBiQ==
X-Gm-Message-State: APjAAAVRchbtmU9GeMZ+ftqAwPv4VmxTT9zm729VTf00jEku533r/yTG epBZ9bCg8pkQCxCLOz56oRYyng==
X-Google-Smtp-Source: APXvYqyxyPLQVwZqkMpXmjFQKz0GypdXmqH3HHVVGeRo8vCWmRb2J3z2RAsavhu/gOTeLO8YT7Z74Q==
X-Received: by 2002:a05:600c:219a:: with SMTP id e26mr14505873wme.62.1574690911430; Mon, 25 Nov 2019 06:08:31 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id t187sm8368211wma.16.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Nov 2019 06:08:30 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Neil Madden <>
In-Reply-To: <>
Date: Mon, 25 Nov 2019 14:08:29 +0000
Cc: Dave Tonge <>, oauth <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Torsten Lodderstedt <>
X-Mailer: Apple Mail (2.3601.0.10)
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: Mon, 25 Nov 2019 14:08:35 -0000

On 25 Nov 2019, at 12:09, Torsten Lodderstedt <> wrote:
> Hi Neil, 
>> On 25. Nov 2019, at 12:38, Neil Madden <> wrote:
>> But for web-based SPAs and so on, I'm not sure the cost/benefit trade off is really that good. The biggest threat for tokens being stolen/misused is still XSS, and DPoP does nothing to protect against that. It also doesn't protect against many other ways that tokens leak in browsers - e.g. if a token leaks in your browser history then the threat is that the attacker is physically using your device, in which case they also have access to your DPoP keys. In the cases like the Facebook breach, where highly automated mass compromise was achieved, I think we're lacking evidence that PoP would help there either.
>> The single most important thing we can do to protect web-based apps is to encourage the principle of least privilege. Every access token should be as tightly constrained as possible - in scope, in audience, and in expiry time. Ideally at the point of being issued ...
> I tend to agree with your assessment. The simplest way with current OAuth is use of code+pkce+refresh tokens, narrowly scoped access tokens, and resource indicators to mint RS-specific, privilege restricted, short lived access tokens. 
> Do you think we should spell this out in the SPA BCP?

I think that would certainly be a great start.

-- Neil