+8.1.2 Specific Usability Considerations
---+8.1.2.1 User Perspectives on Online Identity
---+8.1.2.2 User Perspectives of Trust and Benefits
---+8.1.2.3 User Mental Models and Beliefs

8.1.2 Specific Usability Considerations

This section addresses the specific usability considerations that have been identified with federated identity systems. This section does not attempt to present exhaustive coverage of all usability factors related to federated identity systems. Rather, it is focused on the larger, more pervasive themes in the usability literature, primarily users’ perspectives on identity, user adoption, trust, and perceptions of federated identity space. In some cases, implementation examples are provided. However, specific solutions are not prescribed. The implementations mentioned are examples to encourage innovative technological approaches addressing specific usability needs. See standards for system design and coding, specifications, APIs, and current best practices for additional examples. Implementations are sensitive to many factors that prevent a one-size-fits-all solution.

1. Panoramica

8.1.2.1 User Perspectives on Online Identity

Even when users are familiar with federated identity systems, there are different approaches to federated identity that make it necessary to establish reliable expectations for how user data is treated, especially in terms of privacy and the sharing of information. Users and implementers have different concepts of identity. Users think of identity as logging in and gaining access to their own private space. Implementers think of identity in terms of authenticators, assertions, assurance levels, and the necessary set of identity attributes to provide a service. Given this disconnect, it is essential to help users form an accurate concept of identity as it applies to federated identity systems. A good model of identity gives users a foundation for understanding the benefits and risks of federated systems and encourages user adoption and trust of these systems.

To minimize the personal information collected and protect privacy, IdPs and RPs ought to inform users of the benefits and drawbacks of pseudonymous identification, what information is transmitted, and for what purpose.

Many properties of identity have implications for how users manage identities, both within and among federations. Just as users manage multiple identities based on context outside of cyberspace, users must learn to manage their identity in a federated environment. Therefore, it must be clear to users how identity and context are used. The following factors should be considered:

Provide users with the requisite context and scope in order to distinguish among different user roles. For example, differentiate whether the user is acting on their own behalf or on behalf of another, such as their employer.

Provide users with unique, meaningful, and descriptive identifiers to distinguish among entities, such as IdPs, RPs, and accounts. Any such user-facing identifiers are likely to be in addition to identifiers used by the underlying protocols, which are not normally exposed to the user.

Provide users with information on data ownership and those authorized to make changes. Identities and the data associated with them can sometimes be updated and changed by multiple actors. For example, some healthcare data is updated and owned by the patient, while some data is only updated by a hospital or doctor’s practice.

Provide users with the ability to easily verify, view, and update attributes. Identities and user roles change over time (e.g., address, health, and financial data). The ability to update attributes or make attribute release decisions may not be offered at the same time. Ensure that the process for users to change attributes is well-known, documented, and easy to perform. See Sec. 5.3 of [SP800-63A] for more information about allowing users to update core attributes.

Provide users with a means to update data, even if the associated subscriber account or RP subscriber account is disabled or terminated. Consider applicable audit, legal, or policy constraints when tracking updated data.

Provide users with a means to completely delete their identities completely and remove all information about themselves, including their transaction history. In certain cases, deactivating the RP subscriber account is more appropriate than deleting it, as the RP may be required to retain portions of the data in the RP subscriber account. Consider applicable audit, legal, or policy constraints that may preclude such actions.

Provide users with clear, easy-to-find information on the site or application data retention policy.

Provide users with appropriate anonymity and pseudonymity options and the ability to switch among such identity options as desired, in accordance with the organization’s data access policies.

Provide a means for users to manage each IdP to RP connection, including complete separation and the removal of RP access to one or more attributes.
8.1.2.2 User Perspectives of Trust and Benefits

Many factors can influence user adoption of federated identity systems. As with any technology, users may value some factors more than others. Users often weigh perceived benefits versus risks before making technology adoption decisions. It is critical that IdPs and RPs provide users with sufficient information to enable them to make informed decisions. The concepts of trust and tiers of trust are fundamental principles in federated identity systems that can drive user adoption. Finally, a positive user experience may also result in increased user demand for federation, triggering the increased adoption by RPs.

To encourage user adoption, IdPs and RPs need to establish and build trust with users and help them understand the benefits and risks of adoption. The following factors should be considered:

Allow users to control their information disclosure and provide explicit consent through the appropriate use of interactive user interfaces and notifications (see Sec. 7.2). Considerations such as balancing the content, size, and frequency of notifications and tailoring notifications to specific communities are necessary to avoid users clicking through without fully understanding the implications of their consent.

For attribute sharing, consider the following:
Provide a means for users to verify those attributes and attribute values that will be shared. Follow good security practices (see Sec. 3.11.2 and Sec. 6).
Enable users to consent to a partial list of attributes rather than an all-or-nothing approach. Allow users some degree of online access, even if the user does not consent to share all information.
Clearly convey to the user what they are sharing, particularly when the user has a choice to selectively disclose their attributes.
Allow users to update their consent to their list of shared attributes, and provide a means to convey the updated consent to concerned parties, such as affected RPs.
Minimize unnecessary information presented to users. For example, do not display system-generated attributes (e.g., pairwise pseudonymous identifiers), even if they are shared with the RP as part of the authentication response.
Minimize user steps and navigation. For example, build attribute consent into the federation protocols, such as commonly found in OAuth or OpenID Connect.
Provide effective redress methods such that a user can recover from invalid attribute information claimed by the IdP or collected by the RP. See Sec. 3.6 of [SP800-63] for more requirements on providing redress.
Minimize the number of times that a user is required to consent to attribute sharing, particularly for requests for the same attributes. Limiting the frequency of consent requests avoids user frustration.
Allow users to see where their data has been used, particularly within subscriber-controlled wallets.

Collect information for constrained usage only, and minimize information disclosure (see Sec. 7.3). User trust is eroded by unnecessary and superfluous information collection and disclosure or tracking without explicit consent. For example, only request attributes from the user that are relevant to the current transaction, not for all possible transactions that a user may access at the RP.

Clearly and honestly communicate the potential benefits and risks of using federated identity to users. Benefits that users value include time savings, ease of use, reduced number of passwords to manage, and increased convenience.

User concern over risk can negatively influence their willingness to adopt federated identity systems. Users may have concerns about trust, privacy, security, and single points of failure perceived in federated systems. For example, users may be fearful of losing access to multiple RPs if a single IdP is unavailable, either temporarily or permanently. Additionally, users may be concerned or confused about learning a new authentication process. In order to foster the adoption of federated identity systems, the perceived benefits must outweigh the perceived risks.
8.1.2.3 User Mental Models and Beliefs

Users’ 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.1 Riferimenti

1.2 Requisiti identificati

1.3 Regolamentazioni correlate

2. Requisiti identificati

Requisiti

3. Regolamentazioni correlate

Regolamentazioni
  • NIST -

    EN: Publications of the National Institute of Standards and Technology (NIST), U.S. Department of Commerce, https://www.nist.gov/, from their electronic versions (OSCAL; SP 800-63-4 from its HTML version, https://pages.nist.gov/800-63-4/). Works of NIST employees are not subject to copyright protection in the United States (17 U.S.C. § 105); the OSCAL content is dedicated to the public domain worldwide (CC0 1.0); outside the United States NIST grants the right to reprint its technical series publications in all formats (NIST copyright statement). Republished courtesy of the National Institute of Standards and Technology; each document names its citation. Divided into sections and converted into the GRCA format, the wording unchanged. Only the versions published by NIST are authoritative.

    DE: Veröffentlichungen des National Institute of Standards and Technology (NIST), U.S. Department of Commerce, https://www.nist.gov/, aus ihren elektronischen Fassungen (OSCAL; SP 800-63-4 aus ihrer HTML-Fassung, https://pages.nist.gov/800-63-4/). Werke von NIST-Beschäftigten sind in den USA urheberrechtlich nicht geschützt (17 U.S.C. § 105); die OSCAL-Inhalte sind weltweit gemeinfrei gestellt (CC0 1.0); außerhalb der USA räumt das NIST das Recht ein, seine Technical-Series-Publikationen in allen Formaten neu zu veröffentlichen (Copyright-Hinweis des NIST). „Republished courtesy of the National Institute of Standards and Technology“; jedes Dokument nennt seine Zitierangabe. In Abschnitte aufgeteilt und in das GRCA-Format umgewandelt, der Wortlaut unverändert. Maßgeblich sind allein die vom NIST veröffentlichten Fassungen.