|
+7.2 Notice and Consent |
7.2 Notice and ConsentTo build subscriber trust in federation, subscribers need to be able to develop reliable assumptions about how their information is being processed. For instance, it can be helpful for subscribers to understand what information will be transmitted and which attributes for the transaction are required versus optional, and for subscribers to have the ability to decide whether to transmit optional attributes to the RP. Accordingly, Sec. 3.5 requires that positive confirmation be obtained from the authorized party before any attributes about the subscriber are transmitted to any RP. In determining when a set of RPs should share a shared pairwise pseudonymous identifier (see Sec. 3.4.1.3), the trust agreement considers the subscriber’s understanding of such a grouping of RPs and provides a means for effective notice to the subscriber in assisting such understanding. An effective notice will consider user experience design standards and research, as well as an assessment of privacy risks that may arise from the information processing. There are various factors to be considered, including the reliability of the assumptions that subscribers may have about the processing and the roles of different entities involved in federation. However, a link to a complex, legalistic privacy policy or general terms and conditions that a substantial number of subscribers do not read or understand is never an effective notice. Section 3.5 does not specify which party should provide the notice. In some cases, a party in a federation may not have a direct connection to the subscriber in order to provide notice and obtain consent. Although multiple parties may elect to provide notice, parties can use contracts or trust framework policies to determine in advance which party will provide the notice and obtain confirmation if that determination is based upon factors that center on enabling the subscriber to read the notice and make an informed choice. The IdP is required to inform subscribers of all RPs that might access the subscriber’s attributes. If an RP is on an IdP’s allowlist (see Sec. 4.6.1.1), the subscriber will not be prompted at runtime to consent to the release of their attributes. This single sign-on scenario allows for a more seamless login experience for the subscriber, who might not even realize they are participating in a federation transaction. The IdP makes its list of allowlisted RPs available to the subscriber as part of the terms of the trust agreement. This information allows the subscriber to see which RPs might have access to their attributes, under what circumstances, and for what purposes. If a subscriber’s runtime decisions at the IdP were stored in the subscriber account by the IdP to facilitate future transactions, the IdP also needs to allow the subscriber to view and revoke any RPs that were previously approved during a runtime decision. This list includes information on which attributes were approved and when the approval was recorded. Similarly, if a subscriber’s runtime decisions at the RP are stored in some fashion, the RP also needs to allow the subscriber to view and revoke any IdPs that were approved during a runtime decision. 1. Resumen
1.1 Referencias1.2 Requisitos identificados1.3 Regulaciones relacionadas2. Requisitos identificados
3. Regulaciones relacionadas
|