Daniel, Typo corrected; files are at the same URLs as below (please refresh).
Thank you for letting us know there's an item still under discussion. Is there a time estimate for its resolution? If it's more than a few weeks, it's likely the RFC number would be reassigned. We will wait to hear from you again and from your coauthors before continuing the publication process. RFC Editor/ar > On Dec 9, 2024, at 5:57 AM, Daniel Fett <mail=40danielfett...@dmarc.ietf.org> > wrote: > > Hi Alice, > > I've been notified that there is one more typo in the document, in Section > 4.4.1: "a attacker-in-the-middle attack" (a → an). > > Besides that, there is a security issue that has not yet been disclosed to > the public which we may need to address in this document by a last-minute > normative change. This is still under discussion and obviously need > appropriate consensus in the OAuth working group, so please expect that this > document will be stuck in its current status for a while. > > -Daniel > > Am 22.11.24 um 22:56 schrieb Alice Russo: >> Daniel, >> >> Thank you for your reply. The revised files are here (please refresh): >> >> https://www.rfc-editor.org/authors/rfc9700.html >> >> >> https://www.rfc-editor.org/authors/rfc9700.txt >> >> >> https://www.rfc-editor.org/authors/rfc9700.pdf >> >> >> https://www.rfc-editor.org/authors/rfc9700.xml >> >> >> This diff file shows all changes from the approved I-D: >> >> https://www.rfc-editor.org/authors/rfc9700-diff.html >> >> >> https://www.rfc-editor.org/authors/rfc9700-rfcdiff.html >> (side by side) >> >> This diff file shows the changes made during AUTH48 thus far: >> >> https://www.rfc-editor.org/authors/rfc9700-auth48diff.html >> >> >> https://www.rfc-editor.org/authors/rfc9700-auth48rfcdiff.html >> (side by side) >> >> This diff file shows only the changes since the last posted version: >> >> https://www.rfc-editor.org/authors/rfc9700-lastrfcdiff.html >> >> >> We will wait to hear from you again and from your coauthors >> before continuing the publication process. This page shows >> the AUTH48 status of your document: >> >> https://www.rfc-editor.org/auth48/rfc9700 >> >> >> Thank you. >> RFC Editor/ar >> >> >>> On Nov 22, 2024, at 5:35 AM, Daniel Fett <m...@danielfett.de> >>> wrote: >>> >>> Hi Alice, >>> >>> thanks for the updates to the documents. Please find below a couple of >>> change requests: >>> >>> >>> >>> * Change request in Section 4.4: >>> >>> OLD: Mix-up attacks are in scenarios >>> >>> NEW: Mix-up attacks can occur in scenarios >>> >>> >> [AR] Updated. >> >>> * Change request: >>> >>> We currently have an inconsistent capitalization of the first letter of >>> "Attacker (Ax)" references, mostly from our original document. I suppose >>> "Attacker" should be uppercased in these references. >>> >> [AR] Updated. >> >>> >>> * Change request: >>> >>> The "mutual" in "Mutual TLS for OAuth 2.0" was lowercased in Section 2.2.1, >>> but remains upper case in 4.10.2. I propose to uppercase both, but can live >>> with lowercase as well. >>> >>> >> [AR] Updated to 'mutual TLS' with lowercase 'm' (4 instances in this >> document) to match how it appears in the body of RFC 8705. >> >> >>> * Change request: >>> >>> In Section 4.10.1 we introduce the abbreviation "mTLS", but we use it only >>> once, in Section 2.5; I suggest to remove the "(mTLS)" in Section 4.10.1 >>> and to replace the wording in 2.5 by the one we use in Section 2.2.1 and >>> 4.10.2 (previous change request). >>> >> [AR] Updated. >> >> >>> >>> >>> * Change request: >>> >>> Section 4.5 >>> >>> OLD: described in Section 4.4.1.1. of [RFC6819]. >>> >>> NEW: described in Section 4.4.1.1 of [RFC6819]. >>> >>> >> [AR] Updated. >> >>> >>> >>> Further responses inline: >>> >>> >>> >>> Am 22.11.24 um 01:32 schrieb Alice Russo: >>> >>>> Re: #4 >>>> >>>> >>>>>> In the original: >>>>>> >>>>>> redirect URI (58 instances) vs. redirection URI (1 instance) >>>>>> redirect URL (2 instances) vs. redirection URL (2 instances) >>>>>> >>>>>> >>>>> "redirection URI" is the wording used in RFC6749 so I propose to use that >>>>> everywhere. >>>>> >>>>> >>>> Updated as requested; please review, as this yields many changes. >>>> >>> Looks good to me. >>> >>>> >>>> Re: #8 >>>> >>>> >>>>> NEW: >>>>> >>>>> It is RECOMMENDED to use asymmetric cryptography for client >>>>> authentication, such as mTLS [RFC8705] or signed JWTs ("Private Key >>>>> JWT") in accordance with [RFC7521] and [RFC7523]. The latter is defined >>>>> in [OpenID.Core] as the client authentication method >>>>> <tt>private_key_jwt</tt>. >>>>> >>>>> >>>> Updated as requested; may this phrase be changed as follows to avoid the >>>> plural vs. singular mismatch? >>>> >>>> Current: or signed JWTs ("Private Key JWT") >>>> Perhaps: or a signed JWT ("Private Key JWT") >>>> >>>> >>> I do see the mismatch, but since signed JWTs refers to a mechanism, I would >>> prefer to keep it as-is. Using the singular here might imply that only one >>> such signed JWT can be used, but that would not be a good practice. >>> >> [AR] No change made. >> >> >>>> Re: #14, no reference added for iframe, per your reply. >>>> >>>> Re: #17b, updated to 'healthcare'; however, we see 'eHealth' (1 instance) >>>> elsewhere in this document. Please let us know if you want to use that. >>>> >>>> >>> Excellent point. We also use the example of "open banking" elsewhere. I >>> propose: >>> >>> OLD: (e.g., for email, calendaring, healthcare, or banking) >>> >>> NEW: (e.g., for email, calendaring, eHealth, or open banking) >>> >>> >>> >> [AR] Updated. >> >>> Thanks, >>> Daniel >>> >>> >>> >>> >>>> We will wait to hear from you again and from your coauthors >>>> before continuing the publication process. This page shows >>>> the AUTH48 status of your document: >>>> >>>> >>>> https://www.rfc-editor.org/auth48/rfc9700 >>>> >>>> >>>> >>>> Thank you. >>>> RFC Editor/ar >>>> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
