Section 2. Authorizing Connection Requests

This section specifies how Client connections are authorized by the
   AS and verified by the MQTT Broker.  Figure 1 shows the basic
   protocol flows during connection setup.  The token request and
   response use the token endpoint at the AS, specified for HTTP-based
   interactions in Section 5.8 of the ACE framework [RFC9200].  Steps
   (D) and (E) are optional and use the introspection endpoint specified
   in Section 5.9 of the ACE framework [RFC9200].  The discussion in
   this document assumes that the Client and the Broker use HTTPS to
   communicate with the AS via these endpoints.  The Client and the
   Broker use MQTT to communicate between them.  The C-AS and Broker-AS
   communications MAY be implemented using protocols other than HTTPS,
   e.g., CoAP or MQTT.  Whatever protocol is used for the C-AS and
   Broker-AS communications MUST provide mutual authentication,
   confidentiality protection, and integrity protection.
   If the Client is resource constrained or does not support HTTPS, a
   separate Client Authorization Server may carry out the token request
   on behalf of the Client (Figure 1, steps (A) and (B)) and, later,
   onboard the Client with the token.  The interactions between a Client
   and its Client Authorization Server for token onboarding and support
   for MQTT-based token requests at the AS are out of the scope of this
   document.
                                 +---------------------+
                                 | Client              |
                                 |                     |
      +---(A) Token request------| Client -            |
      |                          | Authorization       |
      |   +-(B) Access token-----> Server Interface    |
      |   |                      |       (HTTPS)       |
      |   |                      |_____________________|
      |   |                      |                     |
   +--v-------------+            |  Pub/Sub Interface  |
   |  Authorization |            |   (MQTT over TLS)   |
   |  Server        |            +----------------^----+
   |________________|                 |           |
      |    ^                 (C) Connection   (F) Connection
      |    |                     request +        response
      |    |                     access token     |
      |    |                          |           |
      |    |                      +---v--------------+
      |    |                      |     Broker       |
      |    |                      |  (MQTT over TLS) |
      |    |                      |__________________|
      |    +(D) Introspection-----|                  |
      |         request (optional)| RS-AS interface  |
      |                           |     (HTTPS)      |
      +-(E) Introspection-------->|__________________|
            response (optional)
                         Figure 1: Connection Setup
2.1.  Client Token Request to the Authorization Server (AS)
   The first step in the protocol flow (Figure 1, step (A)) is the token
   acquisition by the Client from the AS.  The Client and the AS MUST
   perform mutual authentication.  The Client requests an access token
   from the AS, as described in Section 5.8.1 of the ACE framework
   [RFC9200].  The document follows the procedures defined in
   Section 3.2.1 of the DTLS profile [RFC9202] for raw public keys
   (RPKs) [RFC7250]) and in Section 3.3.1 of [RFC7250] for pre-shared
   keys (PSKs).  However, the content type of the request is set to
   "application/ace+json", and the AS uses JSON in the Payload of its
   responses to the Client and the RS.  As explained earlier,
   implementations MAY also use the "application/ace+cbor" content type.
   On receipt of the token request, the AS verifies the request.  If the
   AS successfully verifies the access token request and authorizes the
   Client for the indicated audience (i.e., RS) and scopes (i.e.,
   publish/subscribe permissions over topics, as described in
   Section 2.3), the AS issues an access token (Figure 1, step (B)).
   The response includes the parameters described in Section 5.8.2 of
   the ACE framework [RFC9200].  For RPKs, the parameters are as
   described in Section 3.2.1 of the DTLS profile [RFC9202].  For PSKs,
   the document follows Section 3.3.1 of the DTLS profile [RFC9202].  In
   both cases, if the response contains an "ace_profile" parameter, this
   parameter is set to "mqtt_tls".  The returned token is a Proof-of-
   Possession (PoP) token by default.
   This document follows [RFC7800] for PoP semantics for JWTs (CWTs MAY
   also be used).  The AS includes a "cnf" (confirmation) parameter in
   the PoP token to declare that the Client possesses a particular key
   and the RS can cryptographically confirm that the Client has
   possession of that key, as described in [RFC9201].
   Note that the contents of the web tokens (including the "cnf"
   parameter) are to be consumed by the RS and not the Client (the
   Client obtains the key information in a different manner).  The RPK
   case is handled as described in Section 3.2.1 of the DTLS profile
   [RFC9202].  For the PSK case, the referenced procedures apply, with
   the following exceptions to accommodate JWT and JOSE use.  In this
   case, the AS adds a "cnf" parameter to the Access Information
   carrying a JSON Web Key (JWK) [RFC7517] object that contains either
   the symmetric key itself or a key identifier that can be used by the
   RS to determine the secret key it shares with the Client.  The JWT is
   created as explained in Section 7 of [RFC7519], and the JWT MUST
   include a JSON Web Encryption (JWE) [RFC7516].  If a CWT/COSE is
   used, this information MUST be inside the "COSE_Key" object and MUST
   be encrypted using a "COSE_Encrypt0" structure.
   The AS returns error responses for JSON-based interactions following
   Section 5.2 of [RFC6749].  When CBOR is used, the interactions MUST
   implement the procedure described in Section 5.8.3 of the ACE
   framework [RFC9200].
2.2.  Client Connection Request to the Broker (C)
2.2.1.  Overview of Client-RS Authentication Methods over TLS and MQTT
   Unless the Client publishes and subscribes to only public topics, the
   Client and the Broker MUST perform mutual authentication.  The Client
   MUST authenticate to the Broker either over MQTT or TLS before
   performing any other action.  For MQTT, the options are "None" and
   "ace".  For TLS, the options are "Anon" for an anonymous client, and
   "Known(RPK/PSK)" for RPKs and PSKs, respectively.  The "None" and
   "Anon" options do not provide client authentication but can be used
   either during authentication or in combination with authentication at
   the other layer.  When the Client uses TLS:Anon,MQTT:None, the Client
   can only publish or subscribe to public topics.  Thus, the client
   authentication procedures involve the following possible
   combinations:
   TLS:Anon,MQTT:None:
           This option is used only for the topics that do not require
           authorization, including the "authz-info" topic.  Publishing
           to the "authz-info" topic is described in Section 2.2.2.
   TLS:Anon,MQTT:ace:
           The token is transported inside the CONNECT packet and MUST
           be validated using one of the methods described in
           Section 2.2.2.  This option also supports a tokenless
           connection request for AS discovery.  As per the ACE
           framework [RFC9200], a separate step is needed to determine
           whether the discovered AS URI is authorized to act as an AS.
   TLS:Known(RPK/PSK),MQTT:none:
           This specification supports client authentication with TLS
           with RPKs and PSKs, following the procedures described in the
           DTLS profile [RFC9202].  For the RPK, the Client MUST have
           published the token to the "authz-info" topic.  For the PSK,
           the token MAY be published to the "authz-info" topic or MAY
           be, alternatively, provided as a "PSK identity" (e.g., an
           "identity" in the "identities" field in the Client's
           "pre_shared_key" extension in TLS 1.3).
   TLS:Known(RPK/PSK),MQTT:ace:
           This option SHOULD NOT be chosen as the token transported in
           the CONNECT packet and overwrites any permissions passed
           during the TLS authentication.
   It is RECOMMENDED that the Client implements TLS:Anon,MQTT:ace as the
   first choice when working with protected topics.  However, MQTT
   v3.1.1 Clients that do not prefer to overload the User Name and
   Password fields for ACE (as described in Section 6) MAY implement
   TLS:Known(RPK/PSK),MQTT:none and, consequently, TLS:Anon,MQTT:None to
   submit their token to "authz-info".
   The Broker MUST support TLS:Anon,MQTT:ace.  To support Clients with
   different capabilities, the Broker MAY provide multiple client
   authentication options, e.g., support TLS:Known(RPK),MQTT:none and
   TLS:Anon,MQTT:None, to enable RPK-based client authentication.
   The Client MUST authenticate the Broker during the TLS handshake.  If
   the Client authentication uses TLS:Known(RPK/PSK), then the Broker is
   authenticated using the respective method.  Otherwise, to
   authenticate the Broker, the Client MUST validate a public key from
   an X.509 certificate or an RPK from the Broker against the "rs_cnf"
   parameter in the token response, which contains information about the
   public key used by the RS to authenticate if the token type is "pop"
   and asymmetric keys are used as defined in [RFC9201].  The AS MAY
   include the thumbprint of the RS's X.509 certificate in the "rs_cnf"
   (thumbprint, as defined in [RFC9360]).  In this case, the Client MUST
   validate the RS certificate against this thumbprint.
2.2.2.  authz-info: The Authorization Information Topic
   In the cases when the Client must transport the token to the Broker
   first, the Client connects to the Broker to publish its token to the
   "authz-info" topic.  The "authz-info" topic MUST only be published
   (i.e., the Clients are not allowed to subscribe to it).  "authz-info"
   is not protected, and hence, the Client uses the TLS:Anon,MQTT:None
   option over a TLS connection.  After publishing the token, the Client
   disconnects from the Broker and is expected to reconnect using client
   authentication over TLS (i.e., TLS:Known(RPK/PSK),MQTT:none).
   The Broker stores and indexes all tokens received to the "authz-info"
   topic in its key store (similar to the DTLS profile for ACE
   [RFC9202]).  This profile follows the recommendation of
   Section 5.10.1 of the ACE framework [RFC9200] and expects that the
   Broker stores only one token per PoP key, and any other token linked
   to the same key overwrites an existing token.
   The Broker MUST verify the validity of the token (i.e., through local
   validation or introspection if the token is a reference), as
   described in Section 2.2.5.  If the token is not valid, the Broker
   MUST discard the token.
   Depending on the QoS level of the PUBLISH packet, the Broker returns
   the error response as a PUBACK, PUBREC, or DISCONNECT packet.  If the
   QoS level is equal to 0, and the token is not valid, or if the claims
   cannot be obtained in the case of an introspected token, the Broker
   MUST send a DISCONNECT packet with reason code 0x87 (Not authorized).
   If the PUBLISH Payload does not parse to a token, the Broker MUST
   send a DISCONNECT with reason code 0x99 (Payload format invalid).
   If the QoS level of the PUBLISH packet is greater than or equal to 1,
   and the token is not valid, or the claims cannot be obtained in the
   case of an introspected token, the Broker MUST send reason code 0x87
   (Not authorized) in the PUBACK or PUBREC.  If the PUBLISH Payload
   does not parse to a token, the PUBACK/PUBREC reason code is 0x99
   (Payload format invalid).
   When the Broker sends the "Not authorized" response, it must be noted
   that this corresponds to the token being not valid and not that the
   actual PUBLISH packet was not authorized.  Given that the "authz-
   info" is a public topic, this response is not expected to cause
   confusion.
2.2.3.  Client Authentication over TLS
   This document supports TLS with raw public keys (RPKs) [RFC7250] and
   with pre-shared keys (PSKs).  The TLS session setup follows the DTLS
   profile for ACE [RFC9202], as the profile applies to TLS equally well
   [RFC9430].  When there are exceptions to the DTLS profile, these are
   explicitly stated in the document.  If TLS 1.2 is used, [RFC7925]
   describes how TLS can be used for constrained devices, alongside
   recommended cipher suites.  Additionally, TLS 1.2 implementations
   MUST use the "Extended Main Secret" extension (terminology adopted
   from [TLS-bis]) to incorporate the handshake transcript into the main
   secret [RFC7627].  TLS implementations SHOULD use the Server Name
   Indication (SNI) [RFC6066] and Application-Layer Protocol Negotiation
   (ALPN) [RFC7301] extensions so the TLS handshake authenticates as
   much of the protocol context as possible.
2.2.3.1.  Raw Public Key Mode
   This document follows the procedures defined in Section 3.2.2 of the
   DTLS profile for ACE [RFC9202] with the following exceptions.  The
   Client MUST upload the access token to the Broker using the method
   specified in Section 2.2.2 before initiating the handshake.
2.2.3.2.  Pre-Shared Key Mode
   This document follows the procedures defined in Section 3.3.2 of the
   DTLS profile for ACE [RFC9202] with the following exceptions.
   To use TLS 1.3 with pre-shared keys, the Client utilizes the PSK
   extension specified in [RFC8446] using the key conveyed in the "cnf"
   parameter of the AS response.  The same key is bound to the access
   token in the "cnf" claim.  The Client can upload the token, as
   specified in Section 2.2.2, before initiating the handshake.  When
   using a previously uploaded token, the Client MUST indicate during
   the handshake which previously uploaded access token it intends to
   use.  To do so, it MUST create a "COSE_Key" or "JWK" structure with
   the "kid" that was conveyed in the "rs_cnf" claim in the token
   response from the AS and the key type "symmetric".  This structure is
   then included as the only element in the "cnf" structure and the
   encoded value of that "cnf" structure used as a PSK identity in TLS.
   As an alternative to the access token upload, the Client can provide
   the most recent access token, JWT or CWT, as a PSK identity.
   In contrast to the DTLS profile for ACE [RFC9202], a Client MAY omit
   support for the cipher suites TLS_PSK_WITH_AES_128_CCM_8 and
   TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8.  For TLS 1.2, however, a client
   MUST support TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 for PSKs [RFC8442]
   and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for RPKs [RFC8422], as
   recommended in [RFC9325] (and adjusted to be a PSK cipher suite as
   appropriate).
2.2.4.  Client Authentication over MQTT
2.2.4.1.  Transporting the Access Token inside the MQTT CONNECT
   This section describes how the Client transports the token to the
   Broker inside the CONNECT packet.  If this method is used, the Client
   TLS connection is expected to be anonymous, and the Broker is
   authenticated during the TLS connection setup.  The approach
   described in this section is similar to an earlier proposal by
   Fremantle, et al.  [Fremantle14].
   After sending the CONNECT packet, the Client MUST wait to receive the
   CONNACK packet from the Broker.  The only packets it is allowed to
   send are DISCONNECT or AUTH that are in response to the Broker AUTH.
   Similarly, except for a DISCONNECT and AUTH response from the Client,
   the Broker MUST NOT process any packets before sending a CONNACK
   packet.
   Figure 2 shows the structure of the MQTT CONNECT packet used in MQTT
   v5.0.  A CONNECT packet is composed of a Fixed Header, a Variable
   Header, and a Payload The Fixed Header contains the Control Packet
   Type (CPT), Reserved, and Remaining Length fields.  The Remaining
   Length is a Variable Byte Integer that represents the number of bytes
   remaining within the current Control Packet, including data in the
   Variable Header and the Payload.  The Variable Header contains the
   Protocol Name, Protocol Level, Connect flags, Keep Alive, and
   Properties fields.  The Connect flags in the Variable Header specify
   the properties of the MQTT Session.  It also indicates the presence
   or absence of some fields in the Payload.  The Payload contains one
   or more encoded fields, namely a unique Client Identifier for the
   Client, a Will Topic, Will Payload, User Name, and Password.  All but
   the Client Identifier can be omitted depending on the flags in the
   Variable Header.  The Client Identifier identifies the Client to the
   Broker and, therefore, is unique for each Client.  It must be noted
   that the Client Identifier is an unauthenticated identifier used
   within the MQTT protocol and so is not bound to the access token.
                      0             8             16
                      +---------------------------+
                      |Protocol name length = 4   |
                      +---------------------------+
                      |     'M'            'Q'    |
                      +---------------------------+
                      |     'T'            'T'    |
                      +---------------------------+
                      |Proto.level=5|Connect flags|
                      +---------------------------+
                      |        Keep alive         |
                      +---------------------------+
                      | CONNECT Properties Length |
                      |      (up to 4 bytes)      |
                      +---------------------------+
                      | ( ..Other properties..)   |
                      +---------------------------+
                      |  Authentication Method    |
                      |      (0x15)  |   Len      |
                      |      Len     |   'a'      |
                      |      'c'     |   'e'      |
                      +---------------------------+
                      |  Authentication Data      |
                      |     (0x16)   |    Len     |
                      |      Len     |   token    |
                      |  or token + PoP data      |
                      +---------------------------+
       Figure 2: MQTT v5 CONNECT Variable Header with Authentication
                          Method Property for ACE
   The CONNECT flags are User Name, Password, Will Retain, Will QoS,
   Will Flag, Clean Start, and Reserved.  Table 1 shows how the flags
   MUST be set to use AUTH packets for authentication and authorization,
   i.e., the User Name Flag and Password Flag MUST be set to 0.  An MQTT
   v5.0 Broker MAY also support token transport using the User Name and
   Password to provide a security option for MQTT v3.1.1 Clients, as
   described in Section 6.
    +===========+==========+========+======+======+=======+==========+
    | User Name | Password | Will   | Will | Will | Clean | Reserved |
    | Flag      | Flag     | Retain | QoS  | Flag | Start |          |
    +===========+==========+========+======+======+=======+==========+
    |     0     |    0     |   X    | X X  |  X   |   X   |    0     |
    +-----------+----------+--------+------+------+-------+----------+
                     Table 1: CONNECT Flags for AUTH
   The Will Flag indicates that a Will Message needs to be sent.  The
   Client MAY set the Will Flag as desired (marked as "X" in Table 1).
   If the Will Flag is set to 1, the Broker MUST check that the token
   allows the publication of the Will Message (i.e., the Will Topic
   Filter is in the scope array).  The check is performed against the
   token scope described in Section 2.3.  If the Will authorization
   fails, the connection is refused, as described in Section 2.4.1.  If
   the Broker accepts the connection request, the Broker stores the Will
   Message and publishes it when the Network Connection is closed
   according to Will QoS, Will Retain parameters, and MQTT Will
   management rules.  To avoid publishing the Will Messages in the case
   of temporary network disconnections, the Client specifies a Will
   Delay Interval in the Will Properties.  Section 5 explains how the
   Broker deals with the retained messages in further detail.
   In MQTT v5.0, the Client signals a new Session (i.e., that the
   Session does not continue an existing Session) by setting the Clean
   Start flag to 1 in the CONNECT packet.  In this profile, the Client
   SHOULD always start with a new Session.  The Broker MAY also signal
   that it does not support the continuation of an existing Session by
   setting the Session Expiry Interval to 0 in the CONNACK.  If the
   Broker starts a new Session, the Broker MUST set the Session Present
   flag to 0 in the CONNACK packet to signal this to the Client.
   The Broker MAY support continuing an existing Session, e.g., if the
   Broker requires it for QoS reasons.  In this case, if a CONNECT
   packet is received with Clean Start set to 0, and there is a Session
   associated with the Client Identifier, the Broker MUST resume
   communications with the Client based on the state from the existing
   Session.  In its response, the Broker MUST set the Session Present
   flag to 1 in the CONNACK packet to signal the continuation of an
   existing Session to the Client.  The Session State stored by the
   Client and the Broker is described in Section 5.
   When reconnecting to a Broker that supports continuing existing
   Sessions, the Client MUST still provide a token in addition to using
   the same Client Identifier and setting the Clean Start to 0.  The
   Broker MUST still perform PoP validation on the provided token.  If
   the token matches the stored state, the Broker MAY skip introspecting
   a token-by-reference and use the stored introspection result.  The
   Broker MUST also verify the Client is authorized to receive or send
   MQTT packets that are pending transmission.  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.  Brokers SHOULD implement administrative policies to limit
   misuse.
   Note that, according to the MQTT standard, the Broker uses the Client
   Identifier to identify the Session State.  In the case of a Client
   Identifier collision, a Client may take over another Client's
   Session.  Given that the Broker MUST associate the Client with a
   valid token, a Client will only send or receive messages to its
   authorized topics.  Therefore, while this issue is not expected to
   affect security, it may affect QoS (i.e., PUBLISH or QoS messages
   saved for Client A may be delivered to a Client B).  In addition, if
   this Client Identifier represents a Client already connected to the
   Broker, the Broker sends a DISCONNECT packet to the existing Client
   with reason code 0x8E (Session taken over) and closes the connection
   to the Client.
2.2.4.2.  Authentication Using the AUTH Property
   Figure 2 shows the Authentication Method and Authentication Data
   fields when the client authenticates using the AUTH property.  The
   Client MUST set the Authentication Method as a property of a CONNECT
   packet by using the property identifier 21 (0x15).  This is followed
   by a UTF-8-encoded string containing the name of the Authentication
   Method, which MUST be set to "ace".  If the Broker does not support
   this profile, it sends a CONNACK packet with reason code 0x8C (Bad
   authentication method).
   The Authentication Method is followed by the Authentication Data,
   which has a property identifier 22 (0x16) and is Binary Data.  Based
   on the Authentication Data, the Broker MUST support both options
   below:
   *  proof of possession using a challenge from the TLS session
   *  proof of possession via a Broker-generated challenge/response
2.2.4.2.1.  Proof of Possession Using a Challenge from the TLS Session
   +-----------------------------------------------------------------+
   |Authentication|Token Length|Token   |MAC or Signature            |
   |Data Length   |            |        |(over TLS exporter content) |
   +-----------------------------------------------------------------+
    Figure 3: Authentication Data for PoP Based on TLS Exporter Content
   For this option, the Authentication Data inside the Client's CONNECT
   packet MUST contain the two-byte integer token length, the token, and
   the keyed message digest (MAC) or the Client signature (as shown in
   Figure 3).  The Proof-of-Possession key in the token is used to
   calculate the keyed message digest (MAC) or the Client signature
   based on the content obtained from the TLS exporter ([RFC5705] for
   TLS 1.2 and Section 7.5 of [RFC8446] for TLS 1.3).  This content is
   exported from the TLS session using the exporter label "EXPORTER-ACE-
   MQTT-Sign-Challenge", an empty context, and a length of 32 bytes.
   The token is also validated, as described in Section 2.2.5, and the
   Broker responds with a CONNACK packet with the appropriate response
   code.  The Client cannot reauthenticate using this method during the
   same TLS session (see Section 4).
2.2.4.2.2.  Proof of Possession via Broker-generated Challenge/Response
   +------------------------------------+
   |Authentication|Token Length|Token   |
   |Data Length   |            |        |
   +------------------------------------+
     Figure 4: Authentication Data to Initiate PoP Based on Challenge/
                                  Response
   +--------------------------+
   |Authentication|RS Nonce   |
   |Data Length   |(8 bytes)  |
   +--------------------------+
             Figure 5: Authentication Data for Broker Challenge
   For this option, the Broker follows a Broker-generated challenge/
   response protocol.  If the Authentication Data inside the Client's
   CONNECT contains only the two-byte integer token length and the token
   (as shown in Figure 4), the Broker MUST respond with an AUTH packet
   with the authenticated reason code set to 0x18 (Continue
   Authentication).  The Broker also uses this method if the
   Authentication Data does not contain a token, but the Broker has a
   token stored for the connecting Client.
   The Broker continues authentication using an AUTH packet that
   contains the Authentication Method and the Authentication Data.  The
   Authentication Method MUST be set to "ace", and the Authentication
   Data MUST NOT be empty and MUST contain an 8-byte RS nonce as a
   challenge for the Client (Figure 5).
   +---------------------------------------------------------+
   |Authentication|Client Nonce |MAC or Signature            |
   |Data Length   |(8 bytes)    |(over RS nonce+Client nonce)|
   +---------------------------------------------------------+
      Figure 6: Authentication Data for the Client Challenge Response
   The Client responds to this with an AUTH packet with reason code 0x18
   (Continue Authentication).  Similarly, the Client packet sets the
   Authentication Method to "ace".  The Authentication Data in the
   Client's response is formatted as shown in Figure 6 and includes the
   8-byte Client nonce and the signature or MAC computed over the RS
   nonce concatenated with the Client nonce using PoP key in the token.
   Next, the token is validated as described in Section 2.2.5.  The
   success case is illustrated in Figure 7.  The Client MAY also
   reauthenticate using this challenge-response flow, as described in
   Section 4.
           Client      Broker
            |             |
            |<===========>| TLS connection setup
            |             |
            |             |
            +------------>| CONNECT with Authentication Data
            |             | contains only token
            |             |
            <-------------+ AUTH 0x18 (Cont. Authentication)
            |             | 8-byte RS nonce as challenge
            |             |
            |------------>| AUTH 0x18 (Cont. Authentication)
            |             | 8-byte Client nonce + signature/MAC
            |             |
            |             |---+ Token validation
            |             |   | (may involve introspection)
            |             |<--+
            |             |
            |<------------+ CONNACK 0x00 (Success)
              Figure 7: PoP Challenge/Response Flow - Success
2.2.5.  Broker Token Validation
   The Broker MUST verify the validity of the token either locally
   (e.g., in the case of a self-contained token) or MAY send a request
   to the introspection endpoint of the AS (as described for HTTP-based
   interactions in Section 5.9 of the ACE framework [RFC9200]).  The
   Broker MUST verify the claims in the access token according to the
   rules set in Section 5.10.1.1 of the ACE framework [RFC9200].
   To authenticate the Client, the Broker validates the signature or the
   MAC, depending on how the PoP protocol is implemented.  For self-
   contained tokens, the Broker MUST process the security protection of
   the token first, as specified by the respective token format, i.e., a
   CWT uses COSE, while a JWT uses JOSE.  For a token-by-reference, the
   Broker uses the "cnf" structure returned as a result of token
   introspection, as specified in [RFC7519].  HMAC-SHA-256 (HS256)
   [RFC6234] and Ed25519 [RFC8032] are mandatory to implement for the
   Broker.  The Client MUST implement at least one of them depending on
   the choice of symmetric or asymmetric validation.  Validation of the
   signature or MAC MUST fail if the signature algorithm is set to
   "none" when the key used for the signature algorithm cannot be
   determined or the computed and received signature/MAC do not match.
   The Broker MUST check if the access token is still valid, if it is
   the intended destination (i.e., the audience) of the token, and if
   the token was issued by an authorized Authorization Server.  If the
   Client is using TLS RPK mode to authenticate to the Broker, the AS
   constructs the access token so that the Broker can associate the
   access token with the Client's public key.  The "cnf" claim MUST
   contain either the Client's RPK or, if the key is already known by
   the Broker (e.g., from previous communication), a reference to it.
2.3.  Token Scope and Authorization
   The scope field contains the publish and subscribe permissions for
   the Client.  Therefore, the token or its introspection result MUST be
   cached to allow a Client's future PUBLISH and SUBSCRIBE messages.
   During the CONNECT, if the Will Flag is set to 1, the Broker MUST
   also authorize the publication of the Will Topic and Will Message
   using the token's scope field.  The Broker uses the scope to match
   against the Topic Name in a PUBLISH packet (including Will Topic in
   the CONNECT) or a Topic Filter in a SUBSCRIBE packet.
   The scope in the token is a single value.  For a JWT, the single
   scope is a base64url-encoded string with any padding characters
   removed, which has an internal structure of a JSON array.  For a CWT,
   this information is represented in CBOR.  The internal structure
   follows the Authorization Information Format (AIF) for ACE [RFC9237].
   Using the Concise Data Definition Language (CDDL) [RFC8610], the
   specific data model for MQTT is:
    AIF-MQTT = AIF-Generic<mqtt-topic-filter, mqtt-permissions>
    AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]]
    mqtt-topic-filter = tstr ; as per Section 4.7 of MQTT v5.0
    mqtt-permissions = [+permission]
    permission = "pub"/"sub"
                       Figure 8: AIF-MQTT Data Model
   Topic Filters are implemented according to Section 4.7 of the MQTT
   v5.0 OASIS Standard [MQTT-OASIS-Standard-v5].  By default, Wildcard
   Subscriptions are supported, and so, the Topic Filter may include
   special wildcard characters.  The multi-level wildcard, "#", matches
   any number of levels within a topic, and the single-level wildcard,
   "+", matches one topic level.  The Broker MAY signal in the CONNACK
   explicitly whether Wildcard Subscriptions are supported by returning
   a CONNACK property "Wildcard Subscription Available".  A value of 0
   means that Wildcard Subscriptions are not supported.  A value of 1
   means Wildcard Subscriptions are supported.
   Following this model, an example scope may contain:
    [["topic1",["pub","sub"]],["topic2/#",["pub"]],["+/topic3",["sub"]]]
                          Figure 9: Example Scope
   This access token gives publish ("pub") and subscribe ("sub")
   permissions to the "topic1", publish permission to all the subtopics
   of "topic2", and subscribe permission to all "topic3", skipping one
   level.
   If the scope is empty, the Broker records no permissions for the
   Client for any topic.  In this case, the Client is not able to
   publish or subscribe to any protected topics.  The non-empty scope is
   used to authorize the Will Topic, if provided, in the CONNECT packet,
   during connection setup and, if the connection request succeeds, the
   Topic Names or Topic Filters requested in the future PUBLISH and
   SUBSCRIBE packets.  For the authorization to succeed, the Broker MUST
   verify that the Topic Name or Topic Filter in question is either an
   exact match to or a subset of at least one "topic_filter" in the
   scope.
2.4.  Broker Response to Client Connection Request
   Based on the validation result (obtained either via local inspection
   or using the introspection interface of the AS), the Broker MUST send
   a CONNACK packet to the Client.
2.4.1.  Unauthorized Request and the Optional Authorization Server
        Discovery
   Authentication can fail for the following reasons:
   *  if the Client does not provide a valid token,
   *  the Client omits the Authentication Data field and the Broker has
      no token stored for the Client,
   *  the token or Authentication data are malformed, or
   *  if the Will Flag is set, the authorization checks for the Will
      Topic fails.
   The Broker responds with the CONNACK reason code 0x87 (Not
   Authorized) or any other applicable reason code.
   The Broker MAY also trigger AS discovery and include a User Property
   (identified as property type 38 (0x26)) in the CONNACK for the AS
   Request Creation Hints.  The User Property is a UTF-8 string pair,
   composed of a name and a value.  The name of the User Property MUST
   be set to "ace_as_hint".  The value of the User Property is a UTF-
   8-encoded JSON object containing the mandatory "AS" parameter and the
   optional parameters "audience", "kid", "cnonce", and "scope", as
   defined in Section 5.3 of the ACE framework [RFC9200].
2.4.2.  Authorization Success
   On success, the reason code of the CONNACK is 0x00 (Success).  If the
   Broker starts a new Session, it MUST also set Session Present to 0 in
   the CONNACK packet to signal a new Session to the Client.  Otherwise,
   it MUST set Session Present to 1.
   Having accepted the connection, the Broker MUST be prepared to store
   the token during the connection and after disconnection for future
   use.  If the token is not self-contained and the Broker uses token
   introspection, it MAY cache the validation result to authorize the
   subsequent PUBLISH and SUBSCRIBE packets.  PUBLISH and SUBSCRIBE
   packets, which are sent after a connection setup, do not contain
   access tokens.  If the introspection result is not cached, the Broker
   needs to introspect the saved token for each request.  The Broker
   SHOULD also use a cache timeout to introspect tokens regularly.  The
   timeout value is specific to the application and should be chosen to
   reduce the risk of using stale introspection responses.