Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt

William Denniss <> Sun, 03 May 2020 23:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A02B3A0975 for <>; Sun, 3 May 2020 16:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 zom9BnhWVZSx for <>; Sun, 3 May 2020 16:54:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBF9F3A096B for <>; Sun, 3 May 2020 16:54:15 -0700 (PDT)
Received: by with SMTP id j4so7471767otr.11 for <>; Sun, 03 May 2020 16:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5J2Y9nqMC6D2Qrlf3mNDyi1HV3hLIRkf4potUQWQ+/g=; b=kT/0/c7SrwsDfmZrESikVsMhnhu8GVwnfPWcwdawluBUJ7KctVwWLYNFMGbOtFZ1b9 xLVSf64GgsAsDTI3UIYJgo/dOAZtlOUt8gUNZaZQabTHrHq0EmDGWU00/+/duJKb8HT8 xxdsrmzbMZ96yqRQUh47HyNs5j/xGvwmZ/tRI0qhWhwWKMQJALSss5YgD3zpUBtzN0sK b3U1i7leToK0PhDVVFrmp9RFDfWFRlKUR7mcwmvNSxbABJXCUFwCTjyIyxZsFi2R7LCz 27VRr45jmbKwqD30OVoLKjJPuYEDHWID+z7rHfaIoNa98yNPBnob2IA3F4HBIYdmlhn4 LAjQ==
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=5J2Y9nqMC6D2Qrlf3mNDyi1HV3hLIRkf4potUQWQ+/g=; b=tzVbwB64pkjDkLf279GBpozVH5eX/wyVJ5XMUascVcxq8DQWmG+Mng2sn0yPkwgz9M zdyBPdavpH75kSGkLOu/aAAtJUyl+4a7noPH63FrBrBdijtA2e95im1+TYNunJupslao g2iDHoT7jp7WEFQFp46ZAEF/phU2K73iUpdBlMiO8JygXCXW3k8uvACSLlFOtNmtRnJl j4Ny1OTrSYmaXUCiIG329C1zZPRBeCIZ7rGi/M346TzNBdIWVcbePhslHfzfzSxA4bYK 3EO9r/3okWb6rtk0Wqjh0pBYKhts25rp/aa5tp0eCs4k2GXjLcb6brBIHMf40dzjJ6to Q3jA==
X-Gm-Message-State: AGi0Pua4Jb63X+VVDHQVY2ePbNV/xjODMhzPUFcDVXakfKsTQM+jS2kL gNSlA7y269Sln0vU4LKGJOHafJw2O9y8VzzI6L1XOw==
X-Google-Smtp-Source: APiQypKuQfrnk9pOLmVeOeQMG7t0JM3QAoYhPR9UaCUCdBlSEKvAgLpMwOruecwi/fktBWSH5VJ9esnQFrbOf56bVDA=
X-Received: by 2002:a9d:7ada:: with SMTP id m26mr11717253otn.181.1588550054696; Sun, 03 May 2020 16:54:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: William Denniss <>
Date: Sun, 3 May 2020 16:54:02 -0700
Message-ID: <>
To: Brian Campbell <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="000000000000b8276805a4c72185"
Archived-At: <>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.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: Sun, 03 May 2020 23:54:18 -0000

Hi Brian, et. al,

I reviewed the document. Overall I think the concept is clearly
communicated, both the need, and how it is implemented. It was easy to
read, and concise. Great work!

Some comments and nits:

§ 1:
(nit) "DPoP" should be defined on first use in the body of the document, in
my opinion.

§ 3:

I don't follow this why the sentence "For confidential clients, refresh
tokens are bound to the "client_id", which is more flexible than binding it
to a particular public key." belongs in this explanation of the diagram. Is
it indicating that DPoP is not required for confidential clients? If the
sentence was deleted / moved elsewhere in the doc, would it alter the
meaning of the diagram?

I wonder if the diagram would be simpler with less optionality (e.g. public
/ confidential separated into 2 diagrams, if they behave differently), or
maybe just kept as 1 simple diagram, with any optionality described later.
Generally I think these kind of overview diagrams (which are extremely
helpful, and now I must go add one to my own draft) are best if they give
an overview of the protocol without trying to document the entire
specification, or justify why different decisions are made.

§ 4.1 figure 2

(nit) When showing a decoded JWT with the signature dropped, I think it's a
good idea to first present the full encoded JWT. Someone who is new to JWT
may not realize that this data has a signature (or even that it is encoded
at all), since it was dropped already, while showing the before/after can
make this clear. Not essential, I just think it would help readers. Having
this also sets the scene for later when encoded JWTs are used in example
request headers.

§ 4.1, below figure 2:

Regarding "Note: To keep DPoP simple to implement, only the HTTP method and
   are signed in DPoP proofs."

I found this confusing as the entire JWT is signed, and the signature
covers the whole JWT and not just those 2 claims. I get that since the JWT
only meaningfully contains the HTTP method and URI that the statement is
effectively true, but I would rephrase. Something along the lines of:

"Of the HTTP headers in the request, only the HTTP method and URI are
included in the DPoP JWT, and therefore only these 2 headers of the request
are covered by the DPoP proof"

(nit) I would also drop the "To keep DPoP simple to implement" here, and
maybe move any discussion about the design trade-offs to the security
considerations (9.4).

§ 5

(nit) Expand "AS" on first use (or better: just say "authorization server"
and skip the acronym in this case, as "AS" is insider lingo IMO)

§ 5

Regarding "If a refresh token is issued to a public client"...

What about when it's issued to the confidential client? I think when
specific behavior is documented for one client type, it's probably good to
at least mention how the other types behave.

I think this could be clarified here. In fact, I wonder if the text I
highlighted earlier from § 3 might belong here.

§ 8

(nit) Suggest moving to an Appendix

§ 9.1

(nit) "up to a few seconds", I would just say "e.g. a few seconds in the
future". Seems odd to specify an upper bound on a non-exact number.

§ 9.4

" DPoP does not ensure the integrity of the payload or headers of
   requests.  The signature of DPoP proofs only contains the HTTP URI
   and method, but not, for example, the message body or other request

Again, I find this an awkward phrase, "the signature of the DPoP proofs
only contains the HTTP URI and method", and I think it' better to talk
about the JWT only containing these claims, and the signature therefore
only signing those claims. Also, (nit) does a proof "contain" something, or
more accurately cover/sign something?


On Fri, May 1, 2020 at 12:04 PM Brian Campbell <bcampbell=> wrote:

> I've pushed out a -01 revision of DPoP hopefully allowing folks enough
> time to read it before the interim meeting on Monday (apologies that it
> wasn't sooner but the edits took longer than expected or hoped). For ease
> of reference the changes in this revision are summarized below. There are,
> of course, still outstanding issues and discussion points that I hope to
> make some progress on during the interim meeting on Monday.
>    -01
>    *  Editorial updates
>    *  Attempt to more formally define the DPoP Authorization header
>       scheme
>    *  Define the 401/WWW-Authenticate challenge
>    *  Added "invalid_dpop_proof" error code for DPoP errors in token
>       request
>    *  Fixed up and added to the IANA section
>    *  Added "dpop_signing_alg_values_supported" authorization server
>       metadata
>    *  Moved the Acknowledgements into an Appendix and added a bunch of
>       names (best effort)
> ---------- Forwarded message ---------
> From: < <>>
> Date: Fri, May 1, 2020 at 12:24 PM
> Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt
> To: Torsten Lodderstedt <>, David Waite <
>>, John Bradley <>, Brian
> Campbell <>, Daniel Fett <>,
> Michael Jones <>
> A new version of I-D, draft-ietf-oauth-dpop-01.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
> Name:           draft-ietf-oauth-dpop
> Revision:       01
> Title:          OAuth 2.0 Demonstration of Proof-of-Possession at the
> Application Layer (DPoP)
> Document date:  2020-05-01
> Group:          oauth
> Pages:          22
> URL:
> Status:
> Htmlized:
> Htmlized:
> Diff: 
> Abstract:
>    This document describes a mechanism for sender-constraining OAuth 2.0
>    tokens via a proof-of-possession mechanism on the application level.
>    This mechanism allows for the detection of replay attacks with access
>    and refresh tokens.
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> The IETF Secretariat
> *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