Looks good to me too, no planned changes from me. Andrey
On Thu, Jan 30, 2025 at 8:58 AM John Bradley <ve7...@ve7jtb.com> wrote: > 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> <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> > <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> > <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
