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

Aaron Parecki <> Fri, 22 November 2019 10:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 748F21207FD for <>; Fri, 22 Nov 2019 02:20:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GVgF8otNMQXO for <>; Fri, 22 Nov 2019 02:20:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18A3112080E for <>; Fri, 22 Nov 2019 02:20:12 -0800 (PST)
Received: by with SMTP id q15so6407201ils.8 for <>; Fri, 22 Nov 2019 02:20:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WTHXEjQvfCtm7o8KG5MhiQiFzEcmU8LBhZbrOsRYoA4=; b=yCtlhGWLoIXbfrt+MDsy9lfAQGTQJiRXaiYMpVeh/dhgV02+Rq4nxzZGYcKHQgvsUf QkJa1AUw7N0iYPKkdV3C5lqdocfdn3jUA2tjbcNoTndXTDee4ak5mIHsjDGK7v5f6QEh 3TpdztlnT70C/MG3zZiUV5SolJOO4cDdyqgD9UqPRbBL8jTGXrS+RmVOX5yReC5mePkG vmpJqqbFiu/uASEmk31qdJzRBDlD1HHz8y0P7GrqrRgBgKeP/HLMrbKjNdNhNIoRAkwN rgEhXNISNPIAYmJVBvnHh7w1haWlYSu/kC+nzi/a94hGn4kOdddB4q3tX7//Yb9iVj/u PytQ==
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=WTHXEjQvfCtm7o8KG5MhiQiFzEcmU8LBhZbrOsRYoA4=; b=AB7oIBlUYxkir7QBkqxeU/rFxDXqdPgJo+5j7vrCDT5H8vf648qJHDh8gj6IUoSG52 k94urrG47WVFoXkd67Mz1S+bYlKuijIhBPny+ucRHbaZp8Y/Sgoyar/AXuBJdFej2o5n r59yseykTw5ZxKBUSLLVJhN0rrzlHI8O2aopfOfiQHKRkyPbipHNCg+KlKMDwkobsdOB oR88oI+rGkGCK5Lr/zUJZ5CdeqpN+Nv44aobVfEdSX00THdA853T1JmGyMTVZr4qNOQb 6JIJNeCpfWKpwUKX9o0SqSXVHs33akv5+dKdnuBeA6sGZTzYlldvkmrGjgzsIblkVIfC KDIw==
X-Gm-Message-State: APjAAAXx36Qk7RwRsDh8lhgnOd2OLGFRdUkBl30jHpQQIKQ3/CGbot7F +DrGf3spluETZ4sR678wz4BeEA2fzJE++Q==
X-Google-Smtp-Source: APXvYqzuXvtX8MqZm09Egb37G9T3W9jMG2ehZNwNQ1gaeGsahQkEOQrXz85HQLQE0XBlzNuxEJKw6Q==
X-Received: by 2002:a92:9f1c:: with SMTP id u28mr14611224ili.97.1574418011141; Fri, 22 Nov 2019 02:20:11 -0800 (PST)
Received: from ( []) by with ESMTPSA id n28sm2660317ili.70.2019. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 Nov 2019 02:20:10 -0800 (PST)
Received: by with SMTP id s75so6448609ilc.3 for <>; Fri, 22 Nov 2019 02:20:10 -0800 (PST)
X-Received: by 2002:a92:5ac1:: with SMTP id b62mr15601793ilg.46.1574418009892; Fri, 22 Nov 2019 02:20:09 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Aaron Parecki <>
Date: Fri, 22 Nov 2019 18:19:58 +0800
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Neil Madden <>
Cc: Torsten Lodderstedt <>, oauth <>
Content-Type: multipart/alternative; boundary="0000000000003532e80597ecc23d"
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 10:20:14 -0000

The main concern about token replay in a SPA is that the access token may
be extracted from the app, such as via XSS. Using the Web Crypto API has
the advantage of being able to generate a public private key pair where the
JS code can't access the private key at all, it can only be used to sign
things, making it impossible for an attacker to extract an access token and
use it for anything. You might then say that if a JS app is vulnerable to
XSS then the attacker could just call the signing API anyway, which is a
concern, but that's a different threat profile.


On Fri, Nov 22, 2019 at 6:08 PM Neil Madden <>

> On 22 Nov 2019, at 07:53, Torsten Lodderstedt <torsten=
>> wrote:
> >
> >
> >
> >> On 22. Nov 2019, at 15: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.
> >
> > as a co-author of the DPoP draft I state again what I said yesterday:
> DPoP is a mechanism for sender-constraining access tokens sent from SPAs
> only. The threat to be prevented is token replay.
> I think the phrase "token replay" is ambiguous. Traditionally it refers to
> an attacker being able to capture a token (or whole requests) in use and
> then replay it against the same RS. This is already protected against by
> the use of normal TLS on the connection between the client and the RS. I
> think instead you are referring to a malicious/compromised RS replaying the
> token to a different RS - which has more of the flavour of a man in the
> middle attack (of the phishing kind).
> But if that's the case then there are much simpler defences than those
> proposed in the current draft:
> 1. Get separate access tokens for each RS with correct audience and
> scopes. The consensus appears to be that this is hard to do in some cases,
> hence the draft.
> 2. Make the DPoP token be a simple JWT with an "iat" and the origin of the
> RS. This stops the token being reused elsewhere but the client can reuse it
> (replay it) for many requests.
> 3. Issue a macaroon-based access token and the client can add a correct
> audience and scope restrictions at the point of use.
> Protecting against the first kind of replay attacks only becomes an issue
> if we assume the protections in TLS have failed. But if DPoP is only
> intended for cases where mTLS can't be used, it shouldn't have to protect
> against a stronger threat model in which we assume that TLS security has
> been lost.
> -- Neil
> _______________________________________________
> OAuth mailing list
Aaron Parecki
@aaronpk <>