If we are doing this, it may be worthwhile to plan for a session scheme that also accomodates single-sign-on across a number of systems (so that HAT could be used as the authentication provider for other systems or another trusted system could be used as the authentication provider for HAT).
The single-sign-on capabilities are interesting for HPP-type applications that want to offer services to HAT owners. Those could then forgo their own authentication mechanism and rely on the HAT session
A scheme that has recently gained popularity are JSON Web Tokens ( http://jwt.io/ )
With that, HAT could issue a signed claim to the user that includes her account id (i.e. email) and that could be used as a session token for HAT and other relying parties.
Conversely, HAT could be set up to trust signed claims from a separate authentication component (which could enforce additional measures such as 2FA)
The main advantage over "traditional" session tokens are that the system is stateless (no shared database required), the main disadvantage is that there is no good way to implement "logout" or revokation (tokens will remain valid until the specified expiration date, so the token needs to be short-lived or there needs to be a separate and revokable refresh token).