Re: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow

Filip Skokan <> Tue, 10 March 2020 07:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82BE03A0A63 for <>; Tue, 10 Mar 2020 00:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sXk01MVZnViK for <>; Tue, 10 Mar 2020 00:01:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B3333A0A5B for <>; Tue, 10 Mar 2020 00:01:15 -0700 (PDT)
Received: by with SMTP id g62so56763wme.1 for <>; Tue, 10 Mar 2020 00:01:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=I7qklqUCeL2NdmZHeAQdAE3W78EeXwGW80urk/558wY=; b=cTY8kN6e6TD4WDP7u7Z2Kz7pWDzYQZjVmk3uWmeQ1Uy55mGviX98Wfcb0N9wJ0JogD LTBW1RhsO+i7Be+26J4zwLdO01jXbeaGb8i/8gASxBwu9yi13xDngSKWWGPcibiQVD4Z eiF4s6xooy4JaWaiyff/aA2QHjWC1aUs3kiQ9waYL5EhNDeLErFH6iqoX3jjahy6fQfs BnII5CHIpD9BgDjXD8z7hAzimLg95k8n8RRJ4S9kp2DA/qyVnYO6rXR8kcBNnrqVpDkv u6qvX/THmwZd4+p3wuLg+URpQ8ffGd6+u0Xt0//Mj4YWRhP4tig++kzuKGNYInHwSOnM L2Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=I7qklqUCeL2NdmZHeAQdAE3W78EeXwGW80urk/558wY=; b=VxWERPuphBvySxLUDyqmdJ34PGv/Y6/+CATmzmjruAisCONehKpWRH6p/2JqQwPTyw btdYRfNbMnGlT+S8XmTmPiOPjEWHMpFagSBTS4thTjPajAYPYsibT6+QKSkSCHUhWEGo 0NiIu/+bJvh5BlYfBKoVUJariwvoOjihQRzmcU5A4Pxey8GADK8ihw/Y6yh8IGm8jr9B pt9TYQ2Yw3ZGviKUjYPPEdFH7QniZkCXX8fVSOyC+91mBwPXZ4MYP4wYrVE0I0yMUPG6 Z8p0Ijnt5z+9eEtWnz4W8u1OdJ8AChiwcymVE5Ln+o3cqZgnNh5Kv/MXIdstwrUFP+oW 5aEg==
X-Gm-Message-State: ANhLgQ2y4oly5l5NyDDURVoTtXyfHZ+McgycAPRP7/qzor3+3FY/TgTq Mt2pGj5ErR3nJpHeprKGSKHW82vewg==
X-Google-Smtp-Source: ADFU+vuOqzxdibWrpgp3dysSmXRtFoYwsrS+Y0k6Pb0W6y1jYatI2olJX+yKLw6M2YcH95QEEPit1w==
X-Received: by 2002:a7b:c317:: with SMTP id k23mr393368wmj.87.1583823672378; Tue, 10 Mar 2020 00:01:12 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id n24sm25270902wra.61.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2020 00:01:11 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-17203D4B-7B01-409A-93D6-5B8BA7F15741"
Content-Transfer-Encoding: 7bit
From: Filip Skokan <>
Mime-Version: 1.0 (1.0)
Date: Tue, 10 Mar 2020 08:01:10 +0100
Message-Id: <>
References: <>
Cc: "" <>
In-Reply-To: <>
To: Mike Jones <>
X-Mailer: iPhone Mail (17D50)
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow
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: Tue, 10 Mar 2020 07:01:18 -0000

Hi Mike,

Thank you for the implicit dpop draft, quick questions

- what htu and htm should be used when used with PAR?
- is it fair to say that authorization request provided dpop parameters only apply to authorization endpoint issued access tokens and in case of hybrid flow - the client sends a new proof with the access token request to the token endpoint?


Odesláno z iPhonu

> 10. 3. 2020 v 1:12, Mike Jones <>:
> As I previously described, members of the OAuth working group have developed a simplified approach to providing application-level proof-of-possession protections for OAuth 2.0 access tokens and refresh tokens.  This approach is called OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP).  Among other benefits, it does not require a complicated and error-prone procedure for signing HTTP requests, as some past approaches have.
> However, the DPoP specification to date has assumed that the client is using the OAuth authorization code flow.  As promised at the last IETF meeting, we’ve now published a simple companion specification that describes how DPoP can be used with the OAuth implicit flow – in which access tokens are returned directly from the authorization endpoint.  The specification is mercifully brief because very little had to be added to supplement the existing DPoP spec to enable use of DPoP with the implicit flow.  Thanks to Brian Campbell and John Bradley for whiteboarding this solution with me.
> Finally, in a related development, it was decided during the OAuth virtual interim meeting today to call for working group adoption of the core DPoP draft.  That’s an important step on the journey towards making it a standard.
> The specification is available at:
> An HTML-formatted version is also available at:
>                                                        -- Mike
> P.S.  This notice was also posted at and as @selfissued.
> _______________________________________________
> OAuth mailing list