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

Filip Skokan <> Wed, 09 September 2020 06:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3565F3A0FF5 for <>; Tue, 8 Sep 2020 23:53:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cgMwrtFfYD57 for <>; Tue, 8 Sep 2020 23:53:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C14B3A0FD3 for <>; Tue, 8 Sep 2020 23:53:41 -0700 (PDT)
Received: by with SMTP id s92so1111254ybi.2 for <>; Tue, 08 Sep 2020 23:53:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U7a5/uq6cr2yUI5ChzCum3GXjlxx/HgBP19UKQatXXs=; b=Pg2NIxMNl2lC5Xno5K3yRD+5R+8pRz1fJjZ1N1Fe/lgwq35+pMpAqfjN9/wrU6+WpB Gp5FbqHw4zucQE25ADHnyyX+D+2x0v+F4RdYfDpqr2E9UOR+YdiQGb1nrClMjPYkMSM3 jRb2lJN3V2+Clx9/Ojt2bsqC40sVZiYIWIVvuxRoUSZQoq2YFYQiXKjRF74SgbAYAjc3 Poas43ik1G0GDtmxibyp4M01Y17iX1T6Gt2u84rcD7ngMQyH3FT8mZU8dHIys3vhkAzO FpDBkLjxVHeefGuJU8mA9ODFgbLRZUbLZHi2Biwid+jOSUbKb4qHOzHmnUPQdfiA+EsE /NzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U7a5/uq6cr2yUI5ChzCum3GXjlxx/HgBP19UKQatXXs=; b=a6RWjgL5B8vRq0UVxACDsGWn2vweel7AABWFg60g49JyUToJ2xXmtKP6vuBy5vsKbM 5DnEA+AsaqolV1o3shRji5QYTZeIo7xa357WZ7ie2YtdP+V4n1q7g5O97JZcUoH+9buw u6f8t04+Egh5m+Q/mc8Lz3vyfQLDCYwTZ3hgKdQYSMsvYa2JxfpT9F/vJ+bR4jUlrpln e3tPeHMhx1lgOCv3g2Ewj4baw9/DgDJgoCo42A0GMjuLUL3C4gineyTCUwVYl40mqML5 MfZt78It3GcYPADNYLNTIxc55/7Z3orXCFpypykguyX9XREIKn65zFAfY882RQlhHVNK B8Ow==
X-Gm-Message-State: AOAM531N8Fw6dA8qN304iNyvlHM9LMwGVXD4gRd6QFsPHLHqF6fkhhAw VqgoerxM4J4f0wmbv/HQUVNOULHZuHeuBX4IJQ==
X-Google-Smtp-Source: ABdhPJxsjvQteN9GwIvSfDNbRYm8BwCtvScdSozvDYDEnMxIfHCgk/HIh0C+ulhh7XyvNvXDMqUiYDe1BC+wz7Dg2Sw=
X-Received: by 2002:a25:d0d6:: with SMTP id h205mr3372483ybg.259.1599634420175; Tue, 08 Sep 2020 23:53:40 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Filip Skokan <>
Date: Wed, 9 Sep 2020 08:53:03 +0200
Message-ID: <>
To: Brian Campbell <>
Cc:, oauth <>
Content-Type: multipart/alternative; boundary="00000000000062997105aedbe957"
Archived-At: <>
Subject: Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Sep 2020 06:53:43 -0000

+1 for keeping it simple. The design itself promotes unique-per-instance
keys, not pre-registration.

S pozdravem,
*Filip Skokan*

On Wed, 9 Sep 2020 at 00:46, Brian Campbell <bcampbell=> 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 <> 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]:
>> [*2]:
>> Best regards,
>> Toshio Ito
>> -------------
>> Toshio Ito
>> Research and Development Center
>> Toshiba Corporation
>> _______________________________________________
>> OAuth mailing list
> *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