The Shibboleth Working Group is not the natural habitat for policy focused people like me. Apologies, but we are about to get technical.

Chad La Joie (shibboleth IdP architect guru) is talking about shibboleth 2.1 and new features: particularly the introduction of the ability to explicitly deny the release of certain attributes. 2.1 should be out sometime this week. The usual question has come up - is now the right time to upgrade from 1.3?? Internet2 are keen to move people across to shib2 and of course this will have the benefits offered by SAML2, but it seems to me that most people in the UK federation can happily stay on 1.3 for now.

Now we are talking about the inability to stop people from doing dumb things - the over-riding message being doAn’t ignore the things in bright red boxes in the installation guides on the Internet2 spaces wiki. Back-ups, change-logs also good

The wiki is also the place to look at the Shib2.2 roadmap.

User Consent is again the hot topic for shib2.2. Shib2.2 will have user consent attribute release capabilities based on the SWITCH Arpviewer that i mentioned a couple of weeks ago.

The rest of the session was covered by Scott Cantor who looks after the SP side of shib. Not so many new features on the SP side but a lot of bug fixing (mostly working through Apache bugs!).

The final slot looked at something that has been on the wish-list for sometime: n-tier access. This is still something that is being scoped and is not a promised feature, but the shib team is working on a use-case based around delegation in u-portal. It looks like this will be interesting stuff to track. Some of the questions include SOAP or REST?, links to Kerberos (more important in the US than back home), links to Info Cards, and the emergence of OAuth. More information on the Shib2.2 Roadmap.

The first update from the Internet2 Fall Member meeting, in New Orleans this time. This is the first formal session that I am attending at the meeting although I was at a general update on ‘Federation Soup’ yesterday (how we manage the relationships between different federations across different sectors) and have also managed to fit in a bit of sightseeing!

The InCommon forum is an opportunity for the members of InCommon to talk about their campus implementations of Shibboleth and other federated solutions. Some of the problems are very similar to the UK, although the primary usage drivers for US institutions tend to be internal applications and not commercial third-party resources. Shibboleth was after all initially designed for those scenarios and not the library-focused application that we see in the UK. This is a refreshing reminder after a couple of weeks of people arguing with me that shib is not designed for use with repositories, VLEs etc. etc.

Examples of use-cases include an upcoming implementation for Students Only. This is a site that allows cheap tickets for college students and staff. It uses shibboleth to ascertain a students affiliation to an institution - similar to the Microsoft DreamSpark application in the UK. This cuts down the need for the company to have to directly contact the registrars office at institutions. A three step verification process becomes a one step verification process.

Students are asked to commit to a Privacy Policy with the company. This brings up the questions that I’m hearing all the time at the moment: how do we get consent from students? is it an IdP or SP responsibility? how often does this consent need to be reverified?

The need for accuracy of name came up as well: airline tickets require the formal name of a person (e.g. Robert) and not diminutives (e.g. Bob). Can this be provided by the IdP?

A typo led this presentation to talk about ‘Walk Tough with Shibboleth’. Chuck Norris will now be used to promote shib applications….

Other examples include Research1, a research community with you-tube / facebook like applications.

The structure of InCommon was also discussed. InCommon is different from the UK federation in that it only has one member: Internet2. All other organisations are participants. The member has the power to shutdown Incommon, but has few other rights. The Funding Councils have a similar right in the UK under section 9.2.2 of the Federation Policy document. The idea of both of these structures is to protect the interests of the initial funding organisations and the institutions associated with them. The question was raised regarding institutions and other organisations that join InCommon and the UK federation - how are their interests protected? Should commercial SPs have a representative on the Federation Board for example?

The question is slightly different with InCommon (which charges membership fees) and the UK federation (which does not charge membership fees) but is still interesting to look at.