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

Takahiko Kawasaki <> Tue, 08 September 2020 14:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38B6D3A1400 for <>; Tue, 8 Sep 2020 07:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 77K2tGlbPtTl for <>; Tue, 8 Sep 2020 07:23:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 235903A1420 for <>; Tue, 8 Sep 2020 07:23:31 -0700 (PDT)
Received: by with SMTP id a17so19308442wrn.6 for <>; Tue, 08 Sep 2020 07:23:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BhDZf+TWrMxVUbzET4ByEkVjLsykgd1q59Njb4z7510=; b=qpxhasxaYKnXE6cApeDwkOlsq61W9qDivPeteNwn5cYWNaO5+KV5OXiuv0bqTKxxdo PmthLcJcf269FdgmUELf+ElSSkwSJtZQXnvs1XcFbR/6ZMG6zmp3VYpVFytWud4FdauT UZazh5LbVIhgt78OPtAh8jys+y0LbVeOy79XlSadzOiJ8o0aGQnlkeG/NkdgXFzZXKt6 jYhsFXcXvxG8ViWJlcyPMyzvA7vdRLmcQXKp+vMrKqeXW8J/4uEnBiqCGidLGj2ssg0k vhKAsnrCY+dsuj2di3hWfSFNRyGoC81hfV9MHJU+5Zo7OiKKSJi/o6OhpHx7ZjFkOmUj hFYg==
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=BhDZf+TWrMxVUbzET4ByEkVjLsykgd1q59Njb4z7510=; b=HHlS9u8y+z9QXu4+YeKL801ma0ttBY9yVY3SFHEI0qft1WS6l1VLxSuRoR8VR/qLOq vSIkKdr2uk81ctI90RDwUczJtIowrzz5j/9RF5bS+VsXfnoMFU4AoNHrkBG+H9HwexwC LFufduLYcjQabGsh9JG191G39Wk9KROXdwoGfDYWMy7/NgBJGcjMOOT5Wtkua9nhc84z bxUfEdRdEqUsz0WgKr9jEAatCPXrPsv/kNp8m0ZTm1yApWBf+oKjsRM23Hxx6eOlJY+n 27t8BlvPT4ewYdpajcyGbN9pa1X5vPZrg6VvUJShzcuw2Nd0zFGq9Uvy+cZrA4A6HU0T idJA==
X-Gm-Message-State: AOAM532VWeHhwjYglIW140cqr+Gxl6aKFoekTqYLrWeIpEx3CfZJP46X qnjZpMnegzG3B8bfPz+g56y7uKLIpZWCwHY5Yd/0IQ==
X-Google-Smtp-Source: ABdhPJz/A9UL/fGERUrs3QOMQV81x84U4K6l/ljmN97+DEg6smy2rXDwmCQ3oXlMvVP12IZtAK12vUjXWZUbMTIJiQc=
X-Received: by 2002:adf:f50a:: with SMTP id q10mr26775261wro.319.1599575009956; Tue, 08 Sep 2020 07:23:29 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Takahiko Kawasaki <>
Date: Tue, 8 Sep 2020 23:23:18 +0900
Message-ID: <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="00000000000042a8d505aece14a3"
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: Tue, 08 Sep 2020 14:23:34 -0000

To enable each "instance" of a client application to use a key pair which
is dedicated to the instance, the public key needs to be included in the
DPoP proof. On the other hand, in the scenario you described, all instances
of the client application have to share one key pair. If client application
instances don't have to share one key pair, it's better.

Illustrated DPoP (OAuth Access Token Security Enhancement)

Best Regards,
Takahiko Kawasaki

On Tue, Sep 8, 2020 at 6:29 PM <> 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