Hi,
please find my responses inline.
best regards,
Torsten.
Am 16. Nov. 2024, 22:13 +0100 schrieb rfc-edi...@rfc-editor.org:
> Authors,
>
> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the XML file.
>
> 1) <!--[rfced] FYI, the title of the document has been updated as
> follows. Abbreviations have been expanded per Section 3.6 of RFC 7322
> ("RFC Style Guide"). Please review.
>
> Original:
> JWT Response for OAuth Token Introspection
>
> Current:
> JSON Web Token (JWT) Response for OAuth Token Introspection
> -->
Ok.
>
>
> 2) <!--[rfced] FYI, regarding the use of <tt> within this document, it renders
> (using xml2rfc) in fixed-width font in the HTML and PDF files. However,
> the rendering of <tt> in the text file was changed in September 2021 -
> quotation marks are no longer added. When you review the diff file for
> this document, it will appear that the RPC removed quotation marks;
> however, actually this is due to the rendering change for <tt>.
>
> (For details, see the release notes for v3.10.0 on
> https://github.com/ietf-tools/xml2rfc/blob/main/CHANGELOG.md)
>
> Examples of where <tt> is used in the original (and remains):
> alg value, enc value
> Accept HTTP header field
> aud claim, token_introspection claim
> typ JWT header
> -->
>
I think this is acceptable.
>
> 3) <!--[rfced] May we update this sentence as follows, to clarify the
> phrase "additional JSON Web Token (JWT) secured response"?
>
> Original:
> This specification proposes an additional JSON Web Token (JWT)
> secured response for OAuth 2.0 Token Introspection.
>
> Perhaps:
> This specification proposes an additional response secured by
> JSON Web Token (JWT) for OAuth 2.0 Token Introspection.
> -->
wfm
>
>
> 4) <!--[rfced] Please clarify the latter part of this sentence.
> What is "identifying it as subject" referring to?
>
> Original:
> Authentication can utilize client authentication methods
> or a separate access token issued to the resource server and
> identifying it as subject.
>
> Perhaps (referring to the resource server):
> Authentication can utilize client authentication methods
> or a separate access token issued to the RS to
> identify the RS as the subject.
>
> Or (also referring to the resource server):
> Authentication can utilize client authentication methods
> or a separate access token that is issued to the RS and
> identifies the RS as the subject.
> -->
Please use this text.
>
>
> 5) <!--[rfced] We are having some difficulty parsing this sentence,
> specifically "a dedicated containing JWT claim". How should
> it be updated?
>
> Original:
> The separation of the introspection response
> members into a dedicated containing JWT claim is intended to
> prevent conflict and confusion with top-level JWT claims that
> may bear the same name.
>
> Perhaps:
> The separation of the introspection response
> members into a dedicated, contained JWT claim is intended to
> prevent conflict and confusion with top-level JWT claims that
> may bear the same name.
> -->
It seems we missed one important word „JSON object“.
The separation of the introspection response
members into a dedicated JSON object, containing JWT claim is intended to
prevent conflict and confusion with top-level JWT claims that
may bear the same name.
>
>
> 6) <!--[rfced] Please review whether any of the notes in this document
> should be in the <aside> element. It is defined as "a container for
> content that is semantically less important or tangential to the
> content that surrounds it"
> (https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-aside-2).
> -->
Our notes are not less important than the rest of the text. It is more like
„please consider“.
>
>
> 7) <!--[rfced] draft-ietf-oauth-security-topics (RFC-to-be 9700) does not
> have a Section 3.2. How this should be updated? Please
> see https://www.rfc-editor.org/authors/rfc9700.html
>
> Original:
> Resource servers MUST additionally apply the countermeasures against
> replay as described in [I-D.ietf-oauth-security-topics], section 3.2.
> -->
3.2. has become 2.2. I would nevertheless change the text to referring to the
draft-ietf-oauth-security-topics (RFC-to-be 9700) more general and frame the
topic more precisely.
Here is my proposal:
Resource servers MUST additionally apply the countermeasures against
access token replay as described in [I-D.ietf-oauth-security-topics].
>
>
> 8) <!--[rfced] RFC 7525 has been obsoleted by RFC 9325. Also,
> RFC 7525 is no longer part of BCP 195. How should this sentence
> be updated?
>
> Original:
> The authorization server MUST use Transport Layer Security (TLS) 1.2
> (or higher) per BCP 195 [RFC7525] in order to prevent token data
> leakage.
>
> Perhaps (A), if simple replacement is accurate:
> The authorization server MUST use Transport Layer Security (TLS) 1.2
> (or higher) per BCP 195 [RFC9325] in order to prevent token data
> leakage.
Please use this text.
>
> Or (B), if referencing the whole BCP (RFC 8996 + RFC 9325) is accurate:
> The authorization server MUST use Transport Layer Security (TLS) 1.2
> (or higher) per [BCP195] in order to prevent token data leakage.
> -->
>
>
> 9) <!--[rfced] FYI, in Sections 10.1.1, 10.2.1, and 10.4.1,
> the change controller has been updated from "IESG" to "IETF" to match
> the actual IANA registries. This was noted as follows in the mail
> from IANA: "Note: in accordance with recent practice, the change controller
> for these registrations has been changed from the IESG to the IETF."
>
> This is in keeping with IANA's "Guidance for RFC Authors" (on
> https://www.iana.org/help/protocol-registration):
> "The IESG shouldn't be listed as a change controller unless the RFC that
> created the registry (e.g. port numbers, XML namespaces and schemas)
> requires it. The IETF should be named instead."
>
> We have also updated the change controller in Section 10.3.1 accordingly.
I guess you mean 11.3.1?
> If that is not accurate, please let us know.
> -->
wfm
>
>
> 10) <!-- [rfced] For sourcecode elements, please consider whether the
> "type" attribute should be set and/or has been set correctly.
>
> The current list of preferred values for "type" is available at
> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
> If the current list does not contain an applicable type, feel free to
> suggest additions for consideration. Note that it is also acceptable
> to leave the "type" attribute not set.
> -->
1 and 2 -> http-message
3 and 4 -> json
>
>
> 11) <!-- [rfced] Please review the "Inclusive Language" portion of the online
> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> and let us know if any changes are needed. Updates of this nature typically
> result in more precise language, which is helpful for readers.
>
> Note that our script did not flag any words in particular, but this should
> still be reviewed as a best practice.
> -->
>
Thanks for bringing this to our attention. I reviewed the document using the
guidance given by the NIST documents and don’t see any issues with the current
text.
>
> Thank you.
Thank you for your hard work!
>
> RFC Editor/ap/ar
>
>
> On Nov 16, 2024, rfc-edi...@rfc-editor.org wrote:
>
> *****IMPORTANT*****
>
> Updated 2024/11/16
>
> RFC Author(s):
> --------------
>
> Instructions for Completing AUTH48
>
> Your document has now entered AUTH48. Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> * RFC Editor questions
>
> Please review and resolve any questions raised by the RFC Editor
> that have been included in the XML file as comments marked as
> follows:
>
> <!-- [rfced] ... -->
>
> These questions will also be sent in a subsequent email.
>
> * Changes submitted by coauthors
>
> Please ensure that you review any changes submitted by your
> coauthors. We assume that if you do not speak up that you
> agree to changes submitted by your coauthors.
>
> * Content
>
> Please review the full content of the document, as this cannot
> change once the RFC is published. Please pay particular attention to:
> - IANA considerations updates (if applicable)
> - contact information
> - references
>
> * Copyright notices and legends
>
> Please review the copyright notice and legends as defined in
> RFC 5378 and the Trust Legal Provisions
> (TLP – https://trustee.ietf.org/license-info).
>
> * Semantic markup
>
> Please review the markup in the XML file to ensure that elements of
> content are correctly tagged. For example, ensure that <sourcecode>
> and <artwork> are set correctly. See details at
> <https://authors.ietf.org/rfcxml-vocabulary>.
>
> * Formatted output
>
> Please review the PDF, HTML, and TXT files to ensure that the
> formatted output, as generated from the markup in the XML file, is
> reasonable. Please note that the TXT will have formatting
> limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
>
> * your coauthors
>
> * rfc-edi...@rfc-editor.org (the RPC team)
>
> * other document participants, depending on the stream (e.g.,
> IETF Stream participants are your working group chairs, the
> responsible ADs, and the document shepherd).
>
> * auth48archive@rfc-editor.org, which is a new archival mailing list
> to preserve AUTH48 conversations; it is not an active discussion
> list:
>
> * More info:
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>
> * The archive itself:
> https://mailarchive.ietf.org/arch/browse/auth48archive/
>
> * Note: If only absolutely necessary, you may temporarily opt out
> of the archiving of messages (e.g., to discuss a sensitive matter).
> If needed, please add a note at the top of the message that you
> have dropped the address. When the discussion is concluded,
> auth48archive@rfc-editor.org will be re-added to the CC list and
> its addition will be noted at the top of the message.
>
> You may submit your changes in one of two ways:
>
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes. Information about stream managers can be found in
> the FAQ. Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication. Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
> https://www.rfc-editor.org/authors/rfc9701.xml
> https://www.rfc-editor.org/authors/rfc9701.html
> https://www.rfc-editor.org/authors/rfc9701.pdf
> https://www.rfc-editor.org/authors/rfc9701.txt
>
> Diff file of the text:
> https://www.rfc-editor.org/authors/rfc9701-diff.html
> https://www.rfc-editor.org/authors/rfc9701-rfcdiff.html (side by side)
>
> Diff of the XML:
> https://www.rfc-editor.org/authors/rfc9701-xmldiff1.html
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
> https://www.rfc-editor.org/auth48/rfc9701
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9701 (draft-ietf-oauth-jwt-introspection-response-12)
>
> Title : JWT Response for OAuth Token Introspection
> Author(s) : T. Lodderstedt, Ed., V. Dzhuvinov
> WG Chair(s) : Hannes Tschofenig, Rifaat Shekh-Yusef
> Area Director(s) : Deb Cooley, Paul Wouters
>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
