-
-
-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 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.¶
-
-- 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.¶
-
- - The complete byte array is compressed using gZIP [RFC1952].¶
+
- 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.¶
- - The result of the gZIP compression is then base64url-encoded, as defined in Section 2 of [RFC7515].¶
+
- 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].¶
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 @@