Hi Vladimir, Thank you for your approval. It has been noted: https://www.rfc-editor.org/auth48/rfc9701
We will now ask IANA to update their registry accordingly. After the IANA updates are complete, we will move forward with the publication process. Best regards, RFC Editor/ap > On Dec 9, 2024, at 9:35 AM, Vladimir Dzhuvinov / Connect2id > <vladi...@connect2id.com> wrote: > > Hi Alanna, > > I reviewed the changes and they look good. > > Thanks! > > Vladimir Dzhuvinov > > On 09/12/2024 18:37, Alanna Paloma wrote: >> 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, tors...@lodderstedt.net 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 <apal...@amsl.com>: >>>> 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, torsten=40lodderstedt....@dmarc.ietf.org >>>>> wrote: >>>>> >>>>> 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
