zilinlin/RFC2PSM huggingface dataset:
Section 4. Token Expiration, Update, and Reauthentication

The Broker MUST check for token expiration whenever a CONNECT,
   PUBLISH, or SUBSCRIBE packet is received or sent.  The Broker SHOULD
   check for token expiration on receiving a PINGREQ packet.  The Broker
   MAY also check for token expiration periodically, e.g., every hour.
   This may allow for early detection of a token expiry.
   The token expiration is checked by checking the "exp" claim of a JWT
   or introspection response or via performing an introspection request
   with the AS, as described in Section 5.9 of the ACE framework
   [RFC9200].  Token expirations may trigger the Broker to send PUBACK,
   SUBACK, and DISCONNECT packets with the return code set to "Not
   authorized".  After sending a DISCONNECT packet, the Network
   Connection is closed, and no more messages can be sent.
   The Client MAY reauthenticate a response to PUBACK and SUBACK, which
   signal loss of authorization.  The Clients MAY also proactively
   update their tokens, i.e., before they receive a packet with a "Not
   authorized" return code.  To start reauthentication, the Client MUST
   send an AUTH packet with reason code 0x19 (Reauthentication).  The
   Client MUST set the Authentication Method as "ace" and transport the
   new token in the Authentication Data.  If reauthenticating during the
   current TLS session, the Client MUST NOT use the method described in
   Section 2.2.4.2.1, i.e., proof of possession using a challenge from
   the TLS session, to avoid reusing the same challenge value from the
   TLS-Exporter.  Note that this means that servers will either need to
   record in the session ticket or database entry whether the TLS-
   Exporter-derived challenge was used or always deny use of the TLS-
   Exporter-derived challenge for resumed sessions.  In TLS 1.3, the
   resumed connection would have a new exporter value, but the
   requirement is phrased this way for simplicity.  For
   reauthentications in the same TLS-session, the Client MUST use the
   challenge-response PoP, as defined in Section 2.2.4.2.2.  The Broker
   accepts reauthentication requests if the Client has already submitted
   a token (may be expired), for which it performed proof of possession.
   Otherwise, the Broker MUST deny the request.  If the reauthentication
   fails, the Broker MUST send a DISCONNECT packet with reason code 0x87
   (Not Authorized).
Section 5. Handling Disconnections and Retained Messages

In the case of a Client DISCONNECT, if the Session Expiry Interval is
   set to 0, the Broker doesn't store the Session State but MUST keep
   the retained messages.  If the Broker stores the Session State, the
   state MAY include the token and its introspection result (for
   reference tokens) in addition to the MQTT Session State.  The MQTT
   Session State is identified by the Client Identifier and includes the
   following:
   *  the Client Subscriptions,
   *  messages with QoS levels 1 and 2, which have not been completely
      acknowledged or are pending transmission to the Client, and
   *  if the Session is currently not connected, the time at which the
      Session will end and the Session State will be discarded.
   The token/introspection state is not part of the MQTT Session State,
   and PoP validation is required for each new connection, regardless of
   whether existing MQTT Sessions are continued.
   The messages to be retained are indicated to the Broker by setting a
   RETAIN flag in a PUBLISH packet.  This way, the publisher signals to
   the Broker to store the most recent message for the associated topic.
   Hence, the new subscribers can receive the last sent message from the
   publisher for that particular topic without waiting for the next
   PUBLISH packet.  The Broker MUST continue publishing the retained
   messages as long as the associated tokens are valid.  In the MQTT
   standard, if QoS is 0 for the PUBLISH packet, the Broker may discard
   the retained message any time.  For QoS > 1, the message expiry
   interval dictates how long the retained message is kept.  However, it
   is important that the Broker avoids sending messages indefinitely for
   the Clients that never update their tokens (i.e., the Client connects
   briefly with a valid token, sends a PUBLISH packet with the RETAIN
   flag set to 1 and QoS > 1, disconnects, and never connects again).
   Therefore, the Broker MUST use the minimum of the token expiry and
   message expiry interval to discard a retained message.
   In case of disconnections due to network errors or server
   disconnection due to a protocol error (which includes authorization
   errors), the Will Message is sent if the Client supplied a Will in
   the CONNECT packet.  The Client's token scope array MUST include the
   Will Topic.  The Will Message MUST be published to the Will Topic,
   regardless of whether the corresponding token has expired (as it has
   been validated and accepted during CONNECT).
Section 7. IANA Considerations

7.1.  TLS Exporter Labels Registration
   This document registers "EXPORTER-ACE-MQTT-Sign-Challenge"
   (introduced in Section 2.2.4.2.1 in this document) in the "TLS
   Exporter Labels" registry [RFC8447].
   Recommended:  N
   DTLS-OK:  N
   Reference:  RFC 9431
7.2.  Media Type Registration
   This document registers the "application/ace+json" media type for
   messages of the protocols defined in this document carrying
   parameters encoded in JSON.
   Type name:  application
   Subtype name:  ace+json
   Required parameters:  N/A
   Optional parameters:  N/A
   Encoding considerations:  Encoding considerations are identical to
      those specified for the "application/json" media type.
   Security considerations:  Section 8 of RFC 9431
   Interoperability considerations:  none
   Published specification:  RFC 9431
   Applications that use this media type:  This media type is intended
      for Authorization-Server-Client and Authorization-Server-Resource-
      Server communication as part of the ACE framework using JSON
      encoding, as specified in RFC 9431.
   Fragment identifier considerations:  none
   Additional information:
      Deprecated alias names for this type:  none
      Magic number(s):  none
      File extension(s):  none
      Macintosh file type code(s):  none
   Person & email address to contact for further information:
      Cigdem Sengul <csengul@acm.org>
   Intended usage:  COMMON
   Restrictions on usage:  none
   Author:  Cigdem Sengul <csengul@acm.org>
   Change controller:  IETF
7.3.  ACE OAuth Profile Registration
   The following registrations have been made in the "ACE Profiles"
   registry, following the procedure specified in [RFC9200].
   Name:  mqtt_tls
   Description:  Profile for delegating Client authentication and
      authorization using MQTT for the Client and Broker (RS)
      interactions and HTTP for the AS interactions.  TLS is used for
      confidentiality and integrity protection and server
      authentication.  Client authentication can be provided either via
      TLS or using in-band PoP validation at the MQTT application layer.
   CBOR Value:  3
   Reference:  RFC 9431
7.4.  AIF
   For the media types "application/aif+cbor" and "application/
   aif+json", defined in Section 5.1 of [RFC9237], IANA has registered
   the following entries for the two media type parameters Toid and
   Tperm in the respective subregistry defined in Section 5.2 of
   [RFC9237] within the "Media Type Sub-Parameter Registries".
   For Toid:
      Name:  mqtt-topic-filter
      Description/Specification:  Topic Filter, as defined in
         Section 2.3 of RFC 9431.
      Reference:  RFC 9431, Section 2.3
   For Tperm:
      Name:  mqtt-permissions
      Description/Specification:  Permissions for the MQTT Client, as
         defined in Section 2.3 of RFC 9431.  Tperm is an array of one
         or more text strings that each have a value of either "pub" or
         "sub".
      Reference:  RFC 9431, Section 2.3
Section 8. Security Considerations

This document specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework [RFC9200].
   Therefore, the security considerations outlined in [RFC9200] apply to
   this work.
   In addition, the security considerations outlined in the MQTT v5.0
   OASIS Standard [MQTT-OASIS-Standard-v5] and MQTT v3.1.1 OASIS
   Standard [MQTT-OASIS-Standard-v3.1.1] apply.  Mainly, this document
   provides an authorization solution for MQTT, the responsibility of
   which is left to the specific implementation in the MQTT standards.
   In the following, we comment on a few relevant issues based on the
   current MQTT specifications.
   After the Broker validates an access token and accepts a connection
   from a client, it caches the token to authorize a Client's publish
   and subscribe requests in an ongoing Session.  The Broker does not
   cache any tokens that cannot be validated.  If a Client's permissions
   get revoked, but the access token has not expired, the Broker may
   still grant publish/subscribe to revoked topics.  If the Broker
   caches the token introspection responses, then the Broker SHOULD use
   a reasonable cache timeout to introspect tokens regularly.  The
   timeout value is application specific and should be chosen to reduce
   the risk of using stale introspection responses.  When permissions
   change dynamically, it is expected that the AS also follows a
   reasonable expiration strategy for the access tokens.
   The Broker may monitor Client behavior to detect potential security
   problems, especially those affecting availability.  These include
   repeated token transfer attempts to the public "authz-info" topic,
   repeated connection attempts, abnormal terminations, and Clients that
   connect but do not send any data.  If the Broker supports the public
   "authz-info" topic, described in Section 2.2.2, then this may be
   vulnerable to a DDoS attack, where many Clients use the "authz-info"
   public topic to transport tokens that are not meant to be used and
   that the Broker may need to store until they expire.
   For MQTT v5.0, when a Client connects with a long Session Expiry
   Interval, the Broker may need to maintain the Client's MQTT Session
   State after it disconnects for an extended period.  For MQTT v3.1.1,
   the Session State may need to be stored indefinitely, as it does not
   have a Session Expiry Interval feature.  The Broker SHOULD implement
   administrative policies to limit misuse by the Client resulting from
   continuing existing Sessions.
Section 9. Privacy Considerations

The privacy considerations outlined in [RFC9200] apply to this work.
   In MQTT, the Broker is a central trusted party and may forward
   potentially sensitive information between Clients.  The mechanisms
   defined in this document do not protect the contents of the PUBLISH
   packet from the Broker, and hence, the content of the PUBLISH packet
   is not signed or encrypted separately for the subscribers.  This
   functionality may be implemented using the proposal outlined in the
   ACE Pub-Sub Profile [ACE-PUBSUB-PROFILE].  However, this solution
   would still not provide privacy for other fields of the packet, such
   as Topic Name.
Section Appendix A. Checklist for Profile Requirements

Based on the requirements on profiles for the ACE framework
   [RFC9200], this document fulfills the following:
   *  Optional AS discovery: AS discovery is supported with the MQTT
      v5.0 described in Section 2.2.
   *  The communication protocol between the Client and Broker (RS):
      MQTT
   *  The security protocol between the Client and RS: TLS
   *  Client and RS mutual authentication: Several options are possible
      and described in Section 2.2.1.
   *  Proof-of-possession protocols: Both symmetric and asymmetric keys
      are supported, as specified in Section 2.2.4.2.
   *  Content-Format: For the HTTPS interactions with AS, "application/
      ace+json".
   *  Unique profile identifier: mqtt_tls
   *  Token introspection: The RS uses the HTTPS introspection interface
      of the AS.
   *  Token request: The Client or its Client AS uses the HTTPS token
      endpoint of the AS.
   *  authz-info endpoint: It MAY be supported using the method
      described in Section 2.2.2 but is not protected other than by the
      TLS channel between the Client and RS.
   *  Token transport: Via the "authz-info" topic, TLS with PSKs
      (provided as a PSK identity), or in the MQTT CONNECT packet for
      both versions of MQTT.  The AUTH extensions can also be used for
      authentication and reauthentication for MQTT v5.0, as described in
      Sections 2.2 and 4.
Acknowledgments
   The authors would like to thank Ludwig Seitz for his review and his
   input on the authorization information endpoint; Benjamin Kaduk for
   his review, insightful comments, and contributions to resolving
   issues; and Carsten Bormann for his review and revisions to the AIF-
   MQTT data model.  The authors would like to thank Paul Fremantle for
   the initial discussions on MQTT v5.0 support.
Authors' Addresses
   Cigdem Sengul
   Brunel University
   Dept. of Computer Science
   Uxbridge
   UB8 3PH
   United Kingdom
   Email: csengul@acm.org
   Anthony Kirby
   Oxbotica
   1a Milford House
   Mayfield Road, Summertown
   Oxford
   OX2 7EL
   United Kingdom
   Email: anthony@anthony.org