So as I understand it, mm 2.2 is dropping email reminders of passwords. This has made me think that we'd like more support for 'passwordless' manipulation of the UI.
I've come up with a few approaches for this, and I'd like to get feedback as to what would be acceptable. Please keep in mind I'll allow administrators to require more authentication than I outline below.
- Use case A: an email is a member of a mailing list but has never logged into the interface.
I was thinking it would be ok in this context to allow a user-agent to approach the interface and provide only the email address to be "provisionally authenticated"; they would be allowed to manipulate the member's settings. Once they were done doing so, an email would be sent to the address that required clicking on a confirmation link to make the changes active.
- Use case B: a user-agent presents an email that has used the interface previously. If the user-agent presents a visitation cookie that was active during the previous manipulation, the user is provisionally authenticated again, and gets a similar confirmation email.
If they did *not* have a matching visitation cookie, or present another this-is-really-me token, they would not be allowed to manipulate the interface until they click a email-verification link.
- Use case C: Some other code (an upstream process, OpenId server, etc) provides a username for a user. In this case we accept the user as authenticated, and either use our map of username-> email addresses for purposes of determining membership or accept an email_addresses list from the WSGI environment or from the remote server/other process.
If only the username is provided, the user is given the opportunity to indicate which email addressess should be associated with that username; once they have done so, verification emails are sent to said addresses, and post reply/link activation mailman considers those emails to be associated with that username.
Does this stuff sound reasonable?
~ethan fremen