Re: [OAUTH-WG] JWK Thumbprint URI Specification

David Chadwick <> Thu, 02 December 2021 12:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F2EB3A10A3; Thu, 2 Dec 2021 04:42:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.648
X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ErtsNgC0Lm81; Thu, 2 Dec 2021 04:42:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E02253A1079; Thu, 2 Dec 2021 04:42:19 -0800 (PST)
Received: from ([]) by with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1mslPl-000A4K-L0; Thu, 02 Dec 2021 12:42:17 +0000
Received: from [] (helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1mslPk-00096c-1g; Thu, 02 Dec 2021 12:42:17 +0000
Message-ID: <>
Date: Thu, 02 Dec 2021 12:42:12 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2
From: David Chadwick <>
To: Mike Jones <>, David Waite <>
Cc: "" <>
References: <>
Content-Language: en-GB
Organization: University of Kent
In-Reply-To: <>
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Kent-Spam-Score: -4.2
X-Kent-Spam-Bar: ----
X-Kent-Spam-Report: No, tests=ALL_TRUSTED=-1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, NICE_REPLY_A=-3.3
Archived-At: <>
Subject: Re: [OAUTH-WG] JWK Thumbprint URI Specification
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: Thu, 02 Dec 2021 12:42:25 -0000

On 29/11/2021 20:58, Mike Jones wrote:

Hi DW,


Having the OAuth WG to add a new registration to a registry that it controls is fairly easy.  Our success in motivating and accomplishing registering a new URI scheme may vary.


You can read about how the JWK Thumbprint RFC handles choice of hash functions in the Selection of Hash Function section" class="moz-txt-link-freetext" rel="nofollow">  I would propose that we do the same.  I can plan on adding text to that effect in the next published draft.

Having read section 3.4 this seems to be a rather clunky method of sharing public keys. First a hashing algorithm has to be agreed out of band, then a somewhat painful data canonicalisation has to be performed. Both of these steps can lead to grief.

I would therefore propose a much simpler and less error prone method for sharing the public key as a URI, namely, the key holder takes the JSON specification of the public key as specified in RFC 7517 then base64 encodes it. The recipient simply base 64 decodes the structure and ends up with the JWK. No canonicalisation is needed because the recipient gets the JSON object the sender encoded.

This can be made into a URI in a similar fashion to thumprint e.g.

  • urn:ietf:params:oauth:jwk:<base 64 encoding public key parameters>

Kind regards




                                                       -- Mike


From: David Waite <>
Sent: Wednesday, November 24, 2021 2:42 PM
To: Mike Jones <>
Cc: David Chadwick <>;
Subject: Re: [OAUTH-WG] JWK Thumbprint URI Specification


I would investigate whether there are advantages of having this be a URN vs a URI in a new base scheme (e.g. jkt:bTz_1…). I haven’t seen much URN namespacing of dynamic values (e.g. values not being maintained by the entity responsible for the namespace or sub-spaces), and a new scheme is a terser form. 


Also, do you foresee any reason to support other hashing algorithms, since thumbprints themselves do not dictate a hashing algorithm? An optional hashing seems simple enough to add, except I don’t know of a hash algorithm registry to reference




Sent from my iPhone

On Nov 24, 2021, at 4:18 PM, Mike Jones <> wrote:

The JWK Thumbprint is typically used as a key identifier. Yes, the key needs to be known by other means if you’re going to use it.  Some protocols work that way, which is what this spec is intended to enable.  For instance, the Self-Issued OpenID Provider (SIOP) v1 and v2 protocols send the public key separately in a “sub_jwk” claim.  In other use cases, it may already be known to the receiving party – for instance, from a prior discovery step.


It would be fine to separately also define a URI representation communicating an entire JWK, but that would be for different use cases, and not the goal of this (intentionally narrowly scoped) specification.



                                                       -- Mike


From: OAuth <> On Behalf Of David Chadwick
Sent: Wednesday, November 24, 2021 12:36 PM
Subject: Re: [OAUTH-WG] JWK Thumbprint URI Specification


On 24/11/2021 20:07, Mike Jones wrote:

The JSON Web Key (JWK) Thumbprint specification [" rel="nofollow">RFC 7638] defines a method for computing a hash value over a JSON Web Key (JWK) [" rel="nofollow">RFC 7517] and encoding that hash in a URL-safe manner." rel="nofollow">Kristina Yasuda and I have just created the" rel="nofollow">JWK Thumbprint URI specification, which defines how to represent JWK Thumbprints as URIs. This enables JWK Thumbprints to be communicated in contexts requiring URIs, including in specific JSON Web Token (JWT) [" rel="nofollow">RFC 7519] claims.


My immediate observation is why are you sending the thumbprint of the JSON Web Key and not sending the actual key value in the URI?

Sending the thumbprint means the recipient still has to have some other way of obtaining the actual public key, whereas sending the public key as a URI means that no other way is needed.

Kind regards



Use cases for this specification were developed in the" rel="nofollow">OpenID Connect Working Group of the OpenID Foundation. Specifically, its use is planned in future versions of the" rel="nofollow">Self-Issued OpenID Provider v2 specification.


The specification is available at:

1." rel="nofollow">


                                                       -- Mike


P.S.  This note was also published at" class="moz-txt-link-freetext" rel="nofollow"> and as" rel="nofollow"> @selfissued.



OAuth mailing list" class="moz-txt-link-freetext" rel="nofollow">


OAuth mailing list" class="moz-txt-link-freetext" rel="nofollow">