+3.10 Privacy Requirements
---+3.10.1 Transmitting Subscriber Information
---+3.10.2 Sharing Information Between CSPs
|
3.10 Privacy Requirements
The goal of a subscriber is to interact with and use the RP. Federation involves the transfer of personal attributes from the IdP, a party that is not involved during direct authentication to an RP. Federation also potentially gives the IdP broad visibility into a subscriber’s activities and status. Accordingly, there are specific privacy requirements associated with federation that do not exist in direct authentication. When the RP requests a federation transaction from the IdP, this request and the subsequent processing of the federation transaction reveal to the IdP where the subscriber is logging in. Over time, the IdP could build a profile of subscriber transactions based on the knowledge of which RPs a given subscriber is using. This aggregation could enable new opportunities for subscriber tracking and the use of subscriber identity information in ways that do not align with subscribers’ privacy interests. If the same subscriber account is asserted to multiple RPs, and those RPs communicate with each other, the colluding RPs could track a subscriber’s activity across multiple applications and security domains. The IdP SHOULD employ technical measures (e.g., the use of pairwise pseudonymous identifiers described in Sec. 3.4.1, privacy-enhancing cryptographic protocols) to provide disassociability and discourage subscriber activity tracking and profiling between RPs. When determining such measures, the IdP SHOULD apply relevant guidelines and standards, such as the NIST Privacy Framework [NIST-Privacy]. The following requirements apply specifically to federal agencies that act as an IdP, an RP, or both:
The agency SHALL consult with their Senior Agency Official for Privacy (SAOP) to conduct an analysis that determines whether the requirements of the Privacy Act are triggered by the agency that is acting as an IdP, by the agency that is acting as an RP, or both (see Sec. 7.4).
The agency SHALL publish or identify coverage by a System of Records Notice (SORN), as applicable.
The agency SHALL consult with their SAOP to conduct an analysis that determines whether the requirements of the E-Government Act are triggered by the agency that is acting as an IdP, the agency that is acting as an RP, or both.
The agency SHALL publish or identify coverage by a Privacy Impact Assessment (PIA), as applicable.
The agency SHALL conduct a privacy risk assessment regarding the sharing of subscriber identity information between the IdP and RP.
If the RP subscriber account life cycle process gives the RP access to attributes through a provisioning API (see Sec. 4.6.3), additional privacy measures SHALL be implemented to account for the difference in the RP subscriber account life cycle (e.g., separation of non-active subscriber accounts, proactive removal of disabled and terminated accounts). The IdP SHALL minimize the attributes that are made available to the RP through the provisioning API. The IdP SHALL limit the population of subscriber accounts that are available via the provisioning API to the population of subscribers authorized to use the RP by the trust agreement. To prevent RP retention of identity attributes for accounts that have been terminated at the IdP, the IdP SHALL use the provisioning API to de-provision RP subscriber accounts for terminated subscriber accounts except where restricted by RP data retention requirements, policies, or regulation. This measure helps enforce data minimization principles (see the example in Sec. 9.5). When an RP subscriber account is linked to multiple federated identifiers (see Sec. 3.8.1), the de-provisioning process could result in the RP subscriber account still existing at the RP but linked to a different federated identifier. The IdP and RP SHALL exchange only the minimum data necessary to achieve the function of the system. To increase subscriber control over the release of their identity attributes, trust agreements SHOULD use a runtime decision to control attribute release, as discussed in Sec. 4.6.1.3. When the federation transaction uses an ephemeral provisioning mechanism (see Sec. 4.6.3), the IdP SHOULD use an ephemeral federated identifier for each authorization request to the RP to prevent the RP from storing or correlating information between sessions.
1. Pregled
| Naslov |
Standard |
|
3.10.1 Transmitting Subscriber Information
|
The IdP SHALL limit the transmission of subscriber information to only that which is necessary for the system to function and is stipulated and disclosed by the trust agreement.
These functions include the following:
Identity proofing, authentication, or attribute assertions (collectively “identity service”);
A specific subscriber request to transmit the information;
Fraud mitigation related to the identity service; or
Responding to a security incident related to the identity service.
If an IdP discloses information on subscriber activities at an RP to any party or processes the subscriber’s attributes for any purpose other than these cases, the IdP SHALL implement measures to maintain predictability and manageability commensurate with the privacy risks that arise from the additional processing. Measures MAY include providing clear notice, obtaining subscriber consent, or enabling the selective use or disclosure of attributes. When an IdP gathers the subscriber’s consent to use information outside the identity transaction, the IdP SHALL NOT make consent for the additional processing a condition of the identity service. For example, an IdP cannot require a subscriber to consent to receiving a newsletter in order to allow the subscriber to log into an RP. An RP SHALL limit the transmission of subscriber activities to the associated IdP to the following cases and only if stipulated and disclosed by the trust agreement:
Fraud mitigation related to the identity service
Responding to a security incident related to the identity service
If an RP uses the subscriber’s identity information for any purpose other than those stipulated in the trust agreement, the RP SHALL inform the subscriber and obtain their consent for such additional uses. Subscriber information could also be transmitted to comply with laws or legal processes, regardless of the terms of the trust agreement. See [NISTIR8062] for additional information on privacy engineering and risk management.
|
|
3.10.2 Sharing Information Between CSPs
|
In some larger federation systems, particularly multilateral federations managed by federation authorities, there can be multiple CSPs involved in the same trust agreement. In such cases, it could be desirable for CSPs to share information with each other for activities, such as fraud mitigation (e.g., to prevent an attacker from jumping between CSPs with different accounts to avoid detection). While sharing information in this way can be used to mitigate fraud, there are also substantial privacy concerns as the CSPs could learn subscriber attributes and actions from each other that were not originally disclosed to all CSPs that the subscriber uses. Similar information sharing could be desirable between IdPs that may operate independently from the CSP, such as between subscriber-controlled wallets that are hosted on remote systems, and such sharing has similar privacy considerations. All information transmissions between CSPs and/or IdPs SHALL be subject to the limitations for IdPs enumerated in Sec. 3.10.1. Any such information sharing between CSPs and/or IdPs SHALL be included in their privacy risk assessments. The terms of the trust agreement that connects CSPs SHALL define the policies that apply for the transfer of information shared between CSPs. In a trust agreement managed by a federation authority, the federation authority defines these terms.
|
1.1 Reference
1.2 Utvrđeni zahtjevi
1.3 Povezani propisi
2. Utvrđeni zahtjevi
3. Povezani propisi
- 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.
|