I approve publication. John Bradley
> On Jan 27, 2025, at 3:02 PM, Daniel Fett <m...@danielfett.de> wrote: > > Hi Alice, > > Today, we were finally able to discuss the potential addition to this > document in the working group. There was a consensus in the call that we will > not add anything to the document. > > I therefore give my "go" for publication. > > Thank you, > Daniel > > Am 20.12.24 um 01:18 schrieb Alice Russo: >> 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> >>> <mailto: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> >>>> <mailto: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> >>>>>> <mailto: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
