Federated access management can make things nice and simple for both the user and the service they are accessing. By logging in to their home organisation the user can have that organisation release relevant information to the service – “I am a student”, “this is my e-mail address” and so on. And because that information comes from the organisation, the service is likely to consider it more reliable than information self-asserted by the individual user (especially if being a student entitles you to benefits such as site licences, reduced prices, etc.). Where all this gets a little tricky is explaining to the user – as both good privacy practice and European Data Protection law require – what information about them will be disclosed.
In the off-line world we are all too familiar with forms that seem to demand more information than is actually required (hotel checkin forms that demand an e-mail address are a particular bugbear of mine). In those cases I can simply ignore boxes that seem irrelevant – if the hotel wants to try to persuade me that providing an e-mail address will benefit me then they are welcome to do so. So I’ve been trying to work out what an equivalent interface for federated access management might look like. This, which may not look like any existing tool, is what I’ve come up with:
Clearly the appearance and wording could be made much better: what I’m trying to get my head around is the function. In the on-line world, as off-line, there is some information without which a service simply can’t operate. In the example above I have in mind an electronic journal that is licensed to all students and staff at a particular organisation: obviously if I am not willing to reveal my relationship with the organisation (“affiliation”) to the service provider then I can’t use the service and there’s no point in me trying to log in to it. I’ve taken the view that remembering history for individual users – what searches they have done, how far through a paper they have read, etc. – is a sufficiently key part of the service for an anonymous identifier distinguishing one user from another to be essential too, though it could be argued otherwise. However (as in my hotel example) the ability to e-mail the user updates about the service doesn’t seem like a core part of the service – some users will consider it useful, others a waste of time, some may wish to have the mails sent to a different e-mail address – so this seems like a disclosure of information that the user should have the ability to control. Even users who refuse to provide an e-mail address can still carry on and use the service: my suggested interface therefore provides a check-box to let them choose. Other additional attributes that the service could use but doesn’t depend on could, of course, be added in the same way.
The sets of essential and additional attributes won’t be the same for all types of service. For example authorisation for a particular research group’s collaboration tool may depend on my off-line identity so for these an organisation-verified identity (such as an e-mail address) will be essential while my affiliation is irrelevant.
This leaves the question of who decides which attributes are essential and which are additional. The service provider obviously has to announce which attributes their system can actually understand, but these may not all be essential to provide the service. Here the federated access management system is different to checking in at a hotel, because it is the organisational identity provider that releases information, not me as user. Rather than having every user try to work out which information is essential, possibly causing significant support load when they choose to release too little and the service breaks, it seems more efficient to have the organisational identity provider do that. Since releasing personal data carries some legal risk for the organisation, having the organisation make the decision also gives it the best chance of managing that risk to an acceptable level. Data Protection law sets different rules for essential and additional disclosures – the former are classed as necessary, the latter based on the user’s consent – so there are risks of challenge on both sides, either for forcing a user to “consent” to disclosure when they have no real choice or for disclosing more information than can be justified as “necessary”. Getting the interface right should help avoid those problems.
[UPDATE] The Article 29 Working Party’s new Opinion on the Definition of Consent has an example of just this kind of hybrid approach (though their example is quite a bit more complex than mine.
