Subject: [OAUTH-WG] Comments on draft-chadwick-oauth-jwk-uri-00

From: Mike Jones <[email-masked]>
Date: Fri, 18 Feb 2022 18:33:08 +0000

Thanks for pointing the working group to this individual submission, David.  Here's some initial comments on the document, as you requested.

First, you specify base64 encoding of the JWK, rather than base64url encoding of it.  This would result in non-URL-safe characters in the URI, such as /, +, and =.  If you're going to encode things, I suggest using the URL-safe base64url encoding.

But secondly, I would not re-encode the JWK fields at all.  I know that David Waite had an idea for a representation of JWK URIs where the JSON fields are represented as colon-separated pairs in the URI.  So for instance, the example JWK at https://datatracker.ietf.org/doc/html/rfc7517#section-3 would be instead represented as:

urn:ietf:params:oauth:jwk:kty:EC:crv:P-256:x:f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU:y:x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0:kid:Public%20key%20used%20in%20JWS%20spec%20Appendix%20A.3%20example

This would avoid double base64url-encoding fields, which would prevent unnecessary size expansion.

I suggest you work with David if you want to further pursue the idea of a JWK URI specification.

                                                       Best wishes,
                                                       -- Mike

---

From: David Chadwick <[email-masked]>
Date: Sun, 20 Feb 2022 16:33:17 +0000

Hi Mike

thanks for your suggestions. I am quite
happy to replace base64 with base64url encoding.

I have talked to David Waite about an
alternative coding method. As always it is a tradeoff between
processing vs. storage/transfer size. The more processing we do,
the lower the resulting size. My design original design is for the
minimum of processing by the SIOP (which is usually a smartphone)
with an increase in size of 33%. This is comparable in many cases
to the increase in size of your method as you have to send the JWK
Thumbprint URL as well as the JWK.

If the WG think it is preferable to
process the JWK JSON structure into a colon separated string as
per David Waite's suggestion, to save the 33% size increase, then
this is fine by me. I am happy to change the I-D to this method if
there is concensus to do so. Let's see what other people think.

Kind regards

David

On 18/02/2022 18:33, Mike Jones wrote:

Thanks for pointing the working group to
this individual submission, David.  Here’s some initial
comments on the document, as you requested.

First, you specify base64 encoding of the
JWK, rather than base64url encoding of it.  This would result
in non-URL-safe characters in the URI, such as /, +, and =.
If you’re going to encode things, I suggest using the URL-safe
base64url encoding.

But secondly, I would not re-encode the JWK
fields at all.  I know that David Waite had an idea for a
representation of JWK URIs where the JSON fields are
represented as colon-separated pairs in the URI.  So for
instance, the example JWK at https://datatracker.ietf.org/doc/html/rfc7517#section-3
would be instead represented as:

This would avoid double base64url-encoding
fields, which would prevent unnecessary size expansion.

I suggest you work with David if you want
to further pursue the idea of a JWK URI specification.

Best wishes,

-- Mike