Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Burton Group Catalyst: when is selector ceremony time? (20070628)
Kim Cameron of Microsoft uses the term "ceremony", originated by Carl Ellison and others at Intel, to describe the processes that incorporate the interactions with the human user with their web browser and identity selector and include protections against attacks that target these interactions. (picture)
When using the Microsoft CardSpace identity selector in Internet Explorer, a user who has visited a web page containing a login form accepting information cards 
will have their screen grey-out and the CardSpace selector appear. The CardSpace ceremony temporarily takes control of the screen until the user either selects a card for information to be sent to login, or cancels the interaction.
This is an understandable behavior for an environment in which web sites, through ActiveX, Flash, Java, JavaScript, and other technologies, can control the display of their web sites in the user's browser, and escape the confines of the window, by bringing up windows and dialogs under remote control. For phishing protection, the CardSpace interaction ceremony
- captures the user's attention (they can't use the browser or other applications, although oddly enough music player applications continue playing),
- affects the system's display in a way that's difficult for a web-based application, and
- prevents the web site from affecting the interaction, except as mediated by the selector.
During his presentation on "The Future of Identity and Access at Microsoft" at the Burton Group Catalyst conference, the speaker Joe Long of Microsoft outlined scenarios in enterprise environments involving a rights-protected document transferred from one employee to another, asked the question,
"When does CardSpace come up?"
And suggested that within the context of "a single enterprise", and potentially within the context of "two collaborating enterprises", the CardSpace selector might not need to appear on either the sending or receiving employee's desktops.
This indicates to me the current identity selector ceremony may have too much intrusiveness, and perhaps should only be used for exceptional situations (e.g., when the user visits a site for the very first time), rather than everyday situations.
Apart from CardSpace, the only situations in Windows desktop OS where a ceremony this modal commonly occur are to get in and out of the operating system
- login to the operating system
- logout or change operating system user
- install certain operating system components
- serious OS error recovery (to use task manager to kill misbehaving processes)
Furthermore, the CardSpace identity selector, as implemented today, only protects one scenario, and its use is entirely driven by the web site. Other situations where a user could be phished or inadvertantly reveal sensitive information aren't protected by CardSpace, nor would it be appropriate for a modal dialog to occur every time the operating system detected a potentially dangerous scenario.
Perhaps a less intrusive dialog?
A further argument against modal dialogs is the increased use of virtualization products such as VMware on desktops. Should a web browser running in the dom0 (base non-virtualized operating system) trigger a CardSpace interaction ceremony, this greys out access to all applications on the screen, including other virtual platform's windows (which are potentially in a distinct security context). Conversely, should a web browser running within a virtualized operating system trigger a CardSpace interaction ceremony, then only that operating system's window is greyed out: the rest of the screen is not affected, even though through extension drivers for handling mouse focus or clipboard, data can flow between the dom0 and that operating system.
In his 2006 paper "Fifteen Years After TX: A Look Back at High Assurance Multi-Level Secure Windowing", Jeremy Epstein discussed building TX, a trusted X Window System server for use in multi-level secure (MLS) operating systems. The "window-manager" UI design for TX incorporated labels on window borders, a 'context bar', and layering constraints, to
- give the user an indication of the classification state of each window to assist the user in avoiding misclassification mistakes (e.g., so the user would not accidentally paste top secret information into a secret level document), and
- prevent spoofing by clients: a client opening a window could not affect the window's border label or its relative layering.
In the "lessons learned" section of his paper he writes
"The availability of virtual machine monitors such as VMWare have made MLS itself less important than it was. The TX architecture could be implemented in a VMWare environment, with the trusted servers running in one VMWare partition and other VMWare partitions each supporting a single SLS [untrusted X server], SE [selection emulator], and clients."