IETF Logo Mail Archive

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

Aaron Parecki <aaron@parecki.com> Tue, 10 March 2020 13:46 UTC

Return-Path: <aaron@parecki.com>
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 5A0DD3A0F47 for <oauth@ietfa.amsl.com>; Tue, 10 Mar 2020 06:46:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
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 crWkv0iA1z_4 for <oauth@ietfa.amsl.com>; Tue, 10 Mar 2020 06:46:56 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0613A1375 for <oauth@ietf.org>; Tue, 10 Mar 2020 06:46:55 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id j69so11999350ila.11 for <oauth@ietf.org>; Tue, 10 Mar 2020 06:46:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tc03ftwq0LV5KJeoHZMUiD7VLGgsoKyhzv17io+y1Jw=; b=N+OWw4U3ZwkKER5o0Ak/qooQopLDlxIik6ijBb0ox1Yx/WCAIKLEwblvvzYVK0vvyh vUFDZ+LkIPLMdmlV63lyxCPqHvF2jXQhOTwbPc1k6zmzUOKNczZrD4oaGkABXN2a4cTO IAthvyAFte1Al4FchYfbszwcs6bJl/mmnIn6b9HDdOSQL9cy/OaNV4n025OPbdxozuaY Ag4qx//lIjtcSd61zMbOqGaBIdi2+ohKwL0BiKpXM+f2qu++viwLkuoTh+Beih4Z300q qBNqnNS46X7iWanIGlo7m6CIMbLGxZVjmSJEQBBM5kIFcMVshM7cjVdJHzZ6KMJkYWHK wMGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tc03ftwq0LV5KJeoHZMUiD7VLGgsoKyhzv17io+y1Jw=; b=DioZyF9mH9aiitB4Tf6FSrlumPDkkqiiAsZYIzuthElJVuTcYtzx8ykkF/HC94fAwA PM5rlrNEVhIsmDqRmD11N+i75H9D6GjUs9DCpcPGlVHVirr+x/+umCzHSW91NHJrSC2O 14ZEJm2T3dOYhOyYo6Kxs/Y0chIJ3JwqLgNg6gLop0fn8lcu/jq/uXPP9slx0G4NsnsB u0pCdL7RP1ZyNdzjaGzR9grMPdVkVeJV1afpffDSsQpcDmqKAWBUWVtyuPLfeLLY1S9y 4UGw4I+gPTAaVmip6tiUooLqH0L/WyrRwvyuLOApJQXWRzEg/ecbxLgP8s2EP3fAQ8Mo 93yA==
X-Gm-Message-State: ANhLgQ1Z8sgJWdtdNjWg2Rxp33ZuVT4Bg9peoCVMgg0jjzinwp89ggyc BlFwZDWpThsdz6MRu3VNYa87/b7GMyw=
X-Google-Smtp-Source: ADFU+vteIdRz8RYf45wI0PehBG7wLNFbVoRjLIt/YSypK9lLbRfAl1fo0q6L6D4qCdLvBRgqYxS4ZQ==
X-Received: by 2002:a92:5b51:: with SMTP id p78mr6767206ilb.250.1583848014611; Tue, 10 Mar 2020 06:46:54 -0700 (PDT)
Received: from mail-il1-f170.google.com (mail-il1-f170.google.com. [209.85.166.170]) by smtp.gmail.com with ESMTPSA id j23sm3600786ioa.10.2020.03.10.06.46.53 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2020 06:46:53 -0700 (PDT)
Received: by mail-il1-f170.google.com with SMTP id p1so8020552ils.12 for <oauth@ietf.org>; Tue, 10 Mar 2020 06:46:53 -0700 (PDT)
X-Received: by 2002:a92:8b8b:: with SMTP id i133mr15950448ild.307.1583848013706; Tue, 10 Mar 2020 06:46:53 -0700 (PDT)
MIME-Version: 1.0
References: <CH2PR00MB06784BE1BB83918ABC652C7AF5FF0@CH2PR00MB0678.namprd00.prod.outlook.com> <CAGL6ep+tgKaW=-rXCMk_8HXXNGWYT3sN7GRqY=x4VUW=Qzc+sg@mail.gmail.com> <CC7A1291-553D-4487-BA33-442C482A5D21@mit.edu>
In-Reply-To: <CC7A1291-553D-4487-BA33-442C482A5D21@mit.edu>
From: Aaron Parecki <aaron@parecki.com>
Date: Tue, 10 Mar 2020 06:46:42 -0700
X-Gmail-Original-Message-ID: <CAGBSGjpupNnLdOHNO_SLrBL6a_PUe=vTpZgN7Lv1QY03H1q6jA@mail.gmail.com>
Message-ID: <CAGBSGjpupNnLdOHNO_SLrBL6a_PUe=vTpZgN7Lv1QY03H1q6jA@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003c4bd605a0805abe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/NhosezpCrhd0R2qnrpvzyojifP8>
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:46:58 -0000

This is my sentiment as well, I would not support this text being added to
the DPoP draft.

Aaron



On Tue, Mar 10, 2020 at 6:35 AM Justin Richer <jricher@mit.edu> wrote:

> 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> 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
>>
>>
>>
>> An HTML-formatted version is also available at:
>>
>>    -
>>    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
>> and as @selfissued <https://twitter.com/selfissued>.
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

v2.23.0 | Report a Bug | By Email