Many, perhaps most, wifi access services across the public sector require some sort of authentication of people who use them. 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 in 2018. Andrew Cormack, Jisc Technologies’ chief regulatory adviser, looks at the govroam model and its alternatives.
Govroam minimises the need to hold visitor personal data
Govroam 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 govroam 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, even the session ID isn’t 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.
A definite pseudonym, the use of which is recommended to govroam home organisations, is the Chargeable User ID (CUID – see the corresponding eduroam statement; a govroam-specific policy is to follow). 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.
The GDPR compliance of alternatives should be considered carefully
Compare the GDPR-friendly govroam mechanism with alternative means to provide authenticated visitor access. Where wifi providers can’t rely on govroam’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 user can give multiple e-mail addresses) equivalent of govroam’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 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).
Overall, the govroam solution to granting visitor access, which provides the in-depth audit trail that you might need through cooperation with a visitors’ home site, while minimising the personal data you need to hold, represents an effective way to meet the new requirements of GDPR.
This post was derived from an article soon to be available on Andrew’s regulatory developments blog (article URL to follow).
