Hi Torsten, Thank you for your approval. We have noted it on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9701
Once we receive Vladimir’s approval, we will move this document forward in the publication process. Best regards, RFC Editor/ap > On Dec 8, 2024, at 7:49 AM, [email protected] wrote: > > HI Alanna, > > thank you so much. > > I approve this revision for publication. > > best regards, > Torsten. > Am 2. Dez. 2024, 19:32 +0100 schrieb Alanna Paloma <[email protected]>: >> Hi Torsten, >> >> Thank you for your reply. We have updated the files accordingly. >> >> The files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9701.xml >> https://www.rfc-editor.org/authors/rfc9701.txt >> https://www.rfc-editor.org/authors/rfc9701.html >> https://www.rfc-editor.org/authors/rfc9701.pdf >> >> The relevant diff files have been posted here: >> https://www.rfc-editor.org/authors/rfc9701-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc9701-auth48diff.html (AUTH48 changes) >> >> Please review the document carefully and contact us with any further updates >> you may have. Note that we do not make changes once a document is published >> as an RFC. >> >> We will await approvals from each party listed on the AUTH48 status page >> below prior to moving this document forward in the publication process. >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9701 >> >> Thank you, >> RFC Editor/ap >> >>> On Dec 1, 2024, at 2:51 AM, [email protected] wrote: >>> >>> Hi, >>> >>> please find my responses inline. >>> >>> best regards, >>> Torsten. >>> Am 16. Nov. 2024, 22:13 +0100 schrieb [email protected]: >>> 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, [email protected] 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 >>> >>> * [email protected] (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). >>> >>> * [email protected], 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, >>> [email protected] 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 -- [email protected] To unsubscribe send an email to [email protected]
