Hi, These changes are complete:
On Mon Dec 09 21:54:43 2024, apal...@amsl.com wrote: > 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) Done: https://www.iana.org/assignments/oauth-parameters > 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 [looks like this was cut off by mistake; I've removed only the closing period, per the revised document] > 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) Done: https://www.iana.org/assignments/oauth-parameters > 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 Done: https://www.iana.org/assignments/media-types/application/token-introspection+jwt I've also removed the leading asterisks. thanks, Amanda > Best regards, > RFC Editor/ap > > > On Dec 9, 2024, at 1:47 PM, Alanna Paloma <apal...@amsl.com> 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 > >> <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
