Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

From: Mike Jones <[email-masked]>
Date: Sat, 5 Feb 2022 17:46:40 +0000

David, I believe your objections below are actually about the JWK Thumbprint [RFC 7638<https://www.rfc-editor.org/rfc/rfc7638.html>] computation used by this specification, and not the operation defined by this specification.  JWK Thumbprint became an RFC in 2015.

This specification<https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html> defines how to create a JWK Thumbprint URI by concatenating the URI prefix “urn:ietf:params:oauth:jwk-thumbprint” to an RFC 7638 JWK Thumbprint.  That’s all it does.  That’s why Rifaat’s statement “The JWK Thumbprint URI document is a simple and straightforward specification” is indeed correct.

                                                       Best wishes,
                                                       -- Mike

From: OAuth <[email-masked]> On Behalf Of David Chadwick
Sent: Friday, February 4, 2022 9:55 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

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 list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth

---

From: Warren Parad <[email-masked]>
Date: Sat, 5 Feb 2022 19:15:50 +0100

Then perhaps what is in order is to replace 7638, before moving forward
with this one, that way we don't end up in state where implementations are
based on unnecessary complexity which isn't backwards compatible.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Sat, Feb 5, 2022 at 6:47 PM Mike Jones <Michael.Jones=
[email-masked]> wrote:

> David, I believe your objections below are actually about the JWK
> Thumbprint [RFC 7638 <https://www.rfc-editor.org/rfc/rfc7638.html>]
> computation used by this specification, and not the operation defined by
> this specification.  JWK Thumbprint became an RFC in 2015.
>
>
>
> This specification
> <https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html>
> defines how to create a JWK Thumbprint URI by concatenating the URI prefix “
> urn:ietf:params:oauth:jwk-thumbprint” to an RFC 7638 JWK Thumbprint.
> That’s all it does.  That’s why Rifaat’s statement “*The JWK Thumbprint
> URI document is a simple and straightforward specification*” is indeed
> correct.
>
>
>
>                                                        Best wishes,
>
>                                                        -- Mike
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of * David Chadwick
> *Sent:* Friday, February 4, 2022 9:55 AM
> *To:* [email-masked]
> *Subject:* Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>
>
>
> The *JWK Thumbprint URI *document is a simple and
> straightforward specification.
>
> 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:
>
>    2. the SIOP creates the JWK Thumbprint as described in [RFC7638] and
>    converts it to a URI as described in [JONES],
>    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
>
>
>
>
>
> Please, provide your feedback on the mailing list by *Feb 16th*.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
>
>
>
>
>
> [email-masked]
> [email-masked]

---

From: David Chadwick <[email-masked]>
Date: Sun, 6 Feb 2022 10:39:54 +0000

On 05/02/2022 17:46, Mike Jones wrote:

David, I believe your objections below are
actually about the JWK Thumbprint [RFC 7638] computation used by
this specification, and not the operation defined by this
specification.  JWK Thumbprint became an RFC in 2015.

Hi Mike

no, my objection is to the JWK Thumbprint URI document. I accept
that the JWK Thumbprint RFC already exists.

The aim of the SIOPv2 group is to transfer a public key as a URI,
so it leverages the JWK Thumbprint RFC to do this. As I point out
in my I-D, SIOPv2 transfers the public key and the public key
thumbprint. My I-D suggests that we simply transfer the public key
as a URI then no thumbprint computation is necessary by the
SIOPv2. The recipient can compute its own thumbprint if it needs
to by utilising the JWK Thumprint RFC and in this case no hashing
algorithm needs to be jointly agreed upon.

Kind regards

David

This specification defines how to
create a JWK Thumbprint URI by concatenating the URI prefix “urn:ietf:params:oauth:jwk-thumbprint”
to an RFC 7638 JWK Thumbprint.  That’s all it does.  That’s
why Rifaat’s statement “The JWK Thumbprint URI document is
a simple and straightforward specification” is indeed
correct.

Best wishes,

-- Mike

From: OAuth
<[email-masked]> On Behalf Of
David Chadwick

To: [email-masked]

Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI
document

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:

the SIOP creates an asymmetric key
pair and encodes the public key as a JWK

the SIOP creates the JWK Thumbprint
as described in [RFC7638] and converts it to a URI as
described in [JONES],

the SIOP passes both the JWK and JWK
Thumbprint URI to the RP in the JWT,

the RP extracts the JWK and JWK
Thumbprint from the JWT

the RP re-computes the JWK Thumbprint
from the JWK

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:

Please, provide your feedback on the
mailing list by Feb 16th.

Regards,

Rifaat & Hannes

OAuth mailing list

[email-masked]

---

From: Kristina Yasuda <[email-masked]>
Date: Mon, 7 Feb 2022 20:42:27 +0000

Hi David,

I think your comments below apply to the choices made in another specification (SIOP v2 in OIDF), rather than this IETF draft we are discussing.
I've seen you opened an issue in the OpenID Connect WG Bitbucket. Let's discuss there whether SIOP v2 should use JWK Thumbprint URI.

Best,
Kristina

From: OAuth <[email-masked]> On Behalf Of David Chadwick
Sent: Sunday, February 6, 2022 2:40 AM
To: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 05/02/2022 17:46, Mike Jones wrote:
David, I believe your objections below are actually about the JWK Thumbprint [RFC 7638<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7638.html&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YsMfndDhygG7AkSPK9NeYrKhDwFkd5P%2FSAgZsrXH%2F6Q%3D&reserved=0>] computation used by this specification, and not the operation defined by this specification.  JWK Thumbprint became an RFC in 2015.

Hi Mike

no, my objection is to the JWK Thumbprint URI document. I accept that the JWK Thumbprint RFC already exists.

The aim of the SIOPv2 group is to transfer a public key as a URI, so it leverages the JWK Thumbprint RFC to do this. As I point out in my I-D, SIOPv2 transfers the public key and the public key thumbprint. My I-D suggests that we simply transfer the public key as a URI then no thumbprint computation is necessary by the SIOPv2. The recipient can compute its own thumbprint if it needs to by utilising the JWK Thumprint RFC and in this case no hashing algorithm needs to be jointly agreed upon.

Kind regards

David

This specification<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8Vt%2BwrhXuAC3CjvGzaQtmYv4%2BIV3ElozbVGED4FLUvQ%3D&reserved=0> defines how to create a JWK Thumbprint URI by concatenating the URI prefix "urn:ietf:params:oauth:jwk-thumbprint" to an RFC 7638 JWK Thumbprint.  That's all it does.  That's why Rifaat's statement "The JWK Thumbprint URI document is a simple and straightforward specification" is indeed correct.

                                                       Best wishes,
                                                       -- Mike

From: OAuth <[email-masked]><mailto:[email-masked]> On Behalf Of David Chadwick
Sent: Friday, February 4, 2022 9:55 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8Vt%2BwrhXuAC3CjvGzaQtmYv4%2BIV3ElozbVGED4FLUvQ%3D&reserved=0>

Regards,
 Rifaat & Hannes

OAuth mailing list

https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=L5UFnqyzv16VgMrickO8sVxQ77Om8PDtgM%2BMFjQbfhU%3D&reserved=0>

---

From: David Chadwick <[email-masked]>
Date: Mon, 7 Feb 2022 20:53:35 +0000

On 07/02/2022 20:42, Kristina Yasuda
wrote:

Hi David,

I think your comments below apply to the
choices made in another specification (SIOP v2 in OIDF),
rather than this IETF draft we are discussing.

Hi Kristina

Yes and no.

No, in that the registration of either of the I-Ds as an RFC is a
matter for this list, and should answer this question, "what is
the best way (or ways) of creating a URI from a public key."

Yes, in that the SIOPv2 specification requires at least one way
of specifying a public key as a URI and therefore needs some other
standard or standards to refer to.

I’ve seen you opened an issue in the OpenID
Connect WG Bitbucket. Let’s discuss there whether SIOP v2
should use JWK Thumbprint URI.

Yes we can certainly discuss the latter issue in OIDF

Kind regards

David

Best,

Kristina

From: OAuth

To: Mike Jones <[email-masked]>;
[email-masked]

David, I believe your objections below
are actually about the JWK Thumbprint [RFC 7638] computation used by
this specification, and not the operation defined by this
specification.  JWK Thumbprint became an RFC in 2015.

Hi Mike

no, my objection is to the JWK Thumbprint URI document. I
accept that the JWK Thumbprint RFC already exists.

The aim of the SIOPv2 group is to transfer a public key as a
URI, so it leverages the JWK Thumbprint RFC to do this. As I
point out in my I-D, SIOPv2 transfers the public key and the
public key thumbprint. My I-D suggests that we simply transfer
the public key as a URI then no thumbprint computation is
necessary by the SIOPv2. The recipient can compute its own
thumbprint if it needs to by utilising the JWK Thumprint RFC
and in this case no hashing algorithm needs to be jointly
agreed upon.

Kind regards

David

This specification defines how
to create a JWK Thumbprint URI by concatenating the URI
prefix “urn:ietf:params:oauth:jwk-thumbprint”
to an RFC 7638 JWK Thumbprint.  That’s all it does.  That’s
why Rifaat’s statement “The JWK Thumbprint URI document
is a simple and straightforward specification” is
indeed correct.

Best wishes,

-- Mike

From: OAuth <[email-masked]>
On Behalf Of David Chadwick

To: [email-masked]

Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint
URI document

All,

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:

the SIOP creates an asymmetric
key pair and encodes the public key as a JWK

the SIOP creates the JWK
Thumbprint as described in [RFC7638] and converts it to
a URI as described in [JONES],

the SIOP passes both the JWK
and JWK Thumbprint URI to the RP in the JWT,

the RP re-computes the JWK
Thumbprint from the JWK

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.

Kind regards

David

Please, provide your feedback on
the mailing list by Feb 16th.

Regards,

Rifaat & Hannes

OAuth mailing list

[email-masked]