Don’t confuse outsourced with personal

In honour of today’s ‘Identity Management Matters‘ event (which I am missing, due to gastric flu) I thought I would contribute a post to the conversation rather than my presence. This can be found on twitter at #idm.

One of the ways in which people typically open an Identity Management event these days is to say ‘students use Google mail’ (David Harrison did make a similar point at #idm but this post is NOT about his talk, which took a different direction). With yesterday’s announcement from Facebook, who knows if this will also include Facebook mail? This is often used as an argument for people interested in outsourcing to Google or to Microsoft – they are providing an experience that the users are familiar with.

This is all absolutely fine, right up the point where people then go on to what they see as the next logical step in the argument – students use personal credentials, ergo, we don’t need institutional credentials. This is where I go – ‘huh?’

There is a big difference between a student being provided with an account that is outsourced to Google by the institution and a student using a Google account that they had before they came to University – or a hotmail account, which going on an unscientific study of my sister’s 18 year old friends, they are most likely to have. Outsourcing to Google is no different from the experience had by many institutions in the UK for several years where access management was outsourced to Athens from Eduserv. This account is still attached to the institution, whether it carries with it an address or not. It may be passed on to the user in an alumni agreement, but during the time at the institution the student’s outsourced account is still maintained for them by the institution in agreement with Google, Microsoft etc. This is an important distinction as institutions can then effectively assign authorisation information to the student’s account which makes it usable in a variety of scenarios where proving you are a member of an institution is vitally important.

I think it is important that we keep pointing out that being able to authoritatively prove you (i.e. not self asserted) are a member of an institution or organisation (think CILIP) will continue to be very important. It will probably be most important where your studentyness or your staffyness gets you discounts or free access to things – like tickets, software, content etc. Even if the current institutional licensing model were to break down in favour of individual payments it is likely that many ‘pay-per-view’ systems would still offer discounts and savings based on membership.

Let’s now go back to the first statement made in this piece – the idea that students place more value on their current google account than an institutional account. That may be true, but then they are missing out on a whole bunch of potential savings by not appreciating their institutional account. I’m also not convinced that people don’t want to keep their personal and institutional spaces separate, and I’m also pretty convinced that this separation is a pretty good thing to maintain.

If we assume that I am wrong and the average student really wants to be able to use their Facebook account for example to be able to authoritatively assert they are a student of bloghampton university, let’s think about what that means:

  • Someone will need to ensure that the Facebook account really does belong to that student through a verification process. I’m assuming self-assertion would be OK but it still needs to be done.
  • The student would then need to allow the institution permission to add information to their account. This is possible in the Facebook workflow, but would mean maintaining an application just to provide information to Facebook.
  • The institution would then need to update this information regularly and more importantly REVOCATE it when the affiliation ends.
  • Service Providers that interact with these students would need to be able to extract information out of the account when needed.

All of this would be possible, but would you want to use your Facebook account in this way? Would institutions want to maintain this infrastructure and what would it cost? How would this be replicated across all the different providers that students might have accounts with and prefer to use?

Another approach is account linking, which is often used to support the problem of multiple affiliations. A personal account is in fact just another affiliation, an affiliation with yourself πŸ™‚ Technical solutions have been developed that look at this but they often throw up security concerns, permission concerns and most importantly are usually very flawed in terms of user management tools (you need a PhD to understand what you are doing). A study by Eduserv in fact concluded that maintaining separate accounts was preferable for most users against the complexity of account linking.

So I’m left wondering what point the people who tell me that ‘students use Google mail’ are trying to make. To be honest, so do I. Hotmail as well, which is my primary personal address. I’ve even become very good at only using my personal address for non-work related stuff, rather than my work e-mail. Do you really want us to find a way to add authorisation information to personal accounts? Are you talking about outsourcing rather than personal accounts, which we can already do? Or are you just looking for a way to use a more exciting topic than the mundane world of institutional account management? I don’t mind what your answer is, but I would really like to know the point πŸ™‚

4 thoughts on “Don’t confuse outsourced with personal

  1. Matthew Slowe

    I have a few thoughts on this… not entirely coherant because #idm made for quite a long day πŸ™‚

    The Logins for Life (#logins4life) project asked a similar question about account linking and found that, given the choice of being able to access their Academic (capitalisation deliberate) records via, for example, Facebook Connect, the resounding answer was fairly ambivalent — respondents being quite keen to keep “work” and “play” separate.

    If you did want to go down the “institution asserts membership but allows the user to pass that assertion on” route, this could be achieved quite easily with SSL Client Certificates being signed by the Institution and given to the user … Certificate Revocation Lists and Expiry dates would probably be enough with the third-party then responsible for validating such things… but the technical validation infrastructure is there.

  2. Eve M.

    Account linking is a great start for characterizing the problem. We’ve known forever that one IdP can’t reasonably serve as the attribute authority for everything important about you, which is why ID-WSF went to such lengths to define architectures for all the other stuff you need for a comprehensive solution for multifarious authorities.

    The only part they really hand-waved over was user authorization/consent for account link provisioning — and OAuth went and solved that part while leaving out the comprehensive bits. πŸ™‚ Getting information directly from a trusted authoritative source is the pass of least resistance compared to having to protect and sign some kind of super-duper token that has to pass through a million intermediaries.

    If you look at OAuth through the wrong end of the telescope (or something), it’s doing account linking with extremely lightweight name identifier management. I refer to the original (“three-legged”) OAuth use case as person-to-self sharing, so your “self-affiliation” description is apt!

    In the UMA work, which is OAuth-based, we’re extending the model to solve simple person-to-person and person-to-organization use cases too — true sharing with autonomous clients who aren’t “you again”. UMA attempts to define a centralized place where you can orchestrate selective data sharing among all these parties and get a global view for monitoring and control. (If you’re curious about this work, see and .)

  3. David Chadwick

    Hi Nicole

    unfortunately I think you have missed the point! You confuse authentication with authorisation and the value that distributed authz can bring to the party. Today the same user authenticates to different sites using different un/pws. It is always the same user who is authenticating but none of the sites know this. So each site then authorises the same user differently, using their own local mechanism. What the user wants is the possibility of homogeneity so that each site can authorise him as the same privileged user (if he wishes this) and grant him privileges appropriate to his (group) identity. A credit card is such an authz token today in the physical world. A user can present the same authz token to multiple shops and get the same privileged service in each outlet. Imagine the problems that would be created today if each shop granted different privileges to different holders of the same type of credit card.

    SSO does not provide the homogeneous authz that we want. Whilst it allows the same un/pw to be used by multiple services, it does not grant homogeneous privileges. Attribute based authz on the other hand does, since it allows the same attribute from a single attribute authority to be used by multiple services to authorise the user. So a University of Wherever Staff member attribute issued by the university and presented to multiple services will give the user homogeneous privileges at all the sites that provide services to university staff. These privileges will be the same as those granted to all the other members of his/her group.

    How does this relate to your Facebook example. In this way. If the user has provably linked her Facebook account to her university account, then she can go to multiple service sites, using Facebook SSO and in addition, a signed attribute from her university will be presented that will grant her the privileges of university membership. that she would not enjoy if she had not linked her accounts together. This privilege is not dependent upon the Facebook login, per se, since this only provides authentication (she could have used Twitter, Google or a dozen other sites for authentication if she had first linked this to her university account). The privilege is dependent upon the university’s attribute assertion. Looking to the future, when other validated attributes will be issued by various authorities, such as credit card issuers, driving license authorities etc. by linking these other accounts to her Facebook account she can SSO to multiple services and prove that she is a member of the university, has a full driving license and a valid credit card. Such a system is available and usable today. A public demo is available at my research web site (URL specifically not provided here since it is due to migrate shortly to a new address, but please email me for the current one if you are interested).

    A final note to Eve: whilst OAuth provides a solution for delegation of authority from a user to a third party, it does not provide, as far as I can see, a solution to account linking and the use of multiple attribute assertions from multiple authorities for authorization purposes. And UMA does not provide it either.

  4. nicole Post author

    David, I think your analaogy falls apart very quickly. It is true that a credit card is accepted at lots of places, but it has to be authorised by the bank and it is the bank we ultimately have the trust in. That matches my scenario absolutely – only a bank can authorise my credit card, only an institution can securely guarantee the user’s right to access resources. In fact, your bank analogy perfectly describes federated access management with institutions acting as the ‘bank of access rights’ and giving out ‘credentials as credit cards’ so I’m not sure where you think I have got it wrong. In fact, my institutional credentials mean I don’t HAVE to get my credit card out when I want to use expensive publisher resources, so they are very valuable! Also, people DO get given different access rights with the same sort of credit card…credit limits vary widely.

    This leaves us with a need to somehow ‘link and share’ this information with credentials from other places if we don’t want to use an institutional credential. As I mention in my post this is perfectly possible, I just haven’t seen a solution that is secure enough AND useable enough and both will be required to even begin this process – and yes I have seen your demo πŸ™‚ I also haven’t seen enough research or evidence that this is a problem that is worth investing the sums needed to make it useable enough and secure enough…and I guess that is the crux. It would be great if people could do all these things, but I wouldn’t recommend that our limited resources are spent in this way at the moment.

    The overall point of my post is that lots of people think you can just replace an institutional ID with a Facebook ID and it will just work. Clearly, it really doesn’t.

Comments are closed.