From 3ba763a826a6c8252be58e3319ddb32f7c647bcb Mon Sep 17 00:00:00 2001
From: ID Bot <idbot@example.com>
Date: Mon, 17 Jul 2023 06:35:28 +0000
Subject: [PATCH] Script updating gh-pages from 70e860b. [ci skip]

---
 draft-looker-oauth-jwt-cwt-status-list.html | 156 ++++++++++----------
 draft-looker-oauth-jwt-cwt-status-list.txt  | 126 ++++++++--------
 index.html                                  |   2 +-
 3 files changed, 142 insertions(+), 142 deletions(-)

diff --git a/draft-looker-oauth-jwt-cwt-status-list.html b/draft-looker-oauth-jwt-cwt-status-list.html
index 6402af6..8dee58a 100644
--- a/draft-looker-oauth-jwt-cwt-status-list.html
+++ b/draft-looker-oauth-jwt-cwt-status-list.html
@@ -1052,7 +1052,7 @@
 </tr></thead>
 <tfoot><tr>
 <td class="left">Looker &amp; Bastian</td>
-<td class="center">Expires 11 January 2024</td>
+<td class="center">Expires 18 January 2024</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1065,12 +1065,12 @@
 <dd class="internet-draft">draft-looker-oauth-jwt-cwt-status-list-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2023-07-10" class="published">10 July 2023</time>
+<time datetime="2023-07-17" class="published">17 July 2023</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-01-11">11 January 2024</time></dd>
+<dd class="expires"><time datetime="2024-01-18">18 January 2024</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1119,7 +1119,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 11 January 2024.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 18 January 2024.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1163,21 +1163,21 @@ <h2 id="name-copyright-notice">
             <p id="section-toc.1-1.4.1"><a href="#section-4" class="auto internal xref">4</a>.  <a href="#name-json-web-token-representati" class="internal xref">JSON Web Token Representation</a></p>
 <ul class="compact toc ulBare ulEmpty">
 <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
-                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="auto internal xref">4.1</a>.  <a href="#name-referenced-token-format-and" class="internal xref">Referenced Token Format and Processing Requirements</a></p>
+                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="auto internal xref">4.1</a>.  <a href="#name-status-list-jwt-format-and-" class="internal xref">Status List JWT Format and Processing Requirements</a></p>
 <ul class="compact toc ulBare ulEmpty">
 <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1.2.1">
-                    <p id="section-toc.1-1.4.2.1.2.1.1"><a href="#section-4.1.1" class="auto internal xref">4.1.1</a>.  <a href="#name-status-claim-format" class="internal xref">Status Claim Format</a></p>
+                    <p id="section-toc.1-1.4.2.1.2.1.1"><a href="#section-4.1.1" class="auto internal xref">4.1.1</a>.  <a href="#name-status-list-claim-format" class="internal xref">Status List Claim Format</a></p>
+</li>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1.2.2">
+                    <p id="section-toc.1-1.4.2.1.2.2.1"><a href="#section-4.1.2" class="auto internal xref">4.1.2</a>.  <a href="#name-status-list-encoding" class="internal xref">Status List Encoding</a></p>
 </li>
                 </ul>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
-                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="auto internal xref">4.2</a>.  <a href="#name-status-list-jwt-format-and-" class="internal xref">Status List JWT Format and Processing Requirements</a></p>
+                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="auto internal xref">4.2</a>.  <a href="#name-referenced-token-format-and" class="internal xref">Referenced Token Format and Processing Requirements</a></p>
 <ul class="compact toc ulBare ulEmpty">
 <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.1">
-                    <p id="section-toc.1-1.4.2.2.2.1.1"><a href="#section-4.2.1" class="auto internal xref">4.2.1</a>.  <a href="#name-status-list-claim-format" class="internal xref">Status List Claim Format</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.2">
-                    <p id="section-toc.1-1.4.2.2.2.2.1"><a href="#section-4.2.2" class="auto internal xref">4.2.2</a>.  <a href="#name-status-list-encoding" class="internal xref">Status List Encoding</a></p>
+                    <p id="section-toc.1-1.4.2.2.2.1.1"><a href="#section-4.2.1" class="auto internal xref">4.2.1</a>.  <a href="#name-status-claim-format" class="internal xref">Status Claim Format</a></p>
 </li>
                 </ul>
 </li>
@@ -1332,125 +1332,125 @@ <h2 id="name-terminology">
       <h2 id="name-json-web-token-representati">
 <a href="#section-4" class="section-number selfRef">4. </a><a href="#name-json-web-token-representati" class="section-name selfRef">JSON Web Token Representation</a>
       </h2>
-<div id="jwt-referenced-token">
+<div id="jwt-status-list-format-and-processing">
 <section id="section-4.1">
-        <h3 id="name-referenced-token-format-and">
-<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-referenced-token-format-and" class="section-name selfRef">Referenced Token Format and Processing Requirements</a>
+        <h3 id="name-status-list-jwt-format-and-">
+<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-status-list-jwt-format-and-" class="section-name selfRef">Status List JWT Format and Processing Requirements</a>
         </h3>
-<p id="section-4.1-1">The following rules apply to validating a Referenced Token in JWT representation, which references a Status List Token. Application of additional restrictions and policy are at the discretion of the verifying party.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.1-1">The following rules apply to validating a JWT-based Status List Token. Application of additional restrictions and policy are at the discretion of the verifying party.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
 <ol start="1" type="1" class="normal type-1" id="section-4.1-2">
-<li id="section-4.1-2.1">The JWT <span class="bcp14">MUST</span> contain an "iss" (issuer) claim that contains a unique string identifier for the entity that issued the JWT. In the absence of an application profile specifying otherwise, compliant applications <span class="bcp14">MUST</span> compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of <span>[<a href="#RFC3986" class="cite xref">RFC3986</a>]</span>. The value <span class="bcp14">MUST</span> be equal to that of the "iss" claim contained within the referenced Status List Token.<a href="#section-4.1-2.1" class="pilcrow">¶</a>
+<li id="section-4.1-2.1">The JWT <span class="bcp14">MUST</span> contain an "iss" (issuer) claim that contains a unique string identifier for the entity that issued the JWT. In the absence of an application profile specifying otherwise, compliant applications <span class="bcp14">MUST</span> compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of <span>[<a href="#RFC3986" class="cite xref">RFC3986</a>]</span>. The value <span class="bcp14">MUST</span> be equal to that of the "iss" claim contained within the Referenced Token.<a href="#section-4.1-2.1" class="pilcrow">¶</a>
+</li>
+          <li id="section-4.1-2.2">The JWT <span class="bcp14">MUST</span> contain a "sub" (subject) claim that contains an unique string identifier for that Referenced Token. The value <span class="bcp14">MUST</span> be equal to that of the "uri" claim contained in the "status" claim of the Referenced Token.<a href="#section-4.1-2.2" class="pilcrow">¶</a>
+</li>
+          <li id="section-4.1-2.3">The JWT <span class="bcp14">MUST</span> contain an "iat" (issued at) claim that identifies the time at which it was issued.<a href="#section-4.1-2.3" class="pilcrow">¶</a>
+</li>
+          <li id="section-4.1-2.4">The JWT <span class="bcp14">MUST</span> contain an "status_list" (status list) claim conforming to the rules outlined in <a href="#jwt-status-list-claim-format" class="auto internal xref">Section 4.1.1</a>.<a href="#section-4.1-2.4" class="pilcrow">¶</a>
 </li>
-          <li id="section-4.1-2.2">The JWT <span class="bcp14">MUST</span> contain an "status" (status) claim conforming to the rules outlined in <a href="#jwt-referenced-token-status" class="auto internal xref">Section 4.1.1</a><a href="#section-4.1-2.2" class="pilcrow">¶</a>
+          <li id="section-4.1-2.5">The JWT <span class="bcp14">MAY</span> contain an "exp" (expiration time) claim that conveys when it is considered expired by its issuer.<a href="#section-4.1-2.5" class="pilcrow">¶</a>
+</li>
+          <li id="section-4.1-2.6">The JWT <span class="bcp14">MAY</span> contain other claims.<a href="#section-4.1-2.6" class="pilcrow">¶</a>
+</li>
+          <li id="section-4.1-2.7">The JWT <span class="bcp14">MUST</span> be digitally signed using an asymmetric cryptographic algorithm. Relying parties <span class="bcp14">MUST</span> reject the JWT if it is using a Message Authentication Code (MAC) algorithm. Relying parties <span class="bcp14">MUST</span> reject JWTs with an invalid signature.<a href="#section-4.1-2.7" class="pilcrow">¶</a>
+</li>
+          <li id="section-4.1-2.8">Relying parties <span class="bcp14">MUST</span> reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>.<a href="#section-4.1-2.8" class="pilcrow">¶</a>
 </li>
         </ol>
-<p id="section-4.1-3">The following example is the decoded header and payload of a JWT meeting the processing rules as defined above.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
-<div class="alignLeft art-ascii-art art-text artwork" id="section-4.1-4">
+<div class="alignLeft art-ascii-art art-text artwork" id="section-4.1-3">
 <pre>
 {
+  "typ": "statuslist+jwt",
   "alg": "ES256",
   "kid": "11"
 }
 .
 {
   "iss": "https://example.com",
-  "status": {
-    "idx": 0,
-    "uri": "https://example.com/statuslists/1"
+  "sub": "https://example.com/statuslists/1",
+  "iat": 1683560915,
+  "exp": 1686232115,
+  "status_list": {
+    "bits": 1,
+    "lst": "H4sIAMo_jGQC_9u5GABc9QE7AgAAAA"
   }
 }
-</pre><a href="#section-4.1-4" class="pilcrow">¶</a>
+</pre><a href="#section-4.1-3" class="pilcrow">¶</a>
 </div>
-<div id="jwt-referenced-token-status">
+<div id="jwt-status-list-claim-format">
 <section id="section-4.1.1">
-          <h4 id="name-status-claim-format">
-<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-status-claim-format" class="section-name selfRef">Status Claim Format</a>
+          <h4 id="name-status-list-claim-format">
+<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-status-list-claim-format" class="section-name selfRef">Status List Claim Format</a>
           </h4>
-<p id="section-4.1.1-1">The following rules apply to validating the "status" (status) claim<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.1.1-1">The following rules apply to validating the "status_list" (status list) claim<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
 <ol start="1" type="1" class="normal type-1" id="section-4.1.1-2">
 <li id="section-4.1.1-2.1">The claim value <span class="bcp14">MUST</span> be a valid JSON object.<a href="#section-4.1.1-2.1" class="pilcrow">¶</a>
 </li>
-            <li id="section-4.1.1-2.2">The claim value object <span class="bcp14">MUST</span> contain an "idx" (index) member with a numeric value that represents the index to check for status information in the Status List for the current JWT. The value of this member <span class="bcp14">MUST</span> be a non-negative number, containing a value of zero or greater.<a href="#section-4.1.1-2.2" class="pilcrow">¶</a>
+            <li id="section-4.1.1-2.2">The claim value object <span class="bcp14">MUST</span> contain a "bits" (bit size) member with an numeric value that represents the number of bits per Referenced Token in the Status List ("lst") of the Status List JWT. The allowed values for "bits" are 1,2,4 and 8.<a href="#section-4.1.1-2.2" class="pilcrow">¶</a>
 </li>
-            <li id="section-4.1.1-2.3">The claim value object <span class="bcp14">MUST</span> contain a "uri" member with a string value that identifies the Status List containing the status information for the JWT. The value of this member <span class="bcp14">MUST</span> be a uri conforming to <span>[<a href="#RFC3986" class="cite xref">RFC3986</a>]</span>.<a href="#section-4.1.1-2.3" class="pilcrow">¶</a>
+            <li id="section-4.1.1-2.3">The claim value object <span class="bcp14">MUST</span> contain a "lst" (list) member with a string value that represents the status values for all the tokens it conveys statuses for. The value <span class="bcp14">MUST</span> be computed using the algorithm described in <a href="#jwt-status-list-claim-encoding" class="auto internal xref">Section 4.1.2</a>.<a href="#section-4.1.1-2.3" class="pilcrow">¶</a>
 </li>
           </ol>
 </section>
 </div>
+<div id="jwt-status-list-claim-encoding">
+<section id="section-4.1.2">
+          <h4 id="name-status-list-encoding">
+<a href="#section-4.1.2" class="section-number selfRef">4.1.2. </a><a href="#name-status-list-encoding" class="section-name selfRef">Status List Encoding</a>
+          </h4>
+<p id="section-4.1.2-1">Each status of a Referenced Token <span class="bcp14">MUST</span> be represented with a bit size of 1,2,4, or 8. Therefore up to 2,4,16, or 256 statuses for a Referenced Token are possible, depending on the bit size. This limitation is intended to limit bit manipulation necessary to a single byte for every operation and thus keeping implementations simpler and less error prone.<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal type-1" id="section-4.1.2-2">
+<li id="section-4.1.2-2.1">The overall Status List is encoded as a byte array. Depending on the bitsize, each byte corresponds to 8/(#bit-size) statuses (8,4,2, or 1). The status of each Referenced Token is identified using the index that maps to one or more specific bits within the byte array. The index starts counting at 0 and ends with "size" - 1 (being the last valid entry). The bits within an array are counted from least significant bit "0" to the most significant bit ("7"). All bits of the byte array at a particular index are set to a status value.<a href="#section-4.1.2-2.1" class="pilcrow">¶</a>
+</li>
+            <li id="section-4.1.2-2.2">The complete byte array is compressed using gZIP <span>[<a href="#RFC1952" class="cite xref">RFC1952</a>]</span>.<a href="#section-4.1.2-2.2" class="pilcrow">¶</a>
+</li>
+            <li id="section-4.1.2-2.3">The result of the gZIP compression is then base64url-encoded, as defined in Section 2 of <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>.<a href="#section-4.1.2-2.3" class="pilcrow">¶</a>
+</li>
+          </ol>
 </section>
 </div>
-<div id="jwt-status-list-format-and-processing">
+</section>
+</div>
+<div id="jwt-referenced-token">
 <section id="section-4.2">
-        <h3 id="name-status-list-jwt-format-and-">
-<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-status-list-jwt-format-and-" class="section-name selfRef">Status List JWT Format and Processing Requirements</a>
+        <h3 id="name-referenced-token-format-and">
+<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-referenced-token-format-and" class="section-name selfRef">Referenced Token Format and Processing Requirements</a>
         </h3>
-<p id="section-4.2-1">The following rules apply to validating a JWT-based Status List Token. Application of additional restrictions and policy are at the discretion of the verifying party.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
+<p id="section-4.2-1">The following rules apply to validating a Referenced Token in JWT representation, which references a Status List Token. Application of additional restrictions and policy are at the discretion of the verifying party.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
 <ol start="1" type="1" class="normal type-1" id="section-4.2-2">
-<li id="section-4.2-2.1">The JWT <span class="bcp14">MUST</span> contain an "iss" (issuer) claim that contains a unique string identifier for the entity that issued the JWT. In the absence of an application profile specifying otherwise, compliant applications <span class="bcp14">MUST</span> compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of <span>[<a href="#RFC3986" class="cite xref">RFC3986</a>]</span>. The value <span class="bcp14">MUST</span> be equal to that of the "iss" claim contained within the Referenced Token.<a href="#section-4.2-2.1" class="pilcrow">¶</a>
-</li>
-          <li id="section-4.2-2.2">The JWT <span class="bcp14">MUST</span> contain a "sub" (subject) claim that contains an unique string identifier for that Referenced Token. The value <span class="bcp14">MUST</span> be equal to that of the "uri" claim contained in the "status" claim of the Referenced Token.<a href="#section-4.2-2.2" class="pilcrow">¶</a>
-</li>
-          <li id="section-4.2-2.3">The JWT <span class="bcp14">MUST</span> contain an "iat" (issued at) claim that identifies the time at which it was issued.<a href="#section-4.2-2.3" class="pilcrow">¶</a>
-</li>
-          <li id="section-4.2-2.4">The JWT <span class="bcp14">MUST</span> contain an "status_list" (status list) claim conforming to the rules outlined in <a href="#jwt-status-list-claim-format" class="auto internal xref">Section 4.2.1</a>.<a href="#section-4.2-2.4" class="pilcrow">¶</a>
-</li>
-          <li id="section-4.2-2.5">The JWT <span class="bcp14">MAY</span> contain an "exp" (expiration time) claim that conveys when it is considered expired by its issuer.<a href="#section-4.2-2.5" class="pilcrow">¶</a>
+<li id="section-4.2-2.1">The JWT <span class="bcp14">MUST</span> contain an "iss" (issuer) claim that contains a unique string identifier for the entity that issued the JWT. In the absence of an application profile specifying otherwise, compliant applications <span class="bcp14">MUST</span> compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of <span>[<a href="#RFC3986" class="cite xref">RFC3986</a>]</span>. The value <span class="bcp14">MUST</span> be equal to that of the "iss" claim contained within the referenced Status List Token.<a href="#section-4.2-2.1" class="pilcrow">¶</a>
 </li>
-          <li id="section-4.2-2.6">The JWT <span class="bcp14">MAY</span> contain other claims.<a href="#section-4.2-2.6" class="pilcrow">¶</a>
-</li>
-          <li id="section-4.2-2.7">The JWT <span class="bcp14">MUST</span> be digitally signed using an asymmetric cryptographic algorithm. Relying parties <span class="bcp14">MUST</span> reject the JWT if it is using a Message Authentication Code (MAC) algorithm. Relying parties <span class="bcp14">MUST</span> reject JWTs with an invalid signature.<a href="#section-4.2-2.7" class="pilcrow">¶</a>
-</li>
-          <li id="section-4.2-2.8">Relying parties <span class="bcp14">MUST</span> reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>.<a href="#section-4.2-2.8" class="pilcrow">¶</a>
+          <li id="section-4.2-2.2">The JWT <span class="bcp14">MUST</span> contain an "status" (status) claim conforming to the rules outlined in <a href="#jwt-referenced-token-status" class="auto internal xref">Section 4.2.1</a><a href="#section-4.2-2.2" class="pilcrow">¶</a>
 </li>
         </ol>
-<div class="alignLeft art-ascii-art art-text artwork" id="section-4.2-3">
+<p id="section-4.2-3">The following example is the decoded header and payload of a JWT meeting the processing rules as defined above.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
+<div class="alignLeft art-ascii-art art-text artwork" id="section-4.2-4">
 <pre>
 {
-  "typ": "statuslist+jwt",
   "alg": "ES256",
   "kid": "11"
 }
 .
 {
   "iss": "https://example.com",
-  "sub": "https://example.com/statuslists/1",
-  "iat": 1683560915,
-  "exp": 1686232115,
-  "status_list": {
-    "bits": 1,
-    "lst": "H4sIAMo_jGQC_9u5GABc9QE7AgAAAA"
+  "status": {
+    "idx": 0,
+    "uri": "https://example.com/statuslists/1"
   }
 }
-</pre><a href="#section-4.2-3" class="pilcrow">¶</a>
+</pre><a href="#section-4.2-4" class="pilcrow">¶</a>
 </div>
-<div id="jwt-status-list-claim-format">
+<div id="jwt-referenced-token-status">
 <section id="section-4.2.1">
-          <h4 id="name-status-list-claim-format">
-<a href="#section-4.2.1" class="section-number selfRef">4.2.1. </a><a href="#name-status-list-claim-format" class="section-name selfRef">Status List Claim Format</a>
+          <h4 id="name-status-claim-format">
+<a href="#section-4.2.1" class="section-number selfRef">4.2.1. </a><a href="#name-status-claim-format" class="section-name selfRef">Status Claim Format</a>
           </h4>
-<p id="section-4.2.1-1">The following rules apply to validating the "status_list" (status list) claim<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.2.1-1">The following rules apply to validating the "status" (status) claim<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
 <ol start="1" type="1" class="normal type-1" id="section-4.2.1-2">
 <li id="section-4.2.1-2.1">The claim value <span class="bcp14">MUST</span> be a valid JSON object.<a href="#section-4.2.1-2.1" class="pilcrow">¶</a>
 </li>
-            <li id="section-4.2.1-2.2">The claim value object <span class="bcp14">MUST</span> contain a "bits" (bit size) member with an numeric value that represents the number of bits per Referenced Token in the Status List ("lst") of the Status List JWT. The allowed values for "bits" are 1,2,4 and 8.<a href="#section-4.2.1-2.2" class="pilcrow">¶</a>
-</li>
-            <li id="section-4.2.1-2.3">The claim value object <span class="bcp14">MUST</span> contain a "lst" (list) member with a string value that represents the status values for all the tokens it conveys statuses for. The value <span class="bcp14">MUST</span> be computed using the algorithm described in <a href="#jwt-status-list-claim-encoding" class="auto internal xref">Section 4.2.2</a>.<a href="#section-4.2.1-2.3" class="pilcrow">¶</a>
-</li>
-          </ol>
-</section>
-</div>
-<div id="jwt-status-list-claim-encoding">
-<section id="section-4.2.2">
-          <h4 id="name-status-list-encoding">
-<a href="#section-4.2.2" class="section-number selfRef">4.2.2. </a><a href="#name-status-list-encoding" class="section-name selfRef">Status List Encoding</a>
-          </h4>
-<p id="section-4.2.2-1">Each status of a Referenced Token <span class="bcp14">MUST</span> be represented with a bit size of 1,2,4, or 8. Therefore up to 2,4,16, or 256 statuses for a Referenced Token are possible, depending on the bit size. This limitation is intended to limit bit manipulation necessary to a single byte for every operation and thus keeping implementations simpler and less error prone.<a href="#section-4.2.2-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-4.2.2-2">
-<li id="section-4.2.2-2.1">The overall Status List is encoded as a byte array. Depending on the bitsize, each byte corresponds to 8/(#bit-size) statuses (8,4,2, or 1). The status of each Referenced Token is identified using the index that maps to one or more specific bits within the byte array. The index starts counting at 0 and ends with "size" - 1 (being the last valid entry). The bits within an array are counted from least significant bit "0" to the most significant bit ("7"). All bits of the byte array at a particular index are set to a status value.<a href="#section-4.2.2-2.1" class="pilcrow">¶</a>
-</li>
-            <li id="section-4.2.2-2.2">The complete byte array is compressed using gZIP <span>[<a href="#RFC1952" class="cite xref">RFC1952</a>]</span>.<a href="#section-4.2.2-2.2" class="pilcrow">¶</a>
+            <li id="section-4.2.1-2.2">The claim value object <span class="bcp14">MUST</span> contain an "idx" (index) member with a numeric value that represents the index to check for status information in the Status List for the current JWT. The value of this member <span class="bcp14">MUST</span> be a non-negative number, containing a value of zero or greater.<a href="#section-4.2.1-2.2" class="pilcrow">¶</a>
 </li>
-            <li id="section-4.2.2-2.3">The result of the gZIP compression is then base64url-encoded, as defined in Section 2 of <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>.<a href="#section-4.2.2-2.3" class="pilcrow">¶</a>
+            <li id="section-4.2.1-2.3">The claim value object <span class="bcp14">MUST</span> contain a "uri" member with a string value that identifies the Status List containing the status information for the JWT. The value of this member <span class="bcp14">MUST</span> be a uri conforming to <span>[<a href="#RFC3986" class="cite xref">RFC3986</a>]</span>.<a href="#section-4.2.1-2.3" class="pilcrow">¶</a>
 </li>
           </ol>
 </section>
diff --git a/draft-looker-oauth-jwt-cwt-status-list.txt b/draft-looker-oauth-jwt-cwt-status-list.txt
index 45e08fd..a616353 100644
--- a/draft-looker-oauth-jwt-cwt-status-list.txt
+++ b/draft-looker-oauth-jwt-cwt-status-list.txt
@@ -5,7 +5,7 @@
 Network Working Group                                          T. Looker
 Internet-Draft                                                     MATTR
 Intended status: Informational                                P. Bastian
-Expires: 11 January 2024                                    10 July 2023
+Expires: 18 January 2024                                    17 July 2023
 
 
                         JWT and CWT Status List
@@ -46,7 +46,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 11 January 2024.
+   This Internet-Draft will expire on 18 January 2024.
 
 Copyright Notice
 
@@ -66,11 +66,11 @@ Table of Contents
    2.  Conventions and Definitions
    3.  Terminology
    4.  JSON Web Token Representation
-     4.1.  Referenced Token Format and Processing Requirements
-       4.1.1.  Status Claim Format
-     4.2.  Status List JWT Format and Processing Requirements
-       4.2.1.  Status List Claim Format
-       4.2.2.  Status List Encoding
+     4.1.  Status List JWT Format and Processing Requirements
+       4.1.1.  Status List Claim Format
+       4.1.2.  Status List Encoding
+     4.2.  Referenced Token Format and Processing Requirements
+       4.2.1.  Status Claim Format
    5.  Status Types
      5.1.  Status Types Values
    6.  Example JWT Status Lists
@@ -175,58 +175,7 @@ Table of Contents
 
 4.  JSON Web Token Representation
 
-4.1.  Referenced Token Format and Processing Requirements
-
-   The following rules apply to validating a Referenced Token in JWT
-   representation, which references a Status List Token.  Application of
-   additional restrictions and policy are at the discretion of the
-   verifying party.
-
-   1.  The JWT MUST contain an "iss" (issuer) claim that contains a
-       unique string identifier for the entity that issued the JWT.  In
-       the absence of an application profile specifying otherwise,
-       compliant applications MUST compare issuer values using the
-       Simple String Comparison method defined in Section 6.2.1 of
-       [RFC3986].  The value MUST be equal to that of the "iss" claim
-       contained within the referenced Status List Token.
-
-   2.  The JWT MUST contain an "status" (status) claim conforming to the
-       rules outlined in Section 4.1.1
-
-   The following example is the decoded header and payload of a JWT
-   meeting the processing rules as defined above.
-
-   {
-     "alg": "ES256",
-     "kid": "11"
-   }
-   .
-   {
-     "iss": "https://example.com",
-     "status": {
-       "idx": 0,
-       "uri": "https://example.com/statuslists/1"
-     }
-   }
-
-4.1.1.  Status Claim Format
-
-   The following rules apply to validating the "status" (status) claim
-
-   1.  The claim value MUST be a valid JSON object.
-
-   2.  The claim value object MUST contain an "idx" (index) member with
-       a numeric value that represents the index to check for status
-       information in the Status List for the current JWT.  The value of
-       this member MUST be a non-negative number, containing a value of
-       zero or greater.
-
-   3.  The claim value object MUST contain a "uri" member with a string
-       value that identifies the Status List containing the status
-       information for the JWT.  The value of this member MUST be a uri
-       conforming to [RFC3986].
-
-4.2.  Status List JWT Format and Processing Requirements
+4.1.  Status List JWT Format and Processing Requirements
 
    The following rules apply to validating a JWT-based Status List
    Token.  Application of additional restrictions and policy are at the
@@ -249,7 +198,7 @@ Table of Contents
        the time at which it was issued.
 
    4.  The JWT MUST contain an "status_list" (status list) claim
-       conforming to the rules outlined in Section 4.2.1.
+       conforming to the rules outlined in Section 4.1.1.
 
    5.  The JWT MAY contain an "exp" (expiration time) claim that conveys
        when it is considered expired by its issuer.
@@ -281,7 +230,7 @@ Table of Contents
      }
    }
 
-4.2.1.  Status List Claim Format
+4.1.1.  Status List Claim Format
 
    The following rules apply to validating the "status_list" (status
    list) claim
@@ -296,9 +245,9 @@ Table of Contents
    3.  The claim value object MUST contain a "lst" (list) member with a
        string value that represents the status values for all the tokens
        it conveys statuses for.  The value MUST be computed using the
-       algorithm described in Section 4.2.2.
+       algorithm described in Section 4.1.2.
 
-4.2.2.  Status List Encoding
+4.1.2.  Status List Encoding
 
    Each status of a Referenced Token MUST be represented with a bit size
    of 1,2,4, or 8.  Therefore up to 2,4,16, or 256 statuses for a
@@ -322,6 +271,57 @@ Table of Contents
    3.  The result of the gZIP compression is then base64url-encoded, as
        defined in Section 2 of [RFC7515].
 
+4.2.  Referenced Token Format and Processing Requirements
+
+   The following rules apply to validating a Referenced Token in JWT
+   representation, which references a Status List Token.  Application of
+   additional restrictions and policy are at the discretion of the
+   verifying party.
+
+   1.  The JWT MUST contain an "iss" (issuer) claim that contains a
+       unique string identifier for the entity that issued the JWT.  In
+       the absence of an application profile specifying otherwise,
+       compliant applications MUST compare issuer values using the
+       Simple String Comparison method defined in Section 6.2.1 of
+       [RFC3986].  The value MUST be equal to that of the "iss" claim
+       contained within the referenced Status List Token.
+
+   2.  The JWT MUST contain an "status" (status) claim conforming to the
+       rules outlined in Section 4.2.1
+
+   The following example is the decoded header and payload of a JWT
+   meeting the processing rules as defined above.
+
+   {
+     "alg": "ES256",
+     "kid": "11"
+   }
+   .
+   {
+     "iss": "https://example.com",
+     "status": {
+       "idx": 0,
+       "uri": "https://example.com/statuslists/1"
+     }
+   }
+
+4.2.1.  Status Claim Format
+
+   The following rules apply to validating the "status" (status) claim
+
+   1.  The claim value MUST be a valid JSON object.
+
+   2.  The claim value object MUST contain an "idx" (index) member with
+       a numeric value that represents the index to check for status
+       information in the Status List for the current JWT.  The value of
+       this member MUST be a non-negative number, containing a value of
+       zero or greater.
+
+   3.  The claim value object MUST contain a "uri" member with a string
+       value that identifies the Status List containing the status
+       information for the JWT.  The value of this member MUST be a uri
+       conforming to [RFC3986].
+
 5.  Status Types
 
    This document defines potential statuses of Referenced Tokens as
diff --git a/index.html b/index.html
index eab1802..2a4aace 100644
--- a/index.html
+++ b/index.html
@@ -54,7 +54,7 @@ <h2>Preview for branch <a href="draft-looker-oauth-jwt-cwt-status-list-01">draft
       <tr>
         <td><a href="draft-looker-oauth-jwt-cwt-status-list-01/draft-looker-oauth-jwt-cwt-status-list.html" class="html draft-looker-oauth-jwt-cwt-status-list" title="JWT and CWT Status List (HTML)">JWT and CWT Status List</a></td>
         <td><a href="draft-looker-oauth-jwt-cwt-status-list-01/draft-looker-oauth-jwt-cwt-status-list.txt" class="txt draft-looker-oauth-jwt-cwt-status-list" title="JWT and CWT Status List (Text)">plain text</a></td>
-        <td>same as main</td>
+        <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://vcstuff.github.io/draft-looker-oauth-jwt-cwt-status-list/draft-looker-oauth-jwt-cwt-status-list.txt&amp;url_2=https://vcstuff.github.io/draft-looker-oauth-jwt-cwt-status-list/draft-looker-oauth-jwt-cwt-status-list-01/draft-looker-oauth-jwt-cwt-status-list.txt" class="diff draft-looker-oauth-jwt-cwt-status-list">diff with main</a></td>
       </tr>
     </table>
     <script>