Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

Brian Campbell <bcampbell@pingidentity.com> Tue, 08 September 2020 22:45 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 2AAF63A045B for <oauth@ietfa.amsl.com>; Tue, 8 Sep 2020 15:45:50 -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 7tUGS-dtB8AB for <oauth@ietfa.amsl.com>; Tue, 8 Sep 2020 15:45:48 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 C85933A02BE for <oauth@ietf.org>; Tue, 8 Sep 2020 15:45:47 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id u4so953489ljd.10 for <oauth@ietf.org>; Tue, 08 Sep 2020 15:45:47 -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=HnPu94PGkkInjMmrgD0cNgBWmuk7fwmzVqqtKq0CeVk=; b=FnFIgRxXDDbjcja1J9jQPf7Xy/h02xARo3aUrt3QbH85pZoP3bCU998mvWyKfBxRJp wARGhvPugvgGhMHIkV788oIhzr8ePvTefRo0KkTYb2apJHMDPgy4IfVg+WKhhCb/fRYY LDp0xOYCrim77mCmCxwrlZPRc8cmBlAs3If2c9L5MJEioAbzubvPV9O6H3tvJ7mz7+Da oTXIBchdpYoXM3tJfTHr2T2FBCu4E1Wi5G/hc3afDRT7lbHXAMonoaK3b5BIoLuPJ//y OEnlrXVO4r7GeehpWoDXWju3VnjL9QTcGoth73w5lU8lZs6iA0wZcujEYxZa5VUyJTIK fB9w==
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=HnPu94PGkkInjMmrgD0cNgBWmuk7fwmzVqqtKq0CeVk=; b=EHLb1cCoH75s/Lwxrq5qKGkKv2v+Gdw/+pxcD2zoGwnSg45I8nxLDKDowP9SSVx0C1 geRS7zSZbiwk6gZuECLcLxOR5QEDK6grlfbn1+CGjCaj9BxFRBwxW9CXFuquUzkmk/QV zTaZiUFiWbys1ok+cK5jYBnAtbKgWrw6oW8nsst/YI0rVRmqxdkFTvIYE1gn4bmnULk3 IYRemc72LQicGyyb1AvejwcQZgteAfcSNeA3jv1fHFSAQzeI+VbuB0suHXdCPh5qxx2E HG8PRwg+xtHBts2ckPy9S0PG1jPRNc5cBUz8ro+eUIRrRVp/M0axtEe716820Ru7LMjc O88A==
X-Gm-Message-State: AOAM533djG5CcXC3g0kUCMQK9AD5zrM57evh9C1vElrm3SGVi6COxEax nzIupEw/9XAREn6hZYE5+i21trvTQp9uFUE6epQTIyHppBDqvUPNz0u0BR/th6SgfAM/jTDl0+R Z2yUzyMfxn/4yHuWkXE8Csw==
X-Google-Smtp-Source: ABdhPJxFusVt7pqLJFOayZGt86zCuzak0CEGWNkRRdvm9b/qITqF8atSTZ0tQMuS2XCBQaBlrEFNG9HqfRhKSx2hT5s=
X-Received: by 2002:a2e:5054:: with SMTP id v20mr373530ljd.345.1599605145752; Tue, 08 Sep 2020 15:45:45 -0700 (PDT)
MIME-Version: 1.0
References: <TY1PR01MB1466E7D4AF21EA5C56467E6AE5290@TY1PR01MB1466.jpnprd01.prod.outlook.com>
In-Reply-To: <TY1PR01MB1466E7D4AF21EA5C56467E6AE5290@TY1PR01MB1466.jpnprd01.prod.outlook.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 8 Sep 2020 16:45:19 -0600
Message-ID: <CA+k3eCRffzry_+GVieOcWs0RHqwo_XGgMTwx4LOCZFPioD_xdw@mail.gmail.com>
To: toshio9.ito@toshiba.co.jp
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007e729705aed5186c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/psdEkCEhbSu-cGufPWueVtGG1aU>
Subject: Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?
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, 08 Sep 2020 22:45:50 -0000

Indeed there are cases, as you point out, where the key might be knowable
to the server via some other means, which makes the "jwk" header in the
DPoP proof not strictly necessary. And while omitting the key in such cases
would reduce the size of some messages (the DPoP proof anyway), such
optionality would add complexity to implementations and deployments (and
that kind of complexity can and often does degrade interoperability and
even security). How, for example, would a client know if the access token
includes the public key and thus whether or not to include the key with the
proof? Sure the access token could always include the key (rather than
thumbprint) but then there's the question of how to get the key to the AS.
As well as the stated desire to utilize the same DPoP Proof structure for
requests to both the AS and RS. There will be some clients that have public
key(s) registered and some that won't (maybe a lot that won't as a driving
use case for many for this is key binding access and refresh tokens for
public clients). The protocol defined by the draft needs to account for
both.

Ultimately there are a number of different ways the necessary data could
flow through the various protocol elements. And there are some tradeoffs
with different approaches and/or trying to accommodate variations under one
approach. The approach the draft has taken thus far is to prioritize
consistency and simplicity as much as is possible. And that ethos has led
to how it's currently defined, which is to always include the key in the
proof and bind to a hash of the key in the access token.


On Tue, Sep 8, 2020 at 3:29 AM <toshio9.ito@toshiba.co.jp> wrote:

> Hi all,
>
> In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is
> REQUIRED. However, there are some cases where "jwk" is not necessary in
> theory.
>
> For example, consider a case where the client is registered with the
> Authorization Server, and its one and only public key is also registered
> with
> the AS. In that case, when the AS receives a request on Token endpoint, it
> can
> just use the public key registered for the client to verify the DPoP Proof.
> There is no need to send the public key in DPoP Proof.
>
> The same goes for requests to the Resource Server, if the AS and RS share
> the
> storage for clients' public keys. Things are a little difficult if the AS
> and RS
> are separate. Probably the Access Token or its introspection result have to
> include the public key (instead of its thumbprint as described in section
> 7).
>
> If the client registers multiple keys with the AS, it needs to specify
> which key
> it uses to sign the DPoP Proof. However, there is still no absolute need
> to send
> the whole key in DPoP Proof. Instead, the client could use "kid" header
> parameter to specify the key.
>
> Daniel Fett once mentioned the above case in the GitHub issue #26 [*1],
> but I'm
> not sure what happened to the discussion. There was also a comment on the
> latest
> draft about the "jwk" header parameter [*2]. I agree with using the same
> DPoP
> Proof structure for requests to AS and RS, but I think there are some cases
> where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would allow
> those cases to reduce some messaging overhead.
>
> I'd like to hear your opinions about it.
>
>
> [*1]:
> https://github.com/danielfett/draft-dpop/issues/26#issuecomment-480701746
> [*2]:
> https://mailarchive.ietf.org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv2QRc/
>
>
> Best regards,
> Toshio Ito
>
> -------------
> Toshio Ito
> Research and Development Center
> Toshiba Corporation
>
> _______________________________________________
> 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._