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 > <[email protected]> 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 <[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] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
