Script updating gh-pages from 58e166e. [ci skip]

Author: ID Bot

draft-ietf-oauth-status-list.html

@@ -25,7 +25,7 @@
     pycountry 24.6.1
     PyYAML 6.0.3
     requests 2.32.5
-    wcwidth 0.2.14
+    wcwidth 0.3.0
 -->
 <link href="draft-ietf-oauth-status-list.xml" rel="alternate" type="application/rfc+xml">
 <link href="#copyright" rel="license">
@@ -1048,7 +1048,7 @@
 </tr></thead>
 <tfoot><tr>
 <td class="left">Looker, et al.</td>
-<td class="center">Expires 19 July 2026</td>
+<td class="center">Expires 26 July 2026</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1061,12 +1061,12 @@
 <dd class="internet-draft">draft-ietf-oauth-status-list-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2026-01-15" class="published">15 January 2026</time>
+<time datetime="2026-01-22" class="published">22 January 2026</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Standards Track</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2026-07-19">19 July 2026</time></dd>
+<dd class="expires"><time datetime="2026-07-26">26 July 2026</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1124,7 +1124,7 @@ <h2 id="name-status-of-this-memo">
         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 19 July 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 26 July 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -2408,9 +2408,9 @@ <h3 id="name-status-list-request">
 <a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-status-list-request" class="section-name selfRef">Status List Request</a>
         </h3>
 <p id="section-8.1-1">The default Status List request and response mechanism uses HTTP semantics and Content negotiation as defined in <span>[<a href="#RFC9110" class="cite xref">RFC9110</a>]</span>.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
-<p id="section-8.1-2">The Status Provider <span class="bcp14">SHOULD</span> return the Status List Token in response to an HTTP GET request to the URI provided in the Referenced Token, unless the Relying Party and the Status Provider have alternative methods of distribution.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
+<p id="section-8.1-2">The Status Provider <span class="bcp14">MUST</span> return the Status List Token in response to an HTTP GET request to the URI provided in the Referenced Token, unless the Relying Party and the Status Provider have alternative methods of distribution for the Status List Token.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
 <p id="section-8.1-3">The HTTP endpoint <span class="bcp14">SHOULD</span> support the use of Cross-Origin Resource Sharing (CORS) <span>[<a href="#CORS" class="cite xref">CORS</a>]</span> and/or other methods as appropriate to enable Browser-based clients to access it, unless ecosystems using this specification choose not to support Browser-based clients.<a href="#section-8.1-3" class="pilcrow">¶</a></p>
-<p id="section-8.1-4">The Relying Party <span class="bcp14">SHOULD</span> send the following Accept HTTP Header to indicate the requested response type unless the Content-Type of Status List Tokens in the respective ecosystem is known or the Relying Party supports both formats:<a href="#section-8.1-4" class="pilcrow">¶</a></p>
+<p id="section-8.1-4">The following media types are defined by this specification for HTTP based Content negotiation:<a href="#section-8.1-4" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-8.1-5.1">
             <p id="section-8.1-5.1.1">"application/statuslist+jwt" for Status List Token in JWT format<a href="#section-8.1-5.1.1" class="pilcrow">¶</a></p>
@@ -2419,14 +2419,13 @@ <h3 id="name-status-list-request">
             <p id="section-8.1-5.2.1">"application/statuslist+cwt" for Status List Token in CWT format<a href="#section-8.1-5.2.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
-<p id="section-8.1-6">If the Relying Party does not send an Accept Header, the response type is assumed to be known implicitly or out-of-band.<a href="#section-8.1-6" class="pilcrow">¶</a></p>
-<p id="section-8.1-7">The following is a non-normative example of a request for a Status List Token with type <code>application/statuslist+jwt</code>:<a href="#section-8.1-7" class="pilcrow">¶</a></p>
-<div class="alignLeft art-ascii-art art-text artwork" id="section-8.1-8">
+<p id="section-8.1-6">The following is a non-normative example of a request for a Status List Token with type <code>application/statuslist+jwt</code>:<a href="#section-8.1-6" class="pilcrow">¶</a></p>
+<div class="alignLeft art-ascii-art art-text artwork" id="section-8.1-7">
 <pre>
 GET /statuslists/1 HTTP/1.1
 Host: example.com
 Accept: application/statuslist+jwt
-</pre><a href="#section-8.1-8" class="pilcrow">¶</a>
+</pre><a href="#section-8.1-7" class="pilcrow">¶</a>
 </div>
 </section>
 </div>
@@ -2747,7 +2746,7 @@ <h3 id="name-key-resolution-and-trust-ma">
         <h3 id="name-redirection-3xx">
 <a href="#section-11.4" class="section-number selfRef">11.4. </a><a href="#name-redirection-3xx" class="section-name selfRef">Redirection 3xx</a>
         </h3>
-<p id="section-11.4-1">HTTP clients that follow 3xx (Redirection) status codes <span class="bcp14">SHOULD</span> be aware of the possible dangers of redirects, such as infinite redirection loops, since they can be used for denial-of-service attacks on clients. A client <span class="bcp14">SHOULD</span> detect and intervene in infinite redirections. Clients <span class="bcp14">SHOULD</span> apply the guidance for redirects given in <span><a href="https://rfc-editor.org/rfc/rfc9110#section-15.4" class="relref">Section 15.4</a> of [<a href="#RFC9110" class="cite xref">RFC9110</a>]</span>.<a href="#section-11.4-1" class="pilcrow">¶</a></p>
+<p id="section-11.4-1">HTTP clients that follow 3xx (Redirection) status codes <span class="bcp14">MUST</span> be aware of the possible dangers of redirects, such as infinite redirection loops, since they can be used for denial-of-service attacks on clients. HTTP clients <span class="bcp14">MUST</span> follow the guidance provided in <span><a href="https://rfc-editor.org/rfc/rfc9110#section-15.4" class="relref">Section 15.4</a> of [<a href="#RFC9110" class="cite xref">RFC9110</a>]</span> for handling redirects.<a href="#section-11.4-1" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="security-ttl">
@@ -4697,6 +4696,12 @@ <h2 id="name-document-history">
 </li>
         <li class="normal" id="appendix-D-3.4">
           <p id="appendix-D-3.4.1">small corrections in the introduction<a href="#appendix-D-3.4.1" class="pilcrow">¶</a></p>
+</li>
+        <li class="normal" id="appendix-D-3.5">
+          <p id="appendix-D-3.5.1">change guidance around HTTP content negotiation to refer to RFC 9110<a href="#appendix-D-3.5.1" class="pilcrow">¶</a></p>
+</li>
+        <li class="normal" id="appendix-D-3.6">
+          <p id="appendix-D-3.6.1">strengthen normative guidance around handling cases or redirection<a href="#appendix-D-3.6.1" class="pilcrow">¶</a></p>
 </li>
       </ul>
 <p id="appendix-D-4">-15<a href="#appendix-D-4" class="pilcrow">¶</a></p>

draft-ietf-oauth-status-list.txt

@@ -5,10 +5,10 @@
 Web Authorization Protocol                                     T. Looker
 Internet-Draft                                                     MATTR
 Intended status: Standards Track                              P. Bastian
-Expires: 19 July 2026                                    Bundesdruckerei
+Expires: 26 July 2026                                    Bundesdruckerei
                                                               C. Bormann
                                                                   SPRIND
-                                                         15 January 2026
+                                                         22 January 2026
 
 
                         Token Status List (TSL)
@@ -55,7 +55,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 19 July 2026.
+   This Internet-Draft will expire on 26 July 2026.
 
 Copyright Notice
 
@@ -1153,28 +1153,23 @@ d2                              # tag(18)
    The default Status List request and response mechanism uses HTTP
    semantics and Content negotiation as defined in [RFC9110].
 
-   The Status Provider SHOULD return the Status List Token in response
-   to an HTTP GET request to the URI provided in the Referenced Token,
+   The Status Provider MUST return the Status List Token in response to
+   an HTTP GET request to the URI provided in the Referenced Token,
    unless the Relying Party and the Status Provider have alternative
-   methods of distribution.
+   methods of distribution for the Status List Token.
 
    The HTTP endpoint SHOULD support the use of Cross-Origin Resource
    Sharing (CORS) [CORS] and/or other methods as appropriate to enable
    Browser-based clients to access it, unless ecosystems using this
    specification choose not to support Browser-based clients.
 
-   The Relying Party SHOULD send the following Accept HTTP Header to
-   indicate the requested response type unless the Content-Type of
-   Status List Tokens in the respective ecosystem is known or the
-   Relying Party supports both formats:
+   The following media types are defined by this specification for HTTP
+   based Content negotiation:
 
    *  "application/statuslist+jwt" for Status List Token in JWT format
 
    *  "application/statuslist+cwt" for Status List Token in CWT format
 
-   If the Relying Party does not send an Accept Header, the response
-   type is assumed to be known implicitly or out-of-band.
-
    The following is a non-normative example of a request for a Status
    List Token with type application/statuslist+jwt:
 
@@ -1569,12 +1564,11 @@ d2                              # tag(18)
 
 11.4.  Redirection 3xx
 
-   HTTP clients that follow 3xx (Redirection) status codes SHOULD be
-   aware of the possible dangers of redirects, such as infinite
-   redirection loops, since they can be used for denial-of-service
-   attacks on clients.  A client SHOULD detect and intervene in infinite
-   redirections.  Clients SHOULD apply the guidance for redirects given
-   in Section 15.4 of [RFC9110].
+   HTTP clients that follow 3xx (Redirection) status codes MUST be aware
+   of the possible dangers of redirects, such as infinite redirection
+   loops, since they can be used for denial-of-service attacks on
+   clients.  HTTP clients MUST follow the guidance provided in
+   Section 15.4 of [RFC9110] for handling redirects.
 
 11.5.  Expiration and Caching
 
@@ -3275,6 +3269,11 @@ Document History
 
    *  small corrections in the introduction
 
+   *  change guidance around HTTP content negotiation to refer to RFC
+      9110
+
+   *  strengthen normative guidance around handling cases or redirection
+
    -15
 
    *  limit Status List Token CWT COSE message to Sign1/Mac0

index.html

@@ -29,15 +29,15 @@ <h2>Preview for branch <a href="335-mikes-review">335-mikes-review</a></h2>
       <tr>
         <td><a href="335-mikes-review/draft-ietf-oauth-status-list.html" class="html draft-ietf-oauth-status-list" title="Token Status List (TSL) (HTML)">Token Status List (TSL)</a></td>
         <td><a href="335-mikes-review/draft-ietf-oauth-status-list.txt" class="txt draft-ietf-oauth-status-list" title="Token Status List (TSL) (Text)">plain text</a></td>
-        <td>same as main</td>
+        <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://oauth-wg.github.io/draft-ietf-oauth-status-list/draft-ietf-oauth-status-list.txt&amp;url_2=https://oauth-wg.github.io/draft-ietf-oauth-status-list/335-mikes-review/draft-ietf-oauth-status-list.txt" class="diff draft-ietf-oauth-status-list">diff with main</a></td>
       </tr>
     </table>
     <h2>Preview for branch <a href="issue-334">issue-334</a></h2>
     <table id="branch-issue-334">
       <tr>
         <td><a href="issue-334/draft-ietf-oauth-status-list.html" class="html draft-ietf-oauth-status-list" title="Token Status List (TSL) (HTML)">Token Status List (TSL)</a></td>
         <td><a href="issue-334/draft-ietf-oauth-status-list.txt" class="txt draft-ietf-oauth-status-list" title="Token Status List (TSL) (Text)">plain text</a></td>
-        <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://oauth-wg.github.io/draft-ietf-oauth-status-list/draft-ietf-oauth-status-list.txt&amp;url_2=https://oauth-wg.github.io/draft-ietf-oauth-status-list/issue-334/draft-ietf-oauth-status-list.txt" class="diff draft-ietf-oauth-status-list">diff with main</a></td>
+        <td>same as main</td>
       </tr>
     </table>
     <h2>Preview for branch <a href="327-description-field">327-description-field</a></h2>