The changes look good. Thank you! > On Dec 11, 2024, at 9:46 PM, Amanda Baber via RT <[email protected]> wrote: > > Hi, > > These changes are complete: > > On Mon Dec 09 21:54:43 2024, [email protected] 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 <[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]
