Many, perhaps most, wifi access services want to perform some sort of authentication of people who use them (for those providing connectivity via Janet, it’s a requirement of the Network Connection Policy). Since authentication involves some processing of personal data, it’s worth reviewing how different ways of doing that might be affected (or not) by the General Data Protection Regulation (GDPR) when it comes into force next year.
The eduroam/govroam approach provides both the best guarantees of good behaviour (since the user’s home organisation is required to deal with any breaches of visited site policy) and involves the least exchange of personal data. The visited site only knows where a roaming user comes from, not who they are, and sees no username, e-mail address or other information that would allow them to contact the user directly. The only thing provided by the home site is confirmation that the user has authenticated successfully and will be held to account for their behaviour, and a temporary session ID indicating which connection that applies to. That’s clearly the minimum needed to provide authenticated access, so “necessary for the purpose of the [user agreement] contract” under Article 6(1)(b) of the GDPR. Since UK practice is that home sites do not disclose the identities of roaming users, it could be argued that, under the European Court’s judgment in Breyer, the session ID isn’t even personal data; however visited sites should probably treat it as a pseudonym (recognised by Article 25(1) of the GDPR as a helpful risk-reduction measure) and continue to keep it and any accompanying logs in accordance with their own security policies.
One definite pseudonym, provided by some home organisations, is the Chargeable User ID (CUID). Like the session ID, only the home organisation can link this to an individual or use it to contact them. Home organisations should provide different CUID values to each visited organisation, preventing its use to track visitors between organisations. However CUID does enable a visited organisation to recognise when, for example, an individual is repeatedly logging in and causing problems for the service. Such problems should be resolved by the home organisation, but CUID can let the visited network implement temporary measures until that is done. Since CUID is not necessary to provide the service, the appropriate GDPR basis is likely to be that processing is in the legitimate interest of the visited site, for example to protect the availability of the service. This basis requires the organisation to balance its interests against those of the individual, so visited organisations requesting CUID should review the purpose(s) for which they plan to use it, implement appropriate retention periods and other controls, and then confirm that these do not involve an excessive intrusion into users’ privacy and other rights.
Where wifi providers can’t rely on eduroam’s strong guarantee that users are known to their home organisations and have passwords acceptable to those organisations, some use two-factor approaches instead. These typically ask the user to provide a mobile phone number or e-mail address to which a temporary authentication token can be sent. For a service concerned that usernames may be shared (either knowingly or not) it again seems reasonable to claim that this is a requirement of providing the service the user has requested. An e-mail address or mobile number is, however, likely to be considered as a direct identifier so there’s little doubt that these must be handled in accordance with the GDPR.
Some services request an e-mail address not in order to send a second authentication factor, but to allow the provider to identify patterns of suspicious use. In effect this is a less privacy-protecting (and less effective, since the same user can give more than one e-mail address) equivalent of eduroam’s CUID. Again it’s hard to claim that this is necessary for a contract but, given that Recital 49 of the GDPR recognises that processing personal data for network and information security may be a legitimate interest, that justification (Article 6(1)(f)) might apply instead. This requires, however, that the provider ensures (and, under the GDPR, documents) that their interest is not overridden by the rights and interests of the user. Since identifying patterns of use will require a directly-identifying email address to be kept over multiple login sessions, retention periods and the security of stored data will need careful consideration and implementation.
Finally, if personal data collected during registration or authentication are used for other purposes, then those activities must be justified separately under the GDPR. Some changes likely are likely to be needed to practices common under the previous Data Protection Directive (EU) and Act (UK). In particular, any use of addresses to send marketing e-mails must be opt-in; making such consent a condition of providing service is likely to be unlawful under Article 7(4).
