Network Working Group T. Looker Internet-Draft MATTR Intended status: Informational P. Bastian Expires: 25 April 2024 C. Bormann 23 October 2023 OAuth Status List draft-ietf-oauth-status-list-00 Abstract This specification defines status list data structures for representing the status of JSON Web Tokens (JWTs) [RFC7519] and CBOR Web Tokens (CWTs) [RFC8392]. The status list data structures themselves are also represented as JWTs or CWTs. 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://vcstuff.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/. Source for this draft and an issue tracker can be found at https://github.com/vcstuff/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/. 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 25 April 2024. Looker, et al. Expires 25 April 2024 [Page 1] Internet-Draft OAuth Status List October 2023 Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. JSON Web Token Representation . . . . . . . . . . . . . . . . 5 4.1. Status List JWT Format and Processing Requirements . . . 5 4.1.1. Status List Claim Format . . . . . . . . . . . . . . 6 4.1.2. Status List Encoding . . . . . . . . . . . . . . . . 6 4.2. Referenced Token Format and Processing Requirements . . . 7 4.2.1. Status Claim Format . . . . . . . . . . . . . . . . . 7 5. Status Types . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Status Types Values . . . . . . . . . . . . . . . . . . . 8 6. Example JWT Status Lists . . . . . . . . . . . . . . . . . . 8 6.1. Example Status List with 1-Bit Status Values . . . . . . 8 6.2. Example Status List with 2-Bit Status Values . . . . . . 9 7. Verification and Processing . . . . . . . . . . . . . . . . . 10 7.1. Status List Request . . . . . . . . . . . . . . . . . . . 10 7.2. Status List Response . . . . . . . . . . . . . . . . . . 11 7.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4. Validation Rules . . . . . . . . . . . . . . . . . . . . 11 8. CWT Representations . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9.1. Correct decoding and parsing of the encoded status list . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.2. Cached and Stale status lists . . . . . . . . . . . . . . 12 9.3. Authorized access to the Status List . . . . . . . . . . 12 9.4. History . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 10.1. Issuer tracking and Herd Privacy . . . . . . . . . . . . 12 10.2. Malicious Issuers . . . . . . . . . . . . . . . . . . . 13 10.3. Relying Party tracking . . . . . . . . . . . . . . . . . 13 10.4. Correlation Risks and Tracking . . . . . . . . . . . . . 13 Looker, et al. Expires 25 April 2024 [Page 2] Internet-Draft OAuth Status List October 2023 10.5. Third Party Hosting . . . . . . . . . . . . . . . . . . 14 11. Implementation Considerations . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12.1. JSON Web Token Claims Registration . . . . . . . . . . . 14 12.2. Media Type Registration . . . . . . . . . . . . . . . . 15 13. Normative References . . . . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Document History . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction JSON Web Tokens (JWTs) [RFC7519] and CBOR Web Tokens (CWTs) [RFC8392] as secure token formats, have vast possible applications. Some of these applications can involve issuing a token whereby certain semantics about the token can change over time, which are important to be able to communicate to relying parties in an interoperable manner, such as whether the token is considered invalidated or suspended by its issuer. This document defines Status List representations in JWT and CWT formats that describe the individual statuses of multiple Referenced Tokens, which themselves are also JWTs or CWTs. 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 position correspond to the Referenced Token's status. The document also defines how an issuer of a Referenced Token references a Status List Token. Status Lists may be composed for expressing 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. The Status List Token may be used by an issuer in the Issuer-Holder-Verifier model to express the status of verifiable credentials (Referenced Tokens) issued by an issuer. The following diagram depicts the basic conceptual relationship. +------------------+ +-------------------+ | | References | | | |------------------->| | | Referenced Token | | Status List Token | | (JWT or CWT) | | (JWT or CWT) | | | Describes Status | | | |<-------------------| | +------------------+ +-------------------+ Looker, et al. Expires 25 April 2024 [Page 3] Internet-Draft OAuth Status List October 2023 1.1. Rationale Revocation mechanisms are an essential part for most identity ecosystems. In the past, revocation of X.509 TLS certificates has been proven difficult. Traditional certificate revocation lists (CRLs) have limited scalability; Online Certificate Status Protocol (OCSP) has additional privacy risks, since the client is leaking the requested website to a third party. OCSP stapling is addressing some of these problems at the cost of less up-to-date data. Modern approaches use accumulator-based revocation registries and Zero- Knowledge-Proofs to accommodate for this privacy gap, but face scalability issues again. 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 100,000 or more Referenced Tokens, but still remain relatively small. Placing large amounts of Referenced Tokens into the same list also enables herd privacy relative to the Issuer. 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. 3. Terminology Issuer: An entity that issues the Referenced Token and provides the status information of the Referenced Token by serving a Status List Token on a public endpoint. Relying Party: An entity that relies on the Status List to validate the status of the Referenced Token. Also known as Verifier. Status List: A bit array that lists the statuses of many Referenced Tokens. Status List Token: A token in JWT or CWT representation that contains a cryptographically secured Status List. Referenced Token: A token in JWT or CWT representation which contains a reference to a Status List Token. The information from the contained Status List may give a Relying Party additional information about up-to-date status of the Referenced Token. Looker, et al. Expires 25 April 2024 [Page 4] Internet-Draft OAuth Status List October 2023 4. JSON Web Token Representation 4.1. Status List JWT Format and Processing Requirements The following rules apply to validating a JWT-based Status List Token. Application of additional restrictions and policy are at the discretion of the verifying party. 1. The JWT MUST contain an "iss" (issuer) claim that contains a unique string identifier for the entity that issued the JWT. In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of [RFC3986]. The value MUST be equal to that of the "iss" claim contained within the Referenced Token. 2. The JWT MUST contain a "sub" (subject) claim that contains an unique string identifier for that Referenced Token. The value MUST be equal to that of the "uri" claim contained in the "status" claim of the Referenced Token. 3. The JWT MUST contain an "iat" (issued at) claim that identifies the time at which it was issued. 4. The JWT MUST contain an "status_list" (status list) claim conforming to the rules outlined in Section 4.1.1. 5. The JWT MAY contain an "exp" (expiration time) claim that conveys when it is considered expired by its issuer. 6. The JWT MAY contain other claims. 7. The JWT MUST be digitally signed using an asymmetric cryptographic algorithm. Relying parties MUST reject the JWT if it is using a Message Authentication Code (MAC) algorithm. Relying parties MUST reject JWTs with an invalid signature. 8. Relying parties MUST reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" [RFC7519]. Looker, et al. Expires 25 April 2024 [Page 5] Internet-Draft OAuth Status List October 2023 { "alg": "ES256", "kid": "12", "typ": "statuslist+jwt" } . { "exp": 2291720170, "iat": 1686920170, "iss": "https://example.com", "status_list": { "bits": 2, "lst": "H4sIAOpbjGQC_zvp8hMAZLRLMQMAAAA" }, "sub": "https://example.com/statuslists/1" } 4.1.1. Status List Claim Format The following rules apply to validating the "status_list" (status list) claim 1. The claim value MUST be a valid JSON object. 2. The claim value object MUST contain a "bits" (bit size) member with an numeric value that represents the number of bits per Referenced Token in the Status List ("lst") of the Status List JWT. The allowed values for "bits" are 1,2,4 and 8. 3. The claim value object MUST contain a "lst" (list) member with a string value that represents the status values for all the tokens it conveys statuses for. The value MUST be computed using the algorithm described in Section 4.1.2. 4.1.2. Status List Encoding Each status of a Referenced Token MUST be represented with a bit size of 1,2,4, or 8. Therefore up to 2,4,16, or 256 statuses for a 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. 1. The overall Status List is encoded as a byte array. Depending on the bitsize, each byte corresponds to 8/(#bit-size) statuses (8,4,2, or 1). The status of each Referenced Token is identified using the index that maps to one or more specific bits within the byte array. The index starts counting at 0 and ends with "size" Looker, et al. Expires 25 April 2024 [Page 6] Internet-Draft OAuth Status List October 2023 - 1 (being the last valid entry). The bits within an array are counted from least significant bit "0" to the most significant bit ("7"). All bits of the byte array at a particular index are set to a status value. 2. The complete byte array is compressed using gZIP [RFC1952]. 3. The result of the gZIP compression is then base64url-encoded, as defined in Section 2 of [RFC7515]. 4.2. Referenced Token Format and Processing Requirements The following rules apply to validating a Referenced Token in JWT representation, which references a Status List Token. Application of additional restrictions and policy are at the discretion of the verifying party. 1. The JWT MUST contain an "iss" (issuer) claim that contains a unique string identifier for the entity that issued the JWT. In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of [RFC3986]. The value MUST be equal to that of the "iss" claim contained within the referenced Status List Token. 2. The JWT MUST contain an "status" (status) claim conforming to the rules outlined in Section 4.2.1 The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. { "alg": "ES256", "kid": "11" } . { "iss": "https://example.com", "status": { "idx": 0, "uri": "https://example.com/statuslists/1" } } 4.2.1. Status Claim Format The following rules apply to validating the "status" (status) claim Looker, et al. Expires 25 April 2024 [Page 7] Internet-Draft OAuth Status List October 2023 1. The claim value MUST be a valid JSON object. 2. The claim value object MUST contain an "idx" (index) member with a numeric value that represents the index to check for status information in the Status List for the current JWT. The value of this member MUST be a non-negative number, containing a value of zero or greater. 3. The claim value object MUST contain a "uri" member with a string value that identifies the Status List containing the status information for the JWT. The value of this member MUST be a uri conforming to [RFC3986]. 5. Status Types This document defines potential statuses of Referenced Tokens as Status Type values. If the Status List contains more than one bit per token (as defined by "bits" in the Status List), then the whole value of bits MUST describe one value. A Status List can not represent multiple statuses per Referenced Token. The registry in this document describes the basic Status Type values required for the most common use cases. Additional values may defined for particular use cases. 5.1. Status Types Values A status describes the state, mode, condition or stage of an entity that is described by the status list. Status Types MUST be numeric values between 0 and 255. Status types described by this specification comprise: - 0x00 - "VALID" - The status of the Token is valid, correct or legal. - 0x01 - "INVALID" - The status of the Token is revoked, annulled, taken back, recalled or cancelled. This state is irreversible. - 0x02 - "SUSPENDED" - The status of the Token is temporarily invalid, hanging, debarred from privilege. This state is reversible. The issuer of the Status List Token MUST choose an adequate "bits" (bit size) to be able to describe the required Status Types for the application. 6. Example JWT Status Lists 6.1. Example Status List with 1-Bit Status Values In this example, the Status List is used as a revocation list. It only requires the Status Types "VALID" and "INVALID"; therefore a "bits" of 1 is sufficient. Looker, et al. Expires 25 April 2024 [Page 8] Internet-Draft OAuth Status List October 2023 This example Status List represents the statuses of 16 Referenced Tokens, requiring 16 bits (2 bytes) of 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 Resulting in the byte array and compressed/base64url encoded status list: byte_array = [0xb9, 0xa3] encoded = "H4sIAOpbjGQC_9u5GABc9QE7AgAAAA" 6.2. Example Status List with 2-Bit Status Values In thisexample, 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. Looker, et al. Expires 25 April 2024 [Page 9] Internet-Draft OAuth Status List October 2023 status[0] = 1 status[1] = 2 status[2] = 0 status[3] = 3 status[4] = 0 status[5] = 1 status[6] = 0 status[7] = 1 status[8] = 1 status[9] = 2 status[10] = 3 status[11] = 3 These bits are concatenated: byte 0 1 2 bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ values |1|1|0|0|1|0|0|1| |0|1|0|0|0|1|0|0| |1|1|1|1|1|0|0|1| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / status 3 0 2 1 1 0 1 0 3 3 2 1 index 3 2 1 0 7 6 5 4 11 10 9 8 \___________/ \___________/ \___________/ 0xC9 0x44 0xF9 Resulting in the byte array and compressed/base64url encoded status list: byte_array = [0xc9, 0x44, 0xf9] encoded = "H4sIAOpbjGQC_zvp8hMAZLRLMQMAAAA" 7. Verification and Processing 7.1. Status List Request To obtain the Status List or Status List Token, the Relying Party MUST send a HTTP GET request to the Status List Endpoint. Communication with the Status List Endpoint MUST utilize TLS. Which version(s) should be implemented will vary over time. A TLS server certificate check MUST be performed as defined in Section 5 and 6 of [RFC6125]. The Relying Party SHOULD send the following Accept-Header to indicate the requested response type: * "application/statuslist+jwt" for Status List JWTs Looker, et al. Expires 25 April 2024 [Page 10] Internet-Draft OAuth Status List October 2023 * "application/statuslist+cwt" for Status List CWTs If the Relying Party does not send an Accept Header, the reponse type is assumed to be known implicit or out-of-band. 7.2. Status List Response In the successful response, the Status List Provider MUST use the following content-type: * "application/statuslist+jwt" for Status List JWTs * "application/statuslist+cwt" for Status List CWTs In the case of "application/statuslist+jwt", the response MUST be of type JWT and follow the rules of Section 4.1. In the case of "application/statuslist+cwt", the response MUST be of type JWT and follow the rules of Section 8. The response SHOULD use gzip Content-Encoding as defined in [RFC9110]. 7.3. Caching If caching is required (e.g., to enable the use of alternative mechanisms for hosting, like Content Delivery Networks), the control of the caching mechanism SHOULD be implemented using the standard HTTP Cache-Control as defined in [RFC9111]. 7.4. Validation Rules 8. CWT Representations TBD Define parallel CWT representations for Status Lists and Referenced Tokens. TBD Declare whether JWT and CWT representations can be used interchangeably by the same issuer. For instance, declare whether a status list can reference both JWT and CWT tokens. 9. Security Considerations 9.1. Correct decoding and parsing of the encoded status list TODO elaborate on risks of incorrect parsing/decoding leading to erroneous status data Looker, et al. Expires 25 April 2024 [Page 11] Internet-Draft OAuth Status List October 2023 9.2. Cached and Stale status lists TODO consumers/Relying Party of the status list should be aware if they fetch the up-to-date data 9.3. Authorized access to the Status List TODO elaborate on authorization mechanisms preventing misuse and profiling as described in privacy section 9.4. History TODO elaborate on status list only providing the up-to date/latest status, no historical data, may be provided by the underlying hosting architecture 10. Privacy Considerations 10.1. Issuer tracking and Herd Privacy The main privacy consideration for a Status List, especially in the context of the Issuer-Holder-Verifier model, 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. 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. Looker, et al. Expires 25 April 2024 [Page 12] Internet-Draft OAuth Status List October 2023 10.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. 10.3. Relying Party tracking Once the Relying Party gets the Referenced Token, this enables him to request the Status List to validate the status of the Token through the provided "uri" property 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 inteded 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. This behaviour could be constrained by adding authorization rules to the Status List, see Section 9.3. 10.4. Correlation Risks and Tracking Colluding Issuers and Relying Parties have the possibility to identify the usage of credentials of a particular Holder, as the Referenced Token contains unique, trackable data. To avoid privacy risks for colluding Relying Parties, it is recommended that Issuers use batch issuance to issue multiple tokens, such that Holders can use individual tokens for specific Relying Parties. In this case, every Referenced Token MUST have a dedicated Status List entry. Revoking batch issued Referenced Tokens might reveal this correlation lateron. To avoid information leakage by the values of "uri" and "index", Issuers are RECOMMENDED to: * choose non-sequential, pseudo-random or random indices * use decoy or dead entries to obfuscate the real number of Referenced Tokens within a Status List Looker, et al. Expires 25 April 2024 [Page 13] Internet-Draft OAuth Status List October 2023 * choose to deploy and utilize multiple Status Lists simulantaniously 10.5. Third Party Hosting TODO elaborate on increased privacy if the status list is hosted by a third party instead of the issuer reducing tracking possiblities TODO evaluate deifnition of Status List Provider? An entity that hosts the Status List as a resource for potential Relying Parties. The Status List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party. 11. Implementation Considerations 12. IANA Considerations 12.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]. * Claim Name: status * Claim Description: Reference to a status list containing up-to- date status information on the JWT. * Change Controller: IETF * Specification Document(s): [[ (#jwt-referenced-token) of this specification ]] * Claim Name: status_list * Claim Description: A status list containing up-to-date status information on multiple other JWTs encoded as a bitarray. * Change Controller: IETF * Specification Document(s): [[ (#jwt-status-list-claim-format) of this specification ]] Looker, et al. Expires 25 April 2024 [Page 14] Internet-Draft OAuth Status List October 2023 12.2. 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 * Subtype name: statuslist+jwt * Required parameters: n/a * Optional parameters: n/a * Encoding considerations: binary; A JWT-based Status List is a JWT; JWT values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters. * Security considerations: See (#Security) 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: * File extension(s): n/a * Macintosh file type code(s): 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: binary * Security considerations: See (#Security) 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: * File extension(s): n/a * Macintosh file type code(s): 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 13. Normative References [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, . Looker, et al. Expires 25 April 2024 [Page 15] Internet-Draft OAuth Status List October 2023 [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, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . [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, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, . Acknowledgments We would like to thank Brian Campbell, Francesco Marino, Guiseppe De Marco, Kristina Yasuda, Michael B. Jones, Mike Prorock, Orie Steele, Timo Glastra and Torsten Lodderstedt Looker, et al. Expires 25 April 2024 [Page 16] Internet-Draft OAuth Status List October 2023 for their valuable contributions, discussions and feedback to this specification. Document History -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 Email: chris.bormann@gmx.de Looker, et al. Expires 25 April 2024 [Page 17]