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
