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

Torsten Lodderstedt <> Mon, 25 November 2019 12:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB7D7120170 for <>; Mon, 25 Nov 2019 04:10:15 -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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D4_Z-d-U9TXV for <>; Mon, 25 Nov 2019 04:10:13 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCF1C12001A for <>; Mon, 25 Nov 2019 04:10:12 -0800 (PST)
Received: by with SMTP id n188so13722805wme.1 for <>; Mon, 25 Nov 2019 04:10:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qNFjdclGZvtO78/Xw5YchnDqEs51cPU7fL8tsh6ot3A=; b=J5MlN6uwLmmtv3oX+PIG6gfVYIuf39Ql+6FmCF4gtwoit+m6Oo0TG/SeffhaZ1CaCQ tCK8fuFinqpY91kgpugvsqg74tJIpit/X7yno4a519qHYT99kqnCjUhjchSwnVp/t9xR 6amdB9w12U/MUr8cVxNsaqcjoL04sCGUhBbKbouPyyODMCM8fiT6AVP3tTXHugGAFJAR bSboeyscvINvf0J3BVvthh82ERUaZXxR+bGVPKGLyrDs+VMBvL5C8352UwHU8ghd+p5P uhoTJ/VbkxEeMqwlpusbUuvROiclvSHKVJxbisAuJs7cyTqGnrJv21G57m3JyEcP5L/Q EoUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qNFjdclGZvtO78/Xw5YchnDqEs51cPU7fL8tsh6ot3A=; b=RNCwm3Gda75BCAJbbsr6QGRgOdi2iRf4fdmUKOK+oxPOYeC7PWoKMk/9UBOxhondOL WKUpT2cv/rEhDpqlIcAvbQXxoGhT5D0gnm5W5vougo3QLzOzqdMsJq7Rbf6AIsmW7wKk O5NyniKr6X3MNfso2nIJvPHlQZE5p3R+oSP/FmIZZQVn86xZ9AyGeW3ihgSGn9RdEeZ5 RRdkZZu9ZJ6hJUvPbIRjdMaYftTjtsjcnjmCZ1us8MVeEx8Ka2+0o80yoraNhMVnJjw9 ETeTja0SDyzBcAK5v/uPR+3sHqVh29m9vD6HYieXWdLMgnd0WWfJsXAl/+Rp+8kCbncc CeBQ==
X-Gm-Message-State: APjAAAWAtEhuCTND+oytvrzIT8TciA/p0jiEp0C/EKD5aDrWCLeCK75n 77Szm43Ey6dAzzMyEmZCXXl0vg==
X-Google-Smtp-Source: APXvYqwTRut8UFKll/gi4DWtuiQWKbqZyh283xCOHswX++m5e97gRCx1sYSkFSvO20wNRgniYpB6XA==
X-Received: by 2002:a1c:6386:: with SMTP id x128mr28250666wmb.41.1574683810941; Mon, 25 Nov 2019 04:10:10 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id z6sm10765242wro.18.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Nov 2019 04:10:10 -0800 (PST)
From: Torsten Lodderstedt <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_2D47ECE2-632A-4784-9660-4B9538F43AE5"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Mon, 25 Nov 2019 13:09:58 +0100
In-Reply-To: <>
Cc: Dave Tonge <>, oauth <>
To: Neil Madden <>
References: <> <> <> <>
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 12:10:16 -0000

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?

best regards,