Thanks again, Rifaat. With help from Brian, Filip, and you,
https://www.ietf.org/archive/id/draft-ietf-oauth-rfc7523bis-06.html has been
published to address your review comments.
Thanks again,
-- Mike
From: Rifaat Shekh-Yusef <[email protected]>
Sent: Monday, March 2, 2026 9:21 AM
To: Michael Jones <[email protected]>
Cc: oauth <[email protected]>
Subject: Re: [OAUTH-WG] Shepherd Review - Updates to JWT Client Authentication
and Assertion-Based Authorization Grants
Thanks Mike!
After re-reading the "strong typing" issue with the highlighted sentence, I
think I now understand what you are saying, and I am fine with keeping the text
as is.
Please, publish a new version with the latest changes, and I will try to
complete the shepherd write up later this week.
Regards,
Rifaat
On Mon, Mar 2, 2026 at 11:58 AM Michael Jones
<[email protected]<mailto:[email protected]>> wrote:
Thanks, Rifaat. See my comments below prefixed by “Mike2>”.
From: Rifaat Shekh-Yusef
<[email protected]<mailto:[email protected]>>
Sent: Monday, March 2, 2026 6:47 AM
To: Michael Jones
<[email protected]<mailto:[email protected]>>
Cc: oauth <[email protected]<mailto:[email protected]>>
Subject: Re: [OAUTH-WG] Shepherd Review - Updates to JWT Client Authentication
and Assertion-Based Authorization Grants
See my comments below.
On Sun, Mar 1, 2026 at 10:40 PM Michael Jones
<[email protected]<mailto:[email protected]>> wrote:
Thanks for your review, Rifaat. Replies inline prefixed by “Mike>”.
From: Rifaat Shekh-Yusef
<[email protected]<mailto:[email protected]>>
Sent: Monday, February 23, 2026 11:32 AM
To: oauth <[email protected]<mailto:[email protected]>>
Subject: [OAUTH-WG] Shepherd Review - Updates to JWT Client Authentication and
Assertion-Based Authorization Grants
Hi,
As the shepherd for this document, I have reviewed version 05 of the draft
https://www.ietf.org/archive/id/draft-ietf-oauth-rfc7523bis-05.html
and I have the following comments/questions:
Section 3
It is RECOMMENDED that SAML Bearer Assertions not be used for client
authentication.
Should the RECOMMENDED be a MUST? If not, can you add some text to explain when
SAML Bearer Assertions could still be used?
Mike> How about we change it to say:
It is RECOMMENDED that SAML Bearer Assertions not be used for client
authentication for any new applications. (The authors are not actually aware
of any applications using this feature of RFC 7522.) Should any applications
already be doing this in the manner described in RFC 7522, it is left to the
discretion of their implementers and deployers whether to migrate away from
this feature and/or potentially tighten the audience values used in a manner
parallel to the changes being made in RFC 7523.
If you want new applications to not use SAML Bearer Assertions, then I think
RECOMMENDED should be a MUST; otherwise, you need to explain when SAML Bearer
Assertions can still be used.
Mike2> OK – https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/25
updated to use MUST NOT. Please review.
Section 5, Second paragraph,
“The paragraph describing the audience value in Section 2”
You might want to explicitly state which paragraph this is referring to.
Mike> How about we change it to say:
The last paragraph of Section 2 of [RFC9126] , which describes the audience
value, is replaced by:
Yep
Section 5, Last paragraph,
“Client authentication JWTs SHOULD be explicitly…”
Can you elaborate on what this is a “SHOULD” to make it clear to the
implementer?
Mike> The previous paragraph, beginning “The introduction of strong typing for
JWTs” already gives ample reasons why this should be done but is not required.
I don’t believe any additional text is needed in this case.
If I understood the previous paragraph, it implies that you can still not use
strong typing for backwards compatibility reasons.
If this is the reason for the RECOMMENDED and SHOULD in this section, then it
would be great if you can be explicit about it.
Mike2> That same paragraph already contains the rationale for why this is
RECOMMENDED:
“Since strong typing alone does not prevent the attacks described in
[private_key_jwt.Disclosure<https://drafts.oauth.net/draft-ietf-oauth-rfc7523bis/draft-ietf-oauth-rfc7523bis.html#private_key_jwt.Disclosure>]
and
[Audience.Injection<https://drafts.oauth.net/draft-ietf-oauth-rfc7523bis/draft-ietf-oauth-rfc7523bis.html#Audience.Injection>],
the use of explicit typing is RECOMMENDED for clients, enabling them to signal
their intention of sending a JWT conforming to the requirements herein. This
approach balances security signaling with practical deployment considerations,
avoiding disruption to client deployments that already conform to the tightened
audience requirements but have not yet adopted explicit typing.”
Mike2> Explicit typing can be relied on for new deployments, since new clients
will follow the recommendation. Let us know if there is a specific additional
wording change that you recommend.
Section 8.2
It seems to me that the following references should be moved to the Normative
References section:
IANA.MediaTypes, IANA.OAuthParameters, OpenID.Core, RFC2046, and RFC6838
I agree with you about OpenID.Core because implementers need to use normative
definitions contained in it. The other references are only used to inform the
IANA registrations – not implementers, and so need not be normative. It’s not
customary to make such references normative. (Of course, if the IESG
disagrees, we can always do this later.)
Yeah, this makes sense to me.
Regards,
Rifaat
Regards,
Rifaat
I will create a PR applying these proposed changes later this evening.
Thanks again,
-- Mike
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
