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

John Bradley <ve7jtb@ve7jtb.com> Tue, 08 September 2020 22:55 UTC

Return-Path: <ve7jtb@ve7jtb.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 098E73A07B3 for <oauth@ietfa.amsl.com>; Tue, 8 Sep 2020 15:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.846
X-Spam-Level:
X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, 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=ve7jtb-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 hYaSFufAbuCY for <oauth@ietfa.amsl.com>; Tue, 8 Sep 2020 15:55:30 -0700 (PDT)
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 5F8C73A0787 for <oauth@ietf.org>; Tue, 8 Sep 2020 15:55:30 -0700 (PDT)
Received: by mail-qv1-xf36.google.com with SMTP id di5so570193qvb.13 for <oauth@ietf.org>; Tue, 08 Sep 2020 15:55:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=TGtL37lk4ui9+wBCaQ6TUtG41RF9OqcY4UJzSwCMUZs=; b=QTCaPrrndhsRV4grszmdp/xT52E5L2W6NjvBjdOxzMNJRXyFNnB5Pdw2PQAVOxIrKZ Y32LnYLPWEhO2eFdSpeGGHaapoW3NINwIREo06E8Brtjx5GoZRZAhQeTgJOVeqzgS6sH veVyP1V2ia31XAmwYJ2E2ioxi8mJSTE5HlW9rT7Pi8fqEbDUonmUSaEjVCLktBcJAbBY Iv2qXcB6m0fzJSWthDb3IOSQAzF+TS65V+OPvjJ3JsgQca8fOcP9Vi13XDXg+7B4gJM+ XvW76H9FvfO9cos11nt49ofGTFADuevhmEcaN2cbSD+j1zuI7IGfyH0gCS1CK/voM9CP sxQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=TGtL37lk4ui9+wBCaQ6TUtG41RF9OqcY4UJzSwCMUZs=; b=KZvXZm6yEpJ+0oRTYyQkOw1gUPR5onpT3cQXiqKhMvMCpJMUYkkU24EJ2SA1zf5P0u D4dCqvNc1Z44rI8BolaJmXaDm54UXcor10T5RHgWSWkPxddm2didgVvdOIhJQcvtZah9 7LeyZUGsInr1kae86Yywtj/w2mEqj9w286+HgdmZX4GOeFtNo0LOkpfhVlqJ023pNe0b t5T0Fdq5mAThXsHxjlWq9xij80OHcSbmT258caWDCwqH6ZW14y/jZZMJ6l1pAvPmXeK6 8P3DBXex5c1M1wswC4MrWpdbajQKxJx3Zey0P80jb5ToB3dTgiUuBVFzcuc1ts9ZL+A3 tbQw==
X-Gm-Message-State: AOAM533+w27zJRys1HDaQJg3bCl74ChS6ZgKbvp3CXKDSebPWkf4VnVb 1RLqQprl0N2WkU+quo1r8eYnwzsyLiLOBMLJRh0=
X-Google-Smtp-Source: ABdhPJwWkV6q5L7VRRPmakZdOcZqidyph4WX4lpvmmFd/lewyuLEmj24KXFcJjgRYy4j6ZJGb9Bpaw==
X-Received: by 2002:a05:6214:d6b:: with SMTP id 11mr1449308qvs.30.1599605728789; Tue, 08 Sep 2020 15:55:28 -0700 (PDT)
Received: from [192.168.86.36] ([191.115.26.124]) by smtp.gmail.com with ESMTPSA id d12sm672882qka.34.2020.09.08.15.55.27 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2020 15:55:28 -0700 (PDT)
To: oauth@ietf.org
References: <TY1PR01MB1466E7D4AF21EA5C56467E6AE5290@TY1PR01MB1466.jpnprd01.prod.outlook.com> <CA+k3eCRffzry_+GVieOcWs0RHqwo_XGgMTwx4LOCZFPioD_xdw@mail.gmail.com>
From: John Bradley <ve7jtb@ve7jtb.com>
Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE=
Message-ID: <65ca9259-3095-9051-93b6-653e445acad4@ve7jtb.com>
Date: Tue, 08 Sep 2020 19:55:26 -0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CA+k3eCRffzry_+GVieOcWs0RHqwo_XGgMTwx4LOCZFPioD_xdw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------0F01A297301622074D139C96"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/dU1DzWVWrStqG89KoNwv2fD2BiU>
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:55:33 -0000

+1

On 9/8/2020 7:45 PM, Brian Campbell wrote:
> 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
> <mailto: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 <mailto: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./
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth