[OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

Filip Skokan <panva.ip@gmail.com> Tue, 14 April 2020 08:13 UTC

Return-Path: <panva.ip@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B7CCF3A0404 for <oauth@ietfa.amsl.com>; Tue, 14 Apr 2020 01:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id urqAZbj3WLjp for <oauth@ietfa.amsl.com>; Tue, 14 Apr 2020 01:13:32 -0700 (PDT)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 CCE223A0407 for <oauth@ietf.org>; Tue, 14 Apr 2020 01:13:32 -0700 (PDT)
Received: by mail-yb1-xb2e.google.com with SMTP id h205so6733353ybg.6 for <oauth@ietf.org>; Tue, 14 Apr 2020 01:13:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qQ5+rI+ZANN6xZphofSDogQrBURkhrKU/L2TiD/9//M=; b=AHUWvrwTK1qxtjlBPlsOp7YP81heKYrZok0cIWCdDbE/U/3EgqRabRwpKs4LOVs4R0 75NLZja9eFJV5NOMSsSbr/T1/D4wjOQtTAeSKDereyzctdXWW8umYPKZGeNgXJGicmiN Gu4offqP3LMrGs6jwkZAMzqy6XjnetAxDbedqdZd0bDqj/tJn3lcX9xe3/J9oPjhLEwZ 1sP+AkkUyVRJ5KmYXZOk0NauVN1s2f/v40+6ioVYBjr5DX+CmnYfMd7BIVCL7N2ZrT3A h8xLVfBpr/l62RQlS+Wb4cHl0YmEbbpe9vtWDdg9ocMSLzFQc/e48XxAk1hl4ELlQCfL OQIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qQ5+rI+ZANN6xZphofSDogQrBURkhrKU/L2TiD/9//M=; b=qrEOh4KBiinYtPFTEoEzAPnbp3T/6SRCi235hlp+XgyjxewbrDjQ8xsdYzXDQaf0Wp 8Ua9DjW8Y1Sty9BJvIY2C01rY5DuAy6+2r1nrTT2uAQ0DNDBEFO/YKDjYRhs7gmjz4AF JWxOzB04QdNKeIz1Hzvav3/0IcCNoU2+/2n5BD7p3SDbfYVIi/FMC5NPzTomX1mHHnHZ b+vCK+k5GXNXOiz1kviTeJyJesdNG/chDbqZmfwqGfefQuYThM7wfCxWOOKUlfHjJIAo P8tViHzi3R0aLLg45r0UtW/K/cagFFAeKDnVunEuJdZ3m+qSyuxoZF6TZ/iX/8FkHV3o igdQ==
X-Gm-Message-State: AGi0Puboo3UfJ5owa+IsUKAMrks2ih3Uo1UmqQ5e0nxYLatmcDn4t7Au IR3b4Y0gDi6E9TCL5BSR9c6ykAMaBZb8ciBi1PwF2v838w==
X-Google-Smtp-Source: APiQypI3K+nZhUkOwOkDRJI3x5K6vrDls753W2O3TXNKjGf3vGjP+YIRVzX6gATihul06ijZY2kcmhrQJ6nOvpo9cWw=
X-Received: by 2002:a25:5f0c:: with SMTP id t12mr31392832ybb.254.1586852011693; Tue, 14 Apr 2020 01:13:31 -0700 (PDT)
MIME-Version: 1.0
From: Filip Skokan <panva.ip@gmail.com>
Date: Tue, 14 Apr 2020 10:12:54 +0200
Message-ID: <CALAqi_-9+JYBMSSBnX9PUZkvrPrGTtS8wrJduoPCxMs9+FguPQ@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000077db2e05a33bc627"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/KY3PaxB20ncOLHpk7C9wyM-PgVM>
Subject: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns
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, 14 Apr 2020 08:13:35 -0000

I've wondered about the decision to use a new scheme before
<https://github.com/danielfett/draft-dpop/issues/41#issuecomment-490096716> but
this time i'd like to challenge the immediate usability of the future spec
for one specific case - sender constraining public client Refresh Tokens.

If at all, it is going to take time for RS implementations to recognize the
new `DPoP` authorization scheme, let alone process it properly. In the
meantime, i'd still like to have the option to bind issued public client
refresh tokens using DPoP without affecting the access tokens. In doing so
i get an immediate win in sender constraining the refresh tokens but not
introducing a breaking change for the RS.

   - Do you see this as something an AS implementation is just free to do
   since it's both the issuer and recipient of a refresh token? Should this be
   somehow baked in the draft?
   - Do you think client registration metadata could be used to signal such
   - Do you think the protocol should have signals in the messages
   themselves to say what the client wants to apply DPoP to?
   - What if AS and RS don't have a shared support DPoP JWS Algorithm? Do
   we disqualify such cases or allow for sending two proofs, one for the AS to
   bind refresh tokens to, one for the RS to bind access tokens to?

*Filip Skokan*