...

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users?
• If we are changing behavior how will we phase out the older behavior?
• If we need special migration tools, describe them here.
• When will we remove the existing behavior?

Rejected Alternatives

There is no impact to existing installations because the default is for the feature to be turned off.

Rejected Alternatives

An alternative idea is to add two new request types: "receive re-authentication nonce" and "re-authenticate with nonce".  When re-authentication needs to occur the client would make a separate, new connection to the broker and then send the "receive re-authentication nonce" request to the broker to have it associate a nonce with the credentials and return the nonce to the client.  Then the client would send the  "re-authenticate with nonce" request with the returned nonce over the connection that it wishes to re-authenticate; the broker would then replace the credentials on that connection with the credentials it had previously associated with the nonce.  I don't know if this would work, but if it could work then it does have the advantage of requiring the injection of just a single request over an existing connection that would return very quickly rather than 3 separate requests of which at least one might take a while to return (to retrieve a public key for token signature validation, for example)If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.