[Openid-specs-ab] Issue #1429: Replace JWK Thumbprint URI with JWK URI (openid/connect)

[David Chadwick]

New issue 1429: Replace JWK Thumbprint URI with JWK URI
https://bitbucket.org/openid/connect/issues/1429/replace-jwk-thumbprint-uri-with-jwk-uri

David 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.