Internet-Draft | JWT and CWT Status List | June 2023 |
Looker & Bastian | Expires 21 December 2023 | [Page] |
This specification defines a status list representation and processing rules for usage with JSON Web Tokens [RFC7519] and CBOR Web Tokens [RFC8392].¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://vcstuff.github.io/draft-looker-oauth-jwt-cwt-status-list/draft-looker-oauth-jwt-cwt-status-list.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/.¶
Source for this draft and an issue tracker can be found at https://github.com/vcstuff/draft-looker-oauth-jwt-cwt-status-list.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any 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 21 December 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
JSON Web Tokens (JWTs) [RFC7519] and CBOR Web Tokens (CWTs) [RFC8392] as secure token formats, 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.¶
This document defines a Status List in JWT and CWT representations that describes the individual statuses of multiple Referenced Tokens. 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 which represents a position within this bit array and the value of the bit(s) at this position correspond to the Referenced Token's status. The document also defines how an issuer of a Referenced Token in JWT or CWT representation references a Status List Token. Status Lists may be composed for expressing a range of Status Types, the document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types. The Status List Token may be used by an issuer in the Issuer-Holder-Verifier model, as described in (XXX) to express the status of verifiable credentials (Referenced Tokens) issued by an issuer.¶
The following diagram depicts the basic conceptual relationship.¶
+------------------+ +-------------------+ | | References | | | |------------------->| | | Referenced Token | | Status List Token | | (JWT/CWT Based) | | (JWT/CWT Based) | | | Describes Status | | | |<-------------------| | +------------------+ +-------------------+¶
Revocation mechanisms are an essential part for most identity ecosystems. In the past, revocation of X.509 TLS certificates has been proven difficult as traditional certificate revocation lists (CRLs) have limited scalability and the Online Certificate Status Protocol (OCSP) has additional privacy risks as 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.¶
The approach of this specification seeks to find a balance between scalability, security and privacy by minimizing the status information to mere bits and compressing the resulting binary data. Thereby a Status List may contain statuses of 100.000 or more Referenced Tokens, but still remain relatively small. Placing large amounts of Referenced Tokens into the same list also enables a herd privacy towards the Issuer.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Status List A bit array that lists the statuses of many Referenced Tokens.¶
Status List Token A token in JWT or CWT representation that contains a Status List.¶
Referenced Token A token in JWT or CWT representation which contains a reference to a Status List Token. The information from the contained Status List may give a verifier additional information about up-to-date status of the Referenced Token.¶
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.¶
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": { "bits": 1, "idx": 0, "uri": "https://example.com/statuslists/1" } }¶
The following rules apply to validating the "status" (status) claim¶
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.¶
{ "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_zvp..MAZLRLMQMAAAA" } }¶
The following rules apply to validating the "status_list" (status list) claim¶
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, depending on the bit-size, are possible. 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.¶
Example of a Status List representing the statuses of 16 Referenced Tokens (1-bit status type) with indices 0 to 15 (2 bytes):¶
status[0] = 1 status[1] = 0 status[2] = 0 status[3] = 1 status[4] = 1 status[5] = 1 status[6] = 0 status[7] = 1 status[8] = 1 status[9] = 1 status[10] = 0 status[11] = 0 status[12] = 0 status[13] = 1 status[14] = 0 status[15] = 1¶
These bits are concatenated:¶
byte 0 1 2 bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+... values |1|0|1|1|1|0|0|1| |1|0|1|0|0|0|1|1| |0|... +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+... index 7 6 5 4 3 2 1 0 15 ... 10 9 8 23 \_______________/ \_______________/ 0xB9 0xA3¶
Resulting in the byte array:¶
byte_array = [0xB9, 0xA3]¶
After compression and Base64URL encoding the generated Status List is:¶
"status_list": { "bits": 1, "lst": "H4sIAMo_jGQC_9u5GABc9QE7AgAAAA" }¶
Example of a more complex status list of length 12 using 2 bit statuses (3 bytes):¶
status[0] = 1 status[1] = 2 status[2] = 0 status[3] = 3 status[4] = 0 status[5] = 1 status[6] = 0 status[7] = 1 status[8] = 1 status[9] = 2 status[10] = 3 status[11] = 3¶
These bits are concatenated:¶
byte 0 1 2 bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ values |1|1|0|0|1|0|0|1| |0|1|0|0|0|1|0|0| |1|1|1|1|1|0|0|1| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / status 3 0 2 1 1 0 1 0 3 3 2 1 index 3 2 1 0 7 6 5 4 11 10 9 8 \___________/ \___________/ \___________/ 0xC9 0x44 0xF9¶
Resulting in the byte array:¶
byte_array = [0xC9, 0x44, 0xF9]¶
After compression and Base64URL encoding the generated Status List is:¶
"status_list": { "bits": 2, "lst": "H4sIAMo_jGQC_zvp8hMAZLRLMQMAAAA" }¶
This document defines the possible statuses of Referenced Tokens as Status Type values. If the Status List contains more than one bit per token (as defined by "bits" in the Status List) then the whole value of bits MUST describe one value. A Status List can not encompass multiple statuses per individual bits for a Reference Token.¶
The registry in this document describes the basic Status Type values required for the most common use cases. The registry may be extended as describes in XXX.¶
A status describes the state, mode, condition or stage of an entity that is described by the status list. Status Types MUST be numeric based values between 0 and 255. Status types described by this specification comprise: 0x00 - "VALID" - The status of the Token is valid, correct or legal. 0x01 - "INVALID" - The status of the Token is revoked, annulled, taken back, recalled or cancelled. This state is irreversible. 0x02 - "SUSPENDED" - The status of the Token is temporarily invalid, hanging, debarred from privilege. This state is reversible.¶
The issuer of the Status List Token MUST choose an adequate "bits" (bit size) to be able to describe the required Status Types.ST be used for the "typ" attribute within the "status_list".¶
In the first example the Status List shall be used as a revocation list. It only requires the Status Types "VALID" and "INVALID", therefore a "bits" of 1 is sufficient.¶
In the second example the Status List shall additionally include the Status Type "SUSPENDED. As the Status Type value for "SUSPENDED" is 0x02 and doe snot fit into 1 bit, the "bits" is required to be 2.¶
TODO elaborate on risks of incorrect parsing/decoding leading to erroneous status data¶
TODO consumers/Verifiers of the status list should be aware if they fetch the up-to-date data¶
TODO elaborate on herd privacy, size of the status list¶
TODO elaborate on Verifiers regularly fetching the status list to create a profile, possible countermeasures with authorized access to the status list¶
TODO elaborate on Issuer-Verifier correlation and Verifier-Verifier correlation as the status list introduces unique,trackable data TODO elaborate on issuers avoiding sequential usage of indices and status lists TODO elaborate that a status list only gives information about the maximum number of possible statuses that a list conveys, issuers are recommended to pre-allocate lists, use dead entries that are never assigned or other obfuscation mechanisms¶
TODO elaborate on issuers generating unique status lists per Referenced Token that do not offer herd privacy¶
TODO elaborate on increased privacy if the status list is hosted by a third party instead of the issuer reducing tracking possiblities TODO evaluate deifnition of Status List Provider? An entity that hosts the Status List as a resource for potential verifiers. The Status List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party.¶
This document has no IANA actions.¶
TODO acknowledge.¶
-00¶