Discussion

1. I'd (Mary) like to summarize thoughts from Susan's pros/cons, and more from me...

   Choices:

   1) Initially issue a certificate equivalent to PID/password that includes encryption – easy to issue (self-service), not worth much for strength of authentication or digital signatures. If we do this, we could still issue a LoA3 certificate later, but the problem would be dealing with 2 certificates. How bad a usability problem would this introduce?

   2) Issue a certificate with better identity proofing (may not be able to achieve self-service), but we could have one certificate with good strength and also enable encryption. The advantage is simplicity of only having one certificate for users to manage. The downside of this is the up-front identity proofing (although we could to it in a distributed fashion). Another downside is losing non-repudiation for digital signatures if we include encryption in this certificate. The good side is that we do have PDCs on eTokens for people who feel strongly about the non-repudiation element.

   The LoA 3 certificate will require more technical interface work, and more training, but if we ultimately think we are going to need it, then even if we start with the PID/password-equivalent cert, we'll have to do this work, and will end up managing 2 certs.

   Therefore, I think garnering a perspective from the user support end would be extremely helpful!

2. See "Meeting Note" 2h from 20100805 - Soft PDC project meeting, August 5, 2010

Meeting Notes

1. From 9/30/2010 project meeting.
   1. We already have an eToken and NetCert this will be yet another cert to manage.
   2. With more than 1 cert users are going to have problems.
   3. Do not assume users know how to use certs.
   4. If we decide to issue more than one kind of cert, e.g., LOA 2 & 3, then the applications that use these certs will have to be very clear as to how to use them, e.g., insert eToken now for digital signature...
   5. Since we already have an LOA 4 cert (according to VT standards) in the eToken that provides a high LOA and non-repudiation why add another similar cert to that. Instead issue a widely distributable cert and train users on their appropriate use.
   6. The need we are attempting to solve with a soft cert has nothing to do with our LOA 4, eToken solution.
   7. Aladdin now produces an eToken with the drivers installed on the device making them more portable and overcoming the problem of having to install software on a computer that uses an eToken.
   8. Security comes at the cost of usability.
   9. Since Aladdin is already very windows-centric we already have usability with the eToken for Linux and Mac users.
   10. A key issue is that even if we shoot for an LOA 3 soft cert how do we overcome the risk that once the cert is issued we have no control over it and a user can just change the initial secure password? Once issues does a LOA 3 soft cert remain a LOA 3?
   11. What are the intended uses for soft certs? Without concrete uses it is difficult to talk about usability.
   12. Based on experience with the eToken users are not making the connection between digital signatures, what they mean and exactly how to use them.
   13. An idea that may address usability is to provide different training for different LOA certs. For example a LOA 2 cert may only need a youtube video for training, whereas a LOA 3 cert may need a FDI course.
   14. Regardless of the LOA cert issued it is up to the application that uses the cert to distinguish between the type of cert presented and instruct the user on how to proceed. For example, if an application requests an LOA 2 cert and the user gives it a LOA 4 cert (eToken) then the application should recognize that and be more than happy to proceed.
   15. As a team we seem to be leaning towards a LOA 2 soft cert.
   16. Mary will talk to Erv about these issues and report back.