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

[David Chadwick <[e-mail]>]

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" class="moz-txt-link-freetext" rel="nofollow">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