I also agree that there hasn't been sufficient review of this document to warrant progressing it.
Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Fri, Feb 4, 2022 at 6:56 PM David Chadwick < d.w.chadw...@verifiablecredentials.info> wrote: > On 02/02/2022 12:18, Rifaat Shekh-Yusef wrote: > > All, > > The *JWK Thumbprint URI *document is a simple and > straightforward specification. > > Actually this is a complex and inefficient specification compared to other > possibilities. > > I have written an Internet-Draft outlining an alternative scheme, the JWK > URI, which provides OIDC SIOPv2 with all the requirements that it needs > with much less effort than implementing JWK Thumbprint URIs. I am currently > formatting this I-D correctly to submit to the IETF. The rationale for this > new Internet Draft is as follows. > > 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. > > I therefore kindly request that the JWK Thumbprint URI document does not > progress until the WG has had chance to compare and contrast the two > methods. > > Kind regards > > David > > > > This is a WG Last Call for this document: > https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html > > Please, provide your feedback on the mailing list by *Feb 16th*. > > Regards, > Rifaat & Hannes > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
