Re: [OAUTH-WG] JWK Thumbprint URI Specification

David Waite <david@alkaline-solutions.com> Wed, 24 November 2021 22:41 UTC

Return-Path: <david@alkaline-solutions.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 24B0D3A0CB4 for <oauth@ietfa.amsl.com>; Wed, 24 Nov 2021 14:41:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.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 x01MCkdUkqOQ for <oauth@ietfa.amsl.com>; Wed, 24 Nov 2021 14:41:36 -0800 (PST)
Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CFDF3A0CB3 for <oauth@ietf.org>; Wed, 24 Nov 2021 14:41:36 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by caesium6.alkaline.solutions (Postfix) with ESMTPA id 02936206E1F; Wed, 24 Nov 2021 22:41:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1637793693; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3oxImn6rw8/4BunCjDrz3qRFB3ij7a6pPimL9hUee1Y=; b=dGhqx1BgogqObBNEYOtZQCdghmo2xMiMl/X2h2qWB5tzu7FJWQwtsugNQlIwPzCr6n1OkJ I0w07QZBgb1xRklGFNRiIDbnfAaljFmfM/zddSVr4w9Uktk/VysVLZucrFjFk49c3lB8XV YMs3ng/n+3B5dW2DKZoiRJb7uOu69yc=
Content-Type: multipart/alternative; boundary="Apple-Mail-C0C6E59A-79CB-469D-A6D7-77124C1C5B0C"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
From: David Waite <david@alkaline-solutions.com>
In-Reply-To: <CO1PR00MB09964F02A8CD8231F94401C1F5619@CO1PR00MB0996.namprd00.prod.outlook.com>
Cc: David Chadwick <D.W.Chadwick@kent.ac.uk>, oauth@ietf.org
Date: Wed, 24 Nov 2021 17:41:30 -0500
Message-Id: <0105E968-1397-43BD-9620-B2A1F1CD12F2@alkaline-solutions.com>
References: <CO1PR00MB09964F02A8CD8231F94401C1F5619@CO1PR00MB0996.namprd00.prod.outlook.com>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.mailfrom=david@alkaline-solutions.com
X-Spamd-Bar: +
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/I8CQL8Yc3z18s6WJG9eZAwOAkXo>
Subject: Re: [OAUTH-WG] JWK Thumbprint URI Specification
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: Wed, 24 Nov 2021 22:41:42 -0000

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

-DW

Sent from my iPhone

> On Nov 24, 2021, at 4:18 PM, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> 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.
>  
>                                                        Cheers,
>                                                        -- Mike
>  
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of David Chadwick
> Sent: Wednesday, November 24, 2021 12:36 PM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] JWK Thumbprint URI Specification
>  
> On 24/11/2021 20:07, Mike Jones wrote:
> The JSON Web Key (JWK) Thumbprint specification [RFC 7638] defines a method for computing a hash value over a JSON Web Key (JWK) [RFC 7517] and encoding that hash in a URL-safe manner. Kristina Yasuda and I have just created the 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) [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
> 
> David
> 
>  
> 
> Use cases for this specification were developed in the OpenID Connect Working Group of the OpenID Foundation. Specifically, its use is planned in future versions of the Self-Issued OpenID Provider v2 specification.
>  
> The specification is available at:
> 
> 1.       https://www.ietf.org/archive/id/draft-jones-oauth-jwk-thumbprint-uri-00.html
>  
>                                                        -- Mike
>  
> P.S.  This note was also published at https://self-issued.info/?p=2211 and as @selfissued.
>  
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>  
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth