*FOO Conference Call*
July 16, 2003

*Participants*

Keith Hazelton -- Wisconsin (chair)
Peter Alterman -- Federal PKI Steering Committee
Steven Carmody -- Brown
Brendan Dixon -- Microsoft
Linda Elliot -- PingID
Renee Frost -- Michigan/Internet2
Rich Guida -- Johnson & Johnson
Ingrid Melve -- UNINETT
David Wasley -- UCOP

*Discussion*

CSIS

The first topic of discussion was how FOO and other work on federations relates to the ongoing work in the CSIS committee. It isn't clear how active the effort CSIS is making is, but Ingrid noted that they are potentially a very large player in the space. Peter wasn't sure what CSIS would do, but pointed out that the Federal Government wants a venue for collaboration with the private industry in the eAuthN efforts. Regardless, the group didn't feel that it would be detrimental for FOO and CSIS' committee to move in parallel, although communication is important.

Shibboleth Federation Update

As Shibboleth has moved towards real-world deployments and production environments, it has become clear that there will be a need for several types of federations to support the evolution of sites as they engage with the community. It's clear that sites won't come prepared to interoperate at a high level of assurance, and in many cases, unclear about which sites they will interoperate with and in which manner.

This led Internet2 to deploy a simple federation called InQueue to act as a holding pond for institutions working to understand and deploy Shibboleth, given that some federation functionality is virtually necessary for operation of any Shibboleth implementation. It is expected that institutions that join InQueue will later go on to join a production federation which is appropriate for the applications and communities the institution wishes to participate in.

Federation Interoperability

There is a fundamental and critical discussion ongoing to evaluate how multiple federations may interact and share various services they offer. There are several aspects of what federations do where it will be important to be able to group or bridge between them; among these are the signed representations of metadata enumerating and detailing individual federation members, the definition of the attributes and information exchanged between federation members, and provision of levels of assurance for different authentication methods.

Another important point of interoperability is provision of the trust roots and anchors that some federations may utilize. Whether a federation can be thought of as one large bridge, either in a classical trust or PKI sense, was unclear; the whole idea of the federation serving broadly as a mechanism to identify a user's security domain is very different from a bridge CA, which instead serves to negotiate levels of assurance and allow for use of keys issued within one hierarchy with relying parties in another.

One proposed method of applying PKI to Shibboleth-style federations with several proponents in the higher-ed space is to begin to use bridge CA's to bridge federations. Steven outlined a general means of doing this by adding a dynamic level of assurance to Shibboleth which would be specified based on the federation rules and authentication mechanisms used on the home campus. This would be done in addition to addition of some sort of credential converter which would be responsible for performing the mechanical manipulation and massaging of assertions to ensure interoperability. There are a number of scenarios already arising that don't require use of a means to establish the home institution, since the types of credentials (such as embedded tickets and PKI client certificates) carry that information already, meaning the set of functionality that will need to be transferable may be smaller for certain applications.

Peter generalized these concepts to a broader world of many federated applications. In this world, the application that is using the bridge is going to be responsible itself for performing the credential conversion. He sees bridges as a natural partner for the federated model because the basic goals of avoiding issuing credentials for people outside the hierarchy and making use of more flexible structures are common to both trust models.

There is another entire class of much more amorphous trust in the peer-to-peer world that needs to be understood in the context of current trust structures and institutions.