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

Brian Campbell <bcampbell@pingidentity.com> Wed, 11 March 2020 19:28 UTC

Return-Path: <bcampbell@pingidentity.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 610823A0769 for <oauth@ietfa.amsl.com>; Wed, 11 Mar 2020 12:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=pingidentity.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 qRYhTI2R1FGq for <oauth@ietfa.amsl.com>; Wed, 11 Mar 2020 12:28:23 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 23D923A074B for <oauth@ietf.org>; Wed, 11 Mar 2020 12:28:17 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id q10so2715010lfo.8 for <oauth@ietf.org>; Wed, 11 Mar 2020 12:28:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qdk6xZQfLv+QYnp2v20joFwwrjCmJRI8vBVl2ECv2pw=; b=RqrLghQ5yVGUTm9BIvufda32S5TbBl6SkN6sz7HM4Kr5bWDoHG/lg/PuBbkyAeFQe2 4LDG4pkKtApgxgVNUPtJdO0kYKKssw1s/RXDkTht3EagMuo1vkTu+tTSZSSEDkOhx0n7 mw8t1ZnZYSi8bhlz0jJHXwkTK458hvzIsHghPNTASiPZ94BzEEDNWCy3jxYOz+R843m9 oSgg73yfkLxxc2NpiQtY59cwk5aeI5q+ntC/gFR++bk0YleX6xe63D9hFB5iFeBY3aVu n87uZKdOVEz8oneiVdibaZ+8cLdUmTD/l7olw2tEMmyPWogb36QdLm5Mvoto/a8ILlfI D93A==
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=qdk6xZQfLv+QYnp2v20joFwwrjCmJRI8vBVl2ECv2pw=; b=VQqdGdSFS4IWPtaCXnYSgPJiUG5Lb1uZgFFyA6tqCSi8bSqO6MvfZDEojNT0vFN5rQ y8YcZhg7fNGnSpzWGKDYQXP/1sEk03YjGfRATfY+1z8Zzg04JJzv6wAyN41PDqg4ankS /DmqqQ6qZJyQH+Izd9xA3K3MkBbwviheztwIk3V1Sii/uZsOguNwxeewBE4eRudWfLE2 5/WMmqohWW8l5Aqlop6rIfKnRvLl/tZrwd83ukbdR6qJBq4Io8k5fcMVNubZc06eE2TU GCrsIm67LR8A7beU33tVRRghTQjN40GPA1fRvIKF+40nj1thts0pGEaQNhxN9ERzLjRs nqFA==
X-Gm-Message-State: ANhLgQ1+X760VpDAvmiv1QTp6zo6c5QZGFfFC2nR0Dv2WIkb0MJK6OSU u8Ng2U7+jj9hiDC7KPd/9147R3MObIHf+VLma6o4Sd1FcSRwte3W7Q2eYJ3cgnVzh5PkYmbTVMw 7DqggMothXwYhRw==
X-Google-Smtp-Source: ADFU+vtEP/tJV8Anw3fzSeSBoAlh/rAgaD9GBfRP/8kQ+WX8gdjRw+NHVfpTc4JSg4AUPunGIjgxD1cry1Vb5E+/EYo=
X-Received: by 2002:ac2:46d0:: with SMTP id p16mr2991085lfo.167.1583954895247; Wed, 11 Mar 2020 12:28:15 -0700 (PDT)
MIME-Version: 1.0
References: <CH2PR00MB06784BE1BB83918ABC652C7AF5FF0@CH2PR00MB0678.namprd00.prod.outlook.com><E69C8489-7B6F-42FC-961E-B38B8CE27B00@gmail.com> <MN2PR00MB0686560229292F392C57D399F5FF0@MN2PR00MB0686.namprd00.prod.outlook.com>
In-Reply-To: <MN2PR00MB0686560229292F392C57D399F5FF0@MN2PR00MB0686.namprd00.prod.outlook.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 11 Mar 2020 13:27:49 -0600
Message-ID: <CA+k3eCRLe306RNYYvUNVJcKYhVU2k-kN+DW-AuzSp3ive01jUA@mail.gmail.com>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Cc: Filip Skokan <panva.ip@gmail.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000df3a4b05a0993c2b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/odjlKNcqorVsYcTKs2Xg9D-lwzE>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: 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: Wed, 11 Mar 2020 19:28:26 -0000

On Tue, Mar 10, 2020 at 10:21 AM Mike Jones <Michael.Jones=
40microsoft.com@dmarc.ietf.org> wrote:

> I haven’t thought about PAR but would welcome thoughts.  In general, I
> assume that the “htu” value should be the actual endpoint used.  What do
> others think?
>

Yeah, in general, the “htu” and "htm" values should probably be related to
the actual request being made. PAR is a potentially interesting case where
it could maybe be argued that the values should reflect the eventual
request to the authorization endpoint. But I don't see any real reason to
pursue that angle. PAR could also potentially accept the DPoP header rather
than the dpop parameter because it's being called directly by the client.
But PAR being consistent in how it treats authorization request parameters
is probably preferable. And honestly PAR + DPoP bound access tokens issued
directly from the authorization endpoint seems a dubious combination so
maybe it's okay to be left un or under specified. Or maybe even prohibited.


>
>
> Yes, I agree that the DPoP parameters on the front channel should only
> apply to the front-channel access token, whereas if you’re using a
> response_type like “code token”, then you’d want to send a separate DPoP
> proof JWT to the token endpoint.  I’ll plan to add that to the next draft.
>

+1000



>
>                                                        Thanks,
>
>                                                        -- Mike
>
>
>
> *From:* Filip Skokan <panva.ip@gmail.com>
> *Sent:* Tuesday, March 10, 2020 12:01 AM
> *To:* Mike Jones <Michael.Jones@microsoft.com>
> *Cc:* oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow
>
>
>
> 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?
>
>
>
> Best,
>
> Filip
>
>
>
> Odesláno z iPhonu
>
>
>
> 10. 3. 2020 v 1:12, Mike Jones <
> Michael.Jones=40microsoft.com@dmarc.ietf.org>:
>
> 
>
> 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
>

-- 
_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._