Web Authorization Protocol T. Looker Internet-Draft MATTR Intended status: Informational P. Bastian Expires: 6 August 2025 C. Bormann SPRIND 2 February 2025 Token Status List draft-ietf-oauth-status-list-07 Abstract This specification defines a mechanism, data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web Token and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://oauth- wg.github.io/draft-ietf-oauth-status-list/draft-ietf-oauth-status- list.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/draft-ietf-oauth-status-list. Status of This Memo 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/. Looker, et al. Expires 6 August 2025 [Page 1] Internet-Draft Token Status List February 2025 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 6 August 2025. Copyright Notice Copyright (c) 2025 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Example Use Cases . . . . . . . . . . . . . . . . . . . . 6 1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Design Considerations . . . . . . . . . . . . . . . . . . 6 1.4. Prior Work . . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Status Mechanisms Registry . . . . . . . . . . . . . . . 7 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Status List . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Status List in JSON Format . . . . . . . . . . . . . . . 10 4.2. Status List in CBOR Format . . . . . . . . . . . . . . . 11 5. Status List Token . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Status List Token in JWT Format . . . . . . . . . . . . . 12 5.2. Status List Token in CWT Format . . . . . . . . . . . . . 14 6. Referenced Token . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Status Claim . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Referenced Token in JOSE . . . . . . . . . . . . . . . . 16 6.3. Referenced Token in COSE . . . . . . . . . . . . . . . . 18 7. Status Types . . . . . . . . . . . . . . . . . . . . . . . . 23 7.1. Status Types Values . . . . . . . . . . . . . . . . . . . 24 8. Verification and Processing . . . . . . . . . . . . . . . . . 24 8.1. Status List Request . . . . . . . . . . . . . . . . . . . 24 8.2. Status List Response . . . . . . . . . . . . . . . . . . 25 8.3. Validation Rules . . . . . . . . . . . . . . . . . . . . 26 8.4. Historical resolution . . . . . . . . . . . . . . . . . . 27 Looker, et al. Expires 6 August 2025 [Page 2] Internet-Draft Token Status List February 2025 9. Status List Aggregation . . . . . . . . . . . . . . . . . . . 28 9.1. Issuer Metadata . . . . . . . . . . . . . . . . . . . . . 29 9.2. Status List Parameter . . . . . . . . . . . . . . . . . . 29 9.3. Status List Aggregation in JSON Format . . . . . . . . . 29 10. X.509 Certificate Extensions . . . . . . . . . . . . . . . . 30 10.1. Extended Key Usage Extension . . . . . . . . . . . . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11.1. Correct decoding and parsing of the encoded Status List . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.2. Security Guidance for JWT and CWT . . . . . . . . . . . 31 11.3. Key Resolution and Trust Management . . . . . . . . . . 31 11.4. Status List Caching . . . . . . . . . . . . . . . . . . 32 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 12.1. Observability of Issuers . . . . . . . . . . . . . . . . 33 12.2. Malicious Issuers . . . . . . . . . . . . . . . . . . . 34 12.3. Observability of Relying Parties . . . . . . . . . . . . 34 12.4. Observability of Outsiders . . . . . . . . . . . . . . . 35 12.5. Unlinkability . . . . . . . . . . . . . . . . . . . . . 35 12.5.1. Colluding Relying Parties . . . . . . . . . . . . . 35 12.5.2. Colluding Status Issuer and Relying Party . . . . . 36 12.6. External Status Provider for Privacy . . . . . . . . . . 36 12.7. Historical Resolution . . . . . . . . . . . . . . . . . 36 12.8. Status Types . . . . . . . . . . . . . . . . . . . . . . 37 13. Implementation Considerations . . . . . . . . . . . . . . . . 37 13.1. Referenced Token Lifecycle . . . . . . . . . . . . . . . 37 13.2. Default Values and Double Allocation . . . . . . . . . . 38 13.3. Status List Size . . . . . . . . . . . . . . . . . . . . 38 13.4. External Status Issuer . . . . . . . . . . . . . . . . . 38 13.5. External Status Provider for Scalability . . . . . . . . 39 13.6. Relying Parties avoiding correlatable Information . . . 39 13.7. Status List Formats . . . . . . . . . . . . . . . . . . 39 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 14.1. JSON Web Token Claims Registration . . . . . . . . . . . 40 14.1.1. Registry Contents . . . . . . . . . . . . . . . . . 40 14.2. JWT Status Mechanisms Registry . . . . . . . . . . . . . 40 14.2.1. Registration Template . . . . . . . . . . . . . . . 41 14.2.2. Initial Registry Contents . . . . . . . . . . . . . 42 14.3. CBOR Web Token Claims Registration . . . . . . . . . . . 42 14.3.1. Registry Contents . . . . . . . . . . . . . . . . . 42 14.4. CWT Status Mechanisms Registry . . . . . . . . . . . . . 43 14.4.1. Registration Template . . . . . . . . . . . . . . . 44 14.4.2. Initial Registry Contents . . . . . . . . . . . . . 44 14.5. OAuth Status Types Registry . . . . . . . . . . . . . . 44 14.5.1. Registration Template . . . . . . . . . . . . . . . 45 14.5.2. Initial Registry Contents . . . . . . . . . . . . . 46 14.6. OAuth Parameters Registration . . . . . . . . . . . . . 47 14.7. Media Type Registration . . . . . . . . . . . . . . . . 47 Looker, et al. Expires 6 August 2025 [Page 3] Internet-Draft Token Status List February 2025 14.8. X.509 Certificate Extended Key Purpose OID Registration . . . . . . . . . . . . . . . . . . . . . . 49 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 15.1. Normative References . . . . . . . . . . . . . . . . . . 49 15.2. Informative References . . . . . . . . . . . . . . . . . 52 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 53 Test vectors for Status List encoding . . . . . . . . . . . . . . 53 1 bit Status List . . . . . . . . . . . . . . . . . . . . . . . 53 2 bit Status List . . . . . . . . . . . . . . . . . . . . . . . 54 4 bit Status List . . . . . . . . . . . . . . . . . . . . . . . 55 8 bit Status List . . . . . . . . . . . . . . . . . . . . . . . 56 Document History . . . . . . . . . . . . . . . . . . . . . . . . 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 1. Introduction Token formats secured by JOSE [IANA.JOSE] or COSE [RFC9052], such as JWTs [RFC7519], SD-JWT VCs [SD-JWT.VC], CWTs [RFC8392] and ISO mdoc [ISO.mdoc], have vast possible applications. Some of these applications can involve issuing a token whereby certain semantics about the token or its validity may change over time. Communicating these changes to relying parties in an interoperable manner, such as whether the token is considered invalidated or suspended by its issuer is important for many of these applications. This document defines a Status List data structure that describes the individual statuses of multiple Referenced Tokens. A Referenced Token may be of any format, but is most commonly a data structures secured by JOSE or COSE. The Referenced Token is referenced by the Status List, which describes the status of the Referenced Token. 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 corresponds to the Referenced Token's status. A Status List is provided within a Status List Token protected by cryptographic signature or MAC and this document defines its representations in JWT and CWT format. The following diagram depicts the relationship between the artifacts: Looker, et al. Expires 6 August 2025 [Page 4] Internet-Draft Token Status List February 2025 ┌────────────────┐ describes status ┌──────────────────┐ │ Status List ├──────────────────►│ Referenced Token │ │ (JSON or CBOR) │◄──────────────────┤ (JOSE, COSE, ..) │ └─────┬──────────┘ references └──────────────────┘ │ │ embedded in ▼ ┌───────────────────┐ │ Status List Token │ │ (JWT or CWT) │ └───────────────────┘ An Issuer issues Referenced Tokens to a Holder, the Holder uses and presents those Referenced Tokens to a Relying Party. The Issuer gives updated status information to the Status Issuer, who creates a Status List Token. The Status Issuer provides the Status List Token to the Status Provider, who serves the Status List Token on a public, resolvable endpoint. The roles of the Issuer (of the Referenced Token), the Status Issuer and the Status Provider may be fulfilled by the same entity. If not further specified, the term Issuer may refer to an entity acting for all three roles. This document describes how an Issuer references a Status List Token and how a Relying Party fetches and validates Status Lists. The following diagram depicts the relationship between the involved roles (Relying Party is equivalent to Verifier of [SD-JWT.VC]): issue present Referenced Referenced ┌────────┐ Token ┌────────┐ Token ┌───────────────┐ │ Issuer ├───────────►│ Holder ├───────────►│ Relying Party │ └─┬──────┘ └────────┘ └──┬────────────┘ ▼ update status │ ┌───────────────┐ │ │ Status Issuer │ │ └─┬─────────────┘ │ ▼ provide Status List │ ┌─────────────────┐ fetch Status List │ │ Status Provider │◄───────────────────────────┘ └─────────────────┘ Status Lists may be composed to express 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. Furthermore, the document defines an extension point that enables other specifications to describe additional status mechanisms and creates an IANA registry. Looker, et al. Expires 6 August 2025 [Page 5] Internet-Draft Token Status List February 2025 1.1. Example Use Cases An example of the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of [RFC6749]. Token Introspection [RFC7662] defines another way to determine the status of an issued access token, but it requires the party trying to validate the state of access tokens to directly contact the token issuer, whereas the mechanism defined in this specification does not have this limitation. 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 [SD-JWT.VC]. 1.2. Rationale Revocation mechanisms are an essential part of 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. Another alternative is short-lived Referenced Tokens with regular re-issuance, but this puts additional burden on the Issuer's infrastructure. 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 Status Provider. 1.3. Design Considerations The decisions taken in this specification aim to achieve the following design goals: * the specification shall favor a simple and easy-to-understand concept * the specification shall be easy, fast and secure to implement in all major programming languages Looker, et al. Expires 6 August 2025 [Page 6] Internet-Draft Token Status List February 2025 * the specification shall be optimized to support the most common use cases and avoid unnecessary complexity of corner cases * the Status List shall scale up to millions of tokens to support large-scale government or enterprise use cases * the Status List shall enable caching policies and offline support * the specification shall support JSON and CBOR based tokens * the specification shall not specify key resolution or trust frameworks * the specification shall define an extension point that enables other mechanisms to convey information about the status of a Referenced Token 1.4. Prior Work Representing a status with bits in array is a rather old and well- known concept in computer science and there has been prior work to use this for revocation and status management such as a paper by Smith et al. [smith2020let] that proposed a mechanism called Certificate Revocation Vectors based on xz compressed bit vectors for each expiration day and the W3C bit Status List [W3C.SL] that similarly uses a compressed bit representation. 1.5. Status Mechanisms Registry This specification establishes the IANA "Status Mechanisms" registry for status mechanisms and registers the members defined by this specification. Other specifications can register other members used for status retrieval. Other status mechanisms may have different tradeoffs regarding security, privacy, scalability and complexity. The privacy and security considerations in this document only represent the properties of the Status List mechanism. 2. Conventions and Definitions 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. Looker, et al. Expires 6 August 2025 [Page 7] Internet-Draft Token Status List February 2025 3. Terminology Issuer: An entity that issues the Referenced Token. Status Issuer: An entity that issues the Status List Token about the status information of the Referenced Token. This role may be fulfilled by the Issuer. Status Provider: An entity that provides the Status List Token on a public endpoint. This role may be fulfilled by the Status Issuer. Holder: An entity that receives Referenced Tokens from the Issuer and presents them to Relying Parties. Relying Party: An entity that relies on the Referenced Token and fetches the corresponding Status List Token to validate the status of that Referenced Token. Also known as Verifier. Status List: An object in JSON or CBOR representation containing a bit array that lists the statuses of many Referenced Tokens. Status List Token: A token in JWT or CWT representation that contains a cryptographically secured Status List. Referenced Token: A cryptographically secured data structure that contains a reference to a Status List Token. It is RECOMMENDED to use JSON [RFC8259] with JOSE as defined in [RFC7515] or CBOR [RFC8949] with COSE as defined in [RFC9052]. The information from the contained Status List gives the Relying Party additional information about the current status of the Referenced Token. Examples for Referenced Tokens are SD-JWT VC and ISO mdoc. base64url: Denotes the URL-safe base64 encoding without padding as defined in Section 2 of [RFC7515] as "Base64url Encoding". 4. Status List A Status List is a byte array that contains the statuses of many Referenced Tokens represented by one or multiple bits. A common representation of a Status List is composed by the following algorithm: 1. 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. Looker, et al. Expires 6 August 2025 [Page 8] Internet-Draft Token Status List February 2025 2. The overall Status List is encoded as a byte array. Depending on the bit-size, 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 the 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. 3. The byte array is compressed using DEFLATE [RFC1951] with the ZLIB [RFC1950] data format. Implementations are RECOMMENDED to use the highest compression level available. The following example illustrates a Status List that represents the statuses of 16 Referenced Tokens, requiring 16 bits (2 bytes) for the uncompressed byte array (1 bit status): 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 Looker, et al. Expires 6 August 2025 [Page 9] Internet-Draft Token Status List February 2025 In this example, the Status List additionally includes the Status Type "SUSPENDED". As the Status Type value for "SUSPENDED" is 0x02 and does not fit into 1 bit, the "bits" is required to be 2. This example Status List represents the status of 12 Referenced Tokens, requiring 24 bits (3 bytes) of status (2 bit status): 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 4.1. Status List in JSON Format This section defines the data structure for a JSON-encoded Status List: * status_list: REQUIRED. JSON Object that contains a Status List. It MUST contain at least the following claims: - bits: REQUIRED. JSON Integer specifying the number of bits per Referenced Token in the Status List (lst). The allowed values for bits are 1,2,4 and 8. Looker, et al. Expires 6 August 2025 [Page 10] Internet-Draft Token Status List February 2025 - lst: REQUIRED. JSON String that contains the status values for all the Referenced Tokens it conveys statuses for. The value MUST be the base64url-encoded Status List as specified in Section 4. - aggregation_uri: OPTIONAL. JSON String that contains a URI to retrieve the Status List Aggregation for this type of Referenced Token or Issuer. See section Section 9 for further details. The following example illustrates the JSON representation of the Status List with bit-size 1 from the example above: byte_array = [0xb9, 0xa3] encoded: { "bits": 1, "lst": "eNrbuRgAAhcBXQ" } The following example illustrates the JSON representation of the Status List with bit-size 2 from the example above: byte_array = [0xc9, 0x44, 0xf9] encoded: { "bits": 2, "lst": "eNo76fITAAPfAgc" } See section Appendix "Test vectors for Status List encoding" for more test vectors. 4.2. Status List in CBOR Format This section defines the data structure for a CBOR-encoded Status List: * The StatusList structure is a map (Major Type 5) and defines the following entries: - bits: REQUIRED. Unsigned integer (Major Type 0) that contains the number of bits per Referenced Token in the Status List. The allowed values for bits are 1, 2, 4 and 8. - lst: REQUIRED. Byte string (Major Type 2) that contains the Status List as specified in Section 4. Looker, et al. Expires 6 August 2025 [Page 11] Internet-Draft Token Status List February 2025 - aggregation_uri: OPTIONAL. Text string (Major Type 3) that contains a URI to retrieve the Status List Aggregation for this type of Referenced Token. See section Section 9 for further detail. The following example illustrates the CBOR representation of the Status List in Hex: byte_array = [0xb9, 0xa3] encoded: a2646269747301636c73744a78dadbb918000217015d The following is the CBOR Annotated Hex output of the example above: a2 # map(2) 64 # string(4) 62697473 # "bits" 01 # uint(1) 63 # string(3) 6c7374 # "lst" 4a # bytes(10) 78dadbb918000217015d # "xÚÛ¹\x18\x00\x02\x17\x01]" See section Appendix "Test vectors for Status List encoding" for more test vectors. 5. Status List Token A Status List Token embeds the Status List into a token that is cryptographically signed and protects the integrity of the Status List. This allows for the Status List Token to be hosted by third parties or be transferred for offline use cases. This section specifies Status List Tokens in JSON Web Token (JWT) and CBOR Web Token (CWT) format. 5.1. Status List Token in JWT Format The Status List Token MUST be encoded as a "JSON Web Token (JWT)" according to [RFC7519]. The following content applies to the JWT Header: * typ: REQUIRED. The JWT type MUST be statuslist+jwt. The following content applies to the JWT Claims Set: Looker, et al. Expires 6 August 2025 [Page 12] Internet-Draft Token Status List February 2025 * sub: REQUIRED. As generally defined in [RFC7519]. The sub (subject) claim MUST specify the URI of the Status List Token. The value MUST be equal to that of the uri claim contained in the status_list claim of the Referenced Token. * iat: REQUIRED. As generally defined in [RFC7519]. The iat (issued at) claim MUST specify the time at which the Status List Token was issued. * exp: OPTIONAL. As generally defined in [RFC7519]. The exp (expiration time) claim, if present, MUST specify the time at which the Status List Token is considered expired by the Status Issuer. * ttl: OPTIONAL. The ttl (time to live) claim, if present, MUST specify the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved. The value of the claim MUST be a positive number encoded in JSON as a number. * status_list: REQUIRED. The status_list (status list) claim MUST specify the Status List conforming to the rules outlined in Section 4.1. The following additional rules apply: 1. The JWT MAY contain other claims. 2. The JWT MUST be secured using a cryptographic signature or MAC algorithm. Relying Parties MUST reject JWTs with an invalid signature. 3. Relying Parties MUST reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" [RFC7519]. 4. Application of additional restrictions and policies are at the discretion of the Relying Party. The following is a non-normative example of a Status List Token in JWT format: Looker, et al. Expires 6 August 2025 [Page 13] Internet-Draft Token Status List February 2025 { "alg": "ES256", "kid": "12", "typ": "statuslist+jwt" } . { "exp": 2291720170, "iat": 1686920170, "status_list": { "bits": 1, "lst": "eNrbuRgAAhcBXQ" }, "sub": "https://example.com/statuslists/1", "ttl": 43200 } 5.2. Status List Token in CWT Format The Status List Token MUST be encoded as a "CBOR Web Token (CWT)" according to [RFC8392]. The following content applies to the protected header of the CWT: * 16 (type): REQUIRED. The type of the CWT MUST be statuslist+cwt as defined in [RFC9596]. The following content applies to the CWT Claims Set: * 2 (subject): REQUIRED. As generally defined in [RFC8392]. The subject claim MUST specify the URI of the Status List Token. The value MUST be equal to that of the uri claim contained in the status_list claim of the Referenced Token. * 6 (issued at): REQUIRED. As generally defined in [RFC8392]. The issued at claim MUST specify the time at which the Status List Token was issued. * 4 (expiration time): OPTIONAL. As generally defined in [RFC8392]. The expiration time claim, if present, MUST specify the time at which the Status List Token is considered expired by its issuer. * 65534 (time to live): OPTIONAL. Unsigned integer (Major Type 0). The time to live claim, if present, MUST specify the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved. The value of the claim MUST be a positive number. Looker, et al. Expires 6 August 2025 [Page 14] Internet-Draft Token Status List February 2025 * 65533 (status list): REQUIRED. The status list claim MUST specify the Status List conforming to the rules outlined in Section 4.2. The following additional rules apply: 1. The CWT MAY contain other claims. 2. The CWT MUST be secured using a cryptographic signature or MAC algorithm. Relying Parties MUST reject CWTs with an invalid signature. 3. Relying Parties MUST reject CWTs that are not valid in all other respects per "CBOR Web Token (CWT)" [RFC8392]. 4. Application of additional restrictions and policies are at the discretion of the Relying Party. The following is a non-normative example of a Status List Token in CWT format in Hex: d28453a20126106e7374617475736c6973742b637774a1044231325850a502782168 747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f31061a 648c5bea041a8898dfea19fffe19a8c019fffda2646269747301636c73744a78dadb b918000217015d5840b973b7e73c75316630cc7c28caad342638a91c6b68299d59c4 dcbf9b6162b526e7e5511e54cf5453fc39180896a96f9107bf6a5cdb1cacc5589909 f0fc4bf023 The following is the CBOR Annotated Hex output of the example above: Looker, et al. Expires 6 August 2025 [Page 15] Internet-Draft Token Status List February 2025 d2 # tag(18) 84 # array(4) 53 # bytes(19) a20126106e7374617475736c # "¢\x01&\x10nstatusl" 6973742b637774 # "ist+cwt" a1 # map(1) 04 # uint(4) 42 # bytes(2) 3132 # "12" 58 50 # bytes(80) a502782168747470733a2f2f # "¥\x02x!https://" 6578616d706c652e636f6d2f # "example.com/" 7374617475736c697374732f # "statuslists/" 31061a648c5bea041a8898df # "1\x06\x1ad\x8c[ê\x04\x1a\x88\x98ß" ea19fffe19a8c019fffda264 # "ê\x19ÿþ\x19¨À\x19ÿý¢d" 6269747301636c73744a78da # "bits\x01clstJxÚ" dbb918000217015d # "Û¹\x18\x00\x02\x17\x01]" 58 40 # bytes(64) b973b7e73c75316630cc7c28 # "¹s·ç> ) >>, h'b7c2d4abe85aa5ba814ef95de0385c71c802be8ac33a4a971a85ed800ba7acb 59cb21035f4a68fc0caa450cbefd3b255aec72f83595f0ae7b7d50fe8a1c4cafe' ] 7. Status Types This document defines the statuses of Referenced Tokens as Status Type values. A status describes the state, mode, condition or stage of an entity that is represented by the Referenced Token. A Status List can not represent multiple statuses per Referenced Token. 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. Status Types MUST have a numeric value between 0 and 255 for their representation in the Status List. The issuer of the Status List MUST choose an adequate bits value (bit size) to be able to describe the required Status Types for its application. Looker, et al. Expires 6 August 2025 [Page 23] Internet-Draft Token Status List February 2025 7.1. Status Types Values This document creates a registry in Section 14.5 that includes the most common Status Type values. Additional values may defined for particular use cases. Status Types described by this document comprise: * 0x00 - "VALID" - The status of the Referenced Token is valid, correct or legal. * 0x01 - "INVALID" - The status of the Referenced Token is revoked, annulled, taken back, recalled or cancelled. * 0x02 - "SUSPENDED" - The status of the Referenced Token is temporarily invalid, hanging, debarred from privilege. This state is reversible. The Status Type value 0x03 and Status Type values in the range 0x0B until 0x0F are permanently reserved as application specific. Meaning the processing of Status Types using these values is application specific. All other Status Type values are reserved for future registration. The processing rules for Referenced Tokens (such as JWT or CWT) precede any evaluation of a Referenced Token's status. For example, if a token is evaluated as being expired through the "exp" (Expiration Time) but also has a status of 0x00 ("VALID"), the token is considered expired. See Section 12.8 for privacy considerations on status types. 8. Verification and Processing 8.1. Status List Request To obtain the Status List Token, the Relying Party MUST send an HTTP GET request to the URI provided in the Referenced Token. The HTTP endpoint SHOULD support the use of Cross-Origin Resource Sharing (CORS) [CORS] and/or other methods as appropriate to enable Browser-based clients to access it. The Relying Party SHOULD send the following Accept-Header to indicate the requested response type: * "application/statuslist+jwt" for Status List Token in JWT format * "application/statuslist+cwt" for Status List Token in CWT format Looker, et al. Expires 6 August 2025 [Page 24] Internet-Draft Token Status List February 2025 If the Relying Party does not send an Accept Header, the response type is assumed to be known implicitly or out-of-band. A successful response that contains a Status List Token MUST use an HTTP status code in the 2xx range. A response MAY also choose to redirect the client to another URI using an HTTP status code in the 3xx range, which clients SHOULD follow. A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops). The following are non-normative examples of a request and response for a Status List Token with type application/statuslist+jwt: GET /statuslists/1 HTTP/1.1 Host: example.com Accept: application/statuslist+jwt HTTP/1.1 200 OK Content-Type: application/statuslist+jwt eyJhbGciOiJFUzI1NiIsImtpZCI6IjEyIiwidHlwIjoic3RhdHVzbGlzdCtqd3QifQ.e yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI nR0bCI6NDMyMDB9.-bnvYY-t7smPXMU87krNWSB7i4t-IJ3OOwvpljf9cmxLN7ue-DvX jDwjOzClGDcl8YNf3NVnkxteSYACkWVAug 8.2. Status List Response In the successful response, the Status Provider MUST use the following content-type: * "application/statuslist+jwt" for Status List Token in JWT format * "application/statuslist+cwt" for Status List Token in CWT format In the case of "application/statuslist+jwt", the response MUST be of type JWT and follow the rules of Section 5.1. In the case of "application/statuslist+cwt", the response MUST be of type CWT and follow the rules of Section 5.2. The HTTP response SHOULD use gzip Content-Encoding as defined in [RFC9110]. Looker, et al. Expires 6 August 2025 [Page 25] Internet-Draft Token Status List February 2025 If caching-related HTTP headers are present in the HTTP response, Relying Parties SHOULD prioritize the exp and ttl claims within the Status List Token over the HTTP headers for determining caching behavior. 8.3. Validation Rules Upon receiving a Referenced Token, a Relying Party MUST first perform the validation of the Referenced Token - e.g., checking for expected attributes, valid signature and expiration time. The processing rules for Referenced Tokens (such as JWT or CWT) precede any evaluation of a Referenced Token's status. For example, if a token is evaluated as being expired through the "exp" (Expiration Time) but also has a status of 0x00 ("VALID"), the token is considered expired. As this is out of scope for this document, this validation is not described here, but is expected to be done according to the format of the Referenced Token. If this validation is not successful, the Referenced Token MUST be rejected. If the validation was successful, the Relying Party MUST perform the following validation steps to evaluate the status of the reference token: 1. Check for the existence of a status claim, check for the existence of a status_list claim within the status claim and validate that the content of status_list adheres to the rules defined in Section 6.2 for JOSE-based Referenced Tokens and Section 6.3 for COSE-based Referenced Tokens. Other formats of Referenced Tokens may define other encoding of the URI and index. 2. Resolve the Status List Token from the provided URI 3. Validate the Status List Token: 1. Validate the Status List Token by following the rules defined in section 7.2 of [RFC7519] for JWTs and section 7.2 of [RFC8392] for CWTs. This step might require the resolution of a public key as described in Section 11.3. 2. Check for the existence of the required claims as defined in Section 5.1 and Section 5.2 depending on the token type 4. All existing claims in the Status List Token MUST be checked according to the rules in Section 5.1 and Section 5.2 1. The subject claim (sub or 2) of the Status List Token MUST be equal to the uri claim in the status_list object of the Referenced Token Looker, et al. Expires 6 August 2025 [Page 26] Internet-Draft Token Status List February 2025 2. If the Relying Party has custom policies regarding the freshness of the Status List Token, it SHOULD check the issued at claim (iat or 6) 3. If the expiration time is defined (exp or 4), it MUST be checked if the Status List Token is expired 4. If the Relying Party is using a system for caching the Status List Token, it SHOULD check the ttl claim of the Status List Token and retrieve a fresh copy if (time status was resolved + ttl < current time) 5. Decompress the Status List with a decompressor that is compatible with DEFLATE [RFC1951] and ZLIB [RFC1950] 6. Retrieve the status value of the index specified in the Referenced Token as described in Section 4. Fail if the provided index is out of bounds of the Status List 7. Check the status value as described in Section 7 If any of these checks fails, no statement about the status of the Referenced Token can be made and the Referenced Token SHOULD be rejected. 8.4. Historical resolution By default, the status mechanism defined in this specification only conveys information about the state of Reference Tokens at the time the Status List Token was issued. The validity period for this information, as defined by the issuer, is explicitly stated by the iat (issued at) and exp (expiration time) claims for JWT and their corresponding ones for the CWT representation. If support for historical status information is required, this can be achieved by extending the request for the Status List Token as defined in Section 8.1 with a timestamp. This feature has additional privacy implications as described in Section 12.7. To obtain the Status List Token, the Relying Party MUST send an HTTP GET request to the URI provided in the Referenced Token with the additional query parameter time and its value being a unix timestamp. The response for a valid request SHOULD contain a Status List Token that was valid for that specified time or an error. If the Server does not support the additional query parameter, it SHOULD return a status code of 501 (Not Implemented) or if the requested time is not supported it SHOULD return a status code of 406 (Not Acceptable). A Status List Token might be served via static Looker, et al. Expires 6 August 2025 [Page 27] Internet-Draft Token Status List February 2025 file hosting (e.g., leveraging a Content Delivery Network), which would result in the client not being able to retrieve those status codes. Thus, the client MUST verify support for this feature by verifying that the requested timestamp is within the valid time of the returned token signaled via iat (6 for CWT) and exp (4 for CWT). The following is a non-normative example of a GET request using the time query parameter: GET /statuslists/1?time=1686925000 HTTP/1.1 Host: example.com Accept: application/statuslist+jwt The following is a non-normative example of a response for the above Request: HTTP/1.1 200 OK Content-Type: application/statuslist+jwt eyJhbGciOiJFUzI1NiIsImtpZCI6IjEyIiwidHlwIjoic3RhdHVzbGlzdCtqd3QifQ.e yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI nR0bCI6NDMyMDB9.-bnvYY-t7smPXMU87krNWSB7i4t-IJ3OOwvpljf9cmxLN7ue-DvX jDwjOzClGDcl8YNf3NVnkxteSYACkWVAug 9. Status List Aggregation Status List Aggregation is an optional mechanism to retrieve a list of URIs to all Status List Tokens, allowing a Relying Party to fetch all relevant Status Lists for a specific type of Referenced Token or Issuer. This mechanism is intended to support fetching and caching mechanisms and allow offline validation of the status of a reference token for a period of time. If a Relying Party encounters an invalid Status List referenced in the response from the Status List Aggregation endpoint, it SHOULD continue processing the other valid Status Lists referenced in the response. There are two options for a Relying Party to retrieve the Status List Aggregation. An Issuer MAY support any of these mechanisms: * Issuer metadata: The Issuer of the Referenced Token publishes an URI which links to Status List Aggregation, e.g. in publicly available metadata of an issuance protocol Looker, et al. Expires 6 August 2025 [Page 28] Internet-Draft Token Status List February 2025 * Status List Parameter: The Status Issuer includes an additional claim in the Status List Token that contains the Status List Aggregation URI. 9.1. Issuer Metadata The Issuer MAY link to the Status List Aggregation URI in metadata that can be provided by different means like .well-known metadata as is used commonly in OAuth and OpenID or via a VICAL extension for ISO mDoc / mDL. If the Issuer is an OAuth Authorization Server according to [RFC6749], it is RECOMMENDED to use status_list_aggregation_endpoint for its metadata defined by [RFC8414]. The concrete specification on how this is implemented depends on the specific ecosystem and is out of scope of this specification. 9.2. Status List Parameter The URI to the Status List Aggregation MAY be provided as the optional parameter aggregation_uri in the Status List itself as explained in Section 4.2 and Section 4.1 respectively. A Relying Party may use this URI to retrieve an up-to-date list of relevant Status Lists. 9.3. Status List Aggregation in JSON Format This section defines the structure for a JSON-encoded Status List Aggregation: * status_lists: REQUIRED. JSON array of strings that contains URIs linking to Status List Tokens. The Status List Aggregation URI provides a list of Status List URIs. This aggregation in JSON and the media type return SHOULD be application/json. A Relying Party can iterate through this list and fetch all Status List Tokens before encountering the specific URI in a Referenced Token. The following is a non-normative example for media type application/ json: Looker, et al. Expires 6 August 2025 [Page 29] Internet-Draft Token Status List February 2025 { "status_lists" : [ "https://example.com/statuslists/1", "https://example.com/statuslists/2", "https://example.com/statuslists/3" ] } 10. X.509 Certificate Extensions 10.1. Extended Key Usage Extension [RFC5280] specifies the Extended Key Usage (EKU) X.509 certificate extension for use on end entity certificates. The extension indicates one or more purposes for which the certified public key is valid. The EKU extension can be used in conjunction with the Key Usage (KU) extension, which indicates the set of basic cryptographic operations for which the certified key may be used. The following OID is defined for usage in the EKU extension ``` id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } id-kp-oauthStatusListSigning OBJECT IDENTIFIER ::= { id-kp TBD } ``` 11. Security Considerations The Status List as defined in Section 4 only exists in cryptographically secured containers which allows checking the integrity and origin without relying on other aspects like transport security (e.g., the web PKI). 11.1. Correct decoding and parsing of the encoded Status List Implementers should be particularly careful for the correct parsing and decoding of the Status List. Incorrect implementations might check the index on the wrong data or miscalculate the bit and byte index leading to an erroneous status of the Referenced Token. Beware, that bits are indexed (bit order) from least significant bit to most significant bit (also called "right to left") while bytes are indexed (byte order) in their natural incrementing byte order (usually written for display purpose from left to right). Endianness does not apply here because each status value fits within a single byte. Implementations are RECOMMENDED to verify correctness using the test vectors given by this specification. Looker, et al. Expires 6 August 2025 [Page 30] Internet-Draft Token Status List February 2025 11.2. Security Guidance for JWT and CWT A Status List Token in the JWT format should follow the security considerations of [RFC7519] and the best current practices of [RFC8725]. A Status List Token in the CWT format should follow the security considerations of [RFC8392]. 11.3. Key Resolution and Trust Management This specification does not mandate specific methods for key resolution and trust management, however the following recommendations are made: If the Issuer of the Referenced Token is the same entity as the Status Issuer, then the same key that is embedded into the Referenced Token may be used for the Status List Token. In this case the Status List Token may use: - the same x5c value or an x5t, x5t#S256 or kid parameter referencing to the same key as used in the Referenced Token for JOSE. - the same x5chain value or an x5t or kid parameter referencing to the same key as used in the Referenced Token for COSE. Alternatively, the Status Issuer may use the same web-based key resolution that is used for the Referenced Token. In this case the Status List Token may use: - an x5u, jwks, jwks_uri or kid parameter referencing to a key using the same web-based resolution as used in the Referenced Token for JOSE. - an x5u or kid parameter referencing to a key using the same web-based resolution as used in the Referenced Token for COSE. ┌────────┐ host keys ┌──────────────────────┐ │ Issuer ├────────┬───►│ .well-known metadata │ └─┬──────┘ │ └──────────────────────┘ ▼ update status │ ┌───────────────┐ │ │ Status Issuer ├─┘ └─┬─────────────┘ ▼ provide Status List ┌─────────────────┐ │ Status Provider │ └─────────────────┘ Looker, et al. Expires 6 August 2025 [Page 31] Internet-Draft Token Status List February 2025 If the Issuer of the Referenced Token is a different entity than the Status Issuer, then the keys used for the Status List Token may be cryptographically linked, e.g. by an Certificate Authority through an x.509 PKI. The certificate of the Issuer for the Referenced Token and the Status Issuer should be issued by the same Certificate Authority and the Status Issuer's certificate should utilize extended key usage (Section 10.1). ┌───────────────────────┐ │ Certificate Authority │ └─┬─────────────────────┘ │ authorize │ ┌────────┐ ├─►│ Issuer │ │ └─┬──────┘ │ ▼ update status │ ┌───────────────┐ └─►│ Status Issuer │ └─┬─────────────┘ ▼ provide Status List ┌─────────────────┐ │ Status Provider │ └─────────────────┘ 11.4. Status List Caching When fetching a Status List Token, Relying Parties must carefully evaluate how long a Status List is cached for. Collectively the iat, exp and ttl claims when present in a Status List Token communicate how long a Status List should be cached and should be considered valid for. The following diagram illustrates the relationship between these claims and how they are designed to influence caching. Looker, et al. Expires 6 August 2025 [Page 32] Internet-Draft Token Status List February 2025 Time of fetching │ │ Check for Check for Check for │ updates updates updates │ iat │ │ │ │ exp │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ttl │ ttl │ ttl │ │ │ │ ─────────────► │ ─────────────► │ ─────────────► │ ──► │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ──┼───────────────────────────────────────────────────────────────┼─► │ │ It is essential to understand the distinct purposes of the ttl and exp claims. The ttl claim represents a duration to be interpreted relative to the time the Status List is fetched, indicating when a new version of the Status List may be available. In contrast, the exp claim specifies an absolute timestamp, marking the point in time when the Status List expires and MUST NOT be relied upon any longer. Together, these claims provide guidance on when to check for updates (ttl claim) and when the Status List must be refreshed or replaced (exp claim). 12. Privacy Considerations 12.1. Observability of Issuers The main privacy consideration for a Status List, especially in the context of the Issuer-Holder-Verifier model [SD-JWT.VC], is to prevent the Issuer from tracking the usage of the Referenced Token when the status is being checked. If an Issuer offers status information by referencing a specific token, this would enable him to create a profile for the issued token by correlating the date and identity of Relying Parties, that are requesting the status. Looker, et al. Expires 6 August 2025 [Page 33] Internet-Draft Token Status List February 2025 The Status List approaches these privacy implications by integrating the status information of many Referenced Tokens into the same list. Therefore, the Issuer does not learn for which Referenced Token the Relying Party is requesting the Status List. The privacy of the Holder is protected by the anonymity within the set of Referenced Tokens in the Status List, also called herd privacy. This limits the possibilities of tracking by the Issuer. The herd privacy is depending on the number of entities within the Status List called its size. A larger size results in better privacy but also impacts the performance as more data has to be transferred to read the Status List. Additionally, the Issuer may analyse data from the HTTP request to identify the Relying Party, e.g. through the sender's IP address. This behaviour may be mitigated by: * private relay protocols or other mechanisms hiding the original sender like [RFC9458]. * using trusted Third Party Hosting, see Section 12.6. 12.2. Malicious Issuers A malicious Issuer could bypass the privacy benefits of the herd privacy by generating a unique Status List for every Referenced Token. By these means, he could maintain a mapping between Referenced Tokens and Status Lists and thus track the usage of Referenced Tokens by utilizing this mapping for the incoming requests. This malicious behaviour could be detected by Relying Parties that request large amounts of Referenced Tokens by comparing the number of different Status Lists and their sizes. 12.3. Observability of Relying Parties Once the Relying Party receives the Referenced Token, this enables them to request the Status List to validate its status through the provided uri parameter and look up the corresponding index. However, the Relying Party may persistently store the uri and index of the Referenced Token to request the Status List again at a later time. By doing so regularly, the Relying Party may create a profile of the Referenced Token's validity status. This behaviour may be intended as a feature, e.g. for a KYC process that requires regular validity checks, but might also be abused in cases where this is not intended and unknown to the Holder, e.g. profiling the suspension of a driving license or checking the employment status of an employee credential. Looker, et al. Expires 6 August 2025 [Page 34] Internet-Draft Token Status List February 2025 This behaviour could be mitigated by: * regular re-issuance of the Referenced Token, see Section 13.1. 12.4. Observability of Outsiders Outside actors may analyse the publicly available Status Lists to get information on the internal processes of the Issuer and his related business. This data may allow inferences on the total number of issued Reference Tokens and the revocation rate. Additionally, actors may regularly fetch this data or use the historic data functionality to learn how these numbers change over time. This behaviour could be mitigated by: * disable the historical data feature Section 8.4 * disable the Status List Aggregation Section 9 * choose non-sequential, pseudo-random or random indices * use decoy entries to obfuscate the real number of Referenced Tokens within a Status List * choose to deploy and utilize multiple Status Lists simultaneously 12.5. Unlinkability The tuple of uri and index inside the Referenced Token are unique and therefore is traceable data. 12.5.1. Colluding Relying Parties Two or more colluding Relying Parties may link two transactions involving the same Referenced Token by comparing the status claims of received Referenced Tokens and therefore determine that they have interacted with the same Holder. To avoid privacy risks for colluding Relying Parties, it is RECOMMENDED that Issuers provide the ability to issue batches of one- time-use Referenced Tokens, enabling Holders to use in a single interaction with a Relying Party before discarding. See Section 13.1 to avoid further correlatable information by the values of uri and index, Status Issuers are RECOMMENDED to: * choose non-sequential, pseudo-random or random indices Looker, et al. Expires 6 August 2025 [Page 35] Internet-Draft Token Status List February 2025 * use decoy entries to obfuscate the real number of Referenced Tokens within a Status List * choose to deploy and utilize multiple Status Lists simultaneously 12.5.2. Colluding Status Issuer and Relying Party A Status Issuer and a Relying Party Issuer may link two transaction involving the same Referenced Tokens by comparing the status claims of the Referenced Token and therefore determine that they have interacted with the same Holder. It is therefore recommended to use Status Lists for Referenced Token formats that have similar unlinkability properties. 12.6. External Status Provider for Privacy If the roles of the Status Issuer and the Status Provider are performed by different entities, this may give additional privacy assurances as the Issuer has no means to identify the Relying Party or its request. Third-Party hosting may also allow for greater scalability, as the Status List Tokens may be served by operators with greater resources, like CDNs, while still ensuring authenticity and integrity of Token Status List, as it is signed by the Status Issuer. 12.7. Historical Resolution By default, this specification only supports providing Status List information for the most recent status information and does not allow the lookup of historical information like a validity state at a specific point in time. There exists optional support for a query parameter that allows these kind of historic lookups as described in Section 8.4. There are scenarios where such a functionality is necessary, but this feature should only be implemented when the scenario and the consequences of enabling historical resolution are fully understood. There are strong privacy concerns that have to be carefully taken into consideration when providing a mechanism that allows historic requests for status information - see Section 12.3 for more details. Support for this functionality is optional and Implementers are RECOMMENDED to not support historic requests unless there are strong reasons to do so and after carefully considering the privacy implications. Looker, et al. Expires 6 August 2025 [Page 36] Internet-Draft Token Status List February 2025 12.8. Status Types As previously explained, there is the potential risk of observability by Relying Parties (see Section 12.3) and Outsiders (see Section 12.4). That means that any Status Type that transports special information about a Token can leak information to other parties. This documents defines one additional Status Type with "SUSPENDED" that conveys such additional information. Depending on the use-case, suspended could for example provide information that an authorization in the Token is suspended, but the token itself is still valid. A concrete example would be a driver's license, where the digital driver's license might still be useful to prove other information about its holder, but suspended could signal that it should not be considered valid in the scope of being allowed to drive a car. This case could be solved by either introducing a special status type, or by revoking the Token and re-issuing with changed attributes. For such a case, the status type suspended might be dangerous as it would leak the information of a suspended driver's license even if the driver's license is used as a mean of identification and not in the context of driving a car. This could also allow for the unwanted collection of statistical data on the status of driver's licenses. Ecosystems that want to use other Status Types than "VALID" and "INVALID" should consider the possible leakage of data and profiling possibilities before doing so and evaluate if revocation and re- issuance might a better fit for their use-case. 13. Implementation Considerations 13.1. Referenced Token Lifecycle The lifetime of a Status List Token depends on the lifetime of its Referenced Tokens. Once all Referenced Tokens are expired, the Issuer may stop serving the Status List Token. Referenced Tokens may be regularly re-issued to mitigate the linkability of presentations to Relying Parties. In this case, every re-issued Referenced Token MUST have a fresh Status List entry in order to prevent this from becoming a possible source of correlation. Referenced Tokens may also be issued in batches, such that Holders can use individual tokens for every transaction. In this case, every Referenced Token MUST have a dedicated Status List entry. Revoking batch-issued Referenced Tokens might reveal this correlation later on. Looker, et al. Expires 6 August 2025 [Page 37] Internet-Draft Token Status List February 2025 13.2. Default Values and Double Allocation Implementations producing Status Lists are RECOMMENDED to initialize the Status List byte array with a default value and provide this as an initialization parameter to the Issuer. The Issuer is RECOMMENDED to use a default value that represents the most common value for its Referenced Tokens to avoid an update during issuance. Implementations producing Status Lists are RECOMMENDED to prevent double allocation, i.e. re-using the same uri and index for multiple Referenced Tokens. The Issuer MUST prevent any unintended double allocation by using the Status List. 13.3. Status List Size The storage and transmission size of the Status Issuer's Status List Tokens depends on: - the size of the Status List, i.e. the number of Referenced Tokens - the revocation rate and distribution of the Status List data (due to compression, revocation rates close to 0% or 100% create lowest sizes while revocation rates closer to 50% and random distribution create highest sizes) - the lifetime of Referenced Tokens (shorter lifetimes allows for earlier retirement of Status List Tokens) The Status List Issuer may increase the size of a Status List if it requires indices for additional Referenced Tokens. It is RECOMMENDED that the size of a Status List in bits is divisible in bytes (8 bits) without a remainder, i.e. size-in-bits % 8 = 0. The Status List Issuer may chunk its Referenced Tokens into multiple Status Lists to reduce the transmission size of an individual Status List Token. This may be useful for setups where some entities operate in constrained environments, e.g. for mobile internet or embedded devices. The Status List Issuer may chunk the Status List Tokens depending on the Referenced Token's expiry date to align their lifecycles and allow for easier retiring of Status List Tokens, however the Status Issuer must be aware of possible privacy risks due to correlations. 13.4. External Status Issuer If the roles of the Issuer of the Referenced Token and the Status Issuer are performed by different entities, this may allow for use case that require revocations of Referenced Tokens to be managed by a different entities, e.g. for regulatory or privacy reasons. In this scenario both parties must align on: * the key and trust management as described in Section 11.3 Looker, et al. Expires 6 August 2025 [Page 38] Internet-Draft Token Status List February 2025 * parameters for the Status List - number of bits for the Status Type as described in Section 4 - update cycle of the Issuer used for ttl in the Status List Token as described in Section 5 13.5. External Status Provider for Scalability If the roles of the Status Issuer and the Status Provider are performed by different entities, this may allow for greater scalability, as the Status List Tokens may be served by operators with greater resources, like CDNs. At the same time the authenticity and integrity of Token Status List is still guaranteed, as it is signed by the Status Issuer. 13.6. Relying Parties avoiding correlatable Information If the Relying Party does not require the Referenced Token and the Status List Token after the presentation, e.g. for subsequent status checks or audit trail, it is RECOMMENDED to delete correlatable information, in particular: * the status claim in the Referenced Token * the Status List Token itself The Relying Party should instead only keep the relevant payload from the Referenced Token. 13.7. Status List Formats This specification defines 2 different token formats of the Status List: * JWT * CWT This specification states no requirements to not mix different formats like a CBOR based Referenced Token using a JWT for the Status List, but the expectation is that within an ecosystem, a choice for specific formats is made. Within such an ecosystem, only support for those selected variants is required and implementations should know what to expect via a profile. 14. IANA Considerations Looker, et al. Expires 6 August 2025 [Page 39] Internet-Draft Token Status List February 2025 14.1. JSON Web Token Claims Registration This specification requests registration of the following Claims in the IANA "JSON Web Token Claims" registry [IANA.JWT] established by [RFC7519]. 14.1.1. Registry Contents * Claim Name: status * Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the JWT. * Change Controller: IETF * Specification Document(s): Section 6.1 of this specification * Claim Name: status_list * Claim Description: A status list containing up-to-date status information on multiple tokens. * Change Controller: IETF * Specification Document(s): Section 5.1 of this specification * Claim Name: ttl * Claim Description: Time to Live * Change Controller: IETF * Specification Document(s): Section 5.1 of this specification 14.2. JWT Status Mechanisms Registry This specification establishes the IANA "JWT Status Mechanisms" registry for JWT "status" member values and adds it to the "JSON Web Token (JWT)" registry group at https://www.iana.org/assignments/jwt. The registry records the status mechanism member and a reference to the specification that defines it. Looker, et al. Expires 6 August 2025 [Page 40] Internet-Draft Token Status List February 2025 JWT Status Mechanisms are registered by Specification Required [RFC5226] after a three-week review period on the jwt-reg- review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register JWT Status Mechanism: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. 14.2.1. Registration Template Status Mechanism Value: The name requested (e.g., "status_list"). The name is case sensitive. Names may not match other registered names in a case- insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. Status Mechanism Description: Brief description of the status mechanism. Change Controller: For IETF Stream RFCs, list the IETF. For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required. Looker, et al. Expires 6 August 2025 [Page 41] Internet-Draft Token Status List February 2025 14.2.2. Initial Registry Contents * Status Mechanism Value: status_list * Status Mechanism Description: A status list containing up-to-date status information on multiple tokens. * Change Controller: IETF * Specification Document(s): Section 6.2 of this specification 14.3. CBOR Web Token Claims Registration This specification requests registration of the following Claims in the IANA "CBOR Web Token (CWT) Claims" registry [IANA.CWT] established by [RFC8392]. 14.3.1. Registry Contents * Claim Name: status * Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the CWT. * JWT Claim Name: status * Claim Key: TBD (requested assignment 65535) * Claim Value Type: map * Change Controller: IETF * Reference: Section 6.1 of this specification * Claim Name: status_list * Claim Description: A status list containing up-to-date status information on multiple tokens. * JWT Claim Name: status_list * Claim Key: TBD (requested assignment 65533) * Claim Value Type: map Looker, et al. Expires 6 August 2025 [Page 42] Internet-Draft Token Status List February 2025 * Change Controller: IETF * Specification Document(s): Section 5.2 of this specification * Claim Name: ttl * Claim Description: Time to Live * JWT Claim Name: ttl * Claim Key: TBD (requested assignment 65534) * Claim Value Type: unsigned integer * Change Controller: IETF * Specification Document(s): Section 5.2 of this specification 14.4. CWT Status Mechanisms Registry This specification establishes the IANA "CWT Status Mechanisms" registry for CWT "status" member values and adds it to the "CBOR Web Token (CWT) Claims" registry group at https://www.iana.org/assignments/cwt. The registry records the status mechanism member and a reference to the specification that defines it. CWT Status Mechanisms are registered by Specification Required [RFC5226] after a three-week review period on the cwt-reg- review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register CWT Status Mechanism: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Looker, et al. Expires 6 August 2025 [Page 43] Internet-Draft Token Status List February 2025 IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. 14.4.1. Registration Template Status Mechanism Value: The name requested (e.g., "status_list"). The name is case sensitive. Names may not match other registered names in a case- insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. Status Mechanism Description: Brief description of the status mechanism. Change Controller: For IETF Stream RFCs, list the IETF. For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required. 14.4.2. Initial Registry Contents * Status Mechanism Value: status_list * Status Mechanism Description: A status list containing up-to-date status information on multiple tokens. * Change Controller: IETF * Specification Document(s): Section 6.3 of this specification 14.5. OAuth Status Types Registry This specification establishes the IANA "OAuth Status Types" registry for Status List values and adds it to the "OAuth Parameters" registry group at https://www.iana.org/assignments/oauth-parameters. The registry records a human readable label, the bit representation and a common description for it. Looker, et al. Expires 6 August 2025 [Page 44] Internet-Draft Token Status List February 2025 Status Types are registered by Specification Required [RFC5226] after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register Status Type name: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. 14.5.1. Registration Template Status Type Name: The name is a human-readable case insensitive label for the Status Type that helps to talk about the status of Referenced Token in common language. Status Type Description: Brief description of the Status Type and optional examples. Status Type value: The bit representation of the Status Type in a byte hex representation. Valid Status Type values range from 0x00-0xFF. Values are filled up with zeros if they have less than 8 bits. Change Controller: For IETF Stream RFCs, list the IETF. For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Specification Document(s): Looker, et al. Expires 6 August 2025 [Page 45] Internet-Draft Token Status List February 2025 Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required. 14.5.2. Initial Registry Contents * Status Type Name: VALID * Status Type Description: The status of the Referenced Token is valid, correct or legal. * Status Type value: 0x00 * Change Controller: IETF * Specification Document(s): Section 7 of this specification * Status Type Name: INVALID * Status Type Description: The status of the Referenced Token is revoked, annulled, taken back, recalled or cancelled. * Status Type value: 0x01 * Change Controller: IETF * Specification Document(s): Section 7 of this specification * Status Type Name: SUSPENDED * Status Type Description: The status of the Referenced Token is temporarily invalid, hanging or debarred from privilege. This state is reversible. * Status Type value: 0x02 * Change Controller: IETF * Specification Document(s): Section 7 of this specification * Status Type Name: APPLICATION_SPECIFIC Looker, et al. Expires 6 August 2025 [Page 46] Internet-Draft Token Status List February 2025 * Status Type Description: The status of the Referenced Token is application specific. * Status Type value: 0x03 * Change Controller: IETF * Specification Document(s): Section 7 of this specification * Status Type Name: APPLICATION_SPECIFIC * Status Type Description: The status of the Referenced Token is application specific. * Status Type value: 0x0B-0xOF * Change Controller: IETF * Specification Document(s): Section 7 of this specification 14.6. OAuth Parameters Registration This specification requests registration of the following values in the IANA "OAuth Authorization Server Metadata" registry [IANA.OAuth.Params] established by [RFC8414]. * Metadata Name: status_list_aggregation_endpoint * Metadata Description: URL of the Authorization Server aggregating OAuth Token Status List URLs for token status management. * Change Controller: IETF * Reference: Section 9 of this specification 14.7. Media Type Registration This section requests registration of the following media types [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the manner described in [RFC6838]. To indicate that the content is an JWT-based Status List: * Type name: application Looker, et al. Expires 6 August 2025 [Page 47] Internet-Draft Token Status List February 2025 * Subtype name: statuslist+jwt * Required parameters: n/a * Optional parameters: n/a * Encoding considerations: See Section 5.1 of this specification * Security considerations: See Section 11 of this specification * Interoperability considerations: n/a * Published specification: this specification * Applications that use this media type: Applications using this specification for updated status information of tokens * Fragment identifier considerations: n/a * Additional information: n/a * Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de * Intended usage: COMMON * Restrictions on usage: none * Author: Paul Bastian, paul.bastian@posteo.de * Change controller: IETF * Provisional registration? No To indicate that the content is an CWT-based Status List: * Type name: application * Subtype name: statuslist+cwt * Required parameters: n/a * Optional parameters: n/a * Encoding considerations: See Section 5.2 of this specification * Security considerations: See Section 11 of this specification Looker, et al. Expires 6 August 2025 [Page 48] Internet-Draft Token Status List February 2025 * Interoperability considerations: n/a * Published specification: this specification * Applications that use this media type: Applications using this specification for updated status information of tokens * Fragment identifier considerations: n/a * Additional information: n/a * Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de * Intended usage: COMMON * Restrictions on usage: none * Author: Paul Bastian, paul.bastian@posteo.de * Change controller: IETF * Provisional registration? No 14.8. X.509 Certificate Extended Key Purpose OID Registration IANA is also requested to register the following OID "1.3.6.1.5.5.7.3.TBD" in the "SMI Security for PKIX Extended Key Purpose" registry (1.3.6.1.5.5.7.3), this OID is defined in section Section 10.1. 15. References 15.1. Normative References [CORS] WHATWG, "Fetch Living Standard", n.d., . [IANA.CWT] IANA, "CBOR Web Token (CWT) Claims", n.d., . [IANA.JOSE] IANA, "JSON Object Signing and Encryption (JOSE)", n.d., . [IANA.JWT] IANA, "JSON Web Token Claims", n.d., . Looker, et al. Expires 6 August 2025 [Page 49] Internet-Draft Token Status List February 2025 [IANA.MediaTypes] IANA, "Media Types", n.d., . [IANA.OAuth.Params] IANA, "OAuth Authorization Server Metadata", n.d., . [RFC1950] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, DOI 10.17487/RFC1950, May 1996, . [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, . [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . Looker, et al. Expires 6 August 2025 [Page 50] Internet-Draft Token Status List February 2025 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . Looker, et al. Expires 6 August 2025 [Page 51] Internet-Draft Token Status List February 2025 [RFC9596] Jones, M.B. and O. Steele, "CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter", RFC 9596, DOI 10.17487/RFC9596, June 2024, . 15.2. Informative References [ISO.mdoc] ISO/IEC JTC 1/SC 17, "ISO/IEC 18013-5:2021 ISO-compliant driving licence", n.d.. [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC9458] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458, DOI 10.17487/RFC9458, January 2024, . [SD-JWT.VC] Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based Verifiable Credentials (SD-JWT VC)", Work in Progress, Internet-Draft, draft-ietf-oauth-sd-jwt-vc-08, 3 December 2024, . [smith2020let] Smith, T., Dickinson, L., and K. Seamons, "Let's revoke: Scalable global certificate revocation", Network and Distributed Systems Security (NDSS) Symposium 2020 , n.d., . Looker, et al. Expires 6 August 2025 [Page 52] Internet-Draft Token Status List February 2025 [W3C.SL] Longley, D., Sporny, M., and O. Steele, "W3C Bitstring Status List v1.0", December 2024, . Acknowledgments We would like to thank Brian Campbell, Filip Skokan, Francesco Marino, Guiseppe De Marco, Kristina Yasuda, Markus Kreusch, Martijn Haring, Michael B. Jones, Michael Schwartz, Mike Prorock, Oliver Terbu, Orie Steele, Timo Glastra and Torsten Lodderstedt for their valuable contributions, discussions and feedback to this specification. Test vectors for Status List encoding All examples here are given in the form of JSON or CBOR payloads. The examples are encoded according to Section 4.1 for JSON and Section 4.2 for CBOR. The CBOR examples are displayed as hex values. All values that are not mentioned for the examples below can be assumed to be 0 (VALID). All examples are initialized with a size of 2^20 entries. 1 bit Status List The following example uses a 1 bit Status List (2 possible values): status[0]=1 status[1993]=1 status[25460]=1 status[159495]=1 status[495669]=1 status[554353]=1 status[645645]=1 status[723232]=1 status[854545]=1 status[934534]=1 status[1000345]=1 JSON encoding: Looker, et al. Expires 6 August 2025 [Page 53] Internet-Draft Token Status List February 2025 { "bits": 1, "lst": "eNrt3AENwCAMAEGogklACtKQPg9LugC9k_ACvreiogE AAKkeCQAAAAAAAAAAAAAAAAAAAIBylgQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAXG9IAAAAAAAAAPwsJAAAAAAAAAAAAAAAvhsSAAAAAAAAAAA A7KpLAAAAAAAAAAAAAAAAAAAAAJsLCQAAAAAAAAAAADjelAAAAAAAAAAAKjDMAQAAA ACAZC8L2AEb" } CBOR encoding: a2646269747301636c737458bd78daeddc010dc0200c0041a88249400ad2903e0f4b ba00bd93f002beb7a2a2010000a91e09000000000000000000000000000000807296 04000000000000000000000000000000000000000000000000000000000000000000 000000000000005c6f4800000000000000fc2c240000000000000000000000be1b12 000000000000000000ecaa4b000000000000000000000000000000009b0b09000000 00000000000038de9400000000000000002a30cc010000000080642f0bd8011b 2 bit Status List The following example uses a 2 bit Status List (4 possible values): status[0]=1 status[1993]=2 status[25460]=1 status[159495]=3 status[495669]=1 status[554353]=1 status[645645]=2 status[723232]=1 status[854545]=1 status[934534]=2 status[1000345]=3 JSON encoding: { "bits": 2, "lst": "eNrt2zENACEQAEEuoaBABP5VIO01fCjIHTMStt9ovGV IAAAAAABAbiEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEB5WwIAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAID0ugQAAAAAAAAAAAAAAAAAQG12SgAAA AAAAAAAAAAAAAAAAAAAAAAAAOCSIQEAAAAAAAAAAAAAAAAAAAAAAAD8ExIAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwJEuAQAAAAAAAAAAAAAAAAAAAAAAAMB9S wIAAAAAAAAAAAAAAAAAAACoYUoAAAAAAAAAAAAAAEBqH81gAQw" } CBOR encoding: Looker, et al. Expires 6 August 2025 [Page 54] Internet-Draft Token Status List February 2025 a2646269747302636c737459013d78daeddb310d00211000412ea1a04004fe5520ed 357c28c81d3312b6df68bc65480000000000406e2101000000000000000000000000 0000000000000000000000000000000000000040795b020000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000 0080f4ba0400000000000000000000000000406d764a000000000000000000000000 000000000000000000e0922101000000000000000000000000000000000000fc1312 00000000000000000000000000000000000000000000000000000000000000c0912e 01000000000000000000000000000000000000c07d4b020000000000000000000000 00000000a8614a0000000000000000000000406a1fcd60010c 4 bit Status List The following example uses a 4 bit Status List (16 possible values): status[0]=1 status[1993]=2 status[35460]=3 status[459495]=4 status[595669]=5 status[754353]=6 status[845645]=7 status[923232]=8 status[924445]=9 status[934534]=10 status[1004534]=11 status[1000345]=12 status[1030203]=13 status[1030204]=14 status[1030205]=15 JSON encoding: Looker, et al. Expires 6 August 2025 [Page 55] Internet-Draft Token Status List February 2025 { "bits": 4, "lst": "eNrt0EENgDAQADAIHwImkIIEJEwCUpCEBBQRHOy35Li 1EjoOQGabAgAAAAAAAAAAAAAAAAAAACC1SQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABADrsCAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAADoxaEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIIoCgAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACArpwKAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAGhqVkAzlwIAAAAAiGVRAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABx3AoAgLpVAQAAAAAAAAAAAAAAwM89rwMAAAAAAAAAA AjsA9xMBMA" } CBOR encoding: a2646269747304636c737459024878daedd0410d8030100030081f0226908204244c 025290840414111cecb7e4b8b5123a0e40669b020000000000000000000000000000 0020b549010000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000 0000000000400ebb0200000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000 000000000000e8c5a100000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000082280a00000000000000000000000000 00000000000000000000000000000000000000000000000000000000000080ae9c0a 00000000000000000000000000000000000000000000000000000000000000000000 000000686a5640339702000000008865510000000000000000000000000000000000 00000000000000000000000000000071dc0a0080ba55010000000000000000000000 c0cf3daf03000000000000000008ec03dc4c04c0 8 bit Status List The following example uses a 8 bit Status List (256 possible values): status[233478] = 0 status[52451] = 1 status[576778] = 2 status[513575] = 3 status[468106] = 4 status[292632] = 5 Looker, et al. Expires 6 August 2025 [Page 56] Internet-Draft Token Status List February 2025 status[214947] = 6 status[182323] = 7 status[884834] = 8 status[66653] = 9 status[62489] = 10 status[196493] = 11 status[458517] = 12 status[487925] = 13 status[55649] = 14 status[416992] = 15 status[879796] = 16 status[462297] = 17 status[942059] = 18 status[583408] = 19 status[13628] = 20 status[334829] = 21 status[886286] = 22 status[713557] = 23 status[582738] = 24 status[326064] = 25 status[451545] = 26 status[705889] = 27 status[214350] = 28 status[194502] = 29 status[796765] = 30 status[202828] = 31 status[752834] = 32 status[721327] = 33 status[554740] = 34 status[91122] = 35 status[963483] = 36 status[261779] = 37 status[793844] = 38 status[165255] = 39 status[614839] = 40 status[758403] = 41 status[403258] = 42 status[145867] = 43 status[96100] = 44 status[477937] = 45 status[606890] = 46 status[167335] = 47 status[488197] = 48 status[211815] = 49 status[797182] = 50 status[582952] = 51 status[950870] = 52 status[765108] = 53 Looker, et al. Expires 6 August 2025 [Page 57] Internet-Draft Token Status List February 2025 status[341110] = 54 status[776325] = 55 status[745056] = 56 status[439368] = 57 status[559893] = 58 status[149741] = 59 status[358903] = 60 status[513405] = 61 status[342679] = 62 status[969429] = 63 status[795775] = 64 status[566121] = 65 status[460566] = 66 status[680070] = 67 status[117310] = 68 status[480348] = 69 status[67319] = 70 status[661552] = 71 status[841303] = 72 status[561493] = 73 status[138807] = 74 status[442463] = 75 status[659927] = 76 status[445910] = 77 status[1046963] = 78 status[829700] = 79 status[962282] = 80 status[299623] = 81 status[555493] = 82 status[292826] = 83 status[517215] = 84 status[551009] = 85 status[898490] = 86 status[837603] = 87 status[759161] = 88 status[459948] = 89 status[290102] = 90 status[1034977] = 91 status[190650] = 92 status[98810] = 93 status[229950] = 94 status[320531] = 95 status[335506] = 96 status[885333] = 97 status[133227] = 98 status[806915] = 99 status[800313] = 100 status[981571] = 101 Looker, et al. Expires 6 August 2025 [Page 58] Internet-Draft Token Status List February 2025 status[527253] = 102 status[24077] = 103 status[240232] = 104 status[559572] = 105 status[713399] = 106 status[233941] = 107 status[615514] = 108 status[911768] = 109 status[331680] = 110 status[951527] = 111 status[6805] = 112 status[552366] = 113 status[374660] = 114 status[223159] = 115 status[625884] = 116 status[417146] = 117 status[320527] = 118 status[784154] = 119 status[338792] = 120 status[1199] = 121 status[679804] = 122 status[1024680] = 123 status[40845] = 124 status[234603] = 125 status[761225] = 126 status[644903] = 127 status[502167] = 128 status[121477] = 129 status[505144] = 130 status[165165] = 131 status[179628] = 132 status[1019195] = 133 status[145149] = 134 status[263738] = 135 status[269256] = 136 status[996739] = 137 status[346296] = 138 status[555864] = 139 status[887384] = 140 status[444173] = 141 status[421844] = 142 status[653716] = 143 status[836747] = 144 status[783119] = 145 status[918762] = 146 status[946835] = 147 status[253764] = 148 status[519895] = 149 Looker, et al. Expires 6 August 2025 [Page 59] Internet-Draft Token Status List February 2025 status[471224] = 150 status[134272] = 151 status[709016] = 152 status[44112] = 153 status[482585] = 154 status[461829] = 155 status[15080] = 156 status[148883] = 157 status[123467] = 158 status[480125] = 159 status[141348] = 160 status[65877] = 161 status[692958] = 162 status[148598] = 163 status[499131] = 164 status[584009] = 165 status[1017987] = 166 status[449287] = 167 status[277478] = 168 status[991262] = 169 status[509602] = 170 status[991896] = 171 status[853666] = 172 status[399318] = 173 status[197815] = 174 status[203278] = 175 status[903979] = 176 status[743015] = 177 status[888308] = 178 status[862143] = 179 status[979421] = 180 status[113605] = 181 status[206397] = 182 status[127113] = 183 status[844358] = 184 status[711569] = 185 status[229153] = 186 status[521470] = 187 status[401793] = 188 status[398896] = 189 status[940810] = 190 status[293983] = 191 status[884749] = 192 status[384802] = 193 status[584151] = 194 status[970201] = 195 status[523882] = 196 status[158093] = 197 Looker, et al. Expires 6 August 2025 [Page 60] Internet-Draft Token Status List February 2025 status[929312] = 198 status[205329] = 199 status[106091] = 200 status[30949] = 201 status[195586] = 202 status[495723] = 203 status[348779] = 204 status[852312] = 205 status[1018463] = 206 status[1009481] = 207 status[448260] = 208 status[841042] = 209 status[122967] = 210 status[345269] = 211 status[794764] = 212 status[4520] = 213 status[818773] = 214 status[556171] = 215 status[954221] = 216 status[598210] = 217 status[887110] = 218 status[1020623] = 219 status[324632] = 220 status[398244] = 221 status[622241] = 222 status[456551] = 223 status[122648] = 224 status[127837] = 225 status[657676] = 226 status[119884] = 227 status[105156] = 228 status[999897] = 229 status[330160] = 230 status[119285] = 231 status[168005] = 232 status[389703] = 233 status[143699] = 234 status[142524] = 235 status[493258] = 236 status[846778] = 237 status[251420] = 238 status[516351] = 239 status[83344] = 240 status[171931] = 241 status[879178] = 242 status[663475] = 243 status[546865] = 244 status[428362] = 245 Looker, et al. Expires 6 August 2025 [Page 61] Internet-Draft Token Status List February 2025 status[658891] = 246 status[500560] = 247 status[557034] = 248 status[830023] = 249 status[274471] = 250 status[629139] = 251 status[958869] = 252 status[663071] = 253 status[152133] = 254 status[19535] = 255 JSON encoding: Looker, et al. Expires 6 August 2025 [Page 62] Internet-Draft Token Status List February 2025 { "bits": 8, "lst": "eNrt0WOQM2kYhtGsbdu2bdu2bdu2bdu2bdu2jVnU1my -SWYm6U5enFPVf7ue97orFYAo7CQBAACQuuckAABStqUEAAAAAAAAtN6wEgAE71QJA AAAAIrwhwQAAAAAAdtAAgAAAAAAACLwkAQAAAAAAAAAAACUaFcJAACAeJwkAQAAAAA AAABQvL4kAAAAWmJwCQAAAAAAAAjAwBIAAAB06ywJoDKQBARpfgkAAAAAAAAAAAAAA AAAAACo50sJAAAAAAAAAOiRcSQAAAAAgAJNKgEAAG23mgQAAAAAAECw3pUAQvegBAA AAAAAAADduE4CAAAAyjSvBAAQiw8koHjvSABAb-wlARCONyVoxtMSZOd0CQAAAOjWD RKQmLckAAAAAACysLYEQGcnSAAAAAAQooUlAABI15kSAIH5RAIgLB9LABC4_SUgGZN IAABAmM6RoLbTJIASzCIBAEAhfpcAAAAAAABquk8CAAAAAAAAaJl9SvvzBOICAFWmk IBgfSgBAAAANOgrCQAAAAAAAADStK8EAAC03gASAAAAAAAAAADFWFUCAAAAMjOaBEA DHpYAQjCIBADduFwCAAAAAGitMSSI3BUSAECOHpAA6IHrJQAAAAAAsjeVBAAAKRpVA orWvwQAAAAAAAAAkKRtJAAAAAAAgCbcLAF0bXUJAAAAoF02kYDg7CYBAAAAAEB6NpQ AAAAAAAAAAAAAAEr1uQQAAF06VgIAAAAAAAAAqDaeBAAQqgMkAAAAAABogQMlAAAAA AAa87MEAAAQiwslAAAAAAAAAAAAAAAAMrOyBAAAiekv-hcsY0Sgne6QAAAAAAAgaUt JAAAAAAAAAAAAAAAAAAAAAAAAAADwt-07vjVkAAAAgDy8KgFAUEaSAAAAAJL3vgQAW dhcAgAAoBHDSUDo1pQAAACI2o4SAABZm14CALoyuwQAAPznGQkgZwdLAAAQukclAAA AAAAAAAAAgKbMKgEAAAAAAAAAAAAAAAAAAECftpYAAAAAAAAAAAAACnaXBAAAAADk7 iMJAAAAAAAAAABqe00CAnGbBBG4TAIAgFDdKgFAXCaWAAAAAAAAAAAAAAAAAKAJQwR 72XbGAQAAAKAhh0sAAAAAAABQgO8kAAAAAAAAAAAAACAaM0kAAAC5W0QCAIJ3mAQAx GwxCQAA6nhSAsjZBRIAANEbWQIAAAAAaJE3JACAwA0qAUBIVpKAlphbAiAPp0iQnKE kAAAAAAAgBP1KAAAAdOl4CQAAAAAAAPjLZBIAAG10RtrPm8_CAEBMTpYAAAAAAIjQY BL8z5QSAAAAAEDYPpUAACAsj0gAAADQkHMlAAjHDxIA0Lg9JQAAgHDsLQEAAABAQS6 WAAAAgLjNFs2l_RgLAIAEfCEBlGZZCQAAaIHjJACgtlskAAAozb0SAAAAVFtfAgAAA AAAAAAAAAAAAAAAAAAAAKDDtxIAAAAAVZaTAKB5W0kAANCAsSUgJ0tL0GqHSNBbL0g AZflRAgCARG0kQXNmlgCABiwkAQAAAEB25pIAAAAAAAAAAAAAoFh9SwAAAAAAADWNm OSrpjFsEoaRgDKcF9Q1dxsEAAAAAAAAAAAAAAAAgPZ6SQIAAAAAAAAAgChMLgEAAAA AAAAAqZlQAsK2qQQAAAAAAAD06XUJAAAAqG9bCQAAgLD9IgEAAAAAAAAAAAAAAAAAA EBNe0gAAAAAAAAAAEBPHSEBAAAAlOZtCYA4fS8B0GFRCQAo0gISAOTgNwmC840EAAA AAAAAAAAAAAAAAAAAUJydJfjXPBIAAAAAAAAAAAAAAABk6WwJAAAAAAAAAAAAAAAAq G8UCQAAgPpOlAAAIA83SQAANWwc9HUjGAgAAAAAAACAusaSAAAAAAAAAAAAAAAAAAA AAAAAAAAAqHKVBACQjxklAAAAAAAAAKBHxpQAAAAAACBME0lAdlaUAACyt7sEAAAA0 Nl0EgAAAAAAAAAAAABA-8wgAQAAAAAAAKU4SgKgUtlBAgAAAAAAAAAAgMCMLwEE51k JICdzSgCJGl2CsE0tAQAA0L11JQAAAAAAAAjUOhIAAAAAAAAAAAAAAGTqeQkAAAAAA AAAAAAAKM8SEjTrJwkAAAAAAACocqQEULgVJAAAACjDUxJUKgtKAAAAqbpRAgCA0n0 mAQAAAABAGzwmAUCTLpUAAAAAAAAAAEjZNRIAAAAAAAAAAAAAAAAAAAAA8I-vJaAlh pQAAAAAAHrvzjJ-OqCuuVlLAojP8BJAr70sQZVDJYAgXS0BAAAAAAAAAAAAtMnyEgA AAAAAFONKCQAAAAAAAADorc0kAAAAAAAAgDqOlgAAAAAAAAAAAADIwv0SAAAAAAAAA AAAAADBuV0CIFVDSwAAAABAAI6RAAAAAGIwrQSEZAsJAABouRclAAAAAKDDrxIAAAA 0bkkJgFiMKwEAAAAAAHQyhwRk7h4JAAAAAAAAAAAgatdKAACUYj0JAAAAAAAAAAAAQ nORBLTFJRIAAAAAkIaDJAAAAJryngQAAAAAAAAAAAA98oQEAAAAAAAAAEC2zpcgWY9 LQKL2kwAgGK9IAAAAAPHaRQIAAAAAAAAAAADIxyoSAAAAAAAAAAAAAADQFotLAECz_ gQ1PX-B" } CBOR encoding: Looker, et al. Expires 6 August 2025 [Page 63] Internet-Draft Token Status List February 2025 a2646269747308636c73745907b078daedd1639033691886d1ac6ddbb66ddbb66ddb b66ddbb66ddbb68d59d4d66cbe496626e94e5e9c53d57fbb9ef7ba2b158028ec2401 000090bae724000052b6a504000000000000b4deb0120004ef5409000000008af087 040000000001db400200000000000022f09004000000000000000000946857090000 80789c24010000000000000050bcbe240000005a62700900000000000008c0c01200 000074eb2c09a032900404697e09000000000000000000000000000000a8e74b0900 000000000000e89171240000000080024d2a0100006db79a04000000000040b0de95 0042f7a00400000000000000ddb84e02000000ca34af0400108b0f24a078ef480040 6fec2501108e372568c6d31264e77409000000e8d60d129098b7240000000000b2b0 b604406727480000000010a28525000048d799120081f94402202c1f4b0010b8fd25 2019934800004098ce91a0b6d3248012cc22010040217e970000000000006aba4f02 00000000000068997d4afbf304e2020055a69080607d280100000034e82b09000000 00000000d2b4af040000b4de00120000000000000000c558550200000032339a0440 031e96004230880400ddb85c020000000068ad312488dc151200408e1e9000e881eb 250000000000b23795040000291a55028ad6bf040000000000000090a46d24000000 00008026dc2c01746d7509000000a05d369180e0ec260100000000407a3694000000 00000000000000004af5b90400005d3a560200000000000000a8369e040010aa0324 00000000006881032500000000001af3b3040000108b0b2500000000000000000000 000032b3b204000089e92ffa172c6344a09dee90000000000020694b490000000000 000000000000000000000000000000f0b7ed3bbe3564000000803cbc2a0140504692 0000000092f7be040059d85c020000a011c34940e8d69400000088da8e120000599b 5e0200ba32bb040000fce719092067074b000010ba472500000000000000000080a6 cc2a010000000000000000000000000000409fb696000000000000000000000a7697 0400000000e4ee230900000000000000006a7b4d0202719b0411b84c02008050dd2a 01405c269600000000000000000000000000a00943047bd976c601000000a021874b 0000000000005080ef2400000000000000000000201a3349000000b95b4402008277 980400c46c31090000ea785202c8d905120000d11b590200000000689137240080c0 0d2a01404856928096985b02200fa748909ca12400000000002004fd4a00000074e9 7809000000000000f8cb641200006d7446dacf9bcfc200404c4e96000000000088d0 6012fccf94120000000040d83e950000202c8f48000000d09073250008c70f1200d0 b83d2500008070ec2d0100000040412e9600000080b8cd16cda5fd180b0080047c21 019466590900006881e32400a0b65b24000028cdbd12000000545b5f020000000000 00000000000000000000000000a0c3b7120000000055969300a0795b490000d080b1 2520274b4bd06a8748d05b2f480065f951020080446d24417366960080062c240100 00004076e69200000000000000000000a0587d4b000000000000358d98e4aba6316c 12869180329c17d435771b0400000000000000000000000080f67a49020000000000 000080284c2e0100000000000000a9995002c2b6a904000000000000f4e975090000 00a86f5b09000080b0fd22010000000000000000000000000000404d7b4800000000 00000000404f1d210100000094e66d0980387d2f01d06151090028d2021200e4e037 0982f38d04000000000000000000000000000000509c9d25f8d73c12000000000000 00000000000064e96c09000000000000000000000000a86f1409000080fa4e940000 200f37490000356c1cf47523180800000000000080bac69200000000000000000000 0000000000000000000000a872950400908f192500000000000000a047c694000000 0000204c1349407656940000b2b7bb04000000d0d974120000000000000000000040 fbcc2001000000000000a5384a02a052d94102000000000000000080c08c2f0104e7 59092027734a00891a5d82b04d2d010000d0bd752500000000000008d43a12000000 000000000000000064ea79090000000000000000000028cf121234eb270900000000 0000a872a40450b8152400000028c35312542a0b4a000000a9ba51020080d27d2601 Looker, et al. Expires 6 August 2025 [Page 64] Internet-Draft Token Status List February 2025 00000000401b3c260140932e95000000000000000048d93512000000000000000000 00000000000000f08faf25a025869400000000007aefce327e3aa0aeb9594b0288cf f01240afbd2c4195432580205d2d01000000000000000000b4c9f212000000000014 e34a0900000000000000e8adcd24000000000000803a8e9600000000000000000000 c8c2fd120000000000000000000000c1b95d022055434b0000000040008e91000000 006230ad0484640b09000068b9172500000000a0c3af12000000346e490980588c2b 0100000000007432870464ee1e090000000000000000206ad74a000094623d090000 0000000000000042739104b4c5251200000000908683240000009af29e0400000000 00000000003df284040000000000000040b6ce9720598f4b40a2f693002018af4800 000000f1da4502000000000000000000c8c72a120000000000000000000000d0168b 4b0040b3fe04353d7f81 Document History -07 * add considerations about External Status Issuer or Status Provider * add recommendations for Key Resolution and Trust Management * add extended key usage extensions for x509 * Relying Parties avoiding correlatable Information * editorial changes on terminology and Referenced Tokens * clarify privacy consideration around one time use reference tokens * explain the Status List Token size dependencies * explain possibility to chunk Status List Tokens depending on Referenced Token's expiry date * add short-lived tokens in the Rationale * rename Status Mechanism Methods registry to Status Mechanisms registry * changes as requested by IANA review * emphasize that security and privacy considerations only apply to Status List and no other status mechanisms * differentiate unlinkability between Issuer-RP and RP-RP * add more test vectors for the status list encoding * add prior art Looker, et al. Expires 6 August 2025 [Page 65] Internet-Draft Token Status List February 2025 * updated language around application specific status type values and assigned ranges for application specific usage * add short security considerations section for mac based deployments * privacy considerations for other status types like suspended * fix aggregation_uri text in referenced token * mention key resolution in validation rules -06 * iana registration text updated with update procedures * explicitly mention that status list is expected to be contained in cryptographically secured containers * reworked and simplified introduction and abstract * specify http status codes and allow redirects * add status_list_aggregation_endpoint OAuth metadata * remove unsigned options (json/cbor) of status list * add section about mixing status list formats and media type * fixes from IETF review * update guidance around ttl * add guidance around aggregation endpoint -05 * add optional support for historical requests * update CBOR claim definitions * improve section on Status Types and introduce IANA registry for it * add Status Issuer and Status Provider role description to the introduction/terminology * add information on third party hosting to security consideration Looker, et al. Expires 6 August 2025 [Page 66] Internet-Draft Token Status List February 2025 * remove constraint that Status List Token must not use a MAC -04 * add mDL example as Referenced Token and consolidate CWT and CBOR sections * add implementation consideration for Default Values, Double Allocation and Status List Size * add privacy consideration on using private relay protocols * add privacy consideration on observability of outsiders * add security considerations on correct parsing and decoding * remove requirement for matching iss claim in Referenced Token and Status List Token * add sd-jwt-vc example * fix CWT status_list map encoding * editorial fixes * add CORS considerations to the http endpoint * fix reference of Status List in CBOR format * added status_list CWT claim key assigned * move base64url definition to terminology -03 * remove unused reference to RFC9111 * add validation rules for status list token * introduce the status list aggregation mechanism * relax requirements for status_list claims to contain other parameters * change cwt referenced token example to hex and annotated hex * require TLS only for fetching Status List, not for Status List Token Looker, et al. Expires 6 August 2025 [Page 67] Internet-Draft Token Status List February 2025 * remove the undefined phrase Status List endpoint * remove http caching in favor of the new ttl claim * clarify the sub claim of Status List Token * relax status_list iss requirements for CWT * Fixes missing parts & iana ttl registration in CWT examples -02 * add ttl claim to Status List Token to convey caching * relax requirements on referenced token * clarify Deflate / zlib compression * make a reference to the Issuer-Holder-Verifier model of SD-JWT VC * add COSE/CWT/CBOR encoding -01 * Rename title of the draft * add design consideration to the introduction * Change status claim to in referenced token to allow re-use for other mechanisms * Add IANA Registry for status mechanisms * restructure the sections of this document * add option to return an unsigned Status List * Changing compression from gzip to zlib * Change typo in Status List Token sub claim description * Add access token as an example use-case -00 * Initial draft after working group adoption * update acknowledgments Looker, et al. Expires 6 August 2025 [Page 68] Internet-Draft Token Status List February 2025 * renamed Verifier to Relying Party * added IANA consideration [ draft-ietf-oauth-status-list ] -01 * Applied editorial improvements suggested by Michael Jones. -00 * Initial draft Authors' Addresses Tobias Looker MATTR Email: tobias.looker@mattr.global Paul Bastian Email: paul.bastian@posteo.de Christian Bormann SPRIND Email: chris.bormann@gmx.de Looker, et al. Expires 6 August 2025 [Page 69]