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 <[email protected]> On Behalf Of David Chadwick
Sent: Wednesday, November 24, 2021 12:36 PM
To: [email protected]
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<https://www.rfc-editor.org/rfc/rfc7638.html>] defines a method for
computing a hash value over a JSON Web Key (JWK) [RFC
7517<https://www.rfc-editor.org/rfc/rfc7517.html>] and encoding that hash in a
URL-safe manner. Kristina Yasuda<https://twitter.com/kristinayasuda> and I have
just created the JWK Thumbprint
URI<https://www.ietf.org/archive/id/draft-jones-oauth-jwk-thumbprint-uri-00.html>
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<https://www.rfc-editor.org/rfc/rfc7519.html>] 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<https://openid.net/wg/connect/> of the OpenID Foundation. Specifically,
its use is planned in future versions of the Self-Issued OpenID Provider
v2<https://openid.net/specs/openid-connect-self-issued-v2-1_0.html>
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<https://twitter.com/selfissued/>.
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
