|
+8.1.2.1 User Perspectives on Online Identity |
8.1.2.1 User Perspectives on Online IdentityEven 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. 1. Pregled
1.1 Sklici1.2 Ugotovljene zahteve1.3 Povezani predpisi2. Ugotovljene zahteve
3. Povezani predpisi
|