Federations and Trust Transports

Overview from the "Federations-in-higher-education" BoF at the 2nd Annual PKI Research Workshop
(Jointly sponsored by NIH, NIST, and Internet2, in cooperation with USENIX, the PKI Forum and IFIP TC8)

The federations-in-higher-education BoF addressed two main issues:

1. *What should the InCommon federation use for trust transport?*

The two alternatives discussed were a PKI structure rooted in a central higher-education CA, and packages of certs wrapped in signed XML metadata. Advantages of the PKI model are:

• it provides a ready means of enforcing rules on federations
• establishing the CA is not that much extra work on top of everything that has to be done to establish federation membership anyway
• the ex-CREN CA is available to be adapted for this purpose, and
• once a central CA is up and running, other uses, such as S/MIME, are likely to be found for it. (In this connection Peter Honeyman suggested that "the question of what's useful, isn't useful -- it's a question of what's necessary", and there was a general sense that encrypted mail -- e.g. for medical or insurance documents -- is more likely to meet this criterion than signed mail. Sean Smith argued that S/MIME isn't likely to go anywhere in the university environment until it includes authorization; he noted that he hardly ever gets email from deans, but often gets "The dean says..." email from deans' administrative assistants.)

The chief advantage of the metadata model is its simplicity; it avoids the difficult coding problems inherent in PKI, e.g. handling path validation. Eric Norman described the metadata approach as a reinvention of the host table. Scott accepted this analogy but pointed out that, unlike hosts in a static table, the certs could be looked up in directories and pushed out dynamically. Liberty has developed a "metadata resolution protocol" that enables the "host table" to be implemented as a distributed directory, instead of one big file; this makes the metadata model more scalable than the host table analogy would suggest. See http://www.projectliberty.org/specs/draft-lib-arch-metadata-v1.0-06.pdf and http://www.projectliberty.org/specs/draft-arch-metadata-schema.xsd for more on Liberty's approach to metadata.

2. *How big a problem is federation proliferation?*

There is general agreement that having a large number of federations can't scale over the long term, but disagreement over how much we need to worry about this in the short term. It seems likely that there will be a tendency for everyone to want their own federation. The higher the cost of federation membership, the more likely that people will want to create their own. But, as Scott Cantor pointed out, it's hard to run a federation. This will counterbalance the tendency to proliferation, but where will these tendencies balance? Can a balance be struck which avoids both (on the one hand) having an unmanageable number of federations, and (on the other hand) having too little flexibility in choice of policy?

Peter Honeyman (University of Michigan) staked out an extreme position on both questions: "every association a federation, everyone a CA" -- and, in order to obviate the resulting revocation concerns -- "everything ephemeral". Peter argued that this could scale for long enough to establish federated security as a going concern; in support of this one attendee noted that "I don't talk to five billion people."

Krishna Sankar (Cisco Systems) introduced the Transports for Trust panel with a selection of definitions of trust, emphasizing that trust is multidimensional, dynamic, and context-dependent. [Presentation: Trust Transport Technologies ]

Irving Reid (Baltimore Technologies) surveyed trust models and argued for an approach combining shared policy services with support for a variety of trust transports. [Presentation: Transports for Trust]

Scott Cantor (Ohio State University) gave an overview of Shibboleth, including a one-slide snapshot of Shibboleth's use of SSL. [Presentation: Shibboleth, SAML, and PK(I/i) Shibboleth, SAML, and PK(I/i)]

Slava Kavsan (RSA/Liberty Alliance) outlined the Liberty Alliance "circles of trust" model, mapping it to SAML and setting it in the context of a typology of trust which is developed further in a Liberty white paper, http://www.projectliberty.org/specs/draft-lib-tsp-trust-models-v1.0-14.pdf. [Presentation: Liberty Identity System role in securing Web Services]

Carlisle Adams (Entrust) gave an overview of the development of SAML and outlined projected improvements for v1.1 (incremental fixes) and 2.0 (major additions). [Presentation: SAML: What's Next?]