IANA, Please update your registries as follows to match the edited document at https://www.rfc-editor.org/authors/rfc9701-diff.html.
1) Please remove the periods from the following descriptions in the "OAuth Dynamic Client Registration Metadata” registry <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata>. Old: Client Metadata Name: introspection_signed_response_alg Client Metadata Description: String value indicating the client’s desired introspection response signing algorithm. Client Metadata Name: introspection_encrypted_response_alg Client Metadata Description: String value specifying the desired introspection response content key encryption algorithm (alg value). Client Metadata Name: introspection_encrypted_response_enc Client Metadata Description: String value specifying the desired introspection response content encryption algorithm (enc value). New: Client Metadata Name: introspection_signed_response_alg Client Metadata Description: String value indicating the client’s desired introspection response signing algorithm Client Metadata Name: introspection_encrypted_response_alg Client Metadata Description: String value specifying the desired introspection response content key encryption algorithm (alg value) Client Metadata Name: introspection_encrypted_response_enc Client Metadata Description: String value specifying the desired introspection response content encryption algorithm (enc value) 2) Please remove the periods from the following descriptions in the "OAuth Authorization Server Metadata” registry <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata>. Old: Metadata Name: “introspection_signing_alg_values_supported" Metadata Description: JSON array containing a list of algorithms supported by the authorization server for introspection response signing. Metadata Name: “introspection_encryption_alg_values_supported" Metadata Description: JSON array containing a list of algorithms supported by the authorization server for introspection response content key encryption (alg value). Metadata Name: “introspection_encryption_enc_values_supported” Metadata Description: JSON array containing a list of algorithms supported by the authorization server for introspection response content encryption (enc value). New: Metadata Name: introspection_signing_alg_values_supported Metadata Description: JSON array containing a list of algorithms Metadata Name: introspection_encryption_alg_values_supported Metadata Description: JSON array containing a list of algorithms supported by the authorization server for introspection response content key encryption (alg value) Metadata Name: introspection_encryption_enc_values_supported Metadata Description: JSON array containing a list of algorithms supported by the authorization server for introspection response content encryption (enc value) 3) Please update the "application/token-introspection+jwt" media type entry in the “Media Types" registry <https://www.iana.org/assignments/media-types/application/token-introspection+jwt> by removing the bullets. Additionally, make the following updates to the content: -update the semicolon after “binary” to a period -update Section 7 to be Section 8 in the Security considerations line -remove the “* Provisional registration? No” line Old: * Encoding considerations: binary; A token introspection response is a JWT; JWT values are encoded as a series of base64url-encoded values (with trailing '=' characters removed), some of which may be the empty string, separated by period ('.') characters. * Security considerations: See Section 7 of RFC-ietf-oauth-jwt-introspection-response-12 * Provisional registration? No New: Encoding considerations: binary. A token introspection response is a JWT; JWT values are encoded as a series of base64url-encoded values (with trailing '=' characters removed), some of which may be the empty string, separated by period ('.') characters. Security considerations: See Section 8 of RFC-ietf-oauth-jwt-introspection-response-12 Best regards, RFC Editor/ap > On Dec 9, 2024, at 1:47 PM, Alanna Paloma <[email protected]> wrote: > > 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 >> <[email protected]> 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, [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]
