Internet Technology Program Manager
My colleague Robin Wilton and I participated in the recent Trust and Internet Identity Meeting Europe (TIIME) in Vienna, Austria, co-sponsored by the Internet Society and organized by long-time notable identeratus Rainer Hörbe.
This meeting brought together approximately 100 people who are engaged in advancing the state of the art and strengthening trust around online identity. Structured as an “unconference,” it was up to the attendees to set the agenda and lead the sessions. As you can see from the session list the meeting covered a lot of ground.
I led sessions on IoT Security and Privacy and Blockchain and Identity, two topics of particular interest to me and to the Internet Society. My colleagues and I have written in the past about IoT Security and Privacy, and we plan to write more on both topics.
One of the key themes of the meeting was Federated Identity and Access Management (IAM). This is something that many are not familiar with, at least not by that name, although it plays a significant role in the lives of many, and will widen its reach as time goes on. One of the paradoxes of this technology, like many others, is that when it is working well it “gets out of the way” and is not very visible to people using it. It is only when things break down that it becomes noticeable.
Essentially, it's when you log on at one organization (e.g., a book publisher's site) using an ID and password that was issued to you by another (for instance, the university at which you are a student).
For anyone who would like to learn more about Federated IAM, there are many good resources. Some to get you started include:
The global Research and Education (R&E) community has led the way in developing and fine-tuning the technologies and associated policies that enable Federated IAM to work well, and the technology has become core infrastructure for R&E worldwide. Industries and governments around the world have adopted various aspects of Federated IAM around the world, with more certain to follow. Federations tend to be set up around logical constituencies, such as a local or federal government offering services to its constituents, or vertical industries such as automotive or pharmaceuticals. In the R&E sector federations tend to be national or built around particular fields of study, and in many cases they are run by or at least closely associated with National Research and Education Networks (NRENs).
Federated IAM simplifies things for users, because it reduces the number of IDs and passwords they need to manage, while still securing their access to multiple services. At this point in its evolution, though, having solved many of the easier “low-hanging fruit” problems, it has exposed more challenging ones.
Developing and refining the policies and processes regarding what attributes about its users an Identity Provider (IdP) releases to a Service Provider (SP) has been and continues to be a challenge. An SP relies on user attributes conveyed in a trustworthy manner from the IdP to make access control decisions. The required attributes will vary along a spectrum from those that are not at all revealing about the user’s identity to those that very explicitly and uniquely identify the person, based upon the risk profile of the resource being accessed. E.g. for a digital library resource licensed to an educational institution, all that might be required is an assertion that the user is currently affiliated with the institution, or perhaps also enrolled in a particular class for the current session. For access to your health or financial records, enough identifying information will need to be conveyed to fully convince the resource holder that you are in fact you. And of course this is what we want. I tend to think of privacy controls in this context as a virtual knob that can be turned from 0-10, depending on what is actually needed in a particular context. Unfortunately there is a tendency among some SPs to require much more than they legitimately need, in some cases because they want to use the additional information for financial gain (monetization) either currently or reserving for some possible future use. A common monetization strategy is using profile information for marketing, including packaging and selling to third parties.
The specific set of attributes required by the SP is something that it can negotiate with the IdP on a bilateral basis, often in association with a contract for services. Or a particular bundle of attributes may be released by IdPs to particular classes of SPs. However, users cannot always rely upon IdPs to protect their privacy. It is up to the manager(s) of the IdP to represent the interests of their users and negotiate the release of only those attributes for which the SP can make a legitimate case for being necessary for its purposes in making access decisions. This is essentially the trade-off – users get simplicity because they are relying upon the IdP to negotiate on their behalf.
In this age of data monetization, it is more important than ever for us all to be conscious of what information about us is being sent, where, for what purposes, and how it is being protected. As Federated IAM continues to advance and become more ubiquitous, it is incumbent upon us all to ask the questions of those entrusted with shepherding and protecting our data. This starts with looking at how your IdPs use your data, and why. In some cases this is easy to learn from publicly available information, such as privacy policies or terms of service, but in other cases it will require some digging. Ultimately it is up to us as the stewards of our information and to be on the lookout for possible misuse, and to take steps to protect ourselves.
Although I have used examples from the higher education sector, you have probably encountered federated authentication in another form: the growing trend to invite you to log in to sites using your social media identity.
Using social networking or similar IdPs to login to other sites is very convenient, which is the fundamental value proposition, but in the process of doing so users may be revealing much more about themselves and their activities to that IdP than they intend to, to their detriment. The things you trust an IdP to do are not necessarily the things you trust your social media provider to do. There is a saying: if you are not paying for the service then you are the product. This is true for “free” services such as social networks and email, which use data collected about users to market and sell to others.
An encouraging trend is that of non-commercial IdPs that explicitly promise not to use or abuse your data, and in particular not to sell it. A good example of this is UnitedID.org, which can be used broadly in the R&E sector as well as with select broadly available commercial services, and which will be the subject of a separate blogpost.