Identity Management

The best storytelling starts with a sense of mystery to pull you in, but what is NOT a story? This is the opening to the “teaching and storytelling using Web 2.0″ session at Educause. An exercise in the room included comments around something that is not heard, something that lacks personal engagement, something that does not have narrative. This describes a lot of the way we present information.

Of course the web was used for storytelling before web 2.0: Dreaming Methods is a good example of this. So what is the difference now? I think the real difference is a) the ease in which everyone can now communicate online without needing to understand html and b) the ability to respond to stories, which is closer to the older concept of storytelling as a community exercise.

Bringing this back to make it a bit more relevant to this blog, I’m interested in the difference between fictional storytelling and personal storytelling. As we all use web 2.0 tools, how do we build and manage our own storytelling? This is described as character 101 in this session. We have the aibility to create characters online using persona, and to also use our personas to tell non-fictional stories without necessarily revealing our identity. This creates interesting nuances, with people following and befriending fictional characters (such as meerkats from adverts) and personas of real people that are entirely disconnected from the real person behind them.

Important take away from this session for me? what we do in Web 2.0 is no different from what we have always done. We Chat. We Gossip We Relate. We Discuss. We sometimes Work. Is Web 2.0 really all that different from attending a ball at Netherfield?

OK, so I haven’t written a post for a while due to uber-travelling mode and when I do, it is completely off topic. I finally got around to having a play with Google Wave yesterday. I knew I wouldn’t get very far unless I set myself a task to manage, but luckily @simonmcleish noticed my plea for a use case and suggested we carry out a long over due interview with regard to attribute aggregration. This is something I have been known to have opinions about, so seemed like something that would keep us entertained for a while.

First impressions? Easy enough to use and as we were having a two-way dialogue we were able to give each other hints on what do to. I couldn’t work out how to insert a comment half way through an existing text without prompting (double click on the words before you want to add a comment, not the white space after!). It was also convenient for the task at hand as we both had several other things to do that day and were able to have a fairly in-depth interview whilst popping out and taking phonecalls. Convenience marks – good. A good way to have a discussion online? Probably yes.

We didn’t try to upload files or anything like that so i can’t comment on this experience but again, assume this would be quite a convenient way to collaborate on files. However, I’m not sure it would be any more useful than several other collaboration tools that are out there.

Would I use Wave as a primary communication tool? Probably not. I like the fact that my e-mail address expresses my affiliation and therefore I can speak from it with a certain amount of authority. My Google account (particularly as I don’t use my name in my Google identity) really says nothing about me. Simon brought this up at the beginning of the interview, given that we were talking about verified identities! I also do not want to be limited to finding out what everyone’s Google Wave ID is – I have a nightmare of my e-mail signature getting longer and longer (phone, fax, mobile, twitter, skype, Google Wave, blog….).

As an IM tool? Google Wave has the same drawbacks as all other IM tools in that they are limited to accounts within the same system (with the exception of tools such as Pidgin, where you lose functionality instead). The market is already well covered and again, I have no incentive to really establish my identity in Google Wave other than, say, MSN.

A good collaboration tool? Google Wave is this and I imagine we will see it grow and improve. I already regularly use Google Docs with my team because of the convenience it offers and I guess I will pop in to Wave should it offer us functionality we need at certain points in time. As a communication tool? No thanks, not really ready to ride the Wave as yet.

David Kennedy from Duke presented an incommon sponsered study concerning vendor (what Yanks call Service Providers) best practice regarding access management. Interesting to see how some common themes aligned with our publisher study and it supports us in making arguments to publishers from both sides of the Atlantic.

Up very early this morning to chair a meeting on the Publisher Interface Study. A very simple proposition really – how do we improve the user experience when logging in with federated access, and can we get international agreement on this position?

Mark’s presentation is a very good overview of some of the differences of approach that we are dealing with and have to improve if we are not going to disenfranchise users.

Rhys Smith, who carried out the study on behalf of Cardiff University and Kidderminster College had a very simple message:

Users do not want to understand what is going on. They want to get to the content as quickly and easily as possible. Do not try and describe it, users won’t understand it. Users want one simple term they can learn and look for.

One of the big problems that was discussed was that academic users are not necessarily the main customer base for a lot of publishers. People queried why these publishers don’t consider using OpenID rather than providing usernames and passwords themselves. It may be worth promoting this as a focus alongside the use of an educational log-in process (OpenID / eduID?). Can we work with Kantara to provide a combined voice of federated technologies (including OpenID, Apple, Microsoft, Google) to talk to browser vendors to implement a cookie approach?

This is a much loftier aim than improving the current user experience on Service Providers, which we will take forward regardless….but it does seem possible that all of the new access management technologies have a real opportunity to work together.

This morning at Internet2 started with me and a very croaky throat talking about the work the UK federation is undertaking with the Government Gateway to solve an issue related to parental access to children’s records held at schools.

I was followed by Bob Morgan talking about the far more complex interactions with the US Government. This picked up on my post about the current administration in the US being very interested in social networking and identity.

A simple question comes out of this session – who should provide my citizen ID? In the same way that we have questioned the provision of credentials by institutions within Higher and Further education, is there any need for the Government to act as an Identity Provider for transactions currently managed by the Government Gateway or could commercial systems be used instead?

A big concern is the ability to provide complete trust in systems such as Facebook in terms of establishing the true identity of an individual. Bob highlighted that trust in these scenarios is often established via network of peers who will associate themselves with an entity or not depending on their trust in the ‘true’ identity of the persona being presented. This is very different from the trust in an affiliated institution that is established by federations – but is an interesting concept to consider.

I’ve also spoken before about not reinventing the wheel when it comes to identity assurance profiles, and it seems like the Kantara Assurance work may be worth investigating for the UK federation InCommon will be seeking to be verified via this route.

Hitting the ground running at Internet2 by diving straight in to the technical with the Shibboleth Working Group Meeting. So far San Antonio has been a surprise – certainly nothing like the other venues used by Internet2 over the years.

Shib 2.2 as a release on the SP side primarily provided a response to security incidents that happened over the summer. Otherwise, the main features are delegation, support for xml-valued attribute data, metadata tagging (something the UK federation has been doing for some time), simple attribute aggregation (which will be important as we move forward with the ‘interfederation’ process, and advanced metadata signature processes (good for the signer, good for security).

The meeting moved on to a discussion on user consent, and the importance of consent being built in to the shib codebase. Consent is still a topic that is wide open for discussion within federated access, but tools are emerging such as the Swiss UApprove and to some extent use of OAuth. A per-transaction consent module within shib could be taken forward, but is it the best place for it??

Hand in hand with this comes the idea of handing the same TargetedID across a group of services, as opposed to a particular service. The current IdP implementation does not do this, but the next release is likely to do exactly this. This is interesting for the UK, as I have had several SPs ask me for this functionality as a preference to using PrincipleName. It will be interesting to see what the people concerned with Personally Identifiable Information (PII) will say about this change!

Discussions moved on to ‘interfederation’. One of the important places to start when thinking about interfederation is that federations do not ‘own’ entities and the entities themselves have no real concept of the construct that is a federation. This, and the standards basis of SAML2, makes entities highly mobile. One of the ways of dealing with the interfederation question is to look at metadata aggregation. In this module:

• Metadata registrars take on the technical trust (e.g. registering an entity).
• ‘Federations’ then deal with behavioural trust (e.g. policies for a specific community).
• Registrars and federations MAY be colocated.
• Federations can use multiple registrars to create a metadata aggregation with specific processes wrapped around it for the community requirements.

Metadata ‘richness’ was then discussed. Metadata aggregation should be able to cope with this, but it is important that policy is not implemented at this level – for example metadata extensions could point to policies, but should never direct them.

JISC Collections have a blog now running. Slightly strange as I’ll be posting on this one and the JC blog. It feels like I need identity management not just for access to multiple wordpress sites but for my own head. Different blogs, different styles, different things you can / should say. Anyone who follows Brian Kellys blog will have seen those issues discussed before – I for one await the day when our overlords put chips in our heads that will deal with attribute release and role management in my brain.

Inspired by a discussion on twitter, I find myself once more in the position of having to explain why I am not a fan of the use of proxy referral services in libraries. I should start by saying that I am not a fan of the typical trend of using IP access on library campuses and it is the general move away from any sort of IP-based system that I am actually promoting. I also completely understand why libraries like to use them – the best known proxy products are quick, clean and easy to implement and maintain.

Sometime ago, JSTOR took a strong position on the use of proxy servers, noting:

Without special configuration, these proxy servers often have no access restrictions in place. If the computer is within a range of IP addresses that have access to JSTOR, then the result is that literally anyone in the world can use that proxy server to enter JSTOR, as well as other licensed electronic products and restricted campus resources. It is important to note that this is not a fault of any institution or library, but a weakness inherent in the current system of using IP addresses for authentication to restricted resources.

Now, most library proxies are well enough set-up that they are not providing an open proxy access route. However, easy to set up can sometimes mean sloppily set up, particularly in the use of administrative passwords. We have had many examples of the administrative passwords to proxy servers being made available freely on the internet. So if you are going to use a proxy, make sure that administrative passwords are well looked after and frequently changed – they provide access to nearly ALL your resources!

My second point is that proxies are often set-up without much thought to the credentials being used with the proxy server. Sometimes, only a small set of credentials are used or credentials that a user would have no qualms in sharing. So again, if you are setting up a proxy server tie-in a sensible credential option such as local authentication using shibboleth to increase security.

Thirdly, I just don’t like something that pretends to be something it is not. When using the proxy service, you are basically claiming to be visiting the Service Providers in question from an agreed set of IP addresses ‘owned’ by an institution. In reality, you could be on any computer anywhere in the world. There are a host of security issues that have been caused from such a set up.

Fourthly, there is the problem of accounting and statistics. It is very difficult to provide authoritative data on resource use from proxy servers, or from IP access for that matter! In a time where we need to justify spending constantly, it seems that better resource usage statistics can only be a good thing. I’ve heard this as an argument away from proxies from Service Providers as well – they would like to better understand the market they are serving rather than just receiving access requests from an IP-range.

Finally, there is the user experience. Proxies mirror IP access and plain old IP access routes don’t offer much added value for the user such as personalisation etc.

I really do understand why libraries use proxies, and why they continue to use IP access on-site. There is a particular job of work to be done with US-based publishers on pushing the advantages of more sophisticated access routes and moving away from IP-based licenses. We continue to work with publishers. In the meantime, I hope it is OK if I continue to see the place and role of proxies, but continue to shudder and dislike them. Maybe I am just suffering from access management OCD.

In the meantime, maybe you can tell me why on-site IP access is really a good thing for the user??

Understandably over the last couple of years there has been a slow shift in the access management community to talk more about identity management than access management. The two definitely come hand in hand, but I think we need to be careful about what we actually mean when we use the terms. A trend has started which takes the term federated access and replaces it wholesale with federated identity. I think this is a mistake, as I think the two are actually very different things.

Federated access is all about allowing disparate systems to make use of the same access credentials. It makes use of identity information to ensure that the correct authorisation decisions are made – but at the end of the day its primary focus is on ensuring that users are effectively connected to the resources and services that they require access to.

The entry on wikipedia for federated identity is interesting:

In information technology, federated identity has two general meanings:

• The virtual reunion, or assembled identity, of a person’s user information (or principal), stored across multiple distinct identity management systems. Data are joined together by use of the common token, usually the user name.
• A user’s authentication process across multiple IT systems or even organizations.

I don’t agree with this. I think the first point describes federated identity very well. I think the second point describes federated access. The main difference is that federated access as currently used tends to a) rely on one identity source and b) focuses on access provision rather than identity information. A federated identity system should take us in to the world of multiple identity sources providing both access and identity solutions – such as managing personalisation features, loyalty schemes, recommmendations etc.

Whilst we have federated access in place within the UK, federated identity is definitely the next step. We need to be able to allow users to call identity information from different places and we need to be able to effectively combine user-managed identities with affiliation-managed identities. Technologies like Information Cards are an interesting step on this path – but are still complex for end-users to navigate. I still think there is a different technological solution around the corner that may help us more effectively tackle this challenge…and will wait with interest to see it!

In the meantime, don’t forget that JISC is looking for projects under its latest innovation call. These could tackle both federated access and federated identity and who knows, may produce that illusive new direction!

It is probably not surprising that the current White House is interested in identity. To some extent, Obama’s campaign was all about identity – from the need to publish his birth certificate to quieten the slightly nuttier rumour mongers to his reluctance to trade on his racial and religious background as part of his campaign.

As part of an open social White House, Obama is encouraging federal sites to make use of OpenID. Immediately, we see a bunch of major companies signing up to be OpenID identity providers. Of course, it is actual in the interests of all of these companies to be identity providers – there is a significant value to be had in identity information and companies would much rather manage these identities than let them be locked away behind federal identity systems. I’d be much more excited if any of these companies were properly embracing OpenIDs as consumers – and by this I mean with no need to provide additional information, register separately etc etc as we have seen with the much lauded Facebook adoption of OpenID that amounts to little more than account linking.

What is much more interesting is the announcement of the Open Identity Initiative – an initiative working with InCommon, Kantara, the OpenID Foundation and the InfoCard Foundation across a range of standards to provide efficient access routes to federal resources. This is where the benefits of working with an open standard access management solution really begins to show, and helps demonstrate how shibboleth-based federations can work well with other standards based solutions.