Understood, but you're use case #1
I don't have your IWE experience, so your answers would help design the "casual" system. But, it sounds like you're still one design level up from that--still trying to determine market foci. I do think you're going to find different styles for different markets (it's a Prego problem: [link|http://www.gladwell.com/2004/2004_09_06_a_ketchup.html|http://www.gladwell....06_a_ketchup.html]), but short of a major research investment, I'm not sure how far you'll get determining those. The stickier issue is that authentication systems tend to be tightly integrated into applications, so an "administrative setting" will be tough. It might be best to just make your auth system as pluggable as possible and wait for requests from deployers.
Anyway, here's my best guess on where those segments would center and their requirements:
1. Relaxed: Adding an account is very easy, 1 step if possible, but keep the spam low through restrictions (quotas, IP address auditing). Forgotten passwords are emailed in plain text.
2. Strict: Adding accounts is two-factor, multiple steps (I've used folkert's email-a-URL before and it works well). Changing your pw if you already know it is easy. If you don't, resetting it should be subject to the _same_ auth process as creating it (need an email or IP or ..? in addition to name). In other words, if you're going to make resetting tough, make account creation equally tough.
3. Corporate: Restricted set of users; accounts are hard to get and not administered via the web. Make IIS or PAM handle it for the first release, then add your own later on if needed. All auth traffic is out-of-band.
4. Paranoid: Private keys. :)
