Script updating gh-pages from 15957db. [ci skip]

oauth-wg · May 15, 2024 · 57e97f7 · 57e97f7
1 parent 427f567
commit 57e97f7
Show file tree

Hide file tree

Showing 2 changed files with 21 additions and 21 deletions.
diff --git a/120-status-list-endpoint-is-undefined/draft-ietf-oauth-status-list.html b/120-status-list-endpoint-is-undefined/draft-ietf-oauth-status-list.html
@@ -1031,7 +1031,7 @@
 </tr></thead>
 <tfoot><tr>
 <td class="left">Looker, et al.</td>
-<td class="center">Expires 15 November 2024</td>
+<td class="center">Expires 16 November 2024</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1044,12 +1044,12 @@
 <dd class="internet-draft">draft-ietf-oauth-status-list-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2024-05-14" class="published">14 May 2024</time>
+<time datetime="2024-05-15" class="published">15 May 2024</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Informational</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2024-11-15">15 November 2024</time></dd>
+<dd class="expires"><time datetime="2024-11-16">16 November 2024</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1101,7 +1101,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 15 November 2024.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 16 November 2024.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1340,7 +1340,7 @@ <h2 id="name-introduction">
 <a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
       </h2>
 <p id="section-1-1">Token formats secured by JOSE <span>[<a href="#IANA.JOSE" class="cite xref">IANA.JOSE</a>]</span> or COSE <span>[<a href="#RFC9052" class="cite xref">RFC9052</a>]</span>, such as JSON Web Tokens (JWTs) <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>, CBOR Web Tokens (CWTs) <span>[<a href="#RFC8392" class="cite xref">RFC8392</a>]</span> and ISO mdoc <span>[<a href="#ISO.mdoc" class="cite xref">ISO.mdoc</a>]</span>, have vast possible applications. Some of these applications can involve issuing a token whereby certain semantics about the token can change over time, which are important to be able to communicate to relying parties in an interoperable manner, such as whether the token is considered invalidated or suspended by its issuer.<a href="#section-1-1" class="pilcrow">¶</a></p>
-<p id="section-1-2">This document defines a Status List and its representations in JSON and CBOR formats that describe the individual statuses of multiple Referenced Tokens, which themselves are JWTs or CWTs. The statuses of all Referenced Tokens are conveyed via a bit array in the Status List. Each Referenced Token is allocated an index during issuance that represents its position within this bit array. The value of the bit(s) at this index correspond to the Referenced Token's status. A Status List may either be provided by an HTTPS endpoint or be signed and embedded into a Status List Token, whereas this document defines its representations in JWT and CWT. Status Lists may be composed for expressing a range of Status Types. This document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types. The document also defines how an issuer of a Referenced Token references a Status List (Token).<a href="#section-1-2" class="pilcrow">¶</a></p>
+<p id="section-1-2">This document defines a Status List and its representations in JSON and CBOR formats that describe the individual statuses of multiple Referenced Tokens, which themselves are JWTs or CWTs. The statuses of all Referenced Tokens are conveyed via a bit array in the Status List. Each Referenced Token is allocated an index during issuance that represents its position within this bit array. The value of the bit(s) at this index correspond to the Referenced Token's status. A Status List may either be provided via HTTPS or be signed and embedded into a Status List Token, whereas this document defines its representations in JWT and CWT. Status Lists may be composed for expressing a range of Status Types. This document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types. The document also defines how an issuer of a Referenced Token references a Status List (Token).<a href="#section-1-2" class="pilcrow">¶</a></p>
 <p id="section-1-3">An example for the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of <span>[<a href="#RFC6749" class="cite xref">RFC6749</a>]</span>. Token Introspection <span>[<a href="#RFC7662" class="cite xref">RFC7662</a>]</span> defines another way to determine the status of an issued access token, but it requires the party trying to validate an access tokens status to directly contact the token issuer, whereas the mechanism defined in this specification does not have this limitation.<a href="#section-1-3" class="pilcrow">¶</a></p>
 <p id="section-1-4">Another possible use case for the Status List is to express the status of verifiable credentials (Referenced Tokens) issued by an Issuer in the Issuer-Holder-Verifier model <span>[<a href="#SD-JWT.VC" class="cite xref">SD-JWT.VC</a>]</span>.
 The following diagram depicts the basic conceptual relationship.<a href="#section-1-4" class="pilcrow">¶</a></p>
@@ -1712,9 +1712,9 @@ <h3 id="name-status-list-token-in-cwt-fo">
 d28453a20126106e7374617475736c6973742b637774a1044231325860a502782168
 747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f310173
 68747470733a2f2f6578616d706c652e636f6d061a648c5bea041a8898dfea19fffe
-56a2646269747301636c73744a78dadbb918000217015d5840cf0c7e3f47c3566f46
-b1e4201e7e4434a965619dee044d6097de1965526ec860e52f0811c59ec3ce110b2d
-cb66fb8d14ccd46da277dc7acc3cdcf71c518587f3
+56a2646269747301636c73744a78dadbb918000217015d5840bc35944c9e9d5b6048
+3dc9b48b801abe5ecc340854d9a771894377e5fbcc252900b9af6d40c17c0d2656b4
+6f9bb3b1b321037288759c4a9a1f2f0fe4f4ab4ff8
 </pre><a href="#section-5.2-9" class="pilcrow">¶</a>
 </div>
 <p id="section-5.2-10">The following is the CBOR diagnostic output of the example above:<a href="#section-5.2-10" class="pilcrow">¶</a></p>
@@ -1927,7 +1927,7 @@ <h2 id="name-verification-and-processing">
         <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">To obtain the Status List or Status List Token, the Relying Party <span class="bcp14">MUST</span> send a HTTP GET request to the URI provided in the Referenced Token.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
+<p id="section-8.1-1">To obtain the Status List or Status List Token, the Relying Party <span class="bcp14">MUST</span> send an HTTP GET request to the URI provided in the Referenced Token.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
 <p id="section-8.1-2">If the Status List is provided by an HTTP endpoint (and not as a Status List Token), the provider of the Status List <span class="bcp14">MUST</span> utilize TLS. Which version(s) should be implemented will vary over time. A TLS server certificate check <span class="bcp14">MUST</span> be performed as defined in Section 5 and 6 of <span>[<a href="#RFC6125" class="cite xref">RFC6125</a>]</span>.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
 <p id="section-8.1-3">The Relying Party <span class="bcp14">SHOULD</span> send the following Accept-Header to indicate the requested response type:<a href="#section-8.1-3" class="pilcrow">¶</a></p>
 <ul class="normal">
@@ -2814,7 +2814,7 @@ <h2 id="name-document-history">
 <p id="appendix-B-1">-03<a href="#appendix-B-1" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="appendix-B-2.1">
-          <p id="appendix-B-2.1.1">require TLS for fetching only for Status List, not for Status List Token<a href="#appendix-B-2.1.1" class="pilcrow">¶</a></p>
+          <p id="appendix-B-2.1.1">require TLS only for fetching Status List, not for Status List Token<a href="#appendix-B-2.1.1" class="pilcrow">¶</a></p>
 </li>
         <li class="normal" id="appendix-B-2.2">
           <p id="appendix-B-2.2.1">remove the undefined phrase Status List endpoint<a href="#appendix-B-2.2.1" class="pilcrow">¶</a></p>

diff --git a/120-status-list-endpoint-is-undefined/draft-ietf-oauth-status-list.txt b/120-status-list-endpoint-is-undefined/draft-ietf-oauth-status-list.txt
@@ -5,9 +5,9 @@
 Network Working Group                                          T. Looker
 Internet-Draft                                                     MATTR
 Intended status: Informational                                P. Bastian
-Expires: 15 November 2024                                               
+Expires: 16 November 2024                                               
                                                               C. Bormann
-                                                             14 May 2024
+                                                             15 May 2024
 
 
                            Token Status List
@@ -49,7 +49,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 15 November 2024.
+   This Internet-Draft will expire on 16 November 2024.
 
 Copyright Notice
 
@@ -142,9 +142,9 @@ Table of Contents
    List.  Each Referenced Token is allocated an index during issuance
    that represents its position within this bit array.  The value of the
    bit(s) at this index correspond to the Referenced Token's status.  A
-   Status List may either be provided by an HTTPS endpoint or be signed
-   and embedded into a Status List Token, whereas this document defines
-   its representations in JWT and CWT.  Status Lists may be composed for
+   Status List may either be provided via HTTPS or be signed and
+   embedded into a Status List Token, whereas this document defines its
+   representations in JWT and CWT.  Status Lists may be composed for
    expressing a range of Status Types.  This document defines basic
    Status Types for the most common use cases as well as an
    extensibility mechanism for custom Status Types.  The document also
@@ -518,9 +518,9 @@ Table of Contents
    d28453a20126106e7374617475736c6973742b637774a1044231325860a502782168
    747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f310173
    68747470733a2f2f6578616d706c652e636f6d061a648c5bea041a8898dfea19fffe
-   56a2646269747301636c73744a78dadbb918000217015d5840cf0c7e3f47c3566f46
-   b1e4201e7e4434a965619dee044d6097de1965526ec860e52f0811c59ec3ce110b2d
-   cb66fb8d14ccd46da277dc7acc3cdcf71c518587f3
+   56a2646269747301636c73744a78dadbb918000217015d5840bc35944c9e9d5b6048
+   3dc9b48b801abe5ecc340854d9a771894377e5fbcc252900b9af6d40c17c0d2656b4
+   6f9bb3b1b321037288759c4a9a1f2f0fe4f4ab4ff8
 
    The following is the CBOR diagnostic output of the example above:
 
@@ -736,7 +736,7 @@ d2                              # tag(18)
 8.1.  Status List Request
 
    To obtain the Status List or Status List Token, the Relying Party
-   MUST send a HTTP GET request to the URI provided in the Referenced
+   MUST send an HTTP GET request to the URI provided in the Referenced
    Token.
 
    If the Status List is provided by an HTTP endpoint (and not as a
@@ -1449,7 +1449,7 @@ Document History
 
    -03
 
-   *  require TLS for fetching only for Status List, not for Status List
+   *  require TLS only for fetching Status List, not for Status List
       Token
 
    *  remove the undefined phrase Status List endpoint