Daniel, Checking in on this document; any update on the normative change? Thank you. RFC Editor/ar
> On Dec 9, 2024, at 10:24 AM, Alice Russo <aru...@amsl.com> wrote: > > 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
