14 January 2011
Review of DataONE branded CILogon interface and related issues

Participants: Randy Butler, Dave Vieglais, Jim Basney, Giri Palanisamy, Roger Dahl, Rob Nahf, Ryan Scherle, Mark Servilla, Bob Sandusky, Jeff Horsburgh

Identified Issues:

1. General Appearance (https://cilogon.org/?skin=DataONE)
     - Provide more context for the CILogon logo in the upper righthand  corner (e.g., "Powered by CILogon" (see Rob Nahf email 5 Jan 2011). Jim agrees.
    - HIghlight the "?" icon so that it is more visible (see Rob Nahf email 5 Jan 2011). Is the larger icon better? We increased icon size and text size.
    Yes, the larger icon and font size are better. I would increase the font size for the line "By selecting "Log On", you agree to our privacy policy." too. OK, we can do that.
    
2. InCommon Membership
    - How to educate the user to search out their institution in the InCommon list (see Matt Jones email 5 Jan 2011, point 1)?  Perhaps education at the point of DataONE registration?
    comment: for the issue of a user forgetting / not-knowing their institution, we can adopt the familiar design for logon pages is to have a link to another place: such as: "I forgot my identity provider"  (similar to "I forgot my username" you might see elsewhere).  What the user sees after clicking that link is up for grabs ;-)
    Jim's response: I like this suggestion. Maybe we need a "Help me choose" link. 
     - Need to achive critical mass of institutions that are tied to DataONE  users (based on the Dryad/KBN/DAAC membership) (see Matt Jones email 5 Jan 2011, point 1).  LTER is now pursuing InCommon membeship; this may cover about 2/3 of the KNB list of users. Also, CILogon is working to add more institutions to the list.
    
3. Functional
    - Alternative process for managing certificate, once created (see Matt Jones email 5 Jan 2011, point 2)?  In addition to the Java Web Start application (which performs the key generation and certificate request), CILogon also generates a short-lived token (big string) that may be used to verify a certificate request session.  The client application would be responsible for generating the key pair and sending the certificate request to CILogon via their RESTful API.  CILogon would then generate the certificate accordingly and make it available for download.  Dave observered that the token could be passed to another node, which would then manage the process on behalf of the user (Jim Basney confirmed this approach).
    - What are the necessary attributes contained in the downloaded certificate file (see Matt Jones email 5 Jan 2011, point 3)?  The private key is part of the file that is generated by the CILogon application - the Java app writes both the certificate (received from CILogon) and the previously generated private key in a single file.  The private key should NOT be sent to the DataONE auth service; the private key should be retained by the client and used during certificate verification by DataONE (DataONE would negotiate a PKI session with the client to prove that the client is indeed who they claim to be).  The private key should be retained for the duration of the certificate; if the private key is deleted, then the user would be required to regenerate a new key pair and certificate. (Lots more details about private keys and certificates at https://secure.wikimedia.org/wikipedia/en/wiki/Public-key_cryptography and http://www.cilogon.org/cert-howto.)
    - Logout process (Hilmar reports that after logging out (of CILogon), other users of the same computer can still get to his university resources) -- This is a general shibboleth issue, and the best solution is to close the web browser.  The general issue is that there exists two authenticated web session cookies in the client web browser: one from the IDprovider and one from CILogon; the CILogon page can only end their session, but not the IDProvider session.  Jim Basney suggested the removal of the "Logout" button from the CILogon page so that user would not be lured into a false sense of being logged out from the IDprovider's session and, in its place, text that states the user should close and exit the web browser to securely end the session.