Replace JWK Thumbprint URI with JWK URI

[David W Chadwick]

To produce or validate a JWK Thumbprint, both the sender and the receiver have to have the JWK available to them. Then they have to canonicalise the JWK as described in [RFC7638], and finally hash the octets of the UTF-8 representation of this JSON object with a pre-agreed algorithm in order to both obtain the same hash value. The way that the JWK Thumbprint URI is used in SIOPv2 [SIOPv2] is as follows:

1. the SIOP creates an asymmetric key pair and encodes the public key as a JWK
2. the SIOP creates the JWK Thumbprint as described in [RFC7638] and converts it to a URI as described in [JONES],
3. the SIOP passes both the JWK and JWK Thumbprint URI to the RP in the JWT,
4. the RP extracts the JWK and JWK Thumbprint from the JWT
5. the RP re-computes the JWK Thumbprint from the JWK
6. the RP compares the computed JWK Thumbprint with the received JWK Thumbprint to confirm that they are equal. 

One can see that the use of JWK Thumbprint URIs is both inefficient (in all cases) and a significant disadvantage (in some cases). If the JWK URI is transferred instead of the JWK and JWK Thumbprint URI then:

a) The SIOP will never need to create the JWK Thumbprint URI. The RP may only need to create the JWK Thumbprint if it needs this, for example, as a unique subject identifier. Even in this case, there is still an advantage to the RP in receiving the JWK URI instead of the JWK Thumprint URI, in that the RP no longer needs to pre-agree a hashing algorithm with the SIOP. Thus the RP can independently determine which hashing algorithm to use when creating its own JWK Thumbprint. (Note. If the SIOP were able to canonicalise the same public key in a JWK in different ways and produce different thumbprints from the same public key, then the canonicalisation algorithm is broken, and the RP would never to able to deterministically produce the same thumbprints each time.)

b) In those cases where the SIOP uses ephemeral key pairs and a different public key each time it communicates with an RP, then neither party needs to produce the JWK Thumbprint as it will never be seen again. It is a significant disadvantage to have to use JWK Thumbprints in this case.

[Michael Jones]

The JWK Thumbprint URI has the advantage that it provides a stable identifier for the key. It is able to do so because the JWK Thumbprint computation uses only the REQUIRED JWK fields for the key, removes all whitespace, uses canonical character representations, and canonicalizes the order of those fields before performing the hash.

Without such similar restrictions and canonicalizations, a JWK URI would not provide a stable identifier for the key. Optional fields such as alg could be present or not. The fields could occur in any order. Whitespace could be present. Etc.

Yes, a JWK URI could effectively be used as a more verbose JWK representation usable in contexts requiring URIs, but it would not provide the stable identifier, which is a necessity for any sub value.

[David W Chadwick]

Could you please say why the recipient is not able to use exactly the same canonicalisation rules as are currently defined in the JWK Thumbprint spec, and throw away all non-REQUIRED JWK fields, re-order the required ones etc. It has to do this anyway when re-computing the JWK Thumbprint that it has received from the JWK that it has, in order to check that it matches

[Michael Jones]

Yes, the recipient could use the same canonicalization rules specified in RFC 7638 to compute a JWK Thumbprint of a key received. However, the “sub” claim is meant to contain the stable identifier for the End-User’s account so that it be stored by the RP and tested for equality upon subsequent authentications. A JWK URI wouldn’t meet that criteria as discussed above, whereas a JWK Thumbprint URI does. It’s not that the RP couldn’t compute the JWK Thumbprint - it’s that in your proposal, the stable thumbprint isn’t the “sub” value.

[David W Chadwick]

If the sub contains the same public key URI each time then it is a stable identifier. It may not be canonicalised, but it is stable. If the SIOP wants it to be used as a stable and storable identifier, then it can store the base64 JWK URI and send the same one each time, then it does not matter whether it was canonicalised or not, because the bits will always be the same. So it can be used “as is” by the RP. However, if the key is transient, then it is not a stable identifier and is not meant to be used as such. So the RP will never get the same sub again and thus it wont be used for re-authentication. In a previous issue #1381 we discussed how a user with multiple devices could still re-authenticate by not using the sub claim.

[Michael Jones]

One of the reasons that OpenID Connect Core used the JWK Thumbprint as the sub value was that the thumbprint will be of a predictable, modest size. Whereas some RSA keys are really big – too big to want to use as primary database keys (which is how most systems use the sub value). And I’m told that that keys for some of the post-quantum algorithms are truly enormous. Like the original JWK Thumbprint, using a JWK Thumbprint URI as the subject identifier gives us a one with a modest, predictable size.

[David W Chadwick]

Mike, I hear what you say about DB primary key sizes, and I agree. That is why I am suggesting that the RP, if it needs a compact DB key, creates the thumbprint for itself from the JWK URI. It has to do that anyway with your spec, in order to compare the key with the thumbprint. So it is not inconvenienced by having a JWK URI sent to it instead of a JWK Thumbprint URI. (The SIOP is still inconvenienced in having to create it for a JWK Thumbprint URI.) For those RPs that don't need a DB key from the sub claim, then both the SIOP and RP are freed from the hassle of having to create the thumbprints by using the JWK URI. So the JWK URI is a win-win

‌

[David Waite]

With SIOP, the subject field is expected to:

1. be a URI
2. have that URI indicate how to resolve a key or set of keys used for signing

The JWK Thumbprint URN gives a way to match the SIOP v1 behavior, while methods for negotiating DIDs gives us a way to tie into that ecosystem.

I think support for other URI schemes is important to make sure we have right, including any JWK URI scheme. We need to make it possible for parties to negotiate a JWK URI scheme the same way they might negotiate a particular DID method.

However, I don’t think adding JWK URI would exclude the availability or viability of the schemes which are already possible.

‌

[David Waite]

Re: key sizes, there are key size limits which will affect what implementations accept already - for instance, even a 2k RSA key will push beyond the broad 2k limit established currently for redirection response modes.

For this reason, both the SIOP and RP can advertise and negotiate their capabilities through registration, such as requiring ES256.

[David W Chadwick]

@ David Waite. I agree that adding JWK URI should not exclude JWK Thumbprint URIs. Similarly JWK Thumbprint URIs should not exclude JWK URIs.

‌

[Michael Jones]

During the 14-Feb-22 working group call, there was support for closing this issue after a week's comment period, given how many problems JWK URIs would introduce.

[David W Chadwick]

It would be good to list all the problems that JWK URIs introduce for those SIOPs and RPs that do not need thumbprints. This issue has already listed all the problems that JWK Thumbprint URIs do introduce.

[Michael Jones]

It was agreed on the 24-Feb-22 working group call to close this in favor of PR #127.

[David W Chadwick]

Actually if you listen to the recording of the meeting you will see that I initially agree to close this issue as I was asked to create a PR for adding this URI as a third option. This PR had already been created 6 hours previously (PR #127). The meeting then discussed if a third option was needed or not, and an issue should be created for this. I then said in that case this issue should remain open. (i.e. if it is decided that only two options should be supported then this issue is still relevant as JWK URI should replace JWK Thumbprint URI)

[Kristina Yasuda]

During SIOP June 23 call we discussed that JWK URI accomplishes the same goal as did:jwk did-jwk/spec.md at main · quartzjer/did-jwk (github.com)