Skip to content

Commit

Permalink
Script updating gh-pages from 21dc0f1. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Jan 22, 2024
1 parent 7f05f66 commit a996982
Show file tree
Hide file tree
Showing 2 changed files with 26 additions and 12 deletions.
16 changes: 10 additions & 6 deletions c2bo/status-reference/draft-ietf-oauth-status-list.html
Original file line number Diff line number Diff line change
Expand Up @@ -1031,7 +1031,7 @@
</tr></thead>
<tfoot><tr>
<td class="left">Looker, et al.</td>
<td class="center">Expires 22 July 2024</td>
<td class="center">Expires 25 July 2024</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -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-01-19" class="published">19 January 2024</time>
<time datetime="2024-01-22" class="published">22 January 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-07-22">22 July 2024</time></dd>
<dd class="expires"><time datetime="2024-07-25">25 July 2024</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -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 22 July 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 25 July 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1322,6 +1322,7 @@ <h3 id="name-rationale">
</h3>
<p id="section-1.1-1">Revocation mechanisms are an essential part for most identity ecosystems. In the past, revocation of X.509 TLS certificates has been proven difficult. Traditional certificate revocation lists (CRLs) have limited scalability; Online Certificate Status Protocol (OCSP) has additional privacy risks, since the client is leaking the requested website to a third party. OCSP stapling is addressing some of these problems at the cost of less up-to-date data. Modern approaches use accumulator-based revocation registries and Zero-Knowledge-Proofs to accommodate for this privacy gap, but face scalability issues again.<a href="#section-1.1-1" class="pilcrow"></a></p>
<p id="section-1.1-2">This specification seeks to find a balance between scalability, security, and privacy by minimizing the status information to mere bits (often a single bit) and compressing the resulting binary data. Thereby, a Status List may contain statuses of many thousands or millions Referenced Tokens while remaining as small as possible. Placing large amounts of Referenced Tokens into the same list also enables herd privacy relative to the Issuer.<a href="#section-1.1-2" class="pilcrow"></a></p>
<p id="section-1.1-3">There will likely be different mechanisms to convey token/credential status information in the foreseeable future depending on specific use-cases and their requirements. The way this information is transported in the token is defined with possible re-use or extension in mind.<a href="#section-1.1-3" class="pilcrow"></a></p>
</section>
</div>
<div id="design-considerations">
Expand Down Expand Up @@ -1351,6 +1352,9 @@ <h3 id="name-design-considerations">
</li>
<li class="normal" id="section-1.2-2.7">
<p id="section-1.2-2.7.1">the specification shall not specify key resolution or trust frameworks<a href="#section-1.2-2.7.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1.2-2.8">
<p id="section-1.2-2.8.1">the specification shall design a mechanism to convey information about the validity status of a token/credential that can be re-used/expanded upon<a href="#section-1.2-2.8.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
Expand Down Expand Up @@ -1598,7 +1602,7 @@ <h3 id="name-referenced-token-in-jwt-for">
<p id="section-6.1-3.1.1"><code>iss</code>: <span class="bcp14">REQUIRED</span>. The <code>iss</code> (issuer) claim <span class="bcp14">MUST</span> specify a unique string identifier for the entity that issued the Referenced Token. 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 <code>iss</code> claim contained within the referenced Status List Token.<a href="#section-6.1-3.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-6.1-3.2">
<p id="section-6.1-3.2.1"><code>status</code>: <span class="bcp14">REQUIRED</span>. The <code>status</code> (status) claim <span class="bcp14">MUST</span> specify a JSON Object that contains a reference to a status mechanism.<a href="#section-6.1-3.2.1" class="pilcrow"></a></p>
<p id="section-6.1-3.2.1"><code>status</code>: <span class="bcp14">REQUIRED</span>. The <code>status</code> (status) claim <span class="bcp14">MUST</span> specify a JSON Object that contains at least one reference to a status mechanism.<a href="#section-6.1-3.2.1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-6.1-3.2.2.1">
<p id="section-6.1-3.2.2.1.1"><code>status_list</code>: <span class="bcp14">REQUIRED</span> when the status list mechanism defined in this specification is used. It contains a reference to a Status List or Status List Token. The object contains exactly two claims:<a href="#section-6.1-3.2.2.1.1" class="pilcrow"></a></p>
Expand Down Expand Up @@ -1930,7 +1934,7 @@ <h3 id="name-json-web-token-claims-regis">
<p id="section-13.1-2.1.1">Claim Name: <code>status</code><a href="#section-13.1-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.1-2.2">
<p id="section-13.1-2.2.1">Claim Description: Reference to a status list containing up-to-date status information on the JWT.<a href="#section-13.1-2.2.1" class="pilcrow"></a></p>
<p id="section-13.1-2.2.1">Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the JWT.<a href="#section-13.1-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-13.1-2.3">
<p id="section-13.1-2.3.1">Change Controller: IETF<a href="#section-13.1-2.3.1" class="pilcrow"></a></p>
Expand Down
22 changes: 16 additions & 6 deletions c2bo/status-reference/draft-ietf-oauth-status-list.txt
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,9 @@
Network Working Group T. Looker
Internet-Draft MATTR
Intended status: Informational P. Bastian
Expires: 22 July 2024
Expires: 25 July 2024
C. Bormann
19 January 2024
22 January 2024


Token Status List
Expand Down Expand Up @@ -48,7 +48,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 22 July 2024.
This Internet-Draft will expire on 25 July 2024.

Copyright Notice

Expand Down Expand Up @@ -186,6 +186,12 @@ Table of Contents
Placing large amounts of Referenced Tokens into the same list also
enables herd privacy relative to the Issuer.

There will likely be different mechanisms to convey token/credential
status information in the foreseeable future depending on specific
use-cases and their requirements. The way this information is
transported in the token is defined with possible re-use or extension
in mind.

1.2. Design Considerations

The decisions taken in this specification aim to achieve the
Expand All @@ -210,6 +216,10 @@ Table of Contents
* the specification shall not specify key resolution or trust
frameworks

* the specification shall design a mechanism to convey information
about the validity status of a token/credential that can be re-
used/expanded upon

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Expand Down Expand Up @@ -431,7 +441,7 @@ Table of Contents
the referenced Status List Token.

* status: REQUIRED. The status (status) claim MUST specify a JSON
Object that contains a reference to a status mechanism.
Object that contains at least one reference to a status mechanism.

- status_list: REQUIRED when the status list mechanism defined in
this specification is used. It contains a reference to a
Expand Down Expand Up @@ -736,8 +746,8 @@ Table of Contents

* Claim Name: status

* Claim Description: Reference to a status list containing up-to-
date status information on the JWT.
* Claim Description: Reference to a status or validity mechanism
containing up-to-date status information on the JWT.

* Change Controller: IETF

Expand Down

0 comments on commit a996982

Please sign in to comment.