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> 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
