1. Beyond Pidgen (initial forced-setting event) and MyVT (user-driven setting event), should there be other places where sspr preferences should be set?
2. Should the "allow me to call 4Help" option be true as default?
3. What should we say to the user concerning the use/exposure of their cell number?
4. Should we be concerned about the sms message being intercepted if we only accept the message if it is given through the current web session it was sent from?
5. Is this a sufficient secret key:
    SecureRandom random = new SecureRandom();
           String skey = new BigInteger(35, random).toString(32);  (this results in 7 alphanumeric characters like '7a0ltar' - noting that alpha characters are lowercased.)
6. How long should the sms key be good for (e.g. 5 minutes?)?
7. Is VT ID and otp2sms sufficient for authentication?
8. Should the user be allowed to setup more than 1 remote id provider?
9. Is VT ID and a single successful remote auth event sufficient for authentication?
10. Do we need something else like captcha to slow the app down to mitigate scripting?
11. Are there architectural concerns with the SOA proposal?
12. Should we employ REST for the authentication service, and if so, how should we authenticate requests?

Attendees

Kevin Rooney, Karen Herrington, Marc DeBonis, Michael Hosig, Marvin Addison, Daniel Fisher, David Hawes (teleconference), Greg Kroll, Mary Dunker, Susan Brooker-Gross, Kim Homer, Nate Smith, Doug Atwater

Meeting Notes

• Kevin gave a brief description of the project. This is more than just a password reset project; it is also a way to collect user preferences for resetting password.
• For Hokies password, you would have another category that is "have ou admin reset password".
• a "proof of concept demo"
• in favor of being forced on all users after pidgen
  • notify user they can change settings later
• when user calls 4Help for a password reset they should be forced to set preferences when they reset their temporary password
• make user review (and possibly reset) preferences every time they reset their password through MyVT, no matter how many times that occurs (password resets in general are infrequent). Marvin is in favor of presenting the user preferences every time a user goes to password reset tool since it is only a couple of radio buttons
• many freshman forget their password especially those that create a pid early so most likely they would encounter a review of their preferences at least twice
• we cannot automatically use the number a user gave to VT Alerts according to Carl Harris, however, Carl will check with Univ. Relations to see if we could present the user with a question that says something to the effect that we already have your phone number for VT Alerts purpose can we just use that, possibly without showing the user that phone number. This may be a problem politically that we do not want to take on as it may slow down the project.
• DEMO
  • we should use the words "text messaging" as opposed to "cell phone" or "mobile phone" (mobile phone is used in VT Alerts)
  • discussion about using Banner as the "single" system of record however this may present workflow or usability issues
  • discussion about whether to ask a user for their phone number or "mine" that data and present a list to them. Is this complexity worth the effort?
  • questions about tying the sms message to a web session, or specific tab, or browser, etc.
  • saying anything about OpenID to the user is going to be tricky as most users don't know what it is
  • unchecking the "Allow me to call 4Help to reset my password" option is a conscious decision of user (it is check by default) to not use this method. This means the user would have to come in person to have a password reset if no other options were possible. This option should be programmatically enforced if possible.
  • we will need "state management" in order to manage the number of messages sent to user. The question then becomes what would we do if a user calls and says they are getting multiple messages, what options do we have. Need abuse option
  • perhaps using VT ID number for authentication is not enough. Perhaps use ID # and PID? Having the PID would allow more options like throwing up a capcha to stop scripts/spamming
  • need methods to prevent spam and abuse. May use a number (3, 4, 5) of attempts to be the maximum before halting and requiring a call in
  • once preferences are selected it would be a good idea to present the user with a message asking if they are sure they want these preferences
  • OpenID providers for demo Google & Yahoo. Other providers are possible, e.g., LiveID For usability we may want to present numbered steps for the user to follow rather than a paragraph of text. Perhaps in those numbered steps you could use a UI graphic to indicate to user where they are in the process
• should all preferences be settable or only one or two?
• should certain preferences be forced for certain resets or should it always be a choice?
• should we match the LOA of credentials presented with the method of reset?
• Group decided that we would not require the use of all OpenID providers if more than one is set, but we would allow more than one to be set. On reset the user would be able to choose which preferences set to use for that reset session. Being able to use more than one provider also opens up a security risk by allowing more attack vectors.
• Should user be able to add more than 1 cell phone number to use? Perhaps allow only one in PIDGen and multiple numbers using MyVT
• If we allow Google to be used as an OpenID provider there may be some confusion among alumni as to what password should be used (Google password or VT e-mail password). There are issues and questions about whether we should even consider and use Google as an acceptable provider. Those present decided that Yahoo & Google should be considered/tested further. Google may not be a good provider to use for this because of this problem with having a vt domain on Google