Presentations about Touchstone were made to the Help Staff meeting on September 25th, 2007 and the student employees that evening. This document captures some of the follow-up questions and dialog.
1) How will a someone first encounter Touchstone? What steps will they take that causes them to notice something new or different? What will they notice?
During the pilot, a service's particular error or alternate login page will have an additional button called "Try authenticating via Touchstone". So for example, if you try to log in to Stellar and your certificate does not work or you do not have one, you currently get the page below. 
When the Touchstone pilot goes live, there will be an additional section underneath the current MIT Community Users section on the page below.
During the initial phase of the pilot the pilot applications will always require an explicit customer action to "try Touchstone" if login fails by default. It should never re-direct there automatically, unless the user has at least once chosen to use Touchstone and set explicit preferences for their use of Touchstone.
Here is a screen shot of what a user of Stellar will see if a certificate is not presented to Stellar when logging in:
The login page for http://wiki.mit.edu
is intending to take a similar, yet slightly different approach as seen here: 
2) There are some "start-up" or transition aspects to using this service. It may slow people down, or require them to get some additional information before they can get to web-based information on which they depend to do their work or studies, and which is time-senstive. What can we say to someone about the benefits of this new system, which helps to offset the unfamiliar way of going about old tasks? We would expect clients to ask the following questions. What answers might we give?
a) Does this mean certificates are going away, and I won't have to get them any more?
MIT X.509 Certificates are not going away in the forseeable future. They are used by many web sites on campus and even if all web sites decide to transition to MIT Touchstone it will likely take several years for all of the web sites to make such a transition given time and budget contraints.
User should also remember that when properly used certifcates provide a better defence from having your account compromised by phishing attacks or other mechanims than simply using passwords. MIT Touchstone supports username and password authentication only because certificates and other strong authentication technologies cannot be used on all systems everwhere in the world today.
b) What if I set this up on my office computer? Does it work for my home computer too? What about if I use a computer at an internet cafe?
By offering users a variety of mechanisms to authenticate when using MIT Touchstone, users will be able to use MIT Touchstone enabled web applications from a wide variety of locations, be it home, office, or even while using a computer located in an internet cafe or at an airport kiosk machine. However, the authentication preference which the user may select is specific to the machine and browser. This means that a user might set a preference to use Kerberos tickets on the office computer while having a preference to use certificates from the home computer. The only situations where the user's preference will persist across machines is when using the Athena computing environment or WIN.MIT.EDU.
c) So I have to remember another new password? Can I use the same password as I use for my (email or certificates or machine login or ...)? Sometime you people make me change my password. Do I have to keep changing it every six months? What are the rules for how long my password has to be and what characters I can use? Will you tell me beforehand, or wait until I generate one that's wrong, and then tell me what I need to know?
The only password that can be used with Touchstone is your Kerberos password. This is the same password that you use to access your MIT email using Webmail or native clients. The rules for managing your password are not affected by Touchstone in any way. The MIT Touchstone references IS&T's "Creating and Using Your MIT Kerberos Identity". The help page does not currently reference IS&T's Guidelines for Choosing a Password page nor does it reference IS&T's Changing Your Password page, please let us know if you think these links should be added to the MIT Touchstone help page.
d) If I don't have to use certificates any more, why did you make me get a certificate that expires in 2026?
MIT Touchstone is in its early phase of deployment. You are likely to need certificates to authenticate to other web applications at MIT for the foreseeable future.
User should also remember that when properly used certifcates provide a better defence from having your account compromised by phishing attacks or other mechanims than simply using passwords. MIT Touchstone supports username and password authentication only because certificates and other strong authentication technologies cannot be used on all systems everwhere in the world today.
3) The product presents a set of choices for a person to make before they can go forward, but it doesn't give them criteria for making the choices. For example, they are faced with deciding between
a) user ID and password
b) Kerberos tickets
c) certificates
Many individuals don't know which of these items they have active, or correctly installed, or named as indicated above. Kerberos tickets are dependent on user ID and password at MIT, so what's the difference between those choices? People don't routinely check to see if they certificates or tickets at the start of a work session; they pay attention when a path to a web page is blocked, or if they have to type an ID and password to get access.
Similarly, why/how to choose between the "Authentication Options" (https://idp.mit.edu/auth-options) radio buttons? What about putting a link called "How to choose between these options" to documentation or some background information at the top of this same page?
4) Paul points out that it may be difficult for clients to know whether they are having difficulties with Touchstone, or a different product/service to which it provides access. If the Help Desk identified the problem as a Touchstone issue, what items of information is it useful for us to collect in order to escalate?
- What is the name of the customer?
- What was the time and date when the problem occurred?
- What URL was the user trying to access?
- What browser was being used? (Brand and version)
- What application was the user trying to access?
- What machine was being used when trying to access the URL? (Physical location, hostname, IP address if known)
- Which authentication method(s) did the user attempt to use? (username / password, certificate, existing tickets)
- What error message was displayed?
5) Is there a written list of resources in particular URLs that will help answer questions? Also, we currently have no screen shots or other reference material. Once the pages are available, it is still helpful to have screen shots of things that clients can see, but which we as consultants might not readily be able to duplicate on our own screens. Is there a way for us to get these?
The Touchstone help page can be found at https://idp.mit.edu/help.html
https://idp.mit.edu/auth-options; - This is the application that staff should normally use to determine if Touchstone is functional at this time.
We are also working on a more comprehensive test page which can be found at http://touchstone-tester.mit.edu/. At this time we are concentrating on the mechanics of testing the underlying components. As we complete that phase we will focus on improve the UI and making the page more understandable and functional.
The current default MIT Touchstone login page: 
The following page is normally briefly displayed to a user as the system redirects the user's browser back to the originally requested URL when the user has successfully authenticated to the MIT Touchstone login server, and has JavaScript enabled. If the user is on a slow network link this page may display for longer than the user expects.
Alternatively, when the user has disabled JavaScript, the following page is displayed after a successful authentication; the user will need to click on the Continue button to proceed back to the original site:
The user has five minutes to authenticate successfully from the login page (a timer on the page serves as a reminder of the time remaining). If the user attempts to authenticate after this time limit has been exceeded, the following error page is displayed: 
Touchstone requires that the user accepts cookies from the participating web sites, including the login server, idp.mit.edu. If the user disallows cookies, the following error will be displayed when authentication is attempted (unless the application web server detects the problem before authentication): 
Once the user is redirected back to the original web server, the Shibboleth software on that server normally creates an internal session for the user (so that further interaction with the login server for the user is unnecessary). If this session creation fails for any reason, for example if the Shibboleth daemon is not running on the web server, the user will see an error page similar to the following; note that each web application server will likely have a customized version of this page, to match the rest of the site, but, if it has not been customized, the following stock page is displayed:
It is possible for the user to encounter the following error page. This should be very rare. I obtained this screen shot by using the Firefox extension "Tamper Data" and modifying the contents of the data being sent back to the login server when logging in using my username and password. 