Subject: Re: [OAUTH-WG] JWK Thumbprint URI Specification

From: David Chadwick <[email-masked]>
Date: Thu, 2 Dec 2021 12:42:12 +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 https://datatracker.ietf.org/doc/html/rfc7638#section-3.4.
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

David

Thanks,

-- Mike

From: David Waite <david=[email-masked]>

Sent: Wednesday, November 24, 2021 2:42 PM

To: Mike Jones <[email-masked]>

Cc: David Chadwick <[email-masked]>;
[email-masked]

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

-DW

Sent from my iPhone

On Nov
24, 2021, at 4:18 PM, Mike Jones <Michael.Jones=[email-masked]>
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-masked]>
On Behalf Of David Chadwick

Sent: Wednesday, November 24, 2021 12:36 PM

To: [email-masked]

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-masked]

https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/oauth