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

Justin Richer <jricher@mit.edu> Tue, 10 March 2020 13:33 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4793A1318 for <oauth@ietfa.amsl.com>; Tue, 10 Mar 2020 06:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXUiT2eGA8l8 for <oauth@ietfa.amsl.com>; Tue, 10 Mar 2020 06:33:42 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65A03A136B for <oauth@ietf.org>; Tue, 10 Mar 2020 06:33:41 -0700 (PDT)
Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02ADXbCd000936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 09:33:38 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <CC7A1291-553D-4487-BA33-442C482A5D21@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B0AF1A69-EAD2-4DCE-8D20-80AB42DB13DD"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 10 Mar 2020 09:33:37 -0400
In-Reply-To: <CAGL6ep+tgKaW=-rXCMk_8HXXNGWYT3sN7GRqY=x4VUW=Qzc+sg@mail.gmail.com>
Cc: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
References: <CH2PR00MB06784BE1BB83918ABC652C7AF5FF0@CH2PR00MB0678.namprd00.prod.outlook.com> <CAGL6ep+tgKaW=-rXCMk_8HXXNGWYT3sN7GRqY=x4VUW=Qzc+sg@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/jRVMryH4ayXjvN5FrdvJ41XhJk4>
Subject: Re: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2020 13:33:51 -0000

I for one appreciate it being a separate draft as I don’t agree with this solution but do think we should move forward with DPoP.

 — Justin

> On Mar 10, 2020, at 6:40 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
> 
> Mike,
> 
> What was the reason for creating a separate draft for this?
> Why cannot this be folded into the exiting DPoP draft?
> 
> Regards,
>  Rifaat
> 
> 
> On Mon, Mar 9, 2020 at 8:12 PM Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org <mailto:40microsoft.com@dmarc.ietf.org>> wrote:
> As I previously described <https://self-issued.info/?p=1967>, 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:
> 
> https://tools.ietf.org/html/draft-jones-oauth-dpop-implicit-00 <https://tools.ietf.org/html/draft-jones-oauth-dpop-implicit-00>
>  
> 
> An HTML-formatted version is also available at:
> 
> https://self-issued.info/docs/draft-jones-oauth-dpop-implicit-00.html <https://self-issued.info/docs/draft-jones-oauth-dpop-implicit-00.html>
>  
> 
>                                                        -- Mike
> 
>  
> 
> P.S.  This notice was also posted at https://self-issued.info/?p=2063 <https://self-issued.info/?p=2063> and as @selfissued <https://twitter.com/selfissued>.
> 
>  
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth