See my review comments in the thread “[OAUTH-WG] Comments on
draft-chadwick-oauth-jwk-uri-00”.
-- Mike
From: David Chadwick <[email protected]>
Sent: Friday, February 18, 2022 3:52 AM
To: Mike Jones <[email protected]>; Kristina Yasuda
<[email protected]>; [email protected]
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
Hi Mike
The additional mechanism was published as an I-D last week.
draft-chadwick-oauth-jwk-uri-00.txt
I thought this list had been notified, but my-bad, I see it was not. So I have
just sent out the notification now.
So can we get some feedback from this group as well as the OIDC one, before
progressing either?
Kind regards
David
On 17/02/2022 22:23, Mike Jones wrote:
Hi David,
Rifaat reminded me that yours is the only WGLC comment that has not been
resolved by publication of -01. As noted earlier, the substantive differences
between this draft and the JWK URI draft that you’re proposing are being
primarily discussed in the OpenID Connect working group, where the JWK
Thumbprint URI mechanism is used.
In that discussion, you made this issue comment
https://bitbucket.org/openid/connect/issues/1429/replace-jwk-thumbprint-uri-with-jwk-uri#comment-61838115:
“I agree that adding JWK URI should not exclude JWK Thumbprint URIs. Similarly
JWK Thumbprint URIs should not exclude JWK URIs.”
That seems to me to indicate that you’re OK with this specification being
published, while also wanting both working groups to consider your additional
mechanism when a draft is submitted? Am I hearing you correctly on that?
At least in my mind, the fact that you might publish another not-equivalent
mechanism shouldn’t hold up publication of this mechanism.
Thanks again,
-- Mike
From: David Chadwick
<[email protected]><mailto:[email protected]>
Sent: Monday, February 7, 2022 12:54 PM
To: Kristina Yasuda
<[email protected]><mailto:[email protected]>; Mike
Jones <[email protected]><mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
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 <[email protected]><mailto:[email protected]> On Behalf
Of David Chadwick
Sent: Sunday, February 6, 2022 2:40 AM
To: Mike Jones
<[email protected]><mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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 protected]><mailto:[email protected]> On Behalf
Of David Chadwick
Sent: Friday, February 4, 2022 9:55 AM
To: [email protected]<mailto:[email protected]>
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<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>
Please, provide your feedback on the mailing list by Feb 16th.
Regards,
Rifaat & Hannes
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
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>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
