Inclusion of a sha256 digest of the full username to the logical session id (in addition to the current guid) is necessary to fully disambiguate logical sessions in degraded clusters (when the authoritative record for a session is unreachable).

Semantics for the uid are as follows:

session creation via startSession()

• Sessions can only be created with one, and only one, user authenticated
• The composite key is created from a guid created on the spot, as well as the digest of the currently auth'd username
• Only the session guid is returned to the user
  • This prevents outside users from attempting to send back a value we'd have to check. It's preferable to decorate the guid with the user digest per command, rather than having to check a value the user might send.

session use for a command

• Sessions are passed via the lsid top level field in any command
• Sessions are only meaningful for commands which requireAuth. For sessions which don't require auth, we strip session information from the command at parse time
• Session ids are passed as an object, which can optionally include the username digest
  • It is illegal to pass the username digest unless the currently auth'd user has the impersonate privilege (the __system user does). This enables sessions on shard servers via mongos