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
