Hi, Adding t.conch's ssh manhole (any third party IUsernamePassword provider would've done, really) to my app recently uncovered some unicode handling issues and I'm wondering what the appropriate way to resolve them is. In my API (AMP) there is a: - e-mail which is unicode - password which is unicode In my store (Axiom), there is a: - uid (unique user identifier, think UUID) which is bytes - e-mail which is unicode - password which is bytes, because it's the output of scrypt. scrypt also takes bytes as input: the password is first utf-8 encoded. Previously I was mistakenly handing around IUsernamePasswords where the e-mail address was unicode. Obviously the ICredentialsChecker implementation should take IUsernamePasswords that actually satisfy their contract and don't just pretend to, so ALL credentials it receives should have str/str, no exceptions. So, right now my credentials checker decodes the provided username to unicode in order to find the user by e-mail address (since, as mentioned above, Axiom thinks my e-mail addresses are unicode). The flip side of this is that the login method now first encodes the provided username and password as unicode. This is at least a semantically correct solution, but has the somewhat surprising property that in the 99.9% use case, the e-mail is received as unicode, immediately encoded, and then virtually straight after decoded again. That doesn't mean it's wrong, but it's a little weird. Potential solutions: 1. Make e-mail addresses bytes always. I don't know if this is semantically valid. 2. Add an IUnicodeUsernamePassword interface and implementation, and leaving adaptation to handle decoding/encoding. The downside here is that IIUC cred does not try to adapt to the ICredentialsChecker's supported interfaces, something I believe I complained about a few years back. cheers lvh