|
+8.1.2.3 User Mental Models and Beliefs |
8.1.2.3 User Mental Models and BeliefsUsers’ beliefs and perceptions predispose them to expect certain results and behave in certain ways. Such beliefs, perceptions, and predispositions are referred to in social sciences as “mental models.” For example, people have a mental model of dining out that guides their behavior and expectations at each establishment, such as fast food restaurants, cafeterias, and more formal restaurants. Thus, it is not necessary to be familiar with every establishment to understand how to interact appropriately at each one. Assisting users in establishing good and complete mental models of federation allows users to generalize beyond a single specific implementation. If federated identity systems are not designed from users’ perspectives, users may form incorrect or incomplete mental models that impact their willingness to adopt these systems. The following factors should be considered: Clearly explain the working relationship and information flow among the transacting parties (e.g., RPs, IdPs, proxies) to avoid user misconceptions. Use the actual names of the entities in the explanation rather than the generic terms IdPs and RPs.
Provide prominent visual cues and information so that users understand why seemingly unrelated entities have a working relationship. For example, users may be concerned with mixing online personal activities with government services due to a lack of understanding about the information flow in federated identity systems.
Provide prominent visual cues and information to users when an RP needs to redirect control from their site to an IdP. For example, display RP branding within the IdP user interface to inform users when they are logging in with their IdP for access to the destination RP.
Provide users with clear and usable ways (e.g., visual assurance) to determine the authenticity of the transacting parties (e.g., RPs, IdPs, proxies). This will also help alleviate user concern over leaving one domain for another, especially if the root domain changes (e.g., .gov to .com). For example, display the URL of the IdP so that the user can verify that they are not being phished by a malicious site. Provide users with clear information regarding logins and logouts, including visual cues. Depending on the implementation, logging into an RP with a federated account can create long-running sessions for the user at both the IdP and RP. Users may not realize that ending their session with the RP will not necessarily end their session with the IdP; users will need to explicitly “log out” of the IdP. Users require clear information to remind them if explicit logouts are required to end their IdP sessions. Both the IdP and RP could also have automated logout features, which proactively log the user out based on how long it has been since the user authenticated or how long it has been since the user was active in a session. Users require clear information about when their session might end without any action on their part in order to avoid frustration, lost work, or insecure workarounds (e.g., copying data out of a secure site in order to avoid an unexpected session timeout). Provide users with clear and understandable explanations of trust agreement terms and consequences that are free of technical jargon. Provide users with clear and understandable explanations of the purpose and use of attributes within the system, and clearly disclose the parties to whom attributes are being released and transmitted.
1. Áttekintés
1.1 Hivatkozások1.2 Azonosított követelmények1.3 Kapcsolódó szabályozások2. Azonosított követelmények
3. Kapcsolódó szabályozások
|