I first want to be sure that people realize that I do not personally decide what or how Mac OS X handles identities, how Safari does or does not manage whether it uses a particular identity or not or whether Keychain Access is replaced with something else. I am trying to explain how things work, how to help you manage that environment and to continue to listen to constructive comments/feedback and influence those decisions within Apple.
The second thing to note is that The Smart Card Services have nothing to do with Safari / identity use within the OS. This scenario would currently exist whether you had a file-based Keychain Identity or a Smart Card-based Identity. So, that is why I changed the subject of this message....
On Dec 17, 2008, at 3:32 PM, Fletcher, Boyd C. CIV US USJFCOM JFL J9935 wrote:
ok so for #4 then just whack the ID pref then. there needs to be a way to easily delete ID prefs that your mom could figure out. Using KeyChain Access ain’t it. ;)
Keep in mind that the ability to create/modify Identity Preferences is the only reason things will work at all for some folks if the site does not *require* an X.509 Cert for Client authentication.
I think most of the people on this list would agree that if we had #1 and #2 we would very happy.
From our collective experience the current approach of manually editing ID Prefs is a helluva lot worse user experience than getting prompted for a certificate each time. it is **FAR** easier to explain to a user to just select the cert each time than it is on how to use KeyChain Access.
Goal is to provide Zero-configuration or as close to it as possible. Exactly how that plays itself out within the UI / OS, we'll have to see.
so if #1 has been a consideration why not implement it?
Just because a product developer considers something, doesn't mean that they just whip it out without proper design and thorough consideration. Sometimes there are transition periods between what you have and what you want and that is where we are right now with this.
the current approach apple chose is very clearly not working with the users who are having to use it and SUPPORT it. so in this case Apple UI designers need admit failure and allow the users to tell them how it should work.
This was not an Apple UI Designers issue relating to Identity Prefs. While other development was underway, we were able to ensure that you could still get authenticated access to PK-enabled websites without having to wait for that to be integrated into Safari for all of the UI pieces. Since all of the SSL/TLS handling is done by the OS and not Safari, it was possible to make this happen in the interim. This was additional work done on your behalf to prevent the wait for things to work. Be careful about throwing blame around.
I’ve given up using bugreport. They always blow off my submissions with the terms “ its implemented as designed” . Their arrogance and shortsightedness is amazing.
Admittedly, the way submissions are written up sometimes by folks (ones I have seen throughout the years) it is either not clear what the real intent it really is how things are designed. It is not arrogance, but reality. You can't just yank technology out or make sweeping changes to something that is designed a specific way and relied on by other OS components (stability). One such example was a request to completely remove the use of keychains throughout the OS. User did not want to deal with Keychains at all, but the submission was marked as implemented as designed, because Keychains are currently an integral part of the OS infrastructure. That is not meant to be arrogant, but again a statement of reality. Complaining about something doesn't get desired/needed changes into the product. Clearly articulating environmental/organization/industry requirements/personal desires and noting impact and benefits, goes quite a long way into solving the real problem.
Please provide bug #s and I will look into them.