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.