Re: [OAUTH-WG] DPoP and refresh tokens
Dick Hardt <dick.hardt@gmail.com> Wed, 28 October 2020 22:35 UTC
Return-Path: <dick.hardt@gmail.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 928CD3A0976 for <oauth@ietfa.amsl.com>; Wed, 28 Oct 2020 15:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
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_FONT_LOW_CONTRAST=0.001, 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=gmail.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 jjG-WGsUeEDQ for <oauth@ietfa.amsl.com>; Wed, 28 Oct 2020 15:35:51 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 6834F3A0975 for <oauth@ietf.org>; Wed, 28 Oct 2020 15:35:51 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id p15so959561ljj.8 for <oauth@ietf.org>; Wed, 28 Oct 2020 15:35:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PUgJhOO/G/Av8zYZEDQ3NJZ7yia6nTTM9patQYJyCoE=; b=sGOfIB44HH78lmc4rKWWs0onHGAZbyKmTUEFCxWf14m8VPXSqiiwN+C5j+Bi2r+qiO nRvma9gC+uuFSkf8UJuIxyz5w6E3gT7gliys7m230TLIw3vRh7OAUuRlPqbE8w933ZgO rGCyoHbCzM4kKmVECVKw103UnO1326xrHR75FmtE8cZaRl1fJmzrkiI5W6CwGXmUQV9x f3WsOZ/uCszYXsP0OZErKpsMAzcnjTvEq3qYAqX51J0Bqd/SAmkAlkhfb7Key053HS7P 870yhEBQIdzTQ7ljYtYwQRHKmUSKc7+NJ5uw4MeVxmnd9NXjoL1EZT5VGMKYPSDFQP4N kucw==
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=PUgJhOO/G/Av8zYZEDQ3NJZ7yia6nTTM9patQYJyCoE=; b=KyeutyVk0kcsLqSb58wEYJjE0KoxjnUw9LGL0A/xE1DrsQkExXo3b7JUf8llbyCiO0 I8xt93YjJiXbvyaWgg1HykltdBDJ8j4hzOEbKEbe7Ax2RCLD8apa/Un3udJnPl0nH3bY wgoVP5CIjen1oMaao/Lk6zdOpneAgKvRBw0ZaX/OCvtefocaMQCRweUYKUxUnzhOzpRc vaYTZuLLAe2LhgB1Wb8BjOcWSrGiIv8oGH4jrbNDa/X3BugrrWVExyspG2EU92AOE+Q0 XUn5LAcs9sJTH6SZGdmEi5RJpSXuqPXdK96VrU3YtMwTNBOakdHHZknIeB9xg6HCqwpy gziQ==
X-Gm-Message-State: AOAM531kUb+d8qWk5FgRxb35nqSbK9Aip0CRYyIdUdqoRoiZGY0Ku4+A +xCFkfj8InXVVvCj3yly3wKTIHZ+jTjOcJBVZOk=
X-Google-Smtp-Source: ABdhPJwvheSroASMrCHCBVnVvKOakk0FPNECmf4pBb5wVh+V0UblxJXS1FfDM5EiXXUsIV5r9VInXP1eehmX+MC+Lzw=
X-Received: by 2002:a2e:9a17:: with SMTP id o23mr612213lji.242.1603924549429; Wed, 28 Oct 2020 15:35:49 -0700 (PDT)
MIME-Version: 1.0
References: <CAD9ie-ttterDkFqcW_rbV6gwwU=puL3YJ5c9uLY4Lj3KvEWG-Q@mail.gmail.com> <CA+k3eCQmGa9V5cFy+zFrV8E-agi466=oz_BaR-_cJYMK1HgY+A@mail.gmail.com>
In-Reply-To: <CA+k3eCQmGa9V5cFy+zFrV8E-agi466=oz_BaR-_cJYMK1HgY+A@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Wed, 28 Oct 2020 15:35:13 -0700
Message-ID: <CAD9ie-tw5+aFK5PK3wWKMfq4-17c3X1rO6=oEqt+UgaVfdBzqg@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000003eeff05b2c2c906"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/slIr7HkmPLB-5emcbQuU9boQcEM>
Subject: Re: [OAUTH-WG] DPoP and refresh tokens
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, 28 Oct 2020 22:35:54 -0000
Hey Brian A refresh example would make it more clear, and would also assist in communicating that DPoP could be used just for refresh. I see in the updated text that using DPoP with confidential clients is discouraged. I understand the RT is sender constrained -- but asymmetric cryptography is much stronger than a shared secret. Why discourage its use? ᐧ On Wed, Oct 28, 2020 at 3:20 PM Brian Campbell <bcampbell@pingidentity.com> wrote: > I'm currently working on the draft and hope to have a new revision > published relatively soon. Just the other day I made some changes to the > text around RTs with > https://github.com/danielfett/draft-dpop/commit/11d90264bffa0325461e7f8d96311fac44986974 > that maybe/hopefully makes some of it more clear? But basically the RTs are > only bound for public clients and the exact mechanism to do it is left up > to the AS. The AS both creates and consumes the RT so however it chooses to > associate the DPoP key with the RT is its own implementation detail. > Getting a new bound access token using an RT is meant to be covered in sec > 5 "Token Request (Binding Tokens to a Public Key)" with RT being just one > of the grants that could be presented in the token request in conjunction > with the DPoP proof, and the AS would bind the AT it issues to the key in > that DPoP proof. I'd sort of assumed that would just be understood. But do > you think it (including the recent changes) needs more explanation? > > I do think using DPoP only for token refresh (only for public clients > though) would be appropriate, for some cases anyway. This has come up on > the list here previously and the general consensus was also that it'd be > useful. I plan to add some language describing that (and loosening some > language that could be perceived as prohibiting it) but haven't gotten to > that item on the editing todo list yet. > > > > > On Wed, Oct 28, 2020 at 2:46 PM Dick Hardt <dick.hardt@gmail.com> wrote: > >> Hello >> >> I was reviewing the latest DPoP draft[1] and saw numerous mentions of >> using a DPoP proof for refreshing an access token, but no explicit >> description of how to do that, nor an example. Was this intentional? >> >> Perhaps a new section "Refreshing an Access Token"? >> >> Additionally, I can imagine that an AS can improve its security posture >> by adding support for DPoP *just* to token refresh and not requiring >> existing resource servers to upgrade. Rotating refresh tokens would not be >> as critical for public clients using DPoP for token refresh. >> >> Would using DPoP only for token refresh be appropriate? If so, language >> describing that would be helpful. :) >> >> /Dick >> >> [1] https://tools.ietf.org/html/draft-fett-oauth-dpop-04 >> ᐧ >> _______________________________________________ >> 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.*
- Re: [OAUTH-WG] DPoP and refresh tokens Dick Hardt
- Re: [OAUTH-WG] DPoP and refresh tokens Brian Campbell
- Re: [OAUTH-WG] DPoP and refresh tokens Brian Campbell
- [OAUTH-WG] DPoP and refresh tokens Dick Hardt