[from draft-lear-abfab-arch-02] 5. Privacy Considerations Sharing identity information raises privacy violations and as described throughout this document an existing architecture is re- used for a different usage environment. As such, a discussion about the privacy properties has to take these pre-conditions into consideration. We use the approach suggested in [I-D.morris-privacy-considerations] to shed light into what data is collected and used by which entity, what the relationship between these entities and the end user is, what data about the user is likely needed to be collected, and what the identification level of the data is. 5.1. What entities collect and use data? Figure 2 shows the architecture with the involved entities. Message exchanges are exchanged between the client application, via the relying part to the AAA server. There will likely be intermediaries between the relying party and the AAA server, labeled generically as "federation". In order for the relying party to route messages to the AAA server it is necessary for the client application to provide enough information to enable the identification of the AAA server's domain. While often the username is attached to the domain (in the form of a Network Access Identity (NAI) this is not necessary for the actual protocol operation. The EAP server component within the AAA server needs to authenticate the user and therefore needs to execute the respective authentication protocol. Once the authentication exchange is complete authorization information needs to be conveyed to the relying party to grant the user the necessary application rights. Information about resource consumption may be delivered as part of the accounting exchange during the lifetime of the granted application session. The authentication exchange may reveal an identifier that can be linked to a user. Additionally, a sequence of authentication protocol exchanges may be linked together. Depending on the chosen authentication protocol information at varying degrees may be revealed to all parties along the communication path. This authorization information exchange may disclose identity information about the user. While accounting information is created by the relying party it is likely to needed by intermediaries in the federation for financial settlement purposes and will be stored for billing, fraud detection, statistical purposes, and for service improvement by the AAA server operator. 5.2. Relationship between User's and other Entities The AAA server is a first-party site the user typically has a relationship with. This relationship will be created at the time when the security credentials are exchange and provisioned. The relying party and potential intermediares in the federation are typically operate under the contract of the first-party site. The user typically does not know about the intermediaries in the federation nor does he have any relationship with them. The protocol interaction triggered by the client application happens with the relying party at the time of application access. The relying party does not have a direct contractual relationship with the user but depending on the application the interaction may expose the brand of the application running by the relying party to the end user via some user interface. 5.3. What Data about the User is likely Needed to be Collected? The data that is likely going to be collected as part of a protocol exchange with application access at the relying party is accounting information and authorization information. This information is likely to be kept beyond the terminated application usage for trouble shooting, statistical purposes, etc. There is also like to be additional data collected to to improve application service usage by the relying party that is not conveyed to the AAA server as part of the accounting stream. 5.4. What is the Identification Level of the Data? With regard to identification there are several protocol layers that need to be considered separately. First, there is the EAP method exchange, which as an authentication and key exchange protocol has properties related to identification and protocol linkage. Second, there is identification at the EAP layer for routing of messages. Then, in the exchange between the client application and the relying party the identification depends on the underlying application layer protocol the EAP/GSS-API exchange is tunneled over. Finally, there is the backend exchange via the AAA infrastructure, which involves a range of RADIUS and Diameter extensions and yet to be defined extensions, such as encoding authorization information inside SAML assertions. Since this document does not attempt to define any of these exchanges but rather re-uses existing mechanisms the level of identification heavily depends on the selected mechanisms. The following two examples aim to illustrate the amount of existing work with respect to decrease exposure of personal data. 1. When designing EAP methods a number of different requirements may need to get considered; some of them are conflicting. RFC 4017 [RFC4017], for example, tried to list requirements for EAP methods utilized for network access over Wireless LANs. It also recommends the end-user identity hiding requirement, which is privacy-relevant. Some EAP methods, such as EAP-IKEv2 [RFC5106], also fulfill this requirement. 2. EAP, as the layer encapsulating EAP method specific information, needs identity information to allow routing requests towards the user's home AAA server. This information is carried within the Network Access Identifier (NAI) and the username part of the NAI (as supported by RFC 4282 [RFC4282]) can be obfuscated. 5.5. Privacy Challenges While a lot of standarization work was done to avoid leakage of identity information to intermediaries (such as eavesdroppers on the communication path between the client application and the relying party) in the area of authentication and key exchange protocols. However, from current deployments the weak aspects with respect to security are: 1. Today business contracts are used to create federations between identity providers and relying parties. These contracts are not only financial agreements but they also define the rules about what information is exchanged between the AAA server and the relying party and the potential involvement of AAA proxies and brokers as intermediaries. While these contracts are openly available for university federations they are not public in case of commercial deployments. Quite naturally, there is a lack of transparency for external parties. 2. In today's deployments the ability for users to determine the amount of information exchanged with other parties over time, as well as the possibility to control the amount of information exposed via an explict consent is limited. This is partially due the nature of application capabilities at the time of network access authentication. However, with the envisioned extension of the usage, as described in this document, it is desirable to offer these capabilities.