Section 2.2.3 - the client state MUST include the token

[ciseng]

Jim's review:
Section 2.2.3 - I think that the client state MUST include the token and
either the same token is supplied or a token with the same key is supplied
in order to match with an existing state.

[ciseng]

I used a MAY because:1) MQTT originally identifies resuming client with only client id. 2) The client MUST still provide a token when reconnecting and continuing a session, and the broker MUST perform a validation. 
If the broker additionally keeps the former token then it can do further matches to check if the new token is matching the old token, further confirming that it's the same client. 

The client may have gotten a new token, as it may know its token has expired, or it just expanded its right between sessions. The CONNECT message does not specify how clients can push a historical and a new token. 
It may be seen as an issue that the broker authorises the current session (not the continuation of the session) and uses the MQTT way to access the session state by only the Client ID. A problem may be that client A uses client_id1, disconnects and then client B connects with client_id1, both using session continuation.  Then, the risk is client A's subscribed topics may be delivered to client B because client B's token has the same set of permissions. This is acceptable as client B's token already covers those topics (it may have QoS issues for client A). 

[ciseng]

As discussed in 108 WG meeting: Keep may, explain what may happen if Client IDs clash.

[ciseng]

Made the following text changes - commit 51f08c5

" Note that, according to the MQTT standard, the Broker must use 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 clients provide a token at each connection, clients will only send or receive messages to their 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 of '0x8E (Session taken over)',
and closes the connection to the client. "